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

URL: https://iblockspam.com/blog/mx-record-priority-backup-mx
Last updated: 2026-10-22
Published: 2026-10-22
Topic: Setup guides
Author: iBlockSpam Team

> How MX priority (preference) numbers work, what equal priorities do, why a backup MX can bypass your spam filter, and when a secondary MX still makes sense.

## Short answer

MX priority, also called preference, is a number from 0 to 65535. Senders try the lowest number first and move to higher numbers only when delivery fails; equal numbers share the load at random. Most domains on Microsoft 365, Google Workspace or a filtering service need no backup MX, and an unfiltered one lets spammers bypass your filter.

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](https://iblockspam.com/blog/what-is-an-mx-record): 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](https://www.rfc-editor.org/rfc/rfc1035.html#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](https://learn.microsoft.com/en-us/microsoft-365/admin/setup/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](https://www.rfc-editor.org/rfc/rfc5321.html#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](https://iblockspam.com/blog/what-happens-to-email-when-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"?

| Setup | Example | Behavior |
|---|---|---|
| Single record | `MX 1 smtp.google.com.` | All mail goes to one host name, which the provider runs on many servers |
| Equal pair | `MX 10 mx1…` and `MX 10 mx2…` | Mail is spread at random across both; either can take everything if the other fails |
| Primary plus backup | `MX 10 mail…` and `MX 20 backup…` | The backup gets mail only when the primary fails, or when a sender deliberately skips the primary |
| Mixed providers | `MX 10 filter…` and `MX 20 tenant.mail.protection.outlook.com.` | A bypass: anything sent to the second host skips the filter |

## 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](https://learn.microsoft.com/en-us/microsoft-365/enterprise/external-domain-name-system-records) 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](https://knowledge.workspace.google.com/admin/domains/set-up-mx-records-for-google-workspace) 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](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud) 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](https://iblockspam.com/blog/block-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](https://www.postfix.org/STANDARD_CONFIGURATION_README.html) 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](https://iblockspam.com/blog/backscatter-spam-bounce-messages) 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](https://iblockspam.com/features/outage-spooling) 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](https://iblockspam.com/tools/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](https://www.rfc-editor.org/rfc/rfc8461.html) 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](https://iblockspam.com/tools/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](https://iblockspam.com/tools/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](https://iblockspam.com/blog/change-mx-records-without-losing-email).

## Next steps

- Look up your domain with the free [MX Lookup](https://iblockspam.com/tools/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](https://iblockspam.com/platforms/microsoft-365) works with iBlockSpam.

Browse our other [email setup guides](https://iblockspam.com/blog/topic/setup).

## Frequently asked questions

### What MX priority number should I use?

Use whatever your mail provider documents, for example 1 for Google Workspace's smtp.google.com. If you have a single MX record, Microsoft notes that any value works. The numbers only matter relative to each other: the lowest is tried first, and records with the same number share the load.

### What is the highest MX priority value?

The preference field is a 16-bit integer, so it ranges from 0 to 65535 (RFC 1035, section 3.3.9). Lower values are preferred, so 0 is the most preferred value a record can have. A null MX, which says a domain accepts no mail, also uses 0 with a target of a single dot.

### Can two MX records have the same priority?

Yes. RFC 5321 says that when several MX records share the same preference, the sender must pick among them at random to spread the load. Filtering services and large mail providers often publish two or more hosts at the same number for exactly this reason.

### Will mail be lost if I only have one MX record?

Usually not. If the server can't be reached, sending servers queue the message and retry. RFC 5321 says the give-up time generally needs to be at least 4-5 days, although some senders give up sooner. A single MX that names a provider running many servers behind one host name is the normal setup.

### Why do spammers send mail to my backup MX?

Because any published MX host is public, and nothing forces a sender to follow the priority order. Backup servers often have weaker filtering or no list of valid recipients, so spam sent straight to them is more likely to get through, or to create bounces that land on innocent people.

## Sources

- [RFC 5321: Simple Mail Transfer Protocol, section 5.1 (Locating the Target Host)](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1)
- [RFC 1035: Domain names, section 3.3.9 (MX RDATA format)](https://www.rfc-editor.org/rfc/rfc1035.html#section-3.3.9)
- [Microsoft Learn: Domains FAQ (What is MX priority?)](https://learn.microsoft.com/en-us/microsoft-365/admin/setup/domains-faq)
- [Microsoft Learn: External Domain Name System records for Microsoft 365](https://learn.microsoft.com/en-us/microsoft-365/enterprise/external-domain-name-system-records)
- [Google Workspace Admin Help: Set up MX records for Google Workspace](https://knowledge.workspace.google.com/admin/domains/set-up-mx-records-for-google-workspace)
- [Microsoft Learn: Manage mail flow using a third-party cloud service with Exchange Online](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud)
- [Postfix: Standard configuration examples (primary or backup MX host)](https://www.postfix.org/STANDARD_CONFIGURATION_README.html)
- [RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html)

## Free tools for this guide

- [MX Lookup](https://iblockspam.com/tools/mx-lookup): See where your mail is delivered, spot unfiltered backup MX and broken hosts.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [MTA-STS Checker](https://iblockspam.com/tools/mta-sts-checker): Fetch and validate your MTA-STS policy, match it to your MX hosts and check TLS-RPT.

---

Source: iBlockSpam, https://iblockspam.com/blog/mx-record-priority-backup-mx (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt