Can You Have Multiple MX Records? Understanding Mail Server Redundancy
Learn why domains use multiple MX records, how priorities work, and best practices for mail server redundancy and failover.
Yes, you can have multiple MX records—and for most domains, you should. Multiple MX records provide redundancy, ensuring email delivery continues even when your primary mail server is unavailable.
This guide explains how multiple MX records work, when you need them, and how to configure them correctly.
Why Multiple MX Records Exist
The MX record system was designed with redundancy in mind. When a sending server can't deliver to your primary mail server, it tries backup servers in order of priority.
With a single MX record, your email depends entirely on one server. If that server goes down for maintenance, experiences hardware failure, or becomes unreachable due to network issues, incoming email bounces.
With multiple MX records, sending servers have alternatives. Your primary server handles normal traffic, while backup servers catch email during outages.
How Priority Works With Multiple Records
Each MX record has a priority value. Lower numbers mean higher priority (tried first).
| Priority | Server | Role |
| 10 | mail1.example.com | Primary - handles most traffic |
| 20 | mail2.example.com | Secondary - first backup |
| 30 | mail3.example.com | Tertiary - second backup |
When someone sends email to your domain:
- The sender's server queries your MX records
- It receives all three records with their priorities
- It attempts delivery to priority 10 (mail1.example.com) first
- If that fails, it tries priority 20 (mail2.example.com)
- If that also fails, it tries priority 30 (mail3.example.com)
- Only if all servers fail does the email bounce or get queued for retry
This cascade happens automatically. Senders don't know or care which server ultimately accepts their email.
Common Multi-MX Configurations
Different scenarios call for different configurations:
Standard Redundancy
Most organizations use 2-3 MX records with different priorities:
example.com MX 10 mail.example.com
example.com MX 20 backup.example.com
The primary server handles 100% of traffic during normal operation. The backup only receives email when the primary is unavailable.
Load Balancing
Using the same priority distributes email across multiple servers:
example.com MX 10 mail1.example.com
example.com MX 10 mail2.example.com
When two records share the same priority, sending servers randomly choose between them. This distributes load evenly across both servers.
Google Workspace Configuration
Google provides five MX records with tiered priorities:
example.com MX 1 aspmx.l.google.com
example.com MX 5 alt1.aspmx.l.google.com
example.com MX 5 alt2.aspmx.l.google.com
example.com MX 10 alt3.aspmx.l.google.com
example.com MX 10 alt4.aspmx.l.google.com
This creates three tiers: one primary, two secondary (load balanced), and two tertiary (load balanced). Google's infrastructure ensures all these servers deliver to your mailbox.
Security Gateway Configuration
Email security services sit in front of your actual mail server:
example.com MX 10 gateway.security-provider.com
example.com MX 20 gateway-backup.security-provider.com
All email routes through the security service, which scans it before forwarding to your mail server. Your actual mail server isn't exposed in MX records.
Your mail server may not appear in MX records
If you use a security gateway, spam filter, or cloud email provider, MX records point to their servers, not yours. This is normal and expected.
Best Practices for Multiple MX Records
Use Sufficient Priority Gaps
Space priorities apart (10, 20, 30 instead of 1, 2, 3). This leaves room to insert additional servers later without renumbering everything.
Ensure Backups Actually Work
Having backup MX records is pointless if those servers don't work. Periodically test that:
- Backup servers accept email for your domain
- Email received by backups reaches the same mailboxes
- Backup servers are properly maintained and secured
Don't Create Backup-Only Security Holes
Backup MX servers must have the same security configuration as your primary. Spammers sometimes target lower-priority MX servers hoping for weaker filtering.
Monitor All MX Servers
Don't just monitor your primary. If a backup server goes down, you might not notice until you actually need it during a primary outage.
Keep Configurations Synchronized
If your primary uses specific authentication or encryption requirements, backups should match. Inconsistent configuration between MX servers causes confusing delivery issues.
Questions About Multiple MX Records
Can I have two different email providers?
Technically possible but problematic. If you have MX records pointing to both Google and Microsoft, some email goes to each. Users would need to check both systems. This is rarely intentional and usually indicates an incomplete migration.
How many MX records can I have?
DNS doesn't impose a hard limit. Practically, 2-5 MX records cover most redundancy needs. More than that rarely provides additional benefit.
Do all MX servers need to be different physical servers?
Not necessarily. They need different hostnames, but those hostnames could resolve to load balancers, clusters, or cloud services with their own redundancy. Google's MX records all ultimately deliver to the same Gmail infrastructure.
What if I only have one server?
If you truly have only one mail server with no backup, you can still have one MX record. You lose redundancy, but email works. Consider cloud email providers if availability matters—they handle redundancy for you.
Should priorities be consecutive numbers?
No. Use gaps (10, 20, 30) rather than consecutive numbers (1, 2, 3). Gaps allow inserting new servers without renumbering. The actual numbers don't matter—only their relative order.
Can two MX records have the same priority?
Yes. Same-priority records enable load balancing. Sending servers randomly choose between them, distributing traffic evenly.
Troubleshooting Multiple MX Issues
Email Only Reaches One Server
If email always goes to your primary even when testing backup delivery:
- Primary might be working fine (expected behavior)
- Force-test by querying backup MX directly
- Verify backup servers accept mail for your domain
Inconsistent Delivery Behavior
If email sometimes works and sometimes fails:
- Check all MX servers are functioning
- Verify consistent configuration across servers
- Look for network issues affecting specific servers
Old and New Providers Both Receiving Mail
After an email migration, if both old and new providers get email:
- Old MX records may still exist alongside new ones
- DNS propagation might be incomplete
- Check for duplicate MX records and remove old ones
Monitor Your MX Records
Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.
Never miss an MX issue
Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.
Start Monitoring