{"id":152,"date":"2026-10-14T17:01:29","date_gmt":"2026-10-14T14:01:29","guid":{"rendered":"https:\/\/mx1mail.com\/blog\/mx-priority-failover-design-multiple-mx-records\/"},"modified":"2026-10-14T17:01:29","modified_gmt":"2026-10-14T14:01:29","slug":"mx-priority-failover-design-multiple-mx-records","status":"publish","type":"post","link":"https:\/\/mx1mail.com\/blog\/en\/mx-priority-failover-design-multiple-mx-records\/","title":{"rendered":"MX Priority and Failover Design: How to Plan Reliable Email Receiving with Multiple MX Records"},"content":{"rendered":"

What MX priority is (and what it actually controls)<\/h2>\n

An MX (Mail Exchanger) record tells the internet which servers accept inbound email for a domain. Each MX entry includes a priority value (also called preference). The rule is simple: sending mail servers should try the lowest-numbered MX first. For example, priority 10 is preferred over priority 20.<\/p>\n

The important part is what MX priority does not promise. It doesn\u2019t guarantee load balancing, and it doesn\u2019t guarantee instant failover. MX is a \u201ctry this first, then try that\u201d hint. Real-world results depend heavily on the sender\u2019s mail transfer agent (MTA), DNS caching, connection timeouts, and retry schedules.<\/p>\n

Why organizations publish more than one MX record<\/h2>\n

Multiple MX records are primarily about resilience. If your primary inbound server is temporarily unreachable, other MX hosts can accept mail and keep delivery moving. This can reduce the chance that inbound mail simply stops during maintenance windows, network incidents, or routing problems affecting a single host or location.<\/p>\n

In practice, though, the benefit is often \u201cdelayed but not lost\u201d rather than \u201calways seamless.\u201d SMTP was built around queuing and retries. If a destination can\u2019t be reached, most senders will keep messages in queue and attempt delivery again later.<\/p>\n

Common misconceptions that cause bad designs<\/h2>\n

Misconception 1: Two MX records automatically split traffic evenly<\/h3>\n

If you publish two MX hosts with the same priority, some senders may distribute traffic between them. Others may not. Some will prefer one based on past success, latency, policy checks, or their own internal logic. You should not assume \u201c50\/50\u201d behavior.<\/p>\n

Misconception 2: Failover is instant the moment the primary is down<\/h3>\n

When the primary MX can\u2019t be reached, a sender may try the next MX. But the timing varies. Some systems will attempt an alternate quickly; others will wait, back off, or retry the primary first. If your business expectation is \u201cno delay,\u201d you need more than just MX priorities.<\/p>\n

Misconception 3: A backup MX magically delivers directly to mailboxes<\/h3>\n

A secondary MX is commonly a store-and-forward system: it accepts messages and then relays them to the primary when it becomes reachable. That role requires correct configuration and monitoring. If it\u2019s not designed for that purpose, the secondary can become a black hole, or create routing loops and inconsistent filtering outcomes.<\/p>\n

Key concepts for a practical failover plan<\/h2>\n

Primary vs secondary inbound roles<\/h3>\n

The primary MX is your normal receiving point and typically performs the final delivery into users\u2019 mailboxes. A secondary MX is often positioned to accept mail during short outages and queue it for later forwarding to the primary.<\/p>\n

SMTP queues and retry behavior<\/h3>\n

Email delivery is not a single \u201csend and done\u201d action. Temporary failures (often represented by 4xx SMTP responses or connection timeouts) typically trigger queuing and retries on the sender side. This means failover might not be visible as an immediate switch; it may show up as a delivery delay. Designing for reliability means planning for these delays and ensuring mail is eventually accepted and delivered.<\/p>\n

DNS TTL and caching realities<\/h3>\n

TTL influences how long resolvers and systems cache MX answers. TTL is more relevant when you plan to change records during a migration or a provider switch. In a multi-MX failover design, you usually avoid changing DNS during incidents; you want senders to have the alternates already.<\/p>\n

Practical MX priority patterns (and when they fit)<\/h2>\n

Pattern 1: One primary, one secondary (10 and 20)<\/h3>\n

This is the most common and easiest to reason about. In normal operation, inbound email flows to the priority-10 host. If it\u2019s unreachable, senders attempt the priority-20 host. For this to work well, the secondary needs to be prepared to accept mail responsibly and forward it later, not just \u201cexist in DNS.\u201d<\/p>\n

Pattern 2: Multiple MX with equal priority (10 and 10)<\/h3>\n

Organizations sometimes choose equal priorities aiming for load distribution. This can work in some environments, but it increases operational complexity. If the two MX hosts differ in filtering, TLS settings, capacity, or routing rules, you can end up with inconsistent results and hard-to-debug acceptance behavior.<\/p>\n

Pattern 3: Several tiers (10, 20, 30)<\/h3>\n

More MX records are not automatically better. Each additional MX host is an additional surface to secure, monitor, patch, and keep policy-consistent. Multi-tier designs can make sense for multi-region architectures, but only when you\u2019ve clearly defined responsibilities and have strong operational controls.<\/p>\n

Operational risks of using a secondary MX<\/h2>\n

Filtering gaps and abuse exposure<\/h3>\n

A secondary MX that is less strictly configured than the primary can become the easiest entry point for unwanted mail. If it accepts messages that the primary would have rejected, you may see increased spam or suspicious traffic during outages. Consistent baseline controls (rate limiting, reputation checks, sensible SMTP behavior) matter on every inbound MX.<\/p>\n

Backscatter and incorrect rejection timing<\/h3>\n

If a secondary MX accepts mail for recipients that don\u2019t exist and only later rejects it, it can create unwanted bounce messages to forged senders (backscatter). A better approach is to reject invalid recipients during the SMTP conversation whenever feasible, so the sending system is responsible for notifying the real sender.<\/p>\n

TLS consistency<\/h3>\n

If the primary supports modern TLS while the secondary is misconfigured, some senders may treat delivery differently or delay it. Keep certificates valid and configurations aligned across all MX hosts so your inbound posture remains predictable.<\/p>\n

A setup checklist you can apply to any domain<\/h2>\n