How DNS Mail Exchanger (MX) Records Route the World's Email
When an email is sent to an address such as [email protected], the sending Mail Transfer Agent (MTA) does not immediately know what IP address should receive the transmission. Instead, the sender's server initiates a Domain Name System (DNS) query requesting the MX (Mail Exchanger) Resource Records for the domain.
Standardized by RFC 1035 and updated by RFC 5321, an MX record pairs a target hostname (such as aspmx.l.google.com) with a 16-bit integer representing itspreference value (priority). Senders must attempt delivery to the server with the lowest numerical preference value first. If the primary server is unreachable or offline, the sender proceeds sequentially to servers with higher preference values.
Preference Values and Primary vs. Backup MX Servers
A common misconception among junior systems administrators is that a higher MX number indicates a higher priority. In fact, the opposite is true: lower numbers take strict precedence.
Directs incoming traffic to the primary production mail cluster. Modern cloud suites (Google Workspace, Microsoft 365) frequently assign identical low priority numbers across multiple hosts to distribute load evenly across global data centers.
Acts as a store-and-forward spooler when the primary cluster is experiencing an outage. Caution: spammers frequently target backup MX servers because they historically enforced weaker spam filtering than primary clusters.
The RFC 5321 Implicit A-Record Fallback Trap
Section 5.1 of RFC 5321 mandates a legacy fallback behavior: "If no MX records are published for a domain, the sending SMTP client must treat the domain as though it published an MX record with preference 0 pointing to the domain's A or AAAA record."
This fallback frequently causes severe infrastructure issues:
- Web Server Connection Floods: If your apex domain points to a cloud CDN or static website (e.g., Vercel, Cloudflare, AWS CloudFront), senders will attempt to open raw TCP port 25 connections against the web server, which immediately drops the packets or times out.
- Null MX Protection (RFC 7505): For domains that intentionally do not receive email (such as API subdomains or marketing redirectors), publishing a Null MX record (
0 .) instructs sending mail servers that the domain does not accept email, preventing unauthorized relaying and unwanted retry timeouts.
Frequently Asked Questions (FAQ)
Propagation depends entirely on your previous record's Time to Live (TTL) value. If your TTL was set to 3600 seconds (1 hour), external resolvers will flush their caches within 60 minutes. When planning a mail server migration, it is best practice to reduce TTL to 300 seconds (5 minutes) 48 hours prior to switching.
No. RFC 2181 Section 10.3 strictly mandates that the target of an MX record must be a valid, fully qualified domain name (FQDN) that resolves to an A or AAAA record. Pointing an MX record directly to an IP address or a CNAME alias violates internet standards and causes major MTAs to reject your mail.
MX records govern incoming mail delivery by telling the world which servers receive email for your domain. In contrast, SPF records govern outgoing mail authentication by specifying which servers are authorized to send email on behalf of your domain. Both are essential for email reliability and anti-spoofing protection.