MX Records. Email Routing for Humans

What an MX record is

An MX (Mail Exchange) record is a DNS record on your domain that says: "to deliver mail to user@example.com, contact this host." It's the first lookup any sending mail server performs after the recipient address is parsed.

The format is simple: a priority (lower = preferred) and a hostname. A typical Google Workspace setup looks like:

example.com.  IN  MX  1   aspmx.l.google.com.
example.com.  IN  MX  5   alt1.aspmx.l.google.com.
example.com.  IN  MX  5   alt2.aspmx.l.google.com.
example.com.  IN  MX  10  alt3.aspmx.l.google.com.
example.com.  IN  MX  10  alt4.aspmx.l.google.com.

How mail routing works

When a server somewhere in the world has mail addressed to you@example.com:

1. It queries DNS for the MX records of example.com.
2. It sorts the returned records by priority, lowest first.
3. It connects to the lowest-priority host (or a random one if multiple share the lowest priority).
4. If that connection fails, it tries the next priority tier.
5. If all hosts fail, the message is queued and retried later, typically for 5 days.

Priority numbers are arbitrary integers; what matters is their relative ordering. Priority 1 vs 5 is no different from 10 vs 50, only the relative magnitudes matter.

Priorities and load balancing

Two patterns are common:

• Primary + backup: one host at priority 10, a backup at priority 20. The backup only takes mail when the primary is down.
• Cluster + tiers: multiple hosts at priority 1 (the primary cluster), more at priority 5 (the secondary cluster), more at priority 10 (the tertiary). Senders distribute load across each tier.

For most domains using a mail provider (Google, Microsoft, Fastmail, Zoho), you publish whatever records the provider gives you and don't touch the priorities.

The mistakes that break MX

1. Pointing MX at an IP address. Forbidden by RFC. Many DNS providers won't even let you do it; some do, and the mail simply doesn't get delivered. Always point to a hostname.
2. The MX hostname has no A or AAAA record. Senders look up the MX hostname's IPs as a separate step. If the hostname doesn't resolve, the MX is dead. Common when a domain is decommissioned but referenced in another domain's MX.
3. Trailing dot confusion. In zone files, mail.example.com. with a trailing dot is absolute. Without it, it's relative to the current zone. Many MX outages stem from mail.example.com being interpreted as mail.example.com.example.com.
4. Implicit MX missing. If a domain has no MX records but has an A record, some senders fall back to delivering to the A-record IP (RFC 5321). This is called "implicit MX" and it's a footgun, your web server suddenly receives SMTP traffic. Always publish explicit MX records, even if just pointing to a Null MX (0 .) to say "this domain doesn't receive mail."
5. Stale records during provider migration. When switching from Google Workspace to Microsoft 365 (or vice versa), people add the new records before deleting the old ones. Mail gets split between the two providers, half of it ends up in the wrong inbox. Plan a hard cutover.

The Null MX (RFC 7505)

If your domain doesn't receive mail at all (a marketing-only domain, a static site, etc.), publish a Null MX:

example.com.  IN  MX  0  .

The single dot tells senders "no mail server here, bounce immediately." This prevents implicit MX behavior and also tells spammers not to bother retrying for 5 days. It's the polite, modern way to say "we don't do email."

What can go wrong, and what to watch

MX records, once correctly set, tend to be stable. The breakage modes:

• Provider rotates their MX hostnames (rare but happens during major infrastructure changes).
• A DNS migration drops the records.
• Someone adds an MX during a service trial and forgets to remove it.
• The MX hostname's A record changes IPs, but the hostname stays the same, usually fine, but worth verifying after a major provider incident.

DomainsDoc checks MX records hourly: it resolves every listed MX hostname to its IPs, flags any that fail to resolve, and alerts you if the record set itself changes. Most MX issues become visible long before they cause an outage if you're watching.