MX record priorities decide which mail server a sending system contacts first, and when they are set wrong, mail can be silently delayed, filtered differently or sent to a server the organization no longer controls. This article covers how MX record priorities actually work, how sending servers behave when the first choice fails, and which DNS configuration mistakes cause delivery problems in production. It is aimed at administrators who run their own mail infrastructure, migrate between providers or inherit a zone file full of records nobody can explain.
The main benefit is predictability. Once you know how a remote MTA reads your MX set, you can plan maintenance windows and migrations without guessing where mail will land.
How MX Record Priorities Are Read by Sending Servers
Every MX record has two parts: a preference value (a 16-bit number from 0 to 65535) and a target hostname. RFC 5321, section 5.1, defines the rule. The sending server sorts all MX records by preference and tries the lowest number first. A record with preference 10 is tried before one with preference 20.
When several records share the same preference, the sender should pick between them at random. That is how basic load distribution works with MX records alone. Two hosts at preference 10 should each get roughly half of the inbound connections over time. It won’t be an exact split, because senders cache results and some MTAs implement the randomization loosely.
If a domain has no MX records at all, the sender falls back to the domain’s A or AAAA record and treats that as an implicit MX. This catches people out. A bare marketing domain with only a web server A record can end up receiving SMTP connection attempts on that web server.
What Happens When the Primary Server Fails
The fallback behavior depends on how the failure looks to the sender. If the TCP connection is refused, times out, or the server answers with a 4xx temporary error during the greeting, the sender moves to the next MX host. Postfix, for example, tries up to 5 MX addresses per delivery attempt by default (smtp_mx_address_limit) and opens at most 2 SMTP sessions (smtp_mx_session_limit) before deferring the message.
A 5xx permanent rejection is different. If the primary accepts the connection and then rejects a recipient with 550, the sender will usually not try the backup. The message bounces. So a misconfigured primary that rejects valid users won’t be rescued by a healthy secondary.
If every host fails temporarily, the message sits in the sender’s queue. Postfix keeps retrying for 5 days by default (maximal_queue_lifetime), and Sendmail and Exim use similar windows of about 4-5 days. So a short outage of your only MX host rarely loses mail. It delays it.
The Backup MX Myth
A common belief is that every domain needs a lower-priority backup MX on separate infrastructure “so mail isn’t lost.” For most organizations today, that’s wrong. Sending servers already queue mail for days, as described above. A backup MX only adds value if it can hold mail longer than the senders would, or if it has the same filtering, recipient validation and TLS configuration as the primary.
Most backup MX setups don’t. A secondary host that accepts mail for any address at the domain, then relays it to the primary, becomes a spam magnet. Spammers deliberately target the highest preference number because those hosts tend to have weaker filtering. When the primary later rejects the relayed junk, the backup generates bounces to forged senders, which is backscatter, and that can get your IP listed on blocklists.
The exception is a backup run by the same provider with the same policies. Google Workspace’s legacy set (ASPMX.L.GOOGLE.COM at 1, ALT1 and ALT2 at 5, ALT3 and ALT4 at 10) is an example of that. Google now recommends a single record, smtp.google.com at priority 1, for new setups. Microsoft 365 uses one record pointing to the tenant’s mail.protection.outlook.com host, usually at preference 0.
A Migration Scenario That Goes Sideways
A typical case: a company moves from an on-prem Exchange server to Microsoft 365. The admin adds the new Microsoft MX at preference 0 and leaves the old record, mail.example.com at preference 10, “just in case.” Six months later the Exchange box is decommissioned and its public IP returns to the hosting provider’s pool.
Mail mostly works, so no one notices. But whenever the Microsoft endpoint has a brief hiccup, or a sender’s resolver returns a stale answer, some senders try preference 10. That connection now goes to an IP address assigned to someone else. At best the mail is delayed. At worst, whoever holds that IP accepts the messages.
An experienced mail administrator handles this by lowering TTLs to 300 seconds about 48 hours before the cutover, then removing the legacy MX within days, not months. The reasoning behind that timing is covered in the guide to TTL settings and their security implications. The same principle applies to any provider move. Treat a leftover MX record as a dangling DNS pointer, exactly like an orphaned CNAME.
Common Mistakes With MX Configuration
The first mistake is pointing an MX record at a CNAME. RFC 2181 (section 10.3) and RFC 5321 both prohibit it. Many MTAs will follow the alias anyway, but some won’t, and the failures look random. The MX target must be a hostname with its own A or AAAA records. It must never be an IP address written directly into the record.
The second is forgetting MTA-STS when changing hosts. If the domain publishes an MTA-STS policy (RFC 8461) in enforce mode, every MX hostname has to match an “mx:” line in the policy file. Adding a new provider’s host without updating the policy makes compliant senders like Gmail refuse to deliver to it. Fix the policy, bump the id in the _mta-sts TXT record, then change the MX.
The third is leaving MX records on domains that should never receive mail. Parked domains and campaign domains should publish a null MX (RFC 7505), which is a single record “0 .” that tells senders to bounce immediately. Pair it with an SPF record of “v=spf1 -all” and a reject DMARC policy. The wider picture of locking down non-sending domains is in the article on preventing email spoofing with proper DNS configuration.
How to Audit Your MX Records Step by Step
A practical review takes about 15 minutes per domain:
1. Run dig MX example.com +short against at least two public resolvers and confirm that the answers match your provider’s documentation.
2. Resolve every MX target to A/AAAA and confirm that each IP belongs to infrastructure you currently own or contract.
3. Connect to each host on port 25 with openssl s_client -starttls smtp and check the certificate name and whether the server accepts the connection.
4. Compare the MX hostnames against your MTA-STS policy and your SPF include list for consistency.
5. Repeat for every subdomain and secondary domain, not just the apex.
Step five gets skipped most often. Subdomains such as bounce.example.com or support.example.com often carry MX records for SaaS ticketing or bounce processing, and those records outlive the contract.
FAQ
Does a lower MX number mean higher priority?
Yes. Senders try the lowest preference value first. Only the order matters, so the gap between values doesn’t. Records at 10 and 20 behave the same as records at 1 and 2.
Can two MX records have the same priority?
Yes. Senders should pick between equal-preference hosts at random, which spreads load roughly evenly. Both hosts must accept mail for the same recipients with the same policies.
How long does an MX change take to apply?
It depends on the previous record’s TTL. With a 3600-second TTL, most resolvers pick up the change within an hour, but some senders cache longer. Keep the old server reachable for at least 24-48 hours after the switch.
Summary
MX record priorities are simple: the lowest number is tried first, equal numbers share the load, and temporary failures fall through while permanent rejections don’t. The real risk is not the ordering. It is the records left behind after migrations, pointing at hosts and IPs that are no longer yours. Review MX sets on every domain and subdomain after each provider change, publish null MX where mail isn’t expected, and treat any MX target you can’t account for as a security finding, not just housekeeping.