Email routing uses MX (Mail Exchanger) records to direct messages to the correct server. MX records have priority values—lower numbers are tried first. If the primary server is unavailable, email routes to higher-priority (larger number) backup servers. Multiple MX records with the same priority provide load balancing.
Email Routing: MX Records, Priority, and Failover
How Email Routing Works
When someone sends email to [email protected], their mail server:
- Looks up the MX records for example.com
- Sorts by priority (lowest number first)
- Connects to the first available server and delivers
- Falls back to backup servers if the primary is unavailable
This system has worked since 1986 (RFC 974) and remains the foundation of email delivery. MX records are one part of your overall DNS configuration for email.
MX Record Anatomy
An MX record has two parts:
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.
| Component | Meaning |
|---|---|
example.com. | Domain receiving mail |
IN | Internet class (always IN) |
MX | Record type |
10 or 20 | Priority (lower = preferred) |
mail1.example.com. | Target mail server hostname |
The hostname must have an A record:
mail1.example.com. IN A 192.0.2.10
mail2.example.com. IN A 192.0.2.20
Priority and Failover
Basic Failover Setup
example.com. MX 10 primary.example.com.
example.com. MX 20 backup.example.com.
Normal operation: All mail goes to primary (priority 10).
If primary is unreachable: Mail goes to backup (priority 20).
Load Balancing with Equal Priority
example.com. MX 10 mail1.example.com.
example.com. MX 10 mail2.example.com.
When priorities are equal, sending servers distribute traffic between them. This isn't precise load balancing—each sender picks randomly—but it roughly splits the load.
Enterprise Setup with Tiers
example.com. MX 10 mail-east.example.com.
example.com. MX 10 mail-west.example.com.
example.com. MX 20 backup-east.example.com.
example.com. MX 20 backup-west.example.com.
example.com. MX 50 offsite-backup.example.net.
Traffic splits between east/west primary servers. If both fail, traffic splits between east/west backups. If everything fails, offsite backup catches mail.
Practitioner note: Don't set your backup priority too close to primary (like 10 and 11). Some senders only check the top result. I use 10, 20, 50 increments to make the hierarchy clear and leave room for adding servers later.
Checking MX Records
Using dig
dig MX example.com +short
# Output:
# 10 mail1.example.com.
# 20 mail2.example.com.
# Full details
dig MX example.com
Using nslookup
nslookup -type=mx example.com
Verify the Mail Server Has an A Record
dig A mail1.example.com +short
# Output: 192.0.2.10
No A record = mail can't be delivered to that MX.
Common MX Configurations
Google Workspace
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.
Microsoft 365
example.com. MX 0 example-com.mail.protection.outlook.com.
(Microsoft provides a single MX; they handle redundancy internally)
Self-Hosted with Backup
example.com. MX 10 mail.example.com.
example.com. MX 20 backup.mailprovider.net.
Null MX: Rejecting Email
If a domain should never receive email:
example.com. MX 0 .
This is a "null MX" (RFC 7505). Sending servers immediately reject rather than attempting delivery. Useful for domains that only send, never receive.
MX Fallback to A Record
If no MX records exist, senders look for an A record and try to deliver directly:
# No MX record for example.com
# Sender tries: example.com A record → 192.0.2.1 port 25
This is a legacy fallback. Don't rely on it—always set explicit MX records.
Troubleshooting MX Issues
"Mail Loops Back to Myself"
The receiving server's hostname matches the sending server. Check:
- MX record points to different hostname than sending server
- Receiving server's
myhostnameis set correctly in Postfix
"Connection Refused" on MX
# Test connection to MX server
telnet mail.example.com 25
# or
nc -vz mail.example.com 25
Common causes:
- Firewall blocking port 25
- Mail server not running
- Wrong IP in A record
"No MX Record Found"
dig MX example.com +short
# Empty output = no MX records
Either add MX records or ensure the domain's A record accepts mail (not recommended).
Incorrect A Record for MX Hostname
dig A mail.example.com +short
# Empty or wrong IP
The MX hostname must resolve to an IP where a mail server listens on port 25.
Practitioner note: When clients report "email not arriving," I always check MX first. About 30% of the time, it's a DNS issue—expired domain, wrong MX after migration, or a typo in the hostname. Start with
dig MX domain.combefore investigating anything else.
MX and Email Security
Backup MX Security Risk
Backup MX servers are common attack targets. Spammers know:
- Backup servers may have weaker spam filtering
- They might forward to primary without proper checks
- Some backup services don't verify recipients
If using a third-party backup MX:
- Ensure they validate recipients (no backscatter)
- Confirm they apply spam filtering
- Verify they use TLS to your primary
MX for Security Services
Email security gateways (Mimecast, Proofpoint, Barracuda) sit in front of your mail server:
example.com. MX 10 inbound.security.net.
The security service's MX record points to their servers, which then forward clean mail to your actual mail server.
Migration Strategy
When moving mail servers:
- Lower TTL to 300-600 seconds, 24-48 hours before migration
- Add new server as low-priority MX (e.g., priority 30)
- Test delivery to new server
- Swap priorities - new server becomes priority 10
- Monitor for 24-48 hours
- Remove old server after confirming all mail routes correctly
- Restore TTL to normal (3600-86400 seconds)
If you need help planning an email infrastructure migration or troubleshooting MX routing issues, schedule a consultation.
Sources
- RFC 5321: Simple Mail Transfer Protocol (Section 5 - MX)
- RFC 974: Mail Routing and the Domain System (Original MX RFC)
- RFC 7505: A "Null MX" No Service Resource Record
- Google Workspace: MX Records Setup
- Microsoft 365: External DNS Records
v1.0 · March 2026
Frequently Asked Questions
What does MX priority mean?
MX priority determines the order mail servers are tried. Lower numbers mean higher priority—a server with priority 10 is tried before priority 20. If priority 10 fails, the sender tries 20. Equal priorities split traffic between servers (load balancing).
How many MX records should I have?
At minimum, two MX records pointing to different servers for redundancy. A primary (priority 10) and a backup (priority 20). Large organizations often have 3-5 for additional redundancy and geographic distribution.
What happens if all MX servers are down?
The sending server queues the message and retries. Typically, senders retry for 1-5 days before giving up and bouncing the message back. This is why MX redundancy matters—prolonged outages cause lost mail.
Can I use an IP address in an MX record?
No, MX records must point to hostnames, not IP addresses. The hostname then resolves via an A record (IPv4) or AAAA record (IPv6) to the actual IP. Example: MX points to mail.example.com, which has an A record to 192.0.2.1.
How long does MX record propagation take?
DNS propagation depends on TTL. With a 1-hour TTL, most servers see changes within 1-4 hours. With 24-hour TTL, it takes longer. For mail cutover, lower TTL to 300 seconds a day before the change.
Want this handled for you?
Free 30-minute strategy call. Walk away with a plan either way.