Pedro Paiva

Email learning series

How DNS tells email servers where to deliver a message

By Pedro Paiva

Before transferring a message to reader@example.net, a sending system needs a destination server. DNS supplies routing information for example.net; it doesn’t list valid individual mailboxes.

Start with MX, then resolve the host

An MX record names a mail exchanger and a preference number. Lower numbers are preferred. A sender resolves the selected host’s A and/or AAAA records to connect over IPv4 or IPv6. Equal-preference exchangers should be randomized to spread traffic; senders must be prepared to try alternative destinations under SMTP’s routing rules rather than treating the first failure as proof of permanent failure.

Install your operating system’s dig package (often dnsutils or bind-utils). These commands are real commands, but all output below is invented. Reserved example domains are not public fixtures with these records. Substitute a domain you control for an actual investigation.

dig example.net MX
dig mx1.example.net A
dig mx1.example.net AAAA

Illustrative answer sections:

example.net.       300 IN MX   10 mx1.example.net.
example.net.       300 IN MX   20 mx2.example.net.
mx1.example.net.   300 IN A    192.0.2.25
mx1.example.net.   300 IN AAAA 2001:db8::25

Preference 20 is a fallback, not a second delivery recipient. Inspect mx2’s addresses too when diagnosing failure. Both documentation IPs above are non-production examples. An MX target should be a hostname with address records, not a literal IP or an alias used as an exchanger target.

No MX is different from “no mail”

An existing domain with no MX answer can have an implicit MX: SMTP treats the domain itself as the exchanger and looks for its address records. For an illustrative fallback.example.org, inspect:

dig fallback.example.org MX
dig fallback.example.org A
dig fallback.example.org AAAA

The mock MX reply is status: NOERROR, with zero answers; the mock A reply is fallback.example.org. 300 IN A 192.0.2.30. This is potential routing via the address record, not confirmation that an SMTP service is listening. If actual MX records exist but their targets are unusable, do not replace them with this no-MX fallback.

A null MX explicitly declares that the domain accepts no email:

nomail.example.org. 300 IN MX 0 .

Run dig nomail.example.org MX on your own configured test fixture to see that shape. The root name . is the null target, not a hostname to resolve. A null MX must not coexist with ordinary MX records. It prevents senders from trying an incidental web-server address as an implicit mail destination.

Read DNS status before blaming the mailbox

Keep the normal dig output rather than only +short during diagnosis: a blank short answer hides distinctions.

DNS evidence Meaning for routing
NOERROR, no MX answers Domain exists; investigate address fallback where applicable.
NXDOMAIN Queried domain does not exist; not the same as missing MX.
SERVFAIL or a timeout Lookup failed temporarily; defer and retry rather than inventing a permanent recipient failure.
Null MX Domain explicitly declines email service.

A timeout might display communications error ... timed out; a synthetic SERVFAIL response has status: SERVFAIL and no usable answer. Try a known resolver and inspect DNSSEC or authoritative-server failures when appropriate. Cached answers can remain until their TTL expires, so a recent change need not be visible everywhere immediately.

MX routing gets us to a server. Only the receiving system can accept or reject reader, and even final SMTP acceptance isn’t proof of inbox placement. Keep DNS evidence and message-delivery evidence separate in incident notes.

References