MX Record Check in Email Validation

MX record check is a validation step that queries the DNS of a domain to see whether any mail servers are listed for it. When no MX record exists, the domain cannot receive email, so any address on it will bounce.

What an MX record is

MX (Mail Exchange) is a DNS record type that names the server responsible for accepting email on behalf of a domain. Each record carries two values: a numeric priority and the hostname of the mail server.

A domain can publish multiple MX records at different priority levels. The sending mail transfer agent tries the host with the lowest priority number first. If that host is unreachable, it moves to the next one. This gives built-in redundancy without any extra configuration on the sending side.

How the check actually works

The validator extracts the domain from the email address (the part after @) and fires a DNS query of type MX. The response falls into one of several categories:

• MX records present — the domain is set up to receive mail. Validation continues.
• No MX, but an A record exists — per RFC 5321, a sender may fall back to the A record when no MX is published. Some validators treat this as conditionally valid, though with lower confidence.
• Neither MX nor A record — the domain does not accept email. Address is invalid.
• NXDOMAIN — the domain is not registered or does not exist in DNS at all. Unambiguous rejection.

Why MX checking matters

Syntax validation happily accepts addresses like user@fakefakedomain.com — the format is fine, but the domain does not exist. MX checking catches precisely these cases. It is fast (a DNS query completes in milliseconds) and requires no SMTP connection to the target server.

In practice, 5–15% of the invalid addresses in a typical list belong to non-existent domains. Filtering them out at the MX stage saves real time and compute that would otherwise be spent on pointless SMTP connection attempts.

Edge cases and pitfalls

An MX record can point to a “null” host: MX 0 .. This is an explicit signal — the domain exists but deliberately refuses mail (RFC 7505). Any address on such a domain is invalid.

Sometimes an MX record points to a host that does not answer on port 25. The domain technically has a mail server; in practice it has none. MX checking will not surface this — you need an SMTP probe for that.

DNS results are cached according to their TTL. If a domain was just created or its DNS records recently changed, cached data may be stale. Production-grade validators respect TTL and re-query when necessary.

Where MX checking fits in the validation pipeline

In a multi-stage validator, MX checking runs after syntax analysis and before any SMTP connection. The order makes sense: there is no point connecting to a server that DNS says does not exist, just as there is no point querying DNS for an address that is syntactically broken.

The pipeline runs: syntax → DNS/MX → SMTP → supplemental checks (catch-all detection, disposable providers, role addresses). Each stage drops some bad addresses before the next, more expensive stage even runs.

Real-world examples

Gmail publishes several MX records at different priorities: gmail-smtp-in.l.google.com (priority 5), alt1.gmail-smtp-in.l.google.com (priority 10), and three additional fallbacks. Most large providers follow the same pattern.

Corporate domains on Google Workspace or Microsoft 365 point their MX records at the provider's servers. When a company migrates between providers and forgets to update DNS, the MX records keep pointing at the old, now-dead server. The MX check will show records exist, but an SMTP probe will reveal the actual problem.