Every MX record carries a number in front of its hostname, and that number decides the order in which sending mail servers try your mail hosts. It is called the preference value, though almost everyone says priority, and the rule is the opposite of what intuition suggests: the lowest number is tried first. Understanding how that ordering works, and what a backup MX does once you add one, is the difference between resilient mail and a quietly broken setup that leaks spam or loses messages. Here is how MX priority actually behaves and when a secondary server earns its place.
What the priority number means
An MX record has two parts: a preference value and a mail exchanger hostname. When another server has mail for your domain, it looks up all your MX records, sorts them by preference from lowest to highest, and attempts delivery to the lowest-numbered host first. If that host is unreachable, it moves to the next. The numbers themselves are arbitrary; only their relative order matters, so 10 and 20 behave exactly like 1 and 2.
| Preference | Mail exchanger | Role |
|---|---|---|
| 10 | mx1.example.com | Primary, tried first |
| 20 | mx2.example.com | Secondary, tried if primary fails |
| 30 | mx3.example.com | Tertiary fallback |
You can see the ordering with a simple query. The number printed before each hostname is the preference:
$ dig MX example.com +short
10 mx1.example.com.
20 mx2.example.com.
30 mx3.example.com.Equal priorities mean load balancing
When two or more MX records share the same preference value, the sending server picks among them at random, which spreads inbound mail roughly evenly across those hosts. This is how large providers distribute load. Google Workspace's legacy record set, for example, uses several hosts at matching values so that no single server carries everything.
$ dig MX example.com +short
10 mxa.example.com.
10 mxb.example.com.
20 mx-backup.example.com.Here mxa and mxb share the load at preference 10, and mx-backup only receives mail if both of the primaries are down.
What a backup MX actually does
A backup MX is simply a mail server listed at a higher preference number than your primary. When the primary is unreachable, sending servers deliver to the backup instead. The backup is expected to queue the mail and forward it to the primary once the primary comes back. In theory this prevents mail loss during an outage.
In practice, modern sending servers already do this for you. By the standard, a sender that cannot reach any of your MX hosts must queue the message and keep retrying, typically for several days, before giving up and returning it. A short outage of a few hours therefore does not lose mail even if you have no backup MX at all, because the sender holds the message and tries again later. This is the key reason backup MX is far less necessary than it once was.
The idea dates from an era when mail servers and network links were far less reliable, home and office connections dropped for long stretches, and holding a queue on a nearby always-on relay genuinely reduced loss. Today, cloud mail platforms run their own redundant accepting infrastructure, and the retry-and-queue behavior on the sending side is dependable. That shift is why a setup that once looked prudent now often adds risk without adding much protection.
When a backup MX still helps
There are genuine cases where a secondary mail exchanger adds value:
- Long or frequent primary outages. If your primary is down for days rather than hours, a backup that queues locally can shorten the delay seen by senders whose retry windows are short.
- Spam and virus pre-filtering. Some organizations route all inbound mail through a filtering service listed as the primary MX, with their own server as a lower-preference backup, so every message is scanned first.
- Geographic redundancy at scale. Large senders run multiple accepting hosts in different regions, usually at equal preference, so a regional network failure does not stop inbound mail.
The backscatter and spam risks
A poorly run backup MX can do more harm than good. The classic failure is backscatter. If your backup accepts mail for any recipient at your domain, queues it, and only later discovers the address does not exist when it tries to hand off to the primary, it is now stuck with an undeliverable message. It then generates a bounce back to the sender address, which spammers forge, so your backup ends up blasting bounces at innocent third parties. That gets your backup's IP listed on blocklists.
| Risk | Cause | Mitigation |
|---|---|---|
| Backscatter | Backup accepts then bounces unknown recipients | Backup must share the primary's valid-recipient list |
| Spam magnet | Spammers target the higher MX expecting weaker filtering | Apply identical filtering on every MX |
| Open relay | Backup misconfigured to forward anything | Restrict relay to your domains only |
The rule that prevents all three: a backup MX must enforce exactly the same recipient validation and spam filtering as the primary. If it cannot verify recipients, it should not exist.
A note on the null MX
If a domain does not receive mail at all, the correct signal is not an absent MX record but a null MX: a single record with preference 0 and a hostname of just a dot. It tells senders immediately that the domain accepts no mail, so they fail fast instead of falling back to the domain's A record.
$ dig MX no-mail.example.com +short
0 .Practical recommendations
- For most organizations, run one primary MX, or several at equal preference through your provider, and skip the backup. Sender retry already protects you from short outages.
- If you add a backup, make sure it validates recipients and filters spam identically to the primary.
- Leave clear gaps between preference numbers (10, 20, 30) so you can insert a host later without renumbering.
- Publish a null MX on any domain that only sends, or does nothing, to stop spoofing and misdirected mail.
Confirm your MX order resolves correctly
MX ordering problems are invisible until a server is down and mail starts arriving somewhere unexpected, and a local query only reflects one resolver. After changing any MX record, run your domain through the Valla DNS propagation checker to confirm the preference values and hostnames have gone live consistently across regions. From there, our guides on SPF qualifiers and on reverse DNS for mail servers will help you make sure every host you list is one receivers will actually trust. Set your preferences deliberately, verify them, and your inbound mail routes exactly where you intend.
Backup MX services: picking the best one, and the reseller angle
If you have decided you genuinely need a secondary mail exchanger, the next question is whether to run it yourself or buy a backup MX service. A hosted backup MX is a third party that lists itself at a higher preference than your primary, queues mail when your server is unreachable, and forwards it once you are back. The best backup MX service is not the cheapest or the one with the most locations; it is the one that can enforce your exact recipient list, because a backup that accepts mail for unknown addresses is the backscatter trap described above.
When you actually need a backup MX service
- Self-hosted mail on a single connection that can be down for days rather than hours, where some senders' retry windows may expire first.
- Short-retry senders. If you exchange mail with systems that give up quickly, a queue that holds and re-forwards buys you time.
- You cannot add a second accepting host at equal preference through your own provider, which is the cleaner solution when it is available.
Cloud mail platforms such as Google Workspace and Microsoft 365 already run redundant accepting infrastructure, so for them a third-party backup MX adds risk without adding protection. Skip it.
The reseller angle
Hosting resellers and managed-service providers often bundle a backup MX across all their clients from one filtering platform. That can be efficient, but it concentrates risk: one wrong recipient-verification setting turns every client domain into a backscatter source at once. If you buy backup MX through a reseller, confirm the service does recipient callouts or syncs a valid-address list per domain, not a blanket accept-and-queue.
| Question to ask a backup MX service | The answer you want |
|---|---|
| Does it verify valid recipients? | Yes, per domain, before accepting |
| Does it filter spam identically to the primary? | Yes |
| How long does it queue undeliverable mail? | Several days, matching normal sender retries |
Is a backup MX service worth it for a small business?
Usually no. If your mail runs on a modern cloud platform, sender retry plus the platform's own redundancy already cover short outages. Reserve a backup MX service for self-hosted mail on a fragile connection, and only with strict recipient verification.
Whichever hosts you list, confirm the preference order and hostnames resolve consistently everywhere with the Valla DNS DNS lookup tool before you rely on the failover.