DNS & MX Records: How Email Routing & Verification Work

An MX record (Mail Exchanger record) is the line in a domain's DNS that tells the rest of the internet which servers accept its email. Before a single message moves, the sending server does a DNS lookup to find that record. This guide explains the DNS layer email depends on, how MX records drive routing and failover, and why an MX lookup is the first thing any serious email verification pipeline checks. If you want the layer above this — proving a specific mailbox exists — see our companion piece on SMTP validation.

The DNS records email depends on

Email is not a single protocol bolted onto a server. It rides on a small stack of DNS records that each answer a different question: where do I deliver, who is allowed to send, and can I trust the connecting host. Understanding the whole set makes it obvious why a verification engine queries DNS before it ever opens a socket. Here is the layer at a glance.

The MX, A, and AAAA records govern routing — the subject of this article. The TXT records that carry SPF, DKIM, and DMARC govern authentication, which is a separate concern covered in our guide to SPF, DKIM, and DMARC. Routing answers "where does mail go"; authentication answers "is this sender allowed."

MX records in depth: priority, failover, and null MX

An MX record has two parts: a preference value (an integer) and a mail exchanger hostname. A domain can publish several MX records, and the preference value sets the order in which a sender should try them. Counterintuitively, lower numbers are preferred. Here is what a typical lookup returns:

$ dig MX example.com +short
10 mx1.example.com.
20 mx2.example.com.
30 mx-backup.thirdparty.net.

# nslookup equivalent
$ nslookup -type=MX example.com
example.com  mail exchanger = 10 mx1.example.com.
example.com  mail exchanger = 20 mx2.example.com.
example.com  mail exchanger = 30 mx-backup.thirdparty.net.

A sending server reads that list and behaves as follows:

• Sort by preference, lowest first. Here mx1 (10) is tried before mx2 (20) before the backup (30).
• Failover on connection failure. If mx1 is unreachable or returns a temporary error, the sender moves to the next host. Multiple MX records exist precisely for this redundancy.
• Equal preferences load-balance. Two MX records sharing the same number (for example, two at 10) are chosen between at random, spreading inbound load.
• Resolve the hostname. Each chosen MX hostname is then looked up for its A/AAAA record to get the actual IP to connect to.

There is one special case worth memorizing: the null MX, standardized in RFC 7505. A domain that never receives email can publish a single MX record with priority 0 and a "." as the hostname:

example.com.   IN   MX   0   .

A null MX is an explicit, machine-readable declaration of "this domain accepts no mail." A compliant sender that sees it should reject the message immediately rather than queue and retry for days. For verification purposes, a null MX is as conclusive as no MX at all: any address at that domain is undeliverable.

The full delivery path, step by step

Put the records together and the journey of a message from sender to recipient mail server looks like this:

1. Parse the address. The sending server splits user@recipient.com into the local-part and the domain.
2. MX lookup. It queries DNS for the MX records of recipient.com. If there are none and no fallback applies, or a null MX is present, delivery stops here.
3. Pick the lowest-preference MX and resolve its hostname to an A/AAAA address.
4. Open a TCP connection to that address on port 25 (the standard for server-to-server mail transfer).
5. Run the SMTP conversation — EHLO, optional STARTTLS, MAIL FROM, RCPT TO, DATA — and the recipient server accepts, defers, or rejects the message.

Historically, if a domain had no MX record at all, RFC 5321 allowed senders to fall back to the domain's A record as an "implicit MX." Many mail servers still honor that fallback, which is why a domain can sometimes receive mail without an explicit MX. A null MX overrides this fallback and forbids it. The connection and conversation phases are where verification gets its strongest signal — that is the territory of the SMTP deep dive.

How email verification uses the DNS layer

A verification engine works in cheap-to-expensive order, and the DNS layer sits right after syntax. Syntax parsing catches malformed strings for free. The next gate is the MX lookup, and it is decisive: if a domain has no MX record, an implicit-MX fallback fails, or it publishes a null MX, then no mailbox at that domain can possibly receive mail. The address is invalid and there is no reason to spend resources opening a connection.

When an MX record does exist, it becomes the precondition for the next, more expensive step. The MX hostnames are exactly the servers a verifier connects to for an SMTP probe. So the DNS layer does two jobs in one query:

• It filters out dead domains instantly. Typo domains, parked domains, and decommissioned company domains frequently have no usable MX — caught here with a single lookup.
• It supplies the connection targets. The probe needs to know which server to talk to and in what order; the MX list provides both.

This is why the MX check is bundled into every check KaijuVerifier runs. Our single-email validator reports the MX result alongside disposable, role, catch-all, and typo detection, and the same logic runs at scale through the bulk email cleaner and the REST API. An address that fails the MX gate never wastes a probe.

Common misconfigurations that cause bounces

Most "mysterious" delivery failures trace back to a handful of DNS mistakes. Each one is invisible until mail starts bouncing, which is exactly why a verifier that inspects the DNS layer can flag the domain before you send.

The CNAME and IP cases are the most common own-goals: an administrator points the MX at a load-balancer CNAME or pastes a raw IP, and standards-compliant senders quietly refuse the mail. Dangling MX records appear when a mail provider is removed but its MX hostname is left behind. Each of these inflates your bounce rate — and a high bounce rate damages sender reputation, the subject of our deliverability best practices guide. Catching these domains before a campaign is exactly what list hygiene buys you.

TTL and propagation basics

Every DNS record carries a TTL (time to live), expressed in seconds, that tells resolvers how long they may cache the answer before asking again. TTL is why DNS changes are not instant: until the cached copy expires, resolvers around the world keep serving the old value.

; TTL is the number before IN
example.com.   3600   IN   MX   10  mx1.example.com.
;              ^^^^ cached for 3600 seconds (1 hour)

• Lower the TTL before a planned change. Dropping it to 300 seconds a day ahead means resolvers refresh quickly when you cut over.
• Expect a propagation window. After an MX edit, some resolvers see the new value immediately while others wait out the old TTL — minutes to a few hours is typical.
• Negative caching applies too. If a domain had no MX and you add one, resolvers that cached the "no record" answer may lag until that negative TTL expires.

For verification this means a freshly fixed domain can read as invalid for a short window after the fix, and a freshly broken one can read as valid until caches clear. A verifier that re-queries authoritative servers, rather than trusting a stale cache, gives the most accurate read. When you are cleaning a list, this is also a good argument for verifying close to send time rather than weeks in advance — see how to clean an email list for the full workflow.

Frequently asked questions

What is an MX record?

An MX (Mail Exchanger) record is a DNS entry that names the mail servers responsible for receiving email on behalf of a domain. Each record has a preference number and a hostname; senders use the lowest-numbered host first and fall back to others for redundancy. Without at least one usable MX record — or a permitted A-record fallback — a domain cannot reliably receive mail.

What does a null MX mean for an email address?

A null MX (a single MX record of priority 0 pointing to ".", defined in RFC 7505) is the domain owner explicitly stating that the domain accepts no email. Any address at a null-MX domain is undeliverable, so a verifier marks it invalid without needing to attempt a connection.

Why does an email verifier check MX before SMTP?

The MX lookup is fast and conclusive in the negative case: no MX (and no fallback) or a null MX means no mailbox can exist, so there is no point opening a connection. When an MX does exist, it also tells the verifier which servers to connect to for the SMTP probe, making it the natural precondition for the deeper, more expensive check.

Can a domain receive email without an MX record?

Sometimes. Under RFC 5321, if no MX record exists, many senders fall back to the domain's A/AAAA record as an "implicit MX" and deliver there. This fallback is not guaranteed across every sender and is overridden by a null MX, so relying on it is fragile. Publishing an explicit MX record is the correct, predictable configuration.