You set up MX records for your domain, enter some priority numbers that seem reasonable, and assume email will work. Most of the time it does. Then one day your primary mail server goes offline and you discover that backup MX records don't behave quite the way you expected, or that subtle configuration mistakes have been silently causing delivery problems for months.
Understanding how mail servers actually use MX records goes beyond knowing that lower numbers mean higher priority. Real-world email delivery involves retry logic, fallback behavior, timeout scenarios, and edge cases that can make the difference between reliable communication and mysterious delivery failures.
How MX Priority Actually Works
When a mail server needs to deliver a message to your domain, it queries DNS for your MX records. The response includes one or more records, each with a priority value (also called preference). The sending server attempts delivery to the MX record with the lowest priority number first.
Priority 10: mail.example.com
Priority 20: mail-backup.example.com
Priority 30: mail-fallback.example.com
In normal operation, 100% of your email flows to mail.example.com because it has priority 10 (the lowest value). The other servers sit idle, waiting for circumstances where the primary becomes unavailable.
This isn't load balancing. Unlike web traffic where you might want to distribute load across multiple servers, email delivery strongly prefers using a single server when possible. The higher priority MX records exist solely as failover options.
What Happens When Your Primary Mail Server Fails
When the primary MX server becomes unreachable, sending mail servers don't immediately give up. They follow a decision process that involves timeouts, retry attempts, and eventually trying alternative MX records.
Connection failure: If the mail server at priority 10 doesn't respond to connection attempts (server is down, network problem, firewall blocking traffic), the sending server typically retries a few times over several minutes. After those rapid retries fail, it moves to the next priority level and attempts delivery there.
Connection timeout: If the server accepts the connection but then becomes unresponsive during the SMTP conversation (server overloaded, software bug, network issue), the sending server waits for its timeout period (usually 5-10 minutes) before giving up on that attempt. It may retry the same server or move to the next priority depending on the specific error.
Temporary rejection: If the server explicitly says "I can't accept this message right now, try again later" (4xx SMTP response), the sending server queues the message and retries the same server periodically. This is working as designed and isn't a failure scenario that triggers moving to backup MX records.
Permanent rejection: If the server says "this recipient doesn't exist" or "message rejected for policy reasons" (5xx SMTP response), the sending server gives up entirely and bounces the message back to the sender. It doesn't try alternative MX records because the problem isn't server availability, the destination explicitly rejected the message.
The key insight: backup MX records activate when the primary server is unreachable or unresponsive, not when it's actively rejecting messages for legitimate reasons.
The Backup MX Dilemma
Running a backup MX server sounds like good redundancy, but it introduces complications that many people don't anticipate.
Configuration complexity: Your backup MX server needs to be configured identically to your primary in terms of which recipients it accepts, spam filtering rules, and relay permissions. If the configurations diverge, you'll experience inconsistent behavior depending on which server receives mail.
Synchronization challenges: When your backup MX accepts mail during a primary server outage, those messages need to be delivered to your primary mail system once it's back online. This requires the backup server to queue messages and relay them forward, which adds another layer of complexity and potential failure points.
Spam and backscatter: Spammers exploit backup MX servers that aren't configured with the same recipient verification as the primary. The backup accepts mail for invalid addresses, then later generates bounce messages when it can't deliver them to the primary. This turns your backup MX into a spam relay.
False redundancy: If both your primary and backup MX records point to servers in the same data center on the same network infrastructure with the same power supply, a facility-wide problem takes down both simultaneously. Your backup provides no actual redundancy in the failure scenarios that matter most.
Many small to medium organizations discover that running backup MX servers creates more problems than it solves. Modern mail servers have impressive uptime, and when they do fail, most sending servers queue messages and retry for hours or days, giving you time to restore service.
Equal Priority MX Records
What happens if you configure multiple MX records with the same priority value?
Priority 10: mail1.example.com
Priority 10: mail2.example.com
Technically, the DNS specification says sending servers should randomize selection among equal-priority MX records, effectively distributing load. In practice, different mail servers implement this differently. Some truly randomize, others have implementation-specific preferences, and some always try records in the order they appear in the DNS response.
Equal priority MX records work better for load distribution than using different priority values, but they still don't provide the sophisticated load balancing that web traffic typically uses. For serious mail infrastructure requiring load distribution, you're better off using a single MX record that points to a load balancer, which then distributes traffic to multiple mail servers using proper health checks and algorithms.
The Null MX Record
Sometimes you want to explicitly declare that a domain doesn't accept email. The null MX record accomplishes this:
This tells sending mail servers "this domain does not accept email, don't even try." It's more explicit and efficient than having DNS queries return no MX records at all, which causes sending servers to fall back to checking for an A record and attempting direct delivery.
- Domains that exist only for websites and should never receive email
- Subdomains specifically designated as non-email domains
- Temporary domains during infrastructure setup before email is configured
Why it matters: Without a null MX, sending servers waste time attempting delivery to A record addresses. With a null MX, they immediately know not to try, which reduces unnecessary connection attempts and makes bounce messages arrive faster.
Common MX Misconfigurations and Their Impact
MX record pointing to a CNAME: This violates DNS specifications. MX records must point to A or AAAA records, not CNAMEs. Some mail servers tolerate this and follow the CNAME anyway, but others reject it entirely, causing complete mail delivery failure.
mail.example.com → A 192.0.2.1
MX 10 mail-alias.example.com
mail-alias.example.com → CNAME mail.example.com
mail.example.com → A 192.0.2.1
MX record pointing to an IP address: This also violates specifications and causes delivery failures with standards-compliant mail servers. Always point MX records to hostnames, not IP addresses.
Missing reverse DNS: While not strictly an MX misconfiguration, if your mail server's IP address doesn't have proper reverse DNS (PTR record) pointing back to your mail server hostname, many receiving servers will reject your outbound mail as likely spam. This is one of the first things to check when experiencing deliverability problems.
Priority numbers too close together: Using MX priorities like 10, 11, and 12 doesn't cause technical problems, but it does make the priority order less obvious at a glance. Convention typically uses intervals of 10 (10, 20, 30) to make the hierarchy clear and leave room for inserting additional records later if needed.
MX record pointing to a shared hosting server: Some people point their MX record to the same server that hosts their website. While this works technically, it means website and email share resources. If your website gets compromised or experiences high traffic that affects server performance, email delivery suffers too. Separating concerns by using dedicated email services improves reliability and security. Retry Behavior and Queue Times
When a sending mail server can't immediately deliver a message, it enters a retry queue. Understanding this behavior helps you anticipate what happens during mail server outages.
Most mail servers use exponential backoff: they retry quickly at first, then with increasing delays between attempts. A typical retry schedule might look like:
- Final retry after 24 hours
- Bounce message if still failing
Different mail systems use different schedules. Google's Gmail, for instance, retries for up to 4-5 days before giving up. Microsoft's Exchange Online typically retries for 2-3 days. Smaller mail servers might give up after 24-48 hours.
Practical implications: If your primary mail server goes offline, you have a substantial window (often days) to bring it back online before messages start bouncing. The retry mechanism provides more resilience than backup MX servers for many failure scenarios.
However, for time-sensitive communications (password resets, transaction confirmations, two-factor authentication codes), even a few hours of delay is unacceptable. This is where backup MX infrastructure might be justified despite its complexity.
Testing Your MX Configuration
Don't wait for a real failure to discover your backup MX doesn't work properly. Testing your configuration reveals problems before they impact actual mail delivery.
Verify your MX records are publicly visible:
This shows what mail servers see when looking up your domain. Confirm that all intended MX records appear with correct priorities and hostnames.
Check that each MX hostname resolves to an IP address:
If an MX record points to a hostname that doesn't resolve, mail delivery to that server will fail.
Verify reverse DNS for each mail server IP:
The response should show a hostname, ideally matching your mail server's name.
Test SMTP connectivity to each server:
telnet mail.example.com 25
This verifies that each server accepts connections on the SMTP port. If your primary responds but your backup times out, you've found a problem before it mattered.
Send test messages during simulated failures: Temporarily lower your primary MX record's priority (making it numerically higher) so that sending servers try your backup first. Send test messages and verify they arrive correctly. This confirms your backup server actually works for receiving mail, not just accepting connections.
Monitor actual mail flow: Set up monitoring that tracks which MX server is receiving mail. If your backup server suddenly starts receiving traffic, you have an early warning that something's wrong with your primary before users report problems.
Advanced MX Scenarios
Split delivery based on recipient: Some organizations want different MX handling for different users or departments. Standard MX records can't do this, they apply to the entire domain. To achieve split delivery, you typically need to:
- Have all mail arrive at a single system (your lowest priority MX)
- That system examines recipients and routes messages internally to appropriate servers
- Use subdomains (support.example.com, sales.example.com) with separate MX records if you need truly separate mail infrastructure
Geographic redundancy: Organizations with critical email needs might run mail servers in multiple geographic locations, each with its own MX record at different priorities. This protects against regional outages or network partitioning. However, this requires sophisticated replication to ensure users can access their mail regardless of which server received it.
MX records for subdomains: You can configure MX records for subdomains independently of your main domain. For example, support.example.com might have different MX records than example.com. This is useful when different parts of your organization use different email systems.
Outsourced spam filtering: Some organizations point their lowest-priority MX records at a third-party spam filtering service, which then forwards legitimate mail to internal mail servers. This requires careful configuration to prevent the filtering service from becoming an open relay.
When MX Changes Go Wrong
Updating MX records seems straightforward until something breaks. Common failure scenarios:
Forgetting to update SPF records: When you change which servers send mail on behalf of your domain, you must update SPF records to authorize those new servers. If you switch MX records but forget SPF, your outbound mail might start getting rejected as spam.
Immediate cutover without testing: Changing MX records without first verifying the new servers are properly configured means any configuration problems immediately affect all incoming mail. Better approach: add the new MX at a lower priority, test it, then swap priorities once confirmed working.
Removing old MX records too quickly: During MX changes, some DNS servers might still cache your old records due to TTL. If you immediately decomission the old mail server, messages arriving there during propagation are lost. Keep old infrastructure running for 48-72 hours after changing MX records.
Firewall rules not updated: Your new mail server is configured perfectly, but the network firewall still blocks port 25 from external sources. Mail servers can't reach your new MX, and you don't discover the problem until users report missing email.
SSL certificate problems: If your new mail server doesn't have a valid certificate for its hostname, some sending servers will refuse to deliver mail. Testing SMTP connectivity might work if you're not checking TLS, but real mail delivery fails. Modern email security increasingly requires proper SSL certificates for mail servers. Monitoring and Maintenance
Track delivery patterns: Know your normal incoming mail volume and patterns. Sudden drops might indicate an MX problem preventing delivery. Sudden increases in spam might indicate a compromised backup MX server.
Set up alerts: Configure monitoring to notify you if:
- Your primary MX server becomes unreachable
- Backup MX servers start receiving significant traffic
- Mail queue sizes grow abnormally
- SMTP connection failures increase
Review logs regularly: Mail server logs reveal attempted deliveries, rejections, and errors that might not generate user-visible problems immediately but indicate configuration issues or attacks.
Keep software updated: Mail server software requires regular security updates. Outdated software becomes vulnerable to exploits that could compromise your entire mail system.
Document your configuration: When you need to troubleshoot a mail delivery problem at 2 AM, having documentation of your intended MX setup, server configurations, and firewall rules saves hours of investigation.
Practical Recommendations
For most organizations, a simple MX configuration works best:
Small to medium businesses: Single MX record pointing to a reliable email provider (Google Workspace, Microsoft 365, or a dedicated email hosting service). These platforms have internal redundancy, eliminating the need for you to manage backup MX servers.
Larger organizations with in-house mail servers: Primary MX pointing to your mail server, with backup MX pointing to a service that queues messages during outages. Ensure the backup service integrates properly with your primary system and can't be exploited for spam relay.
Technical organizations with high availability requirements: Multiple MX records pointing to geographically distributed mail servers with proper data replication. This requires significant infrastructure and expertise but provides genuine redundancy.
Projects and non-email domains: Null MX record to explicitly indicate no email service. This is cleaner than relying on lack of MX records and prevents unnecessary delivery attempts.
The Reality of Modern Email Delivery
Email infrastructure has evolved substantially over the past decade. Modern sending servers are remarkably persistent, retrying delivery for days before giving up. Cloud-based email services offer exceptional uptime that makes backup MX servers less necessary than they once were.
The complexity of properly configuring and maintaining backup MX infrastructure often exceeds the benefit for most organizations. Unless you have specific regulatory requirements or truly critical email needs that justify the investment, a single MX record pointing to a reliable service provides better outcomes than a misconfigured redundant setup.
When you do need multiple MX records, invest time in getting the configuration right: proper priority values, synchronized server configurations, thorough testing, and ongoing monitoring. MX records that work correctly during failures require planning and maintenance, not just DNS entries that look reasonable.
Understanding how mail servers actually use MX records, the retry logic, fallback behavior, timeout scenarios, and edge cases, transforms MX configuration from guesswork into informed decision-making. Your domain's email reliability depends on getting these details right. 
.png&w=2048&q=75)
.png&w=3840&q=75)
.png&w=3840&q=75)