MX Records Deep Dive: Email Routing Explained

## What Is an MX Record? An MX record (Mail Exchanger record) is a DNS (Domain Name System) record type that specifies which mail server is responsible for accepting email messages on behalf of a domain. When someone sends an email to `[email protected]`, their mail server performs a DNS lookup asking: "Who accepts email for `example.com`?" The MX records for that domain answer that question. Without MX records, email cannot be delivered to your domain. With incorrect MX records, email is misrouted. Understanding how they work — not just the values to copy-paste — helps you configure them correctly and debug problems when they arise. ## The DNS Lookup Process for Email Here's exactly what happens when someone sends you an email: 1. **Sender's mail server** receives the message and needs to deliver it 2. **DNS resolver query**: The server queries its resolver for MX records on `yourdomain.com` 3. **Resolver** checks its cache; if no cached result, queries authoritative nameservers 4. **Nameserver** for `yourdomain.com` returns the MX records 5. **Priority selection**: The sending server selects the MX record with the lowest priority number 6. **A record lookup**: The server looks up the A Record (or AAAA for IPv6) for the MX hostname to get its IP address 7. **SMTP connection**: The sending server opens a TCP connection to port 25 on that IP address 8. **Message delivery**: The SMTP handshake occurs and the message is transferred This lookup happens billions of times per day across the internet. The entire process typically takes milliseconds. ## Understanding Priority Numbers Every MX record has a priority value (sometimes called preference). The priority is an integer between 0 and 65535, where **lower numbers indicate higher priority**. ``` Priority Mail Server 1 primary-mail.example.com 5 backup1-mail.example.com 10 backup2-mail.example.com ``` A sending mail server always tries the lowest-priority (numerically smallest) server first. If that server is unreachable or returns an error, it tries the next-lowest priority server, and so on. ### Why Multiple MX Records? Multiple MX records provide redundancy. If the primary mail server is down for maintenance or experiencing an outage, email isn't lost — it queues at the sending server and tries again, or immediately fails over to a backup server. This is critical for business continuity. Email that can't be delivered is typically queued for up to 5 days before being bounced back to the sender. ### Equal Priority Records (Load Balancing) When multiple MX records have the same priority value, the sending server picks one at random. This is how Google Workspace achieves load balancing: ``` Priority Mail Server 1 ASPMX.L.GOOGLE.COM ← Always tried first 5 ALT1.ASPMX.L.GOOGLE.COM ← Tried second, randomly 5 ALT2.ASPMX.L.GOOGLE.COM ← Tried second, randomly 10 ALT3.ASPMX.L.GOOGLE.COM ← Tried third, randomly 10 ALT4.ASPMX.L.GOOGLE.COM ← Tried third, randomly ``` The primary server handles normal traffic. If it's overloaded or unavailable, the two priority-5 servers share the overflow equally. The priority-10 servers are the final fallback. ## MX Record Format An MX record has three fields beyond the standard DNS record fields: ``` Name TTL Class Type Priority Exchange example.com 3600 IN MX 10 mail.example.com. ``` - **Name**: The domain (or subdomain) for which this record applies - **TTL**: TTL (Time To Live) in seconds — how long resolvers may cache this record - **Priority**: Preference value (lower = higher priority) - **Exchange**: The fully qualified hostname of the mail server ### Important: MX Records Must Point to Hostnames, Not IPs The Exchange field of an MX record must be a hostname, never an IP address. The hostname must itself have an A Record (or AAAA record) in DNS. You cannot write: ``` MX @ 10 192.168.1.1 ← WRONG: IP addresses not allowed ``` This is defined in RFC 5321 and RFC 2181. Mail servers that receive an IP address in an MX record will typically reject it. ### MX Records Cannot Point to CNAMEs The Exchange hostname must be an A Record, not a CNAME Record. This is another RFC restriction. While some mail servers may handle this gracefully, it's technically invalid and can cause subtle delivery failures: ``` MX @ 10 mail.example.com ← CORRECT: points to an A record MX @ 10 myalias.example.com ← WRONG: if myalias is a CNAME ``` ## TTL Considerations for MX Records The TTL (Time To Live) on MX records affects how quickly email routing changes propagate when you switch providers. **During a migration:** 1. **Before changing**: Lower your MX record TTL to 300 seconds (5 minutes) 2. **Wait**: Allow the current high TTL to expire (e.g., if TTL was 86400, wait 24 hours) 3. **Change records**: Remove old MX records, add new ones 4. **Propagation**: New records take effect within 5 minutes (the new, lower TTL) 5. **After stabilizing**: Raise TTL back to 3600 or higher If you change MX records while the old TTL is still high, some mail servers will continue routing to the old server until their cache expires. ## Verifying MX Records ### Using dig ```bash dig MX yourdomain.com ``` Output: ``` ;; ANSWER SECTION: yourdomain.com. 3600 IN MX 1 ASPMX.L.GOOGLE.COM. yourdomain.com. 3600 IN MX 5 ALT1.ASPMX.L.GOOGLE.COM. yourdomain.com. 3600 IN MX 5 ALT2.ASPMX.L.GOOGLE.COM. yourdomain.com. 3600 IN MX 10 ALT3.ASPMX.L.GOOGLE.COM. yourdomain.com. 3600 IN MX 10 ALT4.ASPMX.L.GOOGLE.COM. ``` ### Using nslookup (Windows) ``` nslookup -type=MX yourdomain.com ``` ### Using Online Tools The DNS Record Helper provides easy MX record lookup without command-line access. MXToolbox (mxtoolbox.com) offers more detailed diagnostics including SMTP testing. ## MX Records for Subdomains MX records can be set for subdomains independently of the root domain. This enables routing email for different departments or purposes to different servers: ``` MX @ 10 mail.example.com ← [email protected] MX support 10 helpdesk.example.com ← [email protected] MX marketing 10 sendgrid.net ← [email protected] ``` Each subdomain has its own independent set of MX records, SPF records, and DKIM keys. ## Null MX Records: Explicitly Rejecting Email If you want to explicitly declare that a domain or subdomain does not accept email — preventing delivery attempts and reducing backscatter spam — you can add a null MX record as defined in RFC 7505: ``` Type Host Priority Value MX @ 0 . ``` The single dot (`.`) as the exchange value signals that no mail should be delivered. This is useful for parked domains and subdomains used only for technical purposes. ## Common MX Record Problems **Split delivery**: Old and new MX records both present simultaneously. Remove old records before adding new ones. **Trailing dot issues**: Some DNS providers require fully qualified domain names (FQDN) with trailing dots (`mail.example.com.`), others don't. Follow your provider's convention. **Propagation delays**: DNS Propagation can take minutes to hours. Don't panic if MX changes don't take effect immediately. Use DNS Record Helper to check propagation status across global resolvers. **MX pointing to CNAME**: Technically invalid. Always ensure your MX Exchange hostname resolves to an A record directly. **Missing A record for MX hostname**: If your MX record points to `mail.yourdomain.com` but that hostname has no A record, email delivery fails. Verify the MX hostname has a valid A Record. **Reverse DNS mismatch**: When your mail server connects to deliver email, receiving servers check that the Reverse DNS (PTR Record) (PTR record) of the sending IP matches the mail server's hostname. Mismatches can trigger spam filters. ## Reading MX Records for Popular Services | Service | Primary MX | Priority | |---|---|---| | Google Workspace | ASPMX.L.GOOGLE.COM | 1 | | Microsoft 365 | {tenant}-com.mail.protection.outlook.com | 0 | | Zoho Mail | mx.zoho.com | 10 | | Fastmail | in1-smtp.messagingengine.com | 10 | | ProtonMail | mail.protonmail.ch | 10 | ## Next Steps - **Custom Email with Your Domain: Complete Setup Guide** — Full email setup walkthrough using MX records - **SPF, DKIM, DMARC: Email Authentication Trilogy** — Authentication records that work alongside MX - **Troubleshooting Email Delivery Issues** — Diagnosing MX record problems - **Email Deliverability: How Domain Reputation Matters** — How MX configuration affects reputation