MX Record Validation: What It Actually Tells You About an Email Address

An MX (Mail Exchange) record is a DNS entry that tells the rest of the internet which servers receive mail for a domain. When [email protected] is sent, the sending server asks DNS "what are the MX records for example.com?" and connects to whatever hosts those records point at. No MX records, no delivery path. MX validation is the verification step that asks this question on your behalf, before the send. It is cheap, it returns fast, and it is decisive in one direction: no usable MX means no mail lands there, no matter how clean the local part looks.

New here? If you want the lookup mechanics first, the priority numbers, the dig and nslookup commands, and the four-line "is this domain set up for mail?" read, start with how to check MX records. That post owns the how-to. This one is about the part that trips people up: a healthy MX record proves less than it looks like it does, and what a verifier has to do with that signal afterward.

01The 30-second summary

The lookup itself is short:

• MX records present and recognizable. The domain can receive mail. The address is worth probing further.
• No MX, but an A/AAAA record. RFC 5321 §5.1 allows a fallback to the domain's IP, but almost nobody runs mail that way anymore. Weak setup, treat with suspicion.
• No MX and no A record. The domain cannot receive mail at all. Every address there is undeliverable without ever opening an SMTP connection.
• The lookup times out or errors. DNS itself is misbehaving. You have no answer, and pretending otherwise is the wrong move.

Each provider also has a recognizable MX signature: aspmx.l.google.com is Google Workspace, <tenant>.mail.protection.outlook.com is a Microsoft 365 protected tenant, a domain pointing at itself is usually self-hosted. The full breakdown of how to read those records by hand lives in how to check MX records. The rest of this post assumes you have that and asks the harder question.

02What MX validation does NOT prove

The check is decisive when it fails. When it passes, it is the start of the investigation, not the end. Four things a healthy MX record cannot tell you:

It does not prove the mailbox exists. example.com can have a perfectly configured MX set and still reject [email protected] because no such mailbox is provisioned. MX validation tells you the domain can receive mail. It says nothing about whether the specific recipient is real. That gap is exactly the gap an SMTP probe exists to close: opening a real connection and walking HELO / MAIL FROM / RCPT TO to read the server's verdict on that one address, without ever delivering a message.

It can be stale. DNS resolvers cache MX records, often for hours after the domain owner changes them. A domain that deleted its MX records an hour ago still "has MX records" for anyone whose resolver has not refreshed. Most of the time this is invisible. It is the usual explanation when an MX check and an actual delivery attempt disagree, and it is a reason a verdict carries a confidence value rather than a flat yes.

It can lie. A domain owner can publish MX records that point at hosts they do not control, or at hosts that accept no incoming mail. The DNS query confirms the record is published. It does not confirm anything on the receiving end is alive and listening. The only way to know is to talk to the host, which again is the SMTP layer, not the DNS layer.

It does not distinguish a catch-all. A domain with valid MX records can be configured to accept mail for every local part, so a fabricated address and a real one both come back 250 OK. MX validation cannot see this at all; the records look identical to a normal domain. Telling a real mailbox from a fabricated one on such a server needs a dedicated second probe, covered in how to check a catch-all domain.

The throughline: MX is a domain-level signal. Three of the four failure modes above are about an address or a server's behavior, which DNS records simply do not describe. A verifier that stops at MX and reports "valid" is over-claiming.

03How MailCull turns the MX signal into a verdict

MX validation does not produce a status on its own. It produces a reason flag that feeds the rest of the pipeline, and the four MX outcomes map onto MailCull's four statuses (deliverable / risky / undeliverable / unknown) like this:

Two things make the flag useful rather than decorative.

First, mx_found carries the resolved MX hostname in the result detail. That string is not just for show: a hostname matching .mail.protection.outlook.com routes the address through a Microsoft-native check that confirms the specific mailbox rather than trusting Microsoft's raw SMTP reply, which is not trustworthy on its own. The MX pattern is what picks the right downstream path. A Google Workspace pattern, a consumer Gmail pattern, and a self-hosted pattern each steer the probe differently.

Second, an mx_missing verdict is preserved even though no SMTP transaction backs it. The address is decisively undeliverable, and the absence of MX records is the proof, no connection required. So the deep scan short-circuits on mx_missing: it skips the SMTP probe entirely and keeps the pre-SMTP undeliverable verdict rather than demoting it to unknown just because there was nothing to connect to. The lesson generalizes: the MX layer is the only place in the pipeline that can confidently say undeliverable before you spend the cost of a probe, so its verdict has to survive the later stages intact.

unknown verdicts, including mx_lookup_unavailable, never decrement credits on any plan. A non-answer should not cost you anything.

04Where MX validation sits in the pipeline

The validation order is deliberate:

1. Syntax: does the address parse per RFC 5321?
2. MX validation: does the domain have working mail infrastructure?
3. Disposable detection: is the domain a known throwaway-inbox provider? (how to detect disposable emails)
4. Role detection: is the local part info@, support@, and so on?
5. SMTP probe: does the receiving server accept the specific recipient? (Includes the M365 cascade for .mail.protection.outlook.com patterns.)
6. Catch-all detection: does the server accept every recipient, including a fabricated one?

MX validation is step 2 because it is fast, cheap, and decisive when it fails. Running an SMTP probe against a domain with no MX records is wasted work; there is nothing to connect to. MX eliminates those cases before the expensive checks run. But notice that steps 5 and 6 exist precisely because step 2 cannot answer the mailbox-level and catch-all questions on its own. The pipeline is built around what MX cannot prove.

05Two evidence-chain rows

A passing Microsoft 365 address, where the MX hostname does real work:

[email protected]                 ✓ deliverable
─────────────────────────────────────────────────────────
syntax_valid              Email format passed RFC 5321 validation
mx_found                  MX record: example-corp-com.mail.protection.outlook.com
provider_microsoft        Microsoft 365 protected tenant detected from MX pattern
m365_confirmed            Microsoft confirmed the specific mailbox natively
smtp_confirmed            Server returned 250 2.1.5 OK

Confidence: 0.94

The mx_found detail (example-corp-com.mail.protection.outlook.com) is what triggers provider_microsoft on the next line and routes the address through the M365 cascade rather than a plain probe. The verdict is deliverable, but confidence is 0.94, not 1.00, because the layers above MX, caching and the live mailbox state, can still shift under it.

A domain with no MX, where MX validation is the entire case:

[email protected]             ✗ undeliverable
─────────────────────────────────────────────────────────
syntax_valid              Email format passed RFC 5321 validation
mx_missing                Domain has no MX records and no A/AAAA fallback

Confidence: 1.00

Confidence 1.00 because there is no ambiguity to resolve. Without MX records the domain receives mail nowhere, and the verdict can be defended on the DNS record alone, no SMTP transaction required. This is the one case where MX validation both opens and closes the investigation.

06What MailCull does

MX validation runs on every verification: Free, Pro, and Max, single check and bulk job. The resolved MX hostname appears in the evidence chain so you can see exactly which infrastructure you would be talking to, and which downstream path the address took. If you want to read a domain's records by hand first, how to check MX records walks through the dig and nslookup commands and the free MX lookup tool. To see the whole verdict end to end, paste an address into MailCull's public checker.

Start free: 500 validation credits per month, no credit card, MX validation plus SMTP probing plus the full evidence chain on every verdict.