MX record priority and backup MX: how they work and whether you need one

Every MX record carries a priority number, and that number decides which server gets your mail first. It also decides what happens when that server is down, and whether a forgotten "backup" record lets spam skip your filter. This guide goes deeper than our MX record basics: how senders really use the numbers, what equal priorities do, and how to decide whether a backup MX is worth having.

What is MX priority?

MX priority, also called preference, is the number in an MX record that tells sending servers which mail server to try first. RFC 1035, section 3.3.9 defines it as "a 16 bit integer which specifies the preference given to this RR among others at the same owner. Lower values are preferred." So the valid range is 0 to 65535, and 0 is the most preferred.

Example records for one domain:

example.com.  3600  IN  MX  10 mx1.example.net.
example.com.  3600  IN  MX  10 mx2.example.net.
example.com.  3600  IN  MX  50 backup.example.org.

Here mx1 and mx2 share the lowest number, so they're the primary pair. backup is tried only if neither of them accepts the message.

Some DNS panels don't ask for a number. Microsoft's Domains FAQ notes that "some label the box preference, and some label it priority", and some "ask you to select Low, Medium, or High". In those panels, High priority means a low number.

How do senders use MX priority?

Sending servers sort your MX records by preference and work up from the lowest number. RFC 5321, section 5.1 sets the rules:

1. The sender looks up all MX records. If one or more exist, it "MUST NOT utilize any address RRs associated with that name unless they are located using the MX RRs". Your web server's A record is ignored.
2. It sorts by preference. "Lower numbers are more preferred than higher ones."
3. Among records with the same preference, "the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers."
4. It tries each address "in order, until a delivery attempt succeeds." The RFC allows a configurable limit, but "the SMTP client SHOULD try at least two addresses."
5. If nothing accepts the message, the sender queues it and retries later. Our guide to what happens when your mail server is down covers retry times.

Only the order matters, not the size of the gap. Priorities 1 and 2 behave exactly like 10 and 500.

Which records count as "primary" and "backup"?

What does a backup MX actually do?

A backup MX (also called a secondary MX) is a server with a higher preference number that accepts mail while the primary is unreachable and passes it on later. RFC 5321 describes what such a relay must do with the message: it sorts the MX list, finds its own entry, and "all records at that preference level and higher-numbered ones MUST be discarded from consideration." In plain terms, a backup can only ever hand mail to a server with a lower number than its own. It holds the message and keeps retrying the primary.

That is the whole benefit: the message sits in a queue you control instead of in each sender's queue. Since sending servers already queue and retry, the benefit is smaller than it looks, unless your senders give up quickly or your outages are long.

Do Microsoft 365 and Google Workspace need a backup MX?

No. Both providers document a single MX record and run many servers behind it.

• Microsoft 365. The DNS records reference says: "You can have multiple MX records; however, that can cause problems for mail delivery. Having a single MX record that directs email to one mail system removes many potential problems." The Exchange Online MX should have a priority "lower than any other MX records (this ensures mail is delivered to Exchange Online)", and "once email is flowing to Exchange Online, you should remove the MX records that are pointing to your old system."
• Google Workspace. The MX setup page gives one record, smtp.google.com with priority 1, and says: "Remove any other MX records. Your email might not work correctly if you keep old or incorrect MX records." Older domains may still use the legacy aspmx records, which Google says are still supported.

Microsoft's Domains FAQ adds one more rule worth knowing: "If you only have one MX record, any value is fine for priority or preference."

Why can a backup MX be a security risk?

A backup MX can be a security risk because senders don't have to respect your priority order, and backup servers are usually filtered less. Two problems follow.

It bypasses your spam filter

If your primary MX points at a filtering service and a backup points anywhere else, spam can go straight to the backup. The most common case is an old record left behind after a filter was added: the filter at priority 10, and the Microsoft 365 or Google host still listed at 20. Microsoft's third-party filtering guidance says "your domain's MX record must point to your third-party service provider", and then to lock Exchange Online down "to only accept mail from your third-party service." Our guide to blocking direct-to-tenant bypass covers that lockdown for both platforms.

It creates backscatter

A backup server that doesn't know which mailboxes exist accepts mail for any address, then has to bounce the undeliverable ones later. Those bounces go to the forged sender addresses on spam: innocent third parties. The Postfix backup MX example lists the valid addresses on the backup for this reason, saying it "prevents your mail queue from filling up with undeliverable MAILER-DAEMON messages." Our guide to backscatter explains the wider problem.

When does a backup MX still make sense?

A backup MX makes sense only when all of these are true:

• You run your own primary server, for example Exchange Server or a cPanel host, and long outages are a real risk.
• The backup runs the same filtering as the primary: the same spam, malware and spoofing checks, at the same strictness.
• The backup knows your valid recipients and rejects unknown ones during the SMTP session instead of bouncing later.
• You watch it. A queue that grows quietly for days is a failure you won't see until users complain.

If you can't meet all four, solve outages at the filtering layer instead. A filtering service that holds mail while your server is down gives you the queue without the side door. iBlockSpam spools mail for up to 5 days when your mail server is unreachable, and publishes only its own hosts in your MX.

Is a second MX at the same priority a backup?

No. Two or more MX records at the same number are a load-balanced set, not a backup. Each one gets a random share of mail all the time, so each one must accept and filter mail exactly the same way. That's normal when every host belongs to the same provider, such as a filtering service that publishes mx1 and mx2 at equal priority. It's a mistake when the hosts belong to different systems, because roughly half your mail takes a different path.

How do you check and fix your MX priorities?

1. List your records. Run your domain through MX Lookup, or dig MX example.com +short on macOS or Linux, and write down every host and number.
2. Identify the owner of each host. Every MX host should belong to the system you intend to receive mail: your mailbox provider, or your filtering service.
3. Remove strays. Delete records for retired servers, old hosting accounts and any mailbox provider host sitting behind a filter.
4. Check equal priorities. Hosts that share a number must belong to the same provider and apply the same rules.
5. Check MTA-STS. If you publish an MTA-STS policy, RFC 8461 requires the MX host a sender picks to match one of the policy's mx patterns, so list every MX host, backup included. The MTA-STS Checker shows your current policy.
6. Confirm the real path. Send a test from an outside account and open the headers in the Email Header Analyzer. The hop before your mailbox should be the server you expect.

If any change moves mail to a different system, lower the TTL first and follow our MX change checklist.

Next steps

• Look up your domain with the free MX Lookup and remove any record that doesn't belong to your mailbox provider or filter.
• If you keep a backup MX, make sure it filters as strictly as the primary and rejects unknown recipients.
• If you want outage protection without a backup MX, see how filtering in front of Microsoft 365 works with iBlockSpam.

Browse our other email setup guides.