A Valid Email Address Is Not a Deliverable One

Type [email protected] into any signup form on the internet and watch it sail through. It passes the browser’s built-in check, it passes the framework’s validator, it passes the thousand-line “RFC-compliant” regex someone copied from Stack Overflow — because it is a valid email address. It’s just not your email address, and validity and deliverability are two different layers that most forms quietly pretend are one. A perfectly-formed address at a domain that doesn’t exist is valid. A perfectly-formed address at a domain that publishes a DNS record explicitly refusing all mail is valid. “Valid” answers the question could this string be an address? It says nothing about the question you actually care about: if I send mail here, will anything receive it?

Untangling the two layers makes it obvious what a validator can honestly promise — and what the paid “email verification” industry is actually selling.

Layer one: syntax, and the regex-golf trap

The syntax layer asks whether the string is shaped like an address. The trap is deciding which spec defines the shape.

RFC 5322 — the internet message format standard — allows things that would get you funny looks: quoted local parts like "john smith"@example.com, comments in parentheses, folding whitespace. A regex that truly implements it runs to thousands of characters, and its reward for all that effort is accepting addresses that no signup form, mail provider, or CRM on earth will take. The WHATWG HTML Standard — the spec that defines what <input type="email"> accepts in every browser — looked at this and made a rare, explicit break with the RFC:

This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the ”@” character), too vague (after the ”@” character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.

That’s the HTML spec, calling the email RFC impractical, in writing. The pattern browsers actually use is one line: dot-atom local part, hostname-shaped domain. That’s the right baseline — but it’s deliberately loose in a few places where real mail servers are strict. RFC 5321, the SMTP standard, adds hard limits the HTML5 pattern doesn’t check:

• Local part ≤ 64 octets (§4.5.3.1.1: “The maximum total length of a user name or other local-part is 64 octets.”)
• Domain ≤ 255 octets (§4.5.3.1.2)
• Whole address ≤ 254 characters — this one’s sneaky. §4.5.3.1.3 caps a forward-path at 256 octets “including the punctuation and element separators”, and the path wraps the address in angle brackets: <[email protected]>. Subtract the two brackets and 254 is what’s left for the address itself.
• No leading, trailing, or doubled dots in the local part — the HTML5 pattern happily accepts [email protected]; RFC 5321’s Dot-string grammar and every major provider do not.

So the practical syntax check is: HTML5 pattern plus RFC 5321’s length and dot rules. Anything stricter starts rejecting real addresses; anything looser accepts strings SMTP will refuse before a single packet leaves your network. Chasing full RFC 5322 compliance is regex golf — an impressive scorecard for a game nobody’s mail server is playing.

And after all that: [email protected] passes every bit of it. Flawlessly shaped. The syntax layer has told you everything it knows.

Layer two: the domain has to want your mail

Deliverability starts where syntax ends — at the DNS. Before any mail server connects anywhere, it looks up the domain’s MX records, the DNS entries that say “mail for this domain goes to these hosts” (covered in DNS record types explained). A healthy mail domain looks like this:

$ dig +short MX gmail.com
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.

Five servers, ranked by preference. But the lookup has four other possible outcomes, and each one tells you something a regex never could:

NXDOMAIN — the domain doesn’t exist. No registration, no zone, nothing. Every address at it is undeliverable, full stop. RFC 5321 §5.1 is blunt: “If a non-existent domain error is returned, this situation MUST be reported as an error.”

Null MX — the domain exists and explicitly refuses mail. RFC 7505 defines a special MX record: preference 0, exchange ”.” (the DNS root, which can never be a mail host). It is a machine-readable “we do not accept email, don’t bother”:

$ dig +short MX example.com
0 .

Yes — example.com itself publishes one, which is why [email protected] is a perfectly valid, deliberately dead address. A domain advertising a Null MX “MUST NOT advertise any other MX RR”, so the signal is unambiguous, and senders are told to fail immediately with a permanent error (a 556 reply) instead of retrying for days. Domains that only send mail — or park pages that want no mail at all — publish this so their names can’t be used for backscatter.

No MX, but an A/AAAA record — the implicit-MX fallback. Here’s the rule almost every homegrown checker gets wrong. An empty MX answer does not mean the domain can’t receive mail. RFC 5321 §5.1: “If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.” Mail falls back to the domain’s plain address record. Real mail domains almost always publish explicit MX records, so this fallback working is a yellow flag, not a green one — but a checker that reports “no MX = invalid” is contradicting the SMTP standard.

No MX and no address records. Nothing to connect to. Mail cannot be delivered, even by the fallback rule.

Which brings us back to gmial.com — the typo domain from the opening line. As of this writing it resolves: registered, no MX records, but a live A record. That’s the implicit-MX case. Mail to your typo’d address doesn’t bounce cleanly into the void — per RFC 5321, a sender may connect to whatever host a typosquatter pointed that A record at. Syntax said “valid.” DNS says “valid, and possibly delivering your password-reset mail to a stranger.”

The two layers, side by side

Address	Syntax layer says	DNS layer says
user@@example.com	Invalid — two ”@“	(never gets this far)
[email protected]	Invalid — RFC 5321 dot rules (HTML5 pattern alone misses it)	(never gets this far)
[email protected]	Valid	No MX, but an A record — implicit-MX fallback to an unknown host
[email protected]	Valid	Null MX (0 .) — domain refuses all mail by design (RFC 7505)
[email protected]	Valid	NXDOMAIN — domain doesn’t exist
[email protected]	Valid	5 MX records — set up to receive mail

Every row below the second line is invisible to a syntax-only validator. That’s the whole argument in one table.

The honest ceiling: what no DNS check can tell you

Now the part the marketing pages skip. Even the last row — valid syntax, healthy MX records — proves only that the domain is set up to receive mail. It cannot tell you that you is a real mailbox there. [email protected] clears both layers identically. The mailbox may not exist, may be full, may be disabled; the receiving server may greylist you (temporarily refuse first-time senders) or accept-then-bounce.

The only ground truth is an actual SMTP conversation: connect to the MX host, MAIL FROM, RCPT TO, and see whether the server says yes to that exact mailbox. Browsers categorically cannot do this — they don’t speak SMTP and can’t open connections to port 25 — and it’s exactly the service paid verification APIs sell. Even they hit a wall: plenty of servers are configured catch-all (accept every RCPT TO, sort it out later) or deliberately refuse to reveal mailbox existence, precisely so spammers can’t validate address lists against them. There is no technique on earth that verifies every address short of sending the mail and watching what happens.

So the honest hierarchy is: syntax filters the malformed, DNS filters the impossible, SMTP filters most of the rest, and only delivery is proof. A validator that tells you which layer each verdict came from is being straight with you. One that stamps “deliverable” after a regex is not.

Checking both layers without uploading your list

This layered model is exactly how our email validator works. The syntax pass runs entirely in your browser: the exact WHATWG HTML5 pattern as the baseline, plus the RFC 5321 refinements — the 64-octet local part, the 254-character total, the dot rules — reported as itemized findings rather than a bare pass/fail, with a “did you mean” suggestion when the domain is one keystroke from a major provider (gmial.com → gmail.com).

Then, for the deliverability layer, it looks up the domain’s MX records live — resolved over DNS-over-HTTPS via Google’s public resolver — and classifies the result into precisely the cases above: real MX records (listed with preferences), Null MX detected as RFC 7505 specifies (a single 0 . record), NXDOMAIN, and the implicit A/AAAA fallback checked before declaring a domain mail-dead. The privacy shape matters here: only the domain name is ever looked up — a DNS query, relayed through our worker so your IP doesn’t go to Google. The addresses themselves never leave your browser. The paid APIs ranking for “email verification” all work the other way: step one is uploading your entire list to their servers. Batch mode handles up to 50 addresses with one deduplicated lookup per domain, and when you want the raw DNS picture behind any verdict, DNS Lookup shows the full record set. (One caveat any DNS-based checker inherits: answers come from resolver caches, so a just-fixed domain can look dead for a little while — that’s TTL expiry, not propagation.)

One adjacent problem this deliberately doesn’t solve: [email protected] and [email protected] are both deliverable — to the same inbox. Gmail ignores dots and everything after a +. If you’re deduplicating a signup list rather than validating it, that’s what the email normalizer is for.

The short version

The form field believes	The mechanism says
”It matched the regex, so it’s a real address”	Syntax bounds the shape; RFC 5321 limits (64-octet local, 254 total) bound the size — nothing more
”A stricter, fully RFC 5322 regex validates better”	The HTML spec itself calls RFC 5322’s grammar a willful-violation-worthy mismatch for address intake
”The domain has no MX, so it’s invalid”	RFC 5321 §5.1: empty MX falls back to an implicit MX on the A/AAAA record
”The domain resolves, so mail will arrive”	It may publish a Null MX (0 ., RFC 7505) — a standing “we accept no mail"
"MX records exist, so the address is deliverable”	Only the receiving server knows if that mailbox exists — and catch-alls won’t even tell SMTP
”The verifier said deliverable, so it’s guaranteed”	Only delivery is proof; everything else is layered evidence