MX records: the site is up and the mail is gone

An MX record has two parts: a number and a hostname. The number is a preference, lower being preferred, and the hostname is a machine that accepts mail for the domain. That is the whole format.

dig +short MX example.com
10 mail.example.com.
20 backup.example.com.

Two rules that the format does not make obvious. The right-hand side must be a hostname, never an IP address; an MX pointing at an address is invalid and some senders will refuse it outright. And equal numbers mean equal preference, so a sender picks among them at random, which is load balancing rather than failover.

None of that is where the trouble is. The trouble is that mail failures are invisible to everything you have set up to watch the site, and they arrive with a delay long enough to hide the cause.

Why this is the worst outage to detect

A web outage announces itself. Somebody loads the site, gets an error, and complains within the hour.

A mail outage is silent on both ends. The sender's server queues the message and retries for hours or days before giving up, so the bounce, if it ever comes, arrives long after the change that caused it. The recipient sees nothing, because nothing arrived, and an empty inbox looks exactly like a quiet week.

Meanwhile your uptime dashboard is green, because it is measuring the website, and the website is fine. This is the same blind spot that makes a status code a claim about a request rather than about a working business, spelled out in what a 200 does not prove. Except here the business function that broke is not even served by the machine you are checking.

The client usually finds out when a customer phones to ask why nobody answered their enquiry, which by then is three weeks of enquiries.

The three ways it breaks on client work

The migration wizard took the MX with it. This is the big one. You move a site to a new host. The new host offers to set the DNS up for you, or the registrar has a button that points the domain at the new nameservers, and either way the zone is rebuilt from a template. The template contains an MX pointing at the new host's own mail service, because that is what a template does. The client's mail, which lives at a completely different provider, is now delivered into a mailbox on the web server that nobody will ever open.

Before any nameserver change, dump the existing zone and keep it. Not the new host's idea of it, the current one:

for t in A AAAA MX TXT CNAME NS SOA SRV; do
  printf '\n;; %s\n' "$t"; dig +noall +answer "$t" example.com
done

Do that before you touch anything, paste it into the ticket, and diff it afterwards. It takes a minute and it is the single highest-value minute in a migration.

The MX points at a name that no longer resolves. A host decommissioned a server, a provider retired a hostname, a client cancelled a mail product and the record stayed. Nothing in the domain's own records looks wrong, because the record is syntactically perfect. The failure is one level down, in whether the target resolves and answers.

dig +short MX example.com | while read -r pref host; do
  printf '%-4s %-35s %s\n' "$pref" "$host" "$(dig +short A "$host" | tr '\n' ' ')"
done

An empty right-hand column is your answer.

The site's own mail was never the same thing as the client's mail. The contact form sends through the web server, from an address at the client's domain, while the domain's SPF record authorises only the mail provider. The message is technically a forgery and gets filed accordingly. Forms stop delivering, the site reports 200, the form says thank you, and the enquiries go into a spam folder nobody reviews.

That one is not an MX problem at all, which is exactly why it survives so long: everybody checks the MX, finds it correct, and stops.

Backup MX, and why the advice aged badly

The classic setup was a second MX at a higher number, on a different network, that would accept mail while the primary was down and forward it later. It was good advice when mail servers were single machines in single buildings.

It is now mostly a liability. Sending servers already queue and retry for days, so a short primary outage loses nothing. Meanwhile a secondary that accepts everything and forwards it later usually has weaker filtering than the primary, and spam senders target the higher-numbered host deliberately for that reason. You have added an entry point that accepts mail your real server would have refused, and it arrives with the secondary's own address as the sender, so it is harder to filter afterwards.

Unless you have a specific reason and a secondary configured with the same recipient validation as the primary, one MX is the better answer.

The opposite case has a proper record too. If a domain sends no mail and receives none, a parked domain or one used only for redirects, declare it explicitly with a null MX: a single record with preference 0 and a hostname of ., defined in RFC 7505. Senders then fail immediately and correctly rather than queueing for days, and it removes the domain as a spoofing target.

What to actually watch

Four checks, none expensive, and the last one is the only one that proves anything.

That the MX records exist and match what you recorded at handover, so a zone rebuild shows up as a diff rather than as a mystery. That each target hostname resolves. That the target accepts a connection on port 25 and answers with a greeting. And a canary: a real message, sent on a schedule to a real mailbox, whose absence is the alert.

Only the canary tests the thing the client cares about. The first three tell you the plumbing looks right, and mail is a domain where the plumbing looks right in almost every failure mode described above.

One last detail that turns a planned change into an unplanned outage. MX records carry a TTL like everything else, and a sending server that cached the old value will keep delivering to the old host for as long as it has left. Lower the TTL before the migration, not during it, for the same reason and with the same mechanics as every other record: propagation is not a thing, TTL is.