Null MX vs no MX vs NXDOMAIN: three DNS results an email verifier should never collapse into one

Separate the transport fact from reputation guesses

RFC 7505 defines a null MX as a single MX record with preference 0 and exchange “.” to state that a domain does not accept email. RFC 5321 separately describes implicit MX behavior when no MX records exist for an otherwise resolvable domain.

These three DNS states mean different things for address validation. NXDOMAIN means the queried domain name does not exist in DNS. A Null MX is an explicit MX record whose exchange is the root label (`0 .`), standardized to say the domain does not accept email. A domain with no MX is different again: classic SMTP rules permit fallback to the domain’s address records as an implicit mail exchanger. Treating all three as “no MX = invalid” discards protocol information and can misclassify domains that intentionally receive mail without an explicit MX record, while failing to recognize the much stronger signal a properly published Null MX provides.

How a green checker can still hide the problem

“No normal MX hostname” is not a sufficient status label. NXDOMAIN means the queried name does not exist, while an existing domain with no MX can be an entirely different SMTP case.

The verifier also needs to distinguish an authoritative “no data” answer from a transient resolver failure. If a DNS server returns SERVFAIL or the query times out, you have not proven any of the three states above. Another common mistake is checking only a web browser: a domain can host a website while publishing Null MX, or receive mail while having no website. Email capability is determined by the DNS and SMTP path relevant to mail, not by HTTP reachability. Store the exact DNS response class so later decisions can be explained instead of flattening every negative-looking result into a single invalid flag.

Recreate the failure with one controlled path

Query the domain and inspect DNS response code, MX answer count, and exact exchange values. If there is no MX, also verify whether the domain itself resolves as required by the SMTP fallback rules before assigning a final status.

A reproducible validation sequence starts with the domain’s existence and MX query. If MX exists, inspect every exchange and recognize the special Null MX form exactly rather than interpreting the dot as a broken hostname. If no MX RRset exists but the domain does, check the fallback address behavior defined by SMTP before declaring the domain non-receiving. If the domain itself is NXDOMAIN, record that separately. Run the same queries from a second resolver when the first answer is suspicious and preserve TTLs. This makes retry policy possible because a permanent protocol declaration and a temporary DNS observation no longer share one status.

Make the smallest reversible change

Give each DNS state its own verifier result and suppression rule. Null MX can be permanently non-mail for that domain; NXDOMAIN is a name failure; no-MX/no-error should continue through the fallback logic instead of being automatically discarded.

Model the results explicitly in the lead database: `nxdomain`, `null_mx`, `implicit_mx_candidate`, `mx_present`, and `dns_unknown` are more useful than a single Boolean. Null MX and confirmed NXDOMAIN can feed strong suppression rules. An implicit-MX candidate may need an SMTP-level or provider-specific check, while SERVFAIL belongs in a retry queue. This richer state prevents a verifier from destroying usable leads during an outage and prevents repeated attempts to domains that have explicitly declared they accept no mail. Recheck old DNS-derived statuses before a later campaign because domain ownership and mail configuration can legitimately change.

A practical mailbox or domain example

MX 0 . is not a placeholder for “MX missing.” The dot is deliberately invalid as a mail exchanger so senders can stop attempting delivery instead of guessing an A host.

Cache these states at the domain level with an expiry appropriate to DNS, but keep recipient-level hard bounces separate. If `example.com` publishes Null MX, every address at that domain can share the same explicit non-mail state until DNS changes. If one mailbox at a normal MX domain returns 5.1.1, that does not make the entire domain invalid. NXDOMAIN is domain-level too, but domains can later be registered or restored, so a long-lived lead database should re-evaluate old DNS suppression before a campaign months later if business policy allows. This hierarchy reduces DNS work and prevents one bad recipient from contaminating other leads. It also makes analytics more honest: “domain declares no mail,” “domain absent,” and “recipient hard-bounced” are different causes with different remediation and recheck policies.

The minimum useful change record

Store DNS rcode, MX records, any fallback address records, resolver timestamp, and the rule that converted those facts into a list-hygiene state.

Conditions that should remain unknown or retryable

Do not probe SMTP when DNS already gives an explicit null-MX signal. Extra connection attempts add noise without changing the domain owner’s published statement that no mail exchanger exists.

Field checklist

• Capture the raw evidence for null MX vs no MX vs NXDOMAIN email verification before editing DNS, queue state, or mailbox metadata.
• Confirm the cited mechanism using null-mx-rfc, smtp-rfc rather than a generic deliverability score.
• Keep a known-good control case so the failing layer can be compared without changing several variables at once.
• Apply the narrow repair described for Null MX vs no MX vs NXDOMAIN: three DNS results an email verifier should never collapse into one and preserve a rollback or retry path.
• Repeat the original failing test after the change; do not substitute a different checker as proof of recovery.
• Store timestamp, affected identity, raw result, action taken, and the post-change result in the operator log.