MX Priority Explained: How Mail Servers Decide Where Email Goes

The Number Nobody Explains Properly

Every MX record carries two pieces of information: a hostname, and a small integer sitting right next to it that most people glance past. That integer is the priority value (RFC 5321 calls it "preference"), and it is the entire routing logic for inbound email in a single field. Get it right and a domain survives a mail server outage without anyone noticing. Get it wrong — or leave every host at the same value without meaning to, or point the lowest number at a decommissioned box — and messages either pile up in a sender's retry queue or land somewhere nobody is watching.

This guide is about that number specifically: what it does mechanically inside a sending server's decision loop, how it behaves when things go wrong, and how experienced administrators actually assign it across primary and backup infrastructure. If you're looking for a general introduction to MX records as a DNS record type, our MX Record Complete Guide covers that ground; this article goes deeper specifically on the priority mechanic and the routing decisions built on top of it.

How the Preference Value Actually Works

An MX record's priority is an unsigned 16-bit integer, so it can technically be anything from 0 to 65535, though in practice almost every deployment you'll ever see uses small, round numbers: 5, 10, 20, 50. The value itself is meaningless in isolation — what matters is how it compares to the other MX priorities published for the same domain. A sending mail transfer agent (MTA) that needs to deliver a message queries the recipient domain's MX records, sorts the returned list by priority ascending, and works down that list starting from the lowest number.

Say a domain publishes three MX records: mail1.example.com at priority 10, mail2.example.com at priority 20, and mail3.example.com at priority 30. A sending server always attempts mail1 first. Only if the connection to mail1 fails outright, times out, or is refused at the SMTP protocol level does the sender move on to mail2. mail3 is essentially never touched unless both of the higher-preference hosts are unreachable. This is a strict ordering, not a suggestion — well-behaved MTAs (Postfix, Exim, Exchange, sendmail) all implement it the same way because it's specified precisely in RFC 5321 section 5.1.

What "Failure" Actually Means to a Sending Server

This is where a lot of assumptions go wrong. Administrators sometimes picture priority failover as something that only kicks in during a dramatic outage — the server is unplugged, the data center is on fire. In practice, sending MTAs treat a much broader set of conditions as reasons to try the next MX host:

• TCP connection refused — nothing is listening on port 25 at that host.
• TCP connection timeout — the host doesn't respond within the sender's connect timeout window, typically somewhere between 30 and 60 seconds depending on the MTA.
• SMTP-level 4xx or 5xx rejection during the greeting or EHLO stage — the server answered, but refused to proceed. A 421 "service not available" is common when a host is intentionally shedding load.
• STARTTLS negotiation failure — for domains enforcing MTA-STS or DANE, a broken or expired certificate on the primary host can cause the sender to abandon the attempt and fall through, depending on policy strictness.
• DNS resolution failure for the MX hostname itself — if mail1.example.com has no A or AAAA record, the sender can't even get an IP to connect to, so it moves on.

None of these require the primary server to be fully "down" in the conventional sense. A server that's alive but overloaded, mid-restart, or serving an expired TLS certificate can trigger exactly the same fallback behavior as a server that's been powered off. That's a feature, not a bug — it's precisely the resilience the priority system is designed to provide — but it means your secondary MX host will see real production traffic far more often than most people expect.

Equal Priority: Load Distribution, Not Failover

When two or more MX records share the exact same priority number, the behavior changes from strict ordering to distribution. RFC 5321 leaves the exact selection method up to the sending implementation, but the near-universal convention is randomized selection among the tied hosts, sometimes weighted, sometimes not. Google Workspace's default MX set is the textbook example of this pattern in production:

example.com.  3600  IN  MX  1   ASPMX.L.GOOGLE.COM.
example.com.  3600  IN  MX  5   ALT1.ASPMX.L.GOOGLE.COM.
example.com.  3600  IN  MX  5   ALT2.ASPMX.L.GOOGLE.COM.
example.com.  3600  IN  MX  10  ALT3.ASPMX.L.GOOGLE.COM.
example.com.  3600  IN  MX  10  ALT4.ASPMX.L.GOOGLE.COM.

Here, ALT1 and ALT2 sit at the same priority tier. Sending servers won't consistently favor one over the other — over a large enough volume of mail, both receive roughly equal inbound connection load. This is genuinely useful for spreading traffic across geographically distributed front-end servers that all belong to the same underlying platform, but it is not the same mechanism as backup MX, where a distinctly higher priority number marks a host as a fallback rather than a peer. Confusing the two is one of the more common configuration mistakes we cover later in this guide.

Assigning Priority Across Primary and Backup Infrastructure

There's no protocol requirement dictating specific numbers, which is exactly why real-world deployments vary so much. What matters is relative ordering and leaving room to maneuver. A pattern we see hold up well across small business and enterprise deployments alike:

• Priority 10 — primary mail platform (Google Workspace, Microsoft 365, or an on-prem cluster's public-facing edge transport servers).
• Priority 20 — a secondary edge transport instance, either geographically separate or on different underlying infrastructure than priority 10.
• Priority 50 — a dedicated backup MX / spool-and-forward relay, whether self-hosted or from a specialist provider, that queues mail and retries delivery to the primary once it recovers.

Leaving gaps between values (10/20/50 instead of 1/2/3) isn't cosmetic. When you eventually add a fourth host — a disaster-recovery region, a migration target you're phasing in — you want to be able to slot it in at priority 15 or 30 without touching the values already in production and risking a typo that silently reorders your entire routing hierarchy.

Behavior During Migrations

Priority becomes a genuinely useful migration tool, not just a resilience mechanism. When moving from an on-premises Exchange server to Microsoft 365 or Google Workspace, a common technique is to publish both mail systems as MX records simultaneously during the cutover window, with the new platform at a lower (preferred) priority and the legacy system temporarily left at a higher number as a safety net. Because DNS changes propagate gradually as cached records expire across the internet's resolvers, some senders will keep hitting the old priority ordering for a period defined by TTL — running both live in parallel avoids a hard cutover where any mail sent during the transition window has nowhere reliable to land.

This only works cleanly if the legacy system is still actually capable of accepting and forwarding mail during the overlap period, and if someone remembers to decommission it afterward. We've seen more than one domain still quietly listing a mail server that was powered off eighteen months earlier, sitting there at priority 50, contributing nothing but a slightly longer sender timeout on the rare occasion a stale resolver cache points at it.

Real-World Platform Examples

How priority gets configured differs by platform mainly in where the knob lives, not in the underlying behavior.

Postfix doesn't set MX priority itself — that lives entirely in DNS, at the zone file or DNS provider level, external to Postfix's own configuration. Postfix's relayhost and transport_maps settings control outbound routing decisions, but inbound priority is purely a DNS artifact that Postfix, as a receiving server, has no say in.

Exim is the same story on the receiving side — priority is a DNS-layer decision — but on the sending side, Exim's dns_ipv4_lookup and related routing options determine how it interprets and sorts the MX list it receives, including how it handles ties and IPv6 versus IPv4 preference among equally-prioritized hosts.

Microsoft Exchange (on-premises) exposes MX priority indirectly through the Accepted Domains and Send Connector configuration when Exchange is doing the sending, but for a domain's own inbound MX, priority is again set wherever that domain's authoritative DNS is hosted — Exchange doesn't publish its own DNS zone by default.

Microsoft 365 auto-provisions a single MX record for a verified domain, typically formatted as domain-com.mail.protection.outlook.com at priority 0, and generally expects to be the sole inbound path unless you deliberately layer additional records for hybrid or backup scenarios.

Google Workspace auto-provisions the five-record ASPMX pattern shown earlier, spreading load across two priority tiers by design, which is part of why Workspace domains rarely need a third-party backup MX for basic redundancy — Google has already built tiered redundancy into the default set.

How Priority Interacts With SPF, DKIM and DMARC

MX priority governs where mail arrives, not whether it's trusted once it does — but the two systems brush against each other in a couple of practical ways. SPF's mx mechanism (v=spf1 mx -all) authorizes the IP addresses that a domain's MX hostnames resolve to, regardless of their priority tier — a low-priority backup host is just as authorized as the primary under this mechanism, which is worth remembering if that backup relay ever needs to originate outbound mail (bounce messages, for instance) on the domain's behalf. DKIM and DMARC don't reference MX priority at all; they operate on the message's signed headers and the domain in the From address, independent of which physical server happened to accept the connection. Where priority does matter for authentication is operational: if your backup MX at priority 50 is a different vendor or platform than your primary, make sure that backup host is also covered by your SPF record and configured not to strip or modify DKIM signatures in transit, or mail arriving via the fallback path can fail authentication checks that would have passed through the primary.

TTL, Propagation and the Timing of Priority Changes

Changing priority values doesn't take effect instantly across the internet — it takes effect as fast as the TTL on the record allows caching resolvers to notice the change. A record cached with a 24-hour TTL means some fraction of senders worldwide will keep using the old priority ordering for up to 24 hours after you've updated DNS, simply because their resolver hasn't re-queried yet. For a routine reordering with no urgency, this is a non-issue. For an emergency reprioritization — say, demoting a compromised host out of the primary slot — it's a real constraint, and it's the reason experienced administrators keep MX TTLs lower (300–600 seconds) than they might otherwise default to, specifically to preserve the ability to react quickly.

Queue Retry Behavior When the Preferred Host Is Down

It's worth being precise about what happens on the sending side when a message can't be delivered to any MX host at all — every priority tier unreachable. The sending MTA doesn't drop the message. It queues it locally and retries on a schedule, typically with exponential backoff: attempts every few minutes initially, stretching to hourly, then to every few hours, continuing for a configurable period before finally bouncing with a non-delivery report. Postfix's default is roughly five days of retry before a permanent bounce; Exchange Online's default queue retry window is similar in spirit though implemented differently. This retry window is precisely why a domain with properly staggered priority values rarely loses mail even during extended primary outages — the sender will keep trying the secondary and tertiary hosts throughout that multi-day window, not just once.

Troubleshooting a Priority Misconfiguration

When inbound mail is arriving inconsistently, delayed, or not at all, priority is one of the first things worth checking alongside the more commonly suspected culprits like spam filtering or DNS resolution. A practical diagnostic sequence:

1. Pull the current MX record set with MX Lookup and confirm the priority values match what you expect — it's surprisingly common for a stale record to have survived a platform migration.
2. Verify every MX hostname resolves to a live A or AAAA record — a priority value pointing at a hostname with no address record is effectively a dead end that sending servers will skip past, silently degrading you to whatever's next in line.
3. Confirm the lowest-priority host actually accepts SMTP connections on port 25 from external networks — internal firewall rules sometimes block inbound port 25 while permitting everything else, which looks identical to a DNS problem from the outside.
4. Check whether two hosts you intended to be primary/backup are accidentally sharing the same priority number — this silently turns your fallback into a load-balanced pair, splitting traffic to a host that may not be provisioned to handle it.
5. Test from multiple external vantage points, since local resolver caching can make a change look like it hasn't taken effect when it actually has everywhere except your own network.

A Best-Practice Checklist

Related Tools

Pull a domain's live MX priority set with MX Lookup. Confirm SPF authorizes every mail host you've configured with SPF Lookup. Check how quickly a priority change is propagating globally with DNS Propagation Checker. For the broader picture of how MX records function as a DNS record type, see the MX Record Complete Guide. For how a backup host should actually be built — not just declared in DNS — read Backup MX Configuration, and for what actually triggers the fallback, see MX Failover: How Automatic Mail Rerouting Works.