What MX priority is (and what it actually controls)
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.
The important part is what MX priority does not promise. It doesn’t guarantee load balancing, and it doesn’t guarantee instant failover. MX is a “try this first, then try that” hint. Real-world results depend heavily on the sender’s mail transfer agent (MTA), DNS caching, connection timeouts, and retry schedules.
Why organizations publish more than one MX record
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.
In practice, though, the benefit is often “delayed but not lost” rather than “always seamless.” SMTP was built around queuing and retries. If a destination can’t be reached, most senders will keep messages in queue and attempt delivery again later.
Common misconceptions that cause bad designs
Misconception 1: Two MX records automatically split traffic evenly
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 “50/50” behavior.
Misconception 2: Failover is instant the moment the primary is down
When the primary MX can’t 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 “no delay,” you need more than just MX priorities.
Misconception 3: A backup MX magically delivers directly to mailboxes
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’s not designed for that purpose, the secondary can become a black hole, or create routing loops and inconsistent filtering outcomes.
Key concepts for a practical failover plan
Primary vs secondary inbound roles
The primary MX is your normal receiving point and typically performs the final delivery into users’ mailboxes. A secondary MX is often positioned to accept mail during short outages and queue it for later forwarding to the primary.
SMTP queues and retry behavior
Email delivery is not a single “send and done” 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.
DNS TTL and caching realities
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.
Practical MX priority patterns (and when they fit)
Pattern 1: One primary, one secondary (10 and 20)
This is the most common and easiest to reason about. In normal operation, inbound email flows to the priority-10 host. If it’s 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 “exist in DNS.”
Pattern 2: Multiple MX with equal priority (10 and 10)
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.
Pattern 3: Several tiers (10, 20, 30)
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’ve clearly defined responsibilities and have strong operational controls.
Operational risks of using a secondary MX
Filtering gaps and abuse exposure
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.
Backscatter and incorrect rejection timing
If a secondary MX accepts mail for recipients that don’t 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.
TLS consistency
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.
A setup checklist you can apply to any domain
- Validate MX targets: MX should point to hostnames that resolve correctly via A/AAAA records. Avoid pointing MX directly to IPs.
- Use clear priorities: A simple 10/20 hierarchy is often sufficient.
- Define the secondary’s job: Is it store-and-forward only, or does it deliver to mailboxes? Document the expected behavior.
- Plan recipient validation: Decide how invalid recipients are handled and ensure the behavior is consistent.
- Monitor the right signals: Track queue growth, SMTP errors, disk usage, and delivery delays.
- Run controlled failover tests: Don’t assume it works; simulate a primary outage and observe how mail flows.
How to test MX failover in a realistic way
Testing isn’t just checking DNS responses. You want to see how external systems behave when the primary is unreachable. In a planned window, you can temporarily make the primary MX inaccessible (for example, blocking inbound TCP/25 in a controlled way) and then send test messages from outside networks. Observe which MX receives the mail, whether it queues properly, and how it forwards once the primary returns.
Also test the recovery phase. When the primary comes back, queued mail may arrive in bursts. That spike reveals whether your inbound and mailbox delivery capacity can absorb backlogged messages without causing additional delays.
Conclusion: keep it simple, measurable, and maintainable
Multiple MX records can improve inbound resilience, but only with the right expectations and disciplined operations. For most companies, a straightforward priority model plus monitoring and periodic testing delivers better results than overly complex multi-tier MX setups.
When planning a business email platform—whether you manage your own infrastructure or use a managed service—treat MX design as part of a larger operational plan that includes DNS management, security consistency, and incident procedures. If you’re moving domains or rebuilding inbound email workflows with MX1Mail, reviewing MX priorities and failover behavior early helps reduce surprises during maintenance and migrations.