The Delivery That Bounced Because of a Dot
Someone sends mail to [email protected]. It bounces:
550 5.1.2 Recipient address rejected: Domain not found
The domain exists. The website loads fine. And an MX lookup shows records published, apparently correctly.
The problem is in a place most people never look: the target hostnames in the MX records, and whether they resolve. An MX record doesn't deliver anything by itself — it points at a hostname, and that hostname has to resolve to an address before any mail moves.
What an MX Record Actually Contains
An MX record has two parts and one strict rule:
example.com. 3600 IN MX 10 mail.example.com.
↑ ↑
preference target hostname
The target must be a hostname, not an IP address. An MX pointing at 192.0.2.10 is invalid. Some DNS providers accept it in their interface; mail servers reject it.
The target must not be a CNAME. RFC 2181 is explicit: an MX target must resolve directly to A or AAAA records. Pointing an MX at a name that's a CNAME is a specification violation. Some mail servers follow it anyway; others reject the domain outright, which produces the maddening symptom of mail arriving from some senders and not others.
The trailing dot matters. In a zone file, mail.example.com without the trailing dot gets the zone name appended, producing mail.example.com.example.com. Most DNS control panels handle this for you, but hand-edited zone files bite regularly.
Checking the Full Chain
The MX Lookup shows the records:
- Enter the domain.
- Read the MX records with their preference values and targets.
Then do the second step almost everyone skips: look up each target hostname's A and AAAA records. An MX record pointing to a hostname that doesn't resolve is a broken configuration that looks completely healthy in an MX lookup alone.
The full delivery chain a sending server walks:
- Query MX for the recipient domain
- Sort results by preference, lowest first
- Resolve the lowest-preference target to A/AAAA records
- Attempt SMTP connection on port 25
- On failure, move to the next preference
A break at any step stops delivery. Steps 3 and 4 are invisible in an MX lookup.
Preference Values
Lower numbers are tried first. The values themselves are arbitrary — only the ordering matters.
example.com. MX 10 mx1.provider.net.
example.com. MX 20 mx2.provider.net.
example.com. MX 30 backup.provider.net.
Equal preference means load balancing. Two records at preference 10 are tried in effectively random order, distributing connections.
Conventional spacing is 10, 20, 30 rather than 1, 2, 3 — leaving room to insert a record between existing ones without renumbering everything.
The backup MX problem
A common piece of legacy advice is to add a low-priority backup MX at a different provider. It's worse advice than it sounds.
Spammers frequently target the highest preference value deliberately, on the assumption that backup servers have weaker filtering than primary ones. A backup MX that accepts mail and forwards it to the primary can become a spam relay into your own network, bypassing whatever filtering sits in front of the primary.
If you run a backup MX, it needs the same filtering and the same recipient validation as the primary. If you can't guarantee that, you're generally better off without one — modern sending servers queue and retry for days, so a few hours of primary downtime doesn't lose mail.
The Null MX
For any domain that doesn't receive email, there's a specific record that says so:
example.com. IN MX 0 .
Preference 0, target a single dot. Defined in RFC 7505, it means "this domain accepts no mail."
Why it matters:
Faster bounces. A sender sees an immediate permanent failure instead of retrying for days.
Reduced backscatter. Without it, a sending server may fall back to the domain's A record and attempt delivery to your web server.
Anti-spoofing hardening. Combined with v=spf1 -all and a DMARC policy of p=reject, it forms the standard three-record hardening set for a non-sending, non-receiving domain.
Any domain you own that exists only for redirects, brand protection, or a marketing microsite should have this. It costs nothing and there's no rollout risk, because there's no legitimate mail to break.
The Implicit MX Fallback
If a domain has no MX records at all, sending servers fall back to its A or AAAA record and attempt SMTP there.
This behaviour is why a domain with a website and no MX records can produce confusing bounces — the sender tries to deliver to your web server, which either refuses the connection or, if something is listening on port 25, does something unexpected.
The null MX exists precisely to disable this fallback explicitly.
Migration Sequence
Changing mail providers is where MX misconfiguration bites hardest, because the failure window is real mail being lost.
The safe order:
1. Lower TTLs first. Days ahead of the change, drop MX TTLs to 300 seconds. This is the step that determines how fast you can roll back. A 24-hour TTL means a mistake persists for 24 hours in some caches.
2. Set up and verify the new provider fully before touching DNS. Mailboxes created, domain verified, SPF and DKIM configured.
3. Add the new MX records at a higher preference number than the existing ones. Mail continues flowing to the old provider; the new one is a fallback you can test.
4. Send test mail and verify delivery paths.
5. Swap the preferences so the new provider is lowest.
6. Leave the old records in place at high preference for several days. Sending servers with cached records will still reach a working destination.
7. Remove the old records once traffic has fully shifted.
8. Raise TTLs back to something sensible — 3600 or higher.
The mistake that loses mail is deleting the old records at the same moment you add the new ones. Any sender holding a cached copy of the old records tries a destination that no longer accepts mail.
Diagnosing Common Failures
"Domain not found" / 5.1.2. MX records missing, or the target hostname doesn't resolve. Check both.
Mail delivers from some senders, not others. Classic symptom of an MX target that's a CNAME. Servers differ in whether they tolerate it.
Timeouts rather than rejections. The hostname resolves but nothing is listening on port 25, or a firewall is dropping the connection.
Mail arriving at the old provider after migration. Cached MX records with a long TTL. Wait for expiry; there's nothing else to do.
Intermittent delays. Often a lowest-preference server that's unreachable, causing every sender to time out on it before falling through to the next.
Practical Tips
Always resolve the MX targets, not just the MX records. This is the check that catches the most failures.
Never point an MX at a CNAME or an IP address.
Use conventional preference spacing so you can insert records later without renumbering.
Publish a null MX on every domain that doesn't receive mail. Including parked domains and redirect domains.
Keep MX TTLs moderate — an hour is reasonable — and lower them before planned changes.
Verify from outside your network. Internal DNS may resolve differently, which hides problems external senders hit.
Check both A and AAAA on targets. A hostname with a broken AAAA record causes failures for IPv6-capable senders while working fine for others.
FAQ
Can an MX record point to an IP address? No. The target must be a hostname that resolves to A or AAAA records.
Can an MX target be a CNAME? It shouldn't be. RFC 2181 prohibits it, and behaviour varies between mail servers, producing inconsistent delivery.
What does the preference number mean? Lower is tried first. The absolute values are arbitrary; only relative order matters. Equal values load balance.
Should I have a backup MX? Usually not, unless it has identical filtering and recipient validation. Sending servers retry for days, and a weakly-filtered backup is a known spam vector.
What is a null MX?
An MX record with preference 0 and a target of ., declaring that a domain accepts no mail. Produces immediate bounces and prevents the A-record fallback.
What happens if a domain has no MX records? Sending servers fall back to the domain's A or AAAA record and attempt delivery there.
The Takeaway
An MX record is a pointer, and most MX failures are failures of what it points at rather than the record itself. Resolve the targets, confirm they're not CNAMEs, publish a null MX on everything that doesn't receive mail, and lower TTLs before any migration — that covers nearly every way this breaks.
Check any domain's mail server records free with the MX Lookup at sadiqbd.com — no sign-up, instant results.
