Developer FIELD NOTES · 4 MIN READ
How Email Validation Actually Works
The anatomy of an email address, the one regex browsers use for input type=email, what it allows and rejects, and why syntax checks are not delivery checks.
An email address is a tiny data structure with a surprisingly contested definition: a local part, an at-sign, and a domain. The full RFC 5322 grammar is famous for allowing absurdities, but browsers, forms, and most validators agree on a much simpler contract — and knowing exactly what that contract checks (and what it cannot) saves you from both false rejections and false confidence.
The anatomy: local part, at-sign, domain
Every address splits at the first at-sign into two halves. In [email protected], the local part is first.last+news and the domain is sub.example.com. The local part belongs to the mailbox owner — plus-addressing like this is a common convention for tagging incoming mail — while the domain is what mail servers actually route to. A validator that understands the shape reports all three pieces: local, domain, and whether the domain ends in a plausible top-level domain (two or more letters after a final dot). That last check matters because user@localhost or a@server are structurally fine on private networks but undeliverable on the public internet.
The one regex browsers actually use
You do not need RFC 5322 to validate a form. The HTML specification defines exactly one email-matching pattern, and every browser applies it to <input type="email">:
^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+
@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?
(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)+$Read it in three moves, as How Regular Expressions Work explains: the local part is one or more characters from an allowed class — letters, digits, and the punctuation .!#$%&'*+/=?^_`{|}~-; then a single domain label must start and end with an alphanumeric, with up to 61 more alphanumerics or hyphens between (the 63-character DNS label limit); then one or more dot-separated labels must follow, which is what makes at least one dot mandatory. That final + is why user@localhost fails while [email protected] passes.
What it allows, and what it rejects
The shape is deliberately pragmatic. It accepts addresses most people would call strange — !#$%&*@example.com is valid because those characters are legal in a local part — and it rejects common typos with specific, explainable reasons: no at-sign at all, two or more at-signs, a domain with no dot, or punctuation in the wrong place. It also refuses things RFC 5322 technically permits: quoted local parts like "john smith"@example.com, comments in parentheses, and IP-literal domains like user@[192.168.0.1]. Those edge cases exist in the RFC but almost never in real mailboxes, and a form that accepts them creates support tickets, not happy users. Case is a non-issue: local parts are technically case-sensitive, but in practice every mailbox treats [email protected] and [email protected] the same.
Validation is not verification
The deepest mistake is confusing "valid" with "real". A syntactically perfect address can belong to nobody: the domain may have no mail exchanger (MX) record, the mailbox may have been deleted, or the address may be a throwaway created to dodge a signup form. No regex can see any of that — delivery is a property of DNS and mail servers, not of string shape. The standard ladder of confidence goes: shape check (instant, free), domain check (does the domain exist and advertise MX records?), then confirmation email (the only proof that someone controls the inbox). Signup forms should run the cheap check instantly and reserve the expensive check for the moment it matters, which is why "confirm your address" emails remain the only technique that verifies anything at all.
When to reject, when to accept
Use the browser-grade pattern everywhere an address enters your system, and report why something failed — "missing an @ symbol" is actionable, "invalid" is not. Accept the plus-tagging and dot conventions users rely on for filtering. Be suspicious, not rejecting, of unusual-but-legal local parts. And never "fix" an address silently: lowercasing the domain is safe, but rewriting a local part can redirect someone's mail to a stranger. Validation's job is to catch typos at the door — verification's job is everything after.
Try it yourself
Type any address into the Email Validator — it applies the browser-grade pattern, splits the address into local part and domain, flags a missing top-level domain, and reports a plain-English reason for every rejection. Paste the regex above into the Regex Tester to watch which test addresses it catches, and feed any piece of it to the Regex Explainer for a token-by-token explanation of what each bracket and quantifier means.