Loading learning content...
Email is one of the oldest and most critical applications on the Internet. When you send an email to user@example.com, how does the message find its way to the right mail server among millions connected to the Internet? The answer lies in a specialized DNS record type: the MX record (Mail Exchanger record).
MX records represent a fundamental architectural decision in Internet design—the separation of mail handling from web hosting. Unlike A records that directly map domain names to IP addresses, MX records introduce a layer of indirection, pointing to hostnames (not IP addresses) responsible for receiving email. This indirection enables sophisticated mail routing, failover, and load distribution.
This page provides exhaustive coverage of MX records: their internal structure, priority mechanics, lookup process, security implications, and real-world deployment patterns. You will emerge with complete understanding of how email finds its destination.
By the end of this page, you will understand: (1) The complete structure and wire format of MX records, (2) Priority/preference mechanics for mail server selection, (3) The SMTP delivery process using MX lookups, (4) Backup mail server configuration for reliability, (5) Common anti-spam patterns in MX configuration, and (6) MX record security considerations including SPF alignment.
The MX record (Mail Exchanger record) is defined in RFC 1035 and RFC 5321 (SMTP specification). Its purpose is to identify which servers are responsible for accepting email on behalf of a domain.
An MX record establishes a relationship between:
example.com)The abstract representation:
<owner-name> IN MX <preference> <mail-exchanger>
For example:
example.com. 3600 IN MX 10 mail.example.com.
This record declares: "Email for @example.com should be sent to mail.example.com with preference 10."
Unlike SRV records or some modern service discovery mechanisms, MX records point to hostnames, not IP addresses. This is a deliberate architectural choice:
The sending mail server must perform an additional DNS lookup to resolve the mail exchanger hostname to an IP address before connecting.
In DNS messages, an MX record appears with the following structure:
| Field | Size | Description |
|---|---|---|
| NAME | Variable | Domain receiving mail |
| TYPE | 2 bytes | Record type = 15 (MX record) |
| CLASS | 2 bytes | Class = 1 (IN = Internet) |
| TTL | 4 bytes | Time-to-live in seconds |
| RDLENGTH | 2 bytes | Length of RDATA (preference + hostname) |
| PREFERENCE | 2 bytes | 16-bit priority value |
| EXCHANGE | Variable | Hostname of mail server (may use compression) |
In the DNS type numbering scheme from RFC 1035:
The type numbers were assigned sequentially as record types were defined in the original specification.
RFC 2181 explicitly states that MX records MUST point directly to A/AAAA records, NOT to CNAME records. While some resolvers tolerate this misconfiguration, it creates undefined behavior, can break DNSSEC validation, and may cause mail delivery failures. Always ensure your MX target has A and/or AAAA records directly.
The preference value (sometimes called priority) is a 16-bit unsigned integer that determines the order in which mail servers should be tried. Understanding this mechanism is essential for designing resilient email infrastructure.
MX preference works on a lower value = higher priority system:
When a mail server needs to deliver email to user@example.com:
example.comIf all servers fail, the sending server queues the message and retries later (typically for up to 5 days, per RFC 5321).
Consider this zone file excerpt:
example.com. 3600 IN MX 10 mail-primary.example.com.
example.com. 3600 IN MX 20 mail-secondary.example.com.
example.com. 3600 IN MX 30 mail-backup.example.com.
Delivery behavior:
mail-primary.example.com (preference 10)mail-secondary.example.com (preference 20)mail-backup.example.com (preference 30)When multiple MX records have equal preference values, sending servers should distribute load among them:
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 10 mail2.example.com.
example.com. 3600 IN MX 10 mail3.example.com.
RFC 5321 specifies that when multiple MX records have equal preference, the sending server SHOULD randomize selection among them. This provides basic load balancing without requiring external infrastructure.
| Pattern | Configuration | Use Case |
|---|---|---|
| Single Server | MX 10 mail.example.com. | Simple setups, small organizations |
| Primary + Backup | MX 10 primary. / MX 20 backup. | Basic redundancy |
| Load Balanced | MX 10 mail1. / MX 10 mail2. | Distribute load across equal servers |
| Geographic | MX 10 us-mail. / MX 20 eu-mail. | Route by geography with fallback |
| Provider Failover | MX 10 gsuite. / MX 20 self-hosted. | Fallback to backup provider |
Use spacing (10, 20, 30) rather than consecutive numbers (1, 2, 3) for preference values. This allows inserting additional servers without renumbering existing records. Need a server between 10 and 20? Use 15. This convention is nearly universal in practice.
Understanding how MX lookups integrate with SMTP delivery is essential for troubleshooting email problems and designing reliable mail infrastructure.
When alice@sender.com sends email to bob@example.com:
Phase 1: Message Submission
Phase 2: MX Resolution
3. Alice's mail server extracts the domain from the recipient: example.com
4. It queries DNS for MX records: dig MX example.com
5. DNS returns: MX 10 mail.example.com. (and any additional MX records)
6. The server sorts results by preference
Phase 3: Target Resolution
7. For each MX target, resolve to IP address: dig A mail.example.com
8. DNS returns: A 93.184.216.34 (and potentially AAAA for IPv6)
Phase 4: SMTP Connection 9. Connect to the resolved IP on port 25 (SMTP) 10. Execute SMTP protocol to transfer the message 11. On success: delivery complete. On failure: try next MX.
Some domains are not configured to receive email—they're purely for web services, APIs, or other purposes. For these domains, RFC 7505 defines the Null MX record:
example.com. 3600 IN MX 0 .
The . (a single dot representing the root label) as the mail exchanger explicitly signals that the domain does not accept email. Sending servers should immediately return a permanent failure (550 error) rather than attempting delivery.
Benefits of Null MX:
RFC 5321 specifies that if no MX record exists for a domain, the sender should fall back to the domain's A or AAAA record:
If no MX records are found:
1. Look up A record for the domain
2. If found, treat as MX with preference 0
3. Attempt delivery to that IP on port 25
This is a legacy fallback mechanism and is NOT recommended:
Email is often business-critical, and backup MX configuration ensures mail delivery continues even when primary servers are unavailable. However, backup mail server architecture requires careful planning to avoid security risks.
example.com. 3600 IN MX 10 mail-primary.example.com.
example.com. 3600 IN MX 20 mail-backup.example.com.
When the primary server is unreachable:
mail-primary.example.commail-backup.example.comStore-and-Forward (Recommended) The backup server queues messages locally and attempts delivery to the primary at regular intervals. When the primary returns, queued messages are delivered.
Immediate Relay The backup server attempts to immediately relay to the primary. If the primary is down, the message is stored and retried.
Store-and-forward is more resilient but requires the backup server to have adequate storage and queue management capabilities.
Misconfigured backup MX servers are a major spam vector. Spammers target backup servers because they're often less protected than primaries. If your backup accepts mail for your domain without proper authentication and filtering, it becomes a spam relay. Backup MX servers MUST implement SPF checking, DKIM verification, and spam filtering identical to primary servers.
Many organizations now use managed email services (Google Workspace, Microsoft 365, Proofpoint, Mimecast) that handle redundancy internally:
; Google Workspace example
example.com. 3600 IN MX 1 aspmx.l.google.com.
example.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
example.com. 3600 IN MX 5 alt2.aspmx.l.google.com.
example.com. 3600 IN MX 10 alt3.aspmx.l.google.com.
example.com. 3600 IN MX 10 alt4.aspmx.l.google.com.
The provider manages failover between data centers, eliminating the need for self-hosted backup MX. This approach:
MX configuration interacts with modern email authentication systems. Understanding these relationships is critical for email deliverability.
SPF (Sender Policy Framework) validates that the sending server is authorized to send email for a domain. A common SPF mechanism is the mx qualifier:
example.com. 3600 IN TXT "v=spf1 mx a ip4:192.0.2.0/24 -all"
The mx mechanism in SPF means: "Allow any IP address that our MX records point to to send mail for this domain."
How it works:
user@example.comexample.commx mechanismexample.comThis creates alignment between sending and receiving infrastructure—servers that receive mail for a domain are also authorized to send mail from it.
DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM. It requires that the domain in the From: header aligns with the domain that passed SPF or DKIM.
MX records don't directly affect DMARC, but your mail infrastructure must be consistent:
Recipient servers sometimes inspect sender MX records as a heuristic:
To maximize deliverability, ensure your sending domain has legitimate MX records, even if you primarily use it for outbound-only communication.
Some organizations implement a controversial pattern called a "defensive" or "tarpit" MX:
example.com. 3600 IN MX 10 mail-real.example.com.
example.com. 3600 IN MX 99 null.example.com. ; Accepts no connections
The theory: Legitimate mail servers try the lowest priority first. Spammers, seeking efficiency, sometimes try the highest-priority (highest-number) servers first, expecting them to be less protected.
If null.example.com doesn't respond or has no A record, spammers using this optimization waste time. However:
For best deliverability, ensure all domains you send from have: (1) Valid MX records pointing to hosts with A/AAAA records, (2) SPF records that include your sending IPs, (3) DKIM signing enabled, and (4) DMARC policy at least at p=none for reporting. This consistent configuration signals legitimacy to receiving servers.
MX records are high-value targets for attackers. Compromising or manipulating MX records enables email interception, phishing, and domain hijacking.
1. DNS Hijacking Attackers compromise DNS infrastructure and modify MX records to point to their mail servers. All incoming email is then copied or redirected.
2. Cache Poisoning Attackers inject false MX records into resolver caches. Sending servers are tricked into delivering mail to attacker servers.
3. Registrar Account Compromise Attackers gain access to domain registrar accounts and change nameserver or DNS record settings, including MX records.
4. BGP Hijacking Attackers announce routes for the IP addresses in MX records, intercepting SMTP connections without modifying DNS.
DNSSEC signs MX records with RRSIG records, preventing spoofing:
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN RRSIG MX 13 2 3600 20240601000000 20240501000000 ...
Validating resolvers reject forged MX records that lack valid signatures.
MTA-STS (RFC 8461) enables domains to declare that mail servers should use TLS:
_mta-sts.example.com TXT recordhttps://mta-sts.example.com/.well-known/mta-sts.txt; MTA-STS DNS record
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20240101"
Policy file example:
version: STSv1
mode: enforce
mx: mail.example.com
mx: backup.example.com
max_age: 604800
DANE (RFC 7671) publishes TLS certificate information in DNS:
_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 ABC123...
The TLSA record binds a specific certificate (or CA) to the mail server. Combined with DNSSEC, this prevents man-in-the-middle attacks on SMTP connections.
Email delivery failures often trace back to MX configuration issues. Here's a systematic approach to diagnosis.
Query MX records directly:
# Using dig
dig MX example.com +short
# Using nslookup
nslookup -type=mx example.com
# Using drill (DNSSEC-aware)
drill MX example.com
Resolve MX targets:
dig A mail.example.com +short
dig AAAA mail.example.com +short
Test SMTP connectivity:
# Test port 25 connection
nc -zv mail.example.com 25
# Interactive SMTP session
openssl s_client -connect mail.example.com:25 -starttls smtp
Check from multiple locations: Use services like MXToolbox, DNSChecker, or dig from multiple vantage points to verify global propagation.
| Symptom | Possible Cause | Diagnostic | Solution |
|---|---|---|---|
| No MX record found | Missing or deleted record | dig MX domain.com | Add MX record to zone |
| MX target doesn't resolve | Missing A/AAAA for MX host | dig A mx-host.domain.com | Add A/AAAA for mail server |
| Connection refused port 25 | Firewall blocking SMTP | nc -zv host 25 | Open port 25 in firewall |
| MX points to CNAME | RFC violation | dig MX then dig host | Change to point directly to A/AAAA |
| Mail loops back | MX points to sending server | Check all MX targets | Correct MX targets |
| High-priority MX unreachable | Network/server failure | Test each MX in order | Fix network or fail over |
| Backscatter increasing | Open relay on backup MX | Check relay configuration | Restrict relay to known domains |
Use test email services like Mail-Tester.com or CheckTLS.com to verify your MX configuration, SPF/DKIM/DMARC alignment, and TLS support. These tools simulate real-world delivery and flag common issues.
We've conducted a comprehensive exploration of MX records—the DNS mechanism enabling email routing across the Internet. Let's consolidate the essential knowledge:
You now possess Principal Engineer-level understanding of MX records—from wire format to delivery mechanics, backup configuration to security hardening. In the next page, we'll explore CNAME records, which enable powerful aliasing and indirection capabilities within DNS.