← RFC Reference

DNS and Mail Routing

How DNS drives the entire email delivery path — MX records, priority and failover, A/AAAA fallback, Null MX, PTR records, and the DNS records that every sending domain needs.

The Mail Routing Algorithm

When a sending server needs to deliver a message to user@example.com, it follows this algorithm, defined in RFC 5321 Section 5:

1. Query MX records for example.com
2. If MX records exist, sort by priority (lowest number = highest preference)
3. For each MX hostname, resolve its A and/or AAAA records to get IP addresses
4. Try connecting to the highest-priority MX. If it fails, try the next one.
5. If no MX records exist (NODATA response), fall back to the domain's A/AAAA record and attempt delivery there
6. If the MX record is a Null MX (0 .), the domain does not accept mail — generate a permanent failure
7. If the domain does not exist at all (NXDOMAIN), generate a permanent failure

MX Records

The MX (Mail Exchanger) record is the primary DNS record type for mail routing. It maps a domain to one or more mail servers with priorities:

Each record has two parts:

• Priority (preference value) — Lower numbers are tried first. The sending server always attempts the lowest-priority MX first.
• Exchange (hostname) — The mail server to connect to. This must be a hostname, never an IP address. The hostname must have an A or AAAA record.

Priority and failover

In the example above, the sender tries mx1.example.com first (priority 10). If that server is unreachable, returns a 4xx temporary error, or the connection times out, the sender tries mx2.example.com (priority 20), then mx-backup.example.com (priority 30).

If multiple MX records share the same priority, the sender should randomize among them. This provides load balancing:

Here, all three servers have equal priority. The sending server picks one at random for each delivery attempt, distributing load across all three.

MX must point to a hostname, not an IP

An MX record's exchange field must be a hostname. It cannot be an IP address (RFC 5321 is explicit about this). The hostname itself must resolve to an A and/or AAAA record. It must not be a CNAME — while some resolvers tolerate MX targets that are CNAMEs, this is technically forbidden and causes interoperability problems.

MX must not point to a CNAME

This is a common misconfiguration. If mx1.example.com is a CNAME pointing to mail.provider.com, some sending servers will fail to deliver. Always use A/AAAA records for MX targets.

A/AAAA Fallback

If a domain has no MX records at all (not even a Null MX), the sending server falls back to the domain's A or AAAA record and attempts SMTP delivery there. This is called the "implicit MX" rule.

The sending server will attempt to deliver to 198.51.100.50 on port 25. This works, but it is considered bad practice for any domain that actively sends or receives mail. Always publish explicit MX records.

The fallback only applies when there are zero MX records. If MX records exist but all MX hosts are unreachable, the sender does not fall back to the A record — it queues the message for retry.

Null MX: "This Domain Does Not Accept Mail"

RFC 7505 defines the Null MX — a way to explicitly declare that a domain does not accept email:

The single dot (.) as the exchange, with priority 0, means "do not attempt delivery." The sending server should immediately generate a permanent failure (5.1.2 — bad destination system) rather than wasting time connecting.

Use Null MX for:

• Domains that only send email and never receive it
• Parked domains
• Domains used exclusively for website hosting

Without a Null MX, senders will fall back to the A record and waste time attempting connections that will never succeed.

PTR Records: Reverse DNS

A PTR record maps an IP address back to a hostname. It is the reverse of an A record:

PTR records are not part of the MX routing algorithm, but they are critical for deliverability. Most major mailbox providers check the PTR record of the connecting server's IP address:

• The IP must have a PTR record (missing PTR = likely spam)
• The PTR hostname should resolve back to the same IP (forward-confirmed reverse DNS, or FCrDNS)
• The PTR hostname should not look "generic" (e.g., 198-51-100-42.dynamic.isp.com suggests a residential connection)

PTR records are managed by the owner of the IP address block (typically your hosting provider or ISP), not through your domain's DNS. You may need to contact your provider to set or change PTR records.

DNS Records Every Sending Domain Needs

Here is the complete set of DNS records for a domain that sends email through a service like Mailer To Go:

For a domain that sends but does not receive mail (e.g., a subdomain used for transactional email):

TTL Considerations

DNS records have a Time To Live (TTL) that controls how long resolvers cache them. For mail-related records:

• MX records: 1 hour (3600) is typical. Lower TTLs allow faster failover but increase DNS query load.
• SPF/DKIM/DMARC records: 1 hour is common. Use shorter TTLs (300 seconds) during initial setup or changes, then increase.
• A/AAAA records for MX hosts: 5 minutes to 1 hour. Shorter if you need rapid IP changes.

When making DNS changes, reduce the TTL before the change (wait for the old TTL to expire), make the change, verify, then increase the TTL back to the operational value.

DNSSEC and Mail

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, preventing spoofing and cache poisoning. For email, DNSSEC is particularly important because:

• It authenticates MX records — an attacker cannot redirect mail to a rogue server by poisoning DNS
• It is required for DANE (DNS-Based Authentication of Named Entities), which binds TLS certificates to DNS
• It authenticates SPF, DKIM public key, and DMARC records

Without DNSSEC, a network attacker can forge DNS responses and redirect or intercept email. DNSSEC adoption for email domains is increasing but not yet universal.

SRV Records for Email Submission

RFC 6186 defines SRV records that mail clients can use to automatically discover submission and IMAP/POP servers:

These are used for mail client autoconfiguration — when a user types their email address, the client queries SRV records to find the correct server, port, and protocol. This is separate from MX-based server-to-server routing.

What Can Go Wrong

Missing MX records

Without MX records, senders fall back to your A record. If your web server is not running an SMTP server on port 25, mail delivery fails after timeout. Always publish explicit MX records, or a Null MX if you don't accept mail.

MX pointing to a CNAME

As noted above, this is technically invalid. Some senders will follow the CNAME; others will fail. Use A/AAAA records for all MX target hostnames.

Circular MX references

If example.com has an MX pointing to mail.example.com, and mail.example.com has its own MX pointing back to example.com, mail can loop. MX targets should be leaf hostnames with A/AAAA records only.

Missing PTR record

Your sending IP has no reverse DNS, or it resolves to a generic ISP hostname. Major mailbox providers (Gmail, Microsoft, Yahoo) will defer or reject your mail. Ensure your sending IPs have PTR records that resolve forward to the same IP.

DNS timeout during delivery

If the recipient domain's DNS servers are slow or unreachable, the sending server cannot resolve MX records. The message is queued for retry. Persistent DNS failures eventually result in a bounce (typically after 4-5 days). There is nothing you can do as a sender — this is the recipient's infrastructure problem.

SPF record exceeds DNS UDP limit

DNS responses over UDP are limited to 512 bytes (or 4096 with EDNS0). A very long SPF record with many include: directives may be truncated. The resolver falls back to TCP, which adds latency and may fail if the DNS server does not support TCP. Keep your SPF record concise.

Debugging DNS for Mail

Essential commands for diagnosing mail routing issues:

Key Takeaways

• MX records are the primary mechanism for mail routing. Lower priority numbers are tried first.
• If no MX records exist, senders fall back to the A/AAAA record. Publish explicit MX records (or Null MX) to avoid ambiguity.
• MX targets must be hostnames with A/AAAA records — never IPs, never CNAMEs.
• PTR records (reverse DNS) are not part of routing but are essential for deliverability. Every sending IP needs a PTR that matches a forward A record.
• A complete sending domain needs MX (or Null MX), SPF, DKIM, and DMARC records at minimum.
• Use dig to verify every DNS record before and after changes.

Further Reading

Related RFCs