MX record priority: how mail servers pick where to deliver

Every MX record carries a number. That number decides which of your mail servers gets the message first. The rule is short, but the backup MX habit that grew around it causes more trouble than it solves.

The rule: lower number wins

The priority (RFC 5321 calls it "preference") is a number from 0 to 65535. A sending server sorts your MX records from lowest to highest and tries them in that order. The number itself means nothing; only the order matters. 0, 1 and 10 all work as "first choice".

example.com.  MX  10 mx1.example.com.   ; tried first
example.com.  MX  20 mx2.example.com.   ; tried if mx1 does not answer
example.com.  MX  30 mx3.example.net.   ; last resort

Equal priorities share the load

When two records have the same number, senders choose between them at random. Over many messages, that splits the traffic roughly in half.

example.com.  MX  10 mx-a.example.com.
example.com.  MX  10 mx-b.example.com.

Both servers must deliver to the same mailboxes, or be able to hand mail to the final store, for this to work. Big providers do this behind one hostname, which is why they often need only one MX record.

What happens when the primary is down

If the server with the lowest number refuses the connection or times out, the sender tries the next one. If every MX fails, the message is not lost. It goes into the sender’s queue, and RFC 5321 says the sender should keep retrying, at least 30 minutes apart, for at least four to five days before giving up with a bounce.

So a few hours of downtime on a single-MX domain usually means delayed mail, not lost mail. A short outage is a bad reason to add a backup MX.

The backup MX trap

A secondary MX with a higher number used to be standard advice. Today it often makes things worse:

• Spammers aim for it. They know backup servers often skip the spam filtering and recipient checks of the primary, so they deliver straight to the highest number.
• Backscatter. A backup that accepts mail for any address and later finds the mailbox does not exist sends bounces to forged senders. That can get your server listed on blacklists.
• Silent drift. Nobody looks at the backup for years. Its certificate expires or its list of valid users goes stale, and you only notice when mail goes missing.

If you keep a backup MX, give it the same filtering, the same valid-recipient list and the same TLS setup as the primary. Otherwise, remove it and rely on sender retries.

Priority values for common providers

For Microsoft 365, copy the exact host from the admin center. Newer domains may be given a host under mx.microsoft instead of mail.protection.outlook.com. Full record sets are in our Google Workspace and Microsoft 365 guides.

Moving providers without losing mail

1. Lower the TTL on your MX records to 300 seconds a day ahead.
2. Create the mailboxes on the new host first.
3. Replace the old MX records with the new ones. Do not leave the old host at a lower number "just in case": it will keep getting mail.
4. Keep the old mailboxes for a few days and collect anything that arrived during the switch.

Check your MX priorities

The MX lookup shows every MX record for a domain in priority order with the IP behind each one. For many domains at once, the free mail health checker checks MX, SPF, DKIM, DMARC, STARTTLS and blacklists for up to 25 domains in one run. New to the topic? Start with what an MX record is.

Questions