A private tutor had a free webmail address on her business cards and wanted something with her own name on it. Parents were occasionally hesitant about writing to an address that looked like a teenager's, and she had heard that a proper domain would look more serious. So she bought a domain and signed up for hosting, and then spent an evening confused about why mail still did not work.
The website had been connected through the domain's nameservers, and she could see the new homepage in her browser. But nobody had added the mail records, so messages had nowhere to go. She did not know what an MX record was, and the control panel presented her with a dozen tabs that all looked equally important.
A support agent walked her through adding the records, SPF and DKIM. By midnight she had her first test message arriving in a new inbox, and it went to spam, which led to the next evening's lesson. This is a composite, but the evening is one that support teams recognise at once.
Where she started
Her plan was reasonable. She registered example.com through the same company that sold her the hosting, chose a plan that included email, and followed the welcome message. It asked her to change the nameservers on the domain to the two the host supplied, and she did. Within an hour the site loaded.
The email part seemed to follow automatically. In the control panel she found a section called "Email accounts" and created [email protected]. The panel announced that the account was ready. She sent a message from her phone's webmail address to the new address, and it never arrived. She sent another, and a bounce came back with text she could not make sense of, including something about the "recipient domain".
The bounce was not wrong. The domain was working, and the server held a mailbox, but the rest of the world did not yet know where to send mail for example.com. A website and an email service are separate things. The website is found through an address record that says "this name is at this server". Mail is found through different records called MX records, which say "mail for this domain goes to this machine".
What the missing pieces were
When nameservers are set properly, the host usually creates the website records and, if the host runs the mail as well, the mail records too. Hers had created the first but not the second. The reason was that she had bought the domain from one company and the hosting from another, and a stale set of records from the registrar's placeholder service was still in the zone.
The agent had her open the DNS zone editor and found two problems. There was no MX record at all, and an old MX record from the registrar's parking service pointed at a server that had nothing to do with her. The corrected records looked like this:
example.com. 3600 IN MX 10 mail.example.com.
mail.example.com. 3600 IN A 203.0.113.40
example.com. 3600 IN TXT "v=spf1 mx include:_spf.example.net ~all"
sel1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."Reading it from the top: the first line says mail for the domain goes to mail.example.com, with priority 10; the second tells the world the IP address of that machine; the third publishes who is allowed to send mail on the domain's behalf; and the fourth publishes a public key that lets receivers check that a message really was signed by her server.
The evening, step by step
The agent kept the instructions short, because she was tired and a little embarrassed. The sequence was:
- Delete the old placeholder MX record, since leaving two sets of mail instructions in place sends some messages to the wrong machine.
- Add the MX record for the host's mail server, using the exact name given in the welcome email.
- Check that the A record for that mail server name exists and points where the host says.
- Add the SPF record as a TXT record on the bare domain. Only one SPF record is allowed per domain, so if another existed it had to be merged, not duplicated.
- Switch on DKIM signing in the email section of the control panel, copy the public key it displayed, and add it as a TXT record under the selector name the panel specified.
- Wait for DNS to catch up. Her TTL was an hour, so the new records were visible within a few minutes at most places.
The SPF builder on this site produces the TXT line from a list of senders, which is easier than assembling it by hand. DKIM records are long and fiddly; copy and paste them, and watch for a panel that splits them across several quotes.
At a quarter to midnight she sent a message from her webmail account to the new address and watched it appear. She replied from the new inbox and, with some pride, saw that arrive too. Then she checked her old inbox and found the reply in the spam folder.
Why the first message went to spam
A brand-new domain has no history. Mailbox providers decide what to do with incoming messages partly from the sender's reputation, and a domain registered the day before has none. A message with a correct SPF record and a valid DKIM signature does well, but passing those checks does not by itself guarantee the inbox.
The missing piece was a DMARC policy, the record that tells receivers what to do when a message fails authentication and where to send reports. The major providers now expect senders to publish one. A first record is deliberately gentle:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"A policy of p=none only asks for reports and takes no action, so it is a safe starting point. After a few weeks of watching the reports and confirming that her own mail passes, she could tighten it. The DMARC builder walks through that progression.
That was the next evening's lesson, and it also covered smaller habits that help a new domain: send a few real messages to real people who will reply, avoid sending a newsletter to a hundred strangers on day one, and keep the first messages plain and personal.
What changes by hosting type
On shared hosting, the panel generally configures most of this for you, provided you use the host's nameservers. With nameservers elsewhere, as in her case, you copy the host's recommended records across by hand. On a VPS or dedicated server you run the mail system yourself, which is a bigger commitment: you configure the mail software, reverse DNS for the IP address and the whole set of records. Many people with a small business choose a hosted mailbox service for exactly that reason, and then only the DNS records remain on the domain.
What stayed with them
A website and a mailbox are separate services that happen to share a domain name. After setting up a domain, check MX, SPF, DKIM and DMARC before printing the address on anything, and send test messages to a few different providers.