NXDOMAIN vs no MX: two very different email-verification results

NXDOMAIN is about domain existence

A resolver returns NXDOMAIN when the queried name does not exist in DNS. For an email address, that is strong evidence the domain portion is wrong or no longer delegated, assuming the result is not caused by a transient resolver or DNSSEC problem. A typo such as examlpe.invalid can be suppressed or sent to manual correction rather than passed to SMTP. Store the exact DNS rcode so the decision is auditable.

No MX is only a record-type result

A domain can exist and return NODATA for MX while still having A or AAAA records. SMTP’s routing rules historically define fallback behavior in that case. The absence of MX therefore does not mean the same thing as NXDOMAIN. A verification library that exposes only mx_exists=false hides whether the domain itself exists. Query or store enough DNS detail to tell these states apart.

Temporary resolver failures are a third category

SERVFAIL, timeouts, and temporary network errors should not be converted into NXDOMAIN. They can arise from authoritative DNS outages, DNSSEC validation problems, or your own resolver. Mark them temporary and retry later from a known resolver. If the verifier labels every lookup exception invalid, a short DNS outage can permanently suppress a large set of good leads. Reliability requires preserving uncertainty rather than optimizing for a simple boolean result.

Use syntax checks before DNS

Normalize the address and validate basic syntax before querying the domain. A malformed address with spaces or impossible structure should fail without consuming DNS work. Then lower-case the domain portion, convert internationalized names appropriately in the application layer if you support them, and query DNS. Layered verification makes the final reason clearer: syntax_invalid, domain_nxdomain, domain_no_mx_fallback_possible, dns_temporary_error, and so on.

Do not auto-correct typo domains silently

If a domain resembles a popular provider but is misspelled, flag it for manual review rather than automatically rewriting the prospect’s address. Silent correction can send to a different person or domain than the source data intended. In cold outreach, the safest action is to verify against the original source or another business record. DNS evidence can identify a likely typo; it should not authorize your system to invent recipient data.

A decision table for outbound hygiene

NXDOMAIN with repeated confirmation: suppress or correct from an authoritative source. No MX but A/AAAA fallback: mark unusual and evaluate according to your risk policy. Null MX: suppress because the domain explicitly does not accept mail. SERVFAIL or timeout: retry verification later. Normal MX: continue to mailbox-level checks. This table keeps list hygiene deterministic and makes QA possible because each state has a reason and next action.

Reverification can change the answer

Domains expire, move email providers, or repair DNS. If a lead was important enough to retain, store verification timestamps and allow rechecking after an appropriate interval rather than treating DNS state as permanent. A previous NXDOMAIN on a newly registered company typo may stay invalid, while a temporary SERVFAIL should be rechecked much sooner. Recency belongs in the data model, not in operator memory.

Test with synthetic DNS fixtures

Unit tests should cover normal MX, no MX with A fallback, Null MX, NXDOMAIN, SERVFAIL, and timeout. Mock the resolver result rather than depending on live public domains, because public DNS changes over time. The parser should produce stable internal states and never translate a transient resolver exception into permanent suppression. This is one of the simplest ways to prevent a list-cleaning script from damaging a campaign before any email is sent.

Keep DNS answer classes separate in the verification database

NXDOMAIN means the queried domain name does not exist in DNS; an empty MX answer means only that the queried name has no MX data. Those are not interchangeable. A no-MX domain may still have A or AAAA records and therefore fall under SMTP’s implicit-MX behavior, while a null MX explicitly declares no inbound mail service. A resolver timeout or SERVFAIL is different again: it is a temporary inability to obtain a reliable answer and should not be converted into “invalid domain” simply because a batch verifier wants a binary output.

Represent the result as structured evidence: normalized domain, DNS response class, MX records, null-MX flag, address fallback records, resolver timestamp, and any temporary error. Then make list decisions from that evidence. NXDOMAIN can normally be treated as a strong domain-level invalid signal after you rule out input normalization mistakes; SERVFAIL should be retried; no MX with an address record can be reviewed or allowed to reach the normal delivery system according to your risk policy. Never silently fix a typo such as swapping one letter in a corporate domain, because the corrected address may belong to a different person. This model also makes reverification safe: a domain that was mid-migration yesterday can move from temporary failure to a normal MX result without losing the original audit trail.

Cache negative answers carefully

DNS negative responses have their own caching behavior, so a verifier should not repeatedly query an NXDOMAIN or empty answer every few seconds, nor should it retain the result forever. Store the observed TTL or a bounded reverification time appropriate to your system. This is especially useful around newly created domains and mail migrations, where records can appear after the first check. A cached result should preserve what was actually observed and when; it should never erase the distinction between a confirmed non-existent name and a temporary resolver failure that happened to return during the same batch.

Field checklist

• Store the resolver rcode, not just mx_exists.
• Keep NXDOMAIN separate from no-MX/NODATA.
• Retry SERVFAIL and timeouts instead of suppressing immediately.
• Recognize Null MX as an explicit no-mail signal.
• Do not silently rewrite likely typo domains.
• Unit-test DNS classification with synthetic fixtures.