When MX Priorities Collide: How MTAs Handle Same-Weight Records

You just split your company's inbound mail between a production server and a staging box you forgot existed. Worse, it's been happening for weeks. Half of your support tickets, invoices, and new-business inquiries have been vanishing into a development environment that doesn't route mail. How? Two MX records, both with a priority of 10.

Every admin learns the basic rule of MX records: lower number means higher priority. A record at priority 10 gets traffic before a record at priority 20. But what happens when you have two records at priority 10? The common wisdom says it creates a 'round-robin' for load balancing. This is a dangerously incomplete picture.

The truth is that equal-priority MX records create an unpredictable split. It's a loaded gun pointed at your mail flow, and the trigger is controlled by every sending Mail Transfer Agent (MTA) on the internet. Let's dissect the RFC, examine the failure modes, and build a configuration that actually works.

Deconstructing RFC 5321: The Unforgiving Rules of MX Selection

Forget the simplified guides you've read. The canonical source for SMTP behavior is RFC 5321. Section 5.1, 'Client-Initiated A-Record Lookups', lays out the precise logic a sending MTA must follow when delivering an email. It first looks for an MX record. If found, it must use it. The process is clear: sort records by preference value (the priority number) and try the lowest-numbered hosts first.

But what about a tie? The RFC doesn't leave this to the imagination. The language is prescriptive, and it's the source of all the confusion.

When the lookup results in multiple MX records for a domain, the K-address consists of all of the hosts listed in those MX RRs. The SMTP client MUST sort the MX records on the basis of preference to determine the order of delivery attempts. [...] If there are multiple destinations with the same preference, and the SMTP client is able to attempt delivery to multiple of these, the SMTP client MAY attempt delivery to more than one of these, either sequentially or in parallel. When a single MX record is to be chosen from a set of equal-preference records, the selection MUST be randomized to spread the load...

The key phrases here are 'the selection MUST be randomized' and ' MAY attempt delivery to more than one'. This isn't a friendly suggestion. It's a requirement for sending MTAs to treat same-priority hosts as an unordered, equivalent group and pick one at random. This randomization is the root of the problem. It guarantees that you have no control over which server a given email will be delivered to.

The Dangerous Myth of 'Round Robin'

The term 'round robin' implies a fair, predictable rotation. First email to Server A, second to Server B, third back to Server A. This is not what RFC 5321 mandates, and it's not what happens in reality. The spec says 'randomized,' not 'rotated'.

Implementation Variance is Everything

Every MTA developer reads the RFC and writes code to interpret it. A Postfix server's 'random' selection algorithm might differ from Microsoft Exchange Online's, which will differ from Google's. Some MTAs might get a list of two equal-priority MX hosts from their DNS resolver and simply try the first one on the list, every time. Others might implement a true randomization function for every single message. Still others might randomize once and then cache that decision for a few minutes.

The outcome is chaos at scale. One sending organization might deliver 100% of its mail to your `mx1` server for an hour, while another might split its traffic 50/50 between `mx1` and `mx2`. You have zero ability to predict or control this behavior on the receiving end. Treating same-priority MX records as a reliable load-balancing mechanism is a catastrophic mistake because you are outsourcing your delivery logic to thousands of independent, uncoordinated clients.

Failure Scenario: Accidental Prod/Staging Mail Split

Let's walk through the disaster scenario from the introduction. Your team is preparing to migrate to a new mail gateway. A junior admin, let's call him Dave, is tasked with setting up the staging environment. The production MX record looks like this:

yourdomain.com. 3600 IN MX 10 prod-gateway.yourvendor.com.

To 'test' mail flow to the new staging server, Dave adds a second MX record. Wanting to make sure it's seen as an equal, he gives it the same priority.

The Accidental Load Balancer

The new DNS configuration now looks like this:
yourdomain.com. 3600 IN MX 10 prod-gateway.yourvendor.com.
yourdomain.com. 3600 IN MX 10 staging-box.internal.yourdomain.com.

Immediately, a random percentage of senders worldwide start resolving two priority 10 records for your domain. Their MTAs, following RFC 5321, dutifully randomize their selection. An urgent email from your biggest client about a contract renewal might be delivered to the production gateway. The follow-up, containing wire transfer details, might be sent to the staging server — a Docker container on a developer's laptop that writes incoming mail to `/dev/null`.

Because the acks are happening at the SMTP layer, the sender gets a `250 OK` confirmation. To them, the mail was delivered. They have no idea it went to a black hole. You won't know either until the client calls asking why you never replied.

Failure Scenario: Cloudflare Routing vs. M365 Direct

This isn't just a problem for on-prem or staging environments. A very common modern misconfiguration involves mixing cloud service MX records. Take a popular setup: using Cloudflare's Email Routing service in front of a Microsoft 365 tenant.

The Intended Path

Cloudflare's service is designed to receive your mail, apply filtering rules, and then forward it to its ultimate destination (like your M365 tenant). To do this, it asks you to set your MX records to point exclusively to Cloudflare's servers, for example:

yourdomain.com. 3600 IN MX 10 route1.mx.cloudflare.net.
yourdomain.com. 3600 IN MX 20 route2.mx.cloudflare.net.

Mail hits Cloudflare, gets processed, and is then routed to a hidden destination address you've configured in their dashboard. Simple enough.

The Collision

But often, administrators will leave the old Microsoft 365 MX record in place 'just in case'. Or they'll add it back during a troubleshooting step and forget to remove it. You end up with a configuration like this:

yourdomain.com. 3600 IN MX 10 route1.mx.cloudflare.net.
yourdomain.com. 3600 IN MX 10 yourdomain-com.mail.protection.outlook.com.

Now you have two priority 10 records pointing to two completely different, non-equivalent services. A sending MTA will now randomly choose to either send your mail via Cloudflare (the intended path) or deliver it directly to Microsoft 365, bypassing all your Cloudflare rules, logging, and routing logic. This can cause forwarded messages to fail DMARC (since they don't benefit from Cloudflare rewriting), can break compliance archives, and creates a nightmare for incident response when your logs are split across two disconnected services.

The Right Way: Load Balancing vs. Pure Failover

So, how do you correctly configure MX records for redundancy and resilience? You must decide: are you building a failover system or a load-balanced one? The two are not the same, and your priority numbers must reflect your intent.

Configuration for Pure Failover

This is the most common and safest configuration. You want mail to go to your primary server, and only if that server is completely unreachable should it attempt delivery to a secondary. This is achieved with distinct priority tiers.

yourdomain.com. 3600 IN MX 10 primary.gateway.com.
yourdomain.com. 3600 IN MX 20 secondary.gateway.com.

A sending MTA will always try `primary.gateway.com` first. Only if it gets a connection timeout or a 4xx series temporary failure will it then attempt delivery to `secondary.gateway.com`. The secondary server can be a warm standby in a different data center or even a store-and-forward service. The key is that 100% of your mail traffic is directed to the priority 10 host as long as it is available.

Configuration for True Load Balancing

If you truly want to load balance inbound mail traffic, you can use same-priority MX records. However, this is only safe under one condition: all hosts at that priority level must be identical, fully functional, production-ready gateways. They must lead to the same mail infrastructure, use the same filtering rules, and be able to process any email intended for your domain.

yourdomain.com. 3600 IN MX 10 lb-node1.gateway.com.
yourdomain.com. 3600 IN MX 10 lb-node2.gateway.com.
yourdomain.com. 3600 IN MX 10 lb-node3.gateway.com.
yourdomain.com. 3600 IN MX 50 emergency-only.backup-provider.com.

In this setup, you are explicitly telling the world: 'Pick any of the first three servers at random, I don't care which. They are all equivalent.' The priority 50 record still functions as a pure failover in the unlikely event all three primary nodes are down.

The takeaway

The rule is simple: a single MX priority level means 'these servers are functionally identical.' It does not mean 'try one, then try the next.' If your servers at the same priority level aren't truly interchangeable—if one is staging, one is production, or if they represent different cloud services—you have not built a resilient system. You have built a roulette wheel for your company's most critical communications.

Go check your domain's MX records right now. Do you know what each one does? Are any priorities tied? If so, are you absolutely certain they are equivalent? If not, you have a ticking time bomb in your DNS. When you're ready to audit not just your MX records but the entire email authentication chain, from SPF alignment to ARC preservation, a platform like MailSleuth.AI can help you trace the path and identify where the chain breaks.