MX Records: Enabling Email Routing Across the Internet

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.

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.

Formal Definition

An MX record establishes a relationship between:

• Owner Name: The domain receiving email (e.g., example.com)
• Preference Value: A 16-bit unsigned integer indicating priority (lower = higher priority)
• Mail Exchanger: The hostname of the server accepting mail for this domain

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

Critical Design Principle: Hostnames, Not IP Addresses

Unlike SRV records or some modern service discovery mechanisms, MX records point to hostnames, not IP addresses. This is a deliberate architectural choice:

1. Flexibility: The mail server's IP can change without updating MX records
2. IPv4/IPv6 Abstraction: The hostname resolves to whatever address types the server supports
3. Load Balancing: The mail hostname can have multiple A/AAAA records
4. Indirection: Multiple domains can share the same mail infrastructure

The sending mail server must perform an additional DNS lookup to resolve the mail exchanger hostname to an IP address before connecting.

MX Record Wire Format

In DNS messages, an MX record appears with the following structure:

Why Type 15?

In the DNS type numbering scheme from RFC 1035:

• Type 1 = A (Address)
• Type 2 = NS (Nameserver)
• Type 5 = CNAME
• Type 6 = SOA (Start of Authority)
• Type 15 = MX (Mail Exchanger)

The type numbers were assigned sequentially as record types were defined in the original specification.

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.

The Lower-is-Better Rule

MX preference works on a lower value = higher priority system:

• Preference 10 is tried before preference 20
• Preference 0 is the highest possible priority
• Preference 65535 is the lowest possible priority

How Sending Servers Use Preference

When a mail server needs to deliver email to user@example.com:

1. Query MX records for example.com
2. Sort returned records by preference (lowest first)
3. Attempt delivery to the lowest-preference (highest-priority) server
4. On failure, try the next server in preference order
5. Repeat until delivery succeeds or all servers fail

If all servers fail, the sending server queues the message and retries later (typically for up to 5 days, per RFC 5321).

Example: Multi-Server Configuration

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:

1. First, try mail-primary.example.com (preference 10)
2. If unavailable, try mail-secondary.example.com (preference 20)
3. If still failing, try mail-backup.example.com (preference 30)

Equal Preference: Load Distribution

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.

Understanding how MX lookups integrate with SMTP delivery is essential for troubleshooting email problems and designing reliable mail infrastructure.

Complete Email Delivery Flow

When alice@sender.com sends email to bob@example.com:

Phase 1: Message Submission

1. Alice's email client submits the message to her outgoing mail server (MSA - Mail Submission Agent)
2. The MSA accepts the message and queues it for delivery

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.

The Null MX Record (RFC 7505)

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:

• Prevents unnecessary delivery attempts and retries
• Reduces backscatter spam from bounced messages
• Clearly documents that the domain has no mail capability
• Faster failure compared to waiting for timeouts

Implicit MX (Falling Back to A/AAAA)

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:

• Most hosts at A records don't run mail servers
• Creates confusion between web and mail infrastructure
• Modern domains should always have explicit MX records (or Null MX)
• Security policies (SPF, DMARC) assume explicit mail infrastructure

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.

How Backup MX Works

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:

1. Sending server attempts mail-primary.example.com
2. Connection fails (timeout, refused, etc.)
3. Sending server tries mail-backup.example.com
4. Backup server accepts and stores the message
5. Backup server later forwards to primary when it recovers

Store-and-Forward vs. Immediate Relay

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

Modern Alternative: Cloud Email Services

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:

• Reduces operational burden
• Provides automatic failover
• Maintains consistent security policies across all entry points
• Offers integrated spam/phishing protection

MX configuration interacts with modern email authentication systems. Understanding these relationships is critical for email deliverability.

SPF and MX Alignment

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:

1. Receiving server gets email claiming to be from user@example.com
2. Receiving server queries SPF record for example.com
3. SPF includes mx mechanism
4. Receiving server looks up MX records for example.com
5. For each MX, resolves to IP addresses
6. If sending IP matches any MX IP → SPF passes

This creates alignment between sending and receiving infrastructure—servers that receive mail for a domain are also authorized to send mail from it.

DMARC Organization Domain Alignment

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:

• Mail servers in MX should be in SPF
• DKIM signing should use the same domain
• Return-path domain should match From domain

Detecting Disposable/Temporary Domains

Recipient servers sometimes inspect sender MX records as a heuristic:

1. No MX record: Suspicious—domain can send but not receive
2. Null MX: Domain explicitly doesn't accept mail
3. MX pointing to known spam/bulletproof hosts: Negative signal
4. Very recent domain with minimal MX setup: Suspicious

To maximize deliverability, ensure your sending domain has legitimate MX records, even if you primarily use it for outbound-only communication.

The "MX Doesn't Accept Connections" Anti-Spam Pattern

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:

• This technique is largely deprecated
• Modern spam botnets follow RFC correctly
• It can slow legitimate backup delivery
• Not recommended for production use

MX records are high-value targets for attackers. Compromising or manipulating MX records enables email interception, phishing, and domain hijacking.

Attack Vectors

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.

Defense Mechanisms

DNSSEC for MX Records

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 (Mail Transfer Agent Strict Transport Security)

MTA-STS (RFC 8461) enables domains to declare that mail servers should use TLS:

1. Domain publishes _mta-sts.example.com TXT record
2. Domain hosts policy file at https://mta-sts.example.com/.well-known/mta-sts.txt
3. Policy file specifies allowed MX hosts and TLS requirements
4. Sending servers cache and enforce the policy

; 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 (DNS-Based Authentication of Named Entities)

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.

Diagnostic Commands

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.