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).

PriorityServerRole
10mail1.example.comPrimary - handles most traffic
20mail2.example.comSecondary - first backup
30mail3.example.comTertiary - second backup

When someone sends email to your domain:

  1. The sender's server queries your MX records
  2. It receives all three records with their priorities
  3. It attempts delivery to priority 10 (mail1.example.com) first
  4. If that fails, it tries priority 20 (mail2.example.com)
  5. If that also fails, it tries priority 30 (mail3.example.com)
  6. 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