MX, DNS, and mail routing explained

Email addresses are readable strings, but the system that routes them is not. When a message leaves a sender's outbox, a chain of DNS lookups and server conversations decides where it ends up — and when that chain has a weak link, mail vanishes without anyone doing anything wrong.

This explains what each piece does, in the order it is used.

DNS: the lookup layer

The Domain Name System maps names to information about them. Most people meet it as the thing that turns a website name into a server address, but DNS holds several kinds of record, and email depends on a few of them.

Records relevant to mail:

MX — which server receives mail for the domain
A / AAAA — the address of a host, used once an MX record names one
TXT — carries SPF policies and DMARC policies as text
CNAME — often used to point DKIM records at a mail provider's keys

Two properties matter in practice. Authority: only one DNS provider is authoritative for a domain at any time, which is why editing records at your registrar has no effect if your nameservers point elsewhere — a very common source of "I changed it and nothing happened." TTL: each record carries a lifetime telling other servers how long to cache it, so a change is not instant. A record with a 24-hour TTL can serve stale answers for a day.

MX records: which server gets the mail

MX stands for Mail Exchange. Each record names a hostname and a priority number.

example.com.  MX  10  mail1.example.com.
example.com.  MX  20  mail2.example.com.

Lower numbers are preferred. A sending server tries priority 10 first and falls back to 20 only if the first is unreachable. Equal numbers mean the load is shared between them.

Two details that cause real problems:

An MX record must point to a hostname, not an IP address — the hostname then resolves via its own A record. MX records pointing directly at an IP are invalid and some servers reject them outright.

Subdomains are separate. Mail for mail.example.com is routed by that subdomain's own MX records. A catch-all or mail setup on the parent domain does not extend downward automatically.

If a domain has no MX record at all, some senders fall back to its A record and attempt delivery to the web server — which usually is not running a mail service, so the mail is refused.

Looking up your own records

dig MX example.com +short
nslookup -type=mx example.com

Compare the output against what your mail provider's documentation specifies. The two most common faults are visible immediately: records from a previous provider still present alongside the new ones, and records that simply do not match the provider's published values.

SMTP: the delivery conversation

Once the sending server knows which host to contact, it opens a connection and holds a short structured exchange.

Greeting, and identification of the sending host
MAIL FROM — the return path for bounces
RCPT TO — the recipient address
The receiving server accepts, rejects, or defers that recipient
DATA — the message itself
A final response code

Response codes fall into three families, and the family matters more than the specific number:

2xx — accepted
4xx — temporary; the sender will retry, typically for a day or more
5xx — permanent; the sender gives up and generates a bounce

Greylisting exploits the 4xx family deliberately: an unfamiliar sender is refused once on purpose, because legitimate mail servers retry and much bulk spam does not.

The critical thing to understand is that the conversation ends at acceptance. What happens next — inbox, spam folder, quarantine, a rule that deletes it — is a separate decision the receiving system makes on its own, invisible to the sender.

SPF, DKIM, and DMARC: the trust layer

These do not route mail. They let a receiving server judge whether to believe a message's claimed origin.

SPF is a TXT record listing which servers may send on behalf of the domain. The receiver checks the connecting server against that list. SPF breaks easily under forwarding, because the forwarding server is not on the original domain's list.

DKIM attaches a cryptographic signature to outgoing mail, with the public key published in DNS. The receiver verifies the signature, confirming the message was not altered and genuinely came from the domain. Unlike SPF, DKIM survives forwarding.

DMARC is a policy record stating what to do when SPF and DKIM fail — monitor, quarantine, or reject — and where to send reports. A p=reject policy on a domain whose records are incomplete will cause its own legitimate mail to be refused.

Since 2024, Google and Yahoo have required SPF and DKIM on all bulk mail, DMARC for high-volume senders, and one-click unsubscribe headers, with spam complaint rates kept low. Microsoft has introduced comparable requirements for consumer Outlook accounts. Google publishes its current sender guidelines in full.

The whole path, end to end

The sender's client hands the message to their outgoing server
That server extracts the recipient domain and queries DNS for its MX records
It picks the lowest-priority host and resolves its A record
It connects and runs the SMTP exchange
The receiving server evaluates authentication, reputation, and content
It accepts, rejects, or defers
If accepted, it applies routing rules, filtering, and user rules to decide placement

Steps 1–4 fail because of DNS and MX problems. Steps 5–6 fail because of authentication and reputation. Step 7 is where mail is "delivered" but nowhere to be found.

Misconfigurations that account for most failures

Old provider's MX records left in place. Mail splits between two systems, and roughly half of it lands in a mailbox nobody checks.
Records edited at the wrong place. Changes made at the registrar while a different DNS host is authoritative — no effect at all.
Changes judged too soon. TTL caching means a correct change can look broken for hours.
MX pointing at an IP address. Invalid, and rejected by strict senders.
A DMARC reject policy with incomplete SPF or DKIM. The domain instructs the world to refuse its own mail.
Multiple SPF records on one domain. Only one is permitted; two cause a permanent error rather than a merge.
Subdomain assumed to inherit the parent. It does not.

Checking whether it all works

Reading records tells you what should happen. Sending a message tells you what does. Both are worth doing, because a configuration can be correct on paper and still fail — an unreachable host, a firewall, an expired certificate.

An end-to-end check is simple: send a message to an address on the domain from outside it, then compare the SMTP-level result against what arrives in the mailbox. A rejection points at DNS, MX, or the address; acceptance with nothing visible points at filtering; nothing at all points at the host or the network path.

Frequently asked questions

How long do MX changes take to take effect?

Governed by the TTL on the old record. Values from a few minutes to 24 hours are typical. Lowering the TTL before making a change shortens the transition.

Can I have MX records at two providers at once?

Technically yes, and it is almost always a mistake. Mail distributes between them according to priority, so messages end up split across two systems.

Do I need SPF, DKIM, and DMARC to receive mail?

No — they concern sending. But if the domain also sends, missing or broken records will cause that outbound mail to be filtered or refused.

Why does my domain resolve but mail still bounces?

A domain resolving means its A record works. Mail needs a valid MX record pointing at a host that is actually running a mail service and accepting your recipient.

What is the difference between MX and SMTP?

MX is a DNS record that says where to deliver. SMTP is the protocol used to do the delivering once the destination is known.

To check a domain's routing end to end, send a test message to an address on it and read the delivery status.