The standard advice for email validation is "check the syntax, then look up the MX record". That advice is wrong in a specific and expensive way: the misspellings people actually type at signup have working MX records. An MX-only guard returns a confident pass on them.

What live DNS actually says

Every row below was resolved against Cloudflare's DNS-over-HTTPS resolver on 2026-08-06 and re-checked on 2026-08-24. This is measured behaviour, not a table of hypotheticals.

input domain live DNS answer MX-only guard concludes correct?
outlook.con NXDOMAIN (Status 3) reject yes
gmail.co null MX 0 . reject yes
yahoo.co null MX 0 . reject yes
gmai.com MX → mail.h-email.net accept no
hotmial.com MX → mail.h-email.net accept no
hotmai.com MX → itself, no A/AAAA accept no
gmial.com SERVFAIL (Status 2) fails open no
gmaill.com NOERROR, no MX, no A/AAAA needs a fallback partly

Four of eight rows are wrong. The three accept rows are the interesting ones, because they are not edge cases — gmai.com, hotmial.com and hotmai.com are among the highest-volume misspellings of the two largest consumer mail providers in the world.

Why the typo domains resolve

A domain one keystroke away from gmail.com is valuable. Someone registered it, pointed MX records at a mail host, and now collects whatever arrives. From the resolver's point of view nothing is unusual: the domain exists, it publishes a mail exchanger, the mail exchanger has an address. Every check an MX-only validator performs returns a healthy answer.

The signup consequence is direct. A user types diego@gmai.com, your validator says the domain accepts mail, you write the row, and your welcome email goes somewhere that is not the user. You will never see a bounce, because there is nothing to bounce — the mail was delivered, just not to your customer. Silence looks like success.

The operator fingerprint

Look again at rows four and five. mail.h-email.net serves MX for both gmai.com and hotmial.com. The same mail host is behind misspellings of two unrelated providers.

That is a fingerprint, and it is the most useful thing in the table. Individual typo domains are a long tail that you can never enumerate by hand, but the operators running them are few, and they reuse infrastructure. Clustering candidate domains by their MX host turns "guess every misspelling" into "identify a handful of hosts". This is why nobounce keeps its typosquat host list in a database table that grows as new hosts are observed, rather than as a constant compiled into the validator.

Order the pipeline so typo correction runs first

If DNS runs before typo detection, a resolvable typo domain short-circuits the whole pipeline with a deliverable verdict, and the typo stage never executes. The fix is ordering, not more DNS work:

  1. Syntax, RFC 5322 as practised rather than the full grammar.
  2. Reserved names, per RFC 2606 and RFC 6761, before any network call.
  3. Typo correction against a curated list of high-volume domains.
  4. MX over DNS-over-HTTPS, including null MX and the A/AAAA fallback.
  5. Typosquat MX host matching.
  6. Disposable domains.
  7. Role accounts, which are flagged as risky and never rejected.

Stage three is what saves the signup. Stage five is what catches the typo domains that stage three's edit-distance list has not learned yet.

What a verdict looks like when it works

curl -X POST https://nobounce.dev/demo/check \
  -H 'Content-Type: application/json' \
  -d '{"email":"user@gmai.com"}'

{
  "verdict": "undeliverable",
  "reason": "typosquat_mx",
  "suggestion": "user@gmail.com",
  "confidence": 0.94,
  "checked": { "syntax": true, "mx": true, "typo": true, "disposable": true },
  "cached": true
}

The reason says which stage decided, so you can tell a resolvable typo domain apart from a domain that does not exist. The suggestion is what you show the user. POST /demo/check resolves a frozen fixture corpus rather than live DNS, so it is an evaluation endpoint and cannot be used as a production validator; live checks run against a paid key, from $1/mo.

What this does not solve

Nothing here tells you whether a specific mailbox exists at a domain that is genuinely correct. diego@gmail.com and notdiego@gmail.com are indistinguishable at the DNS layer, and nobounce does not attempt to distinguish them — no SMTP probing, not now and not later. If your requirement is per-mailbox existence, this is the wrong tool and you should read the evaluation document before adopting it.

What it does solve is the case where the domain itself is not what the user meant. That is where the recoverable signups are.