Somewhere in a legacy codebase near you, there’s a 400-character regular expression titled “validate email” that rejects me+news@gmail.com, accepts a..b@c and was copied from a forum answer in 2009. This article is about why that keeps happening — and why it’s the tool that’s wrong, not the developer.

What a real email address can look like

RFC 5322’s address grammar is bigger than intuition suggests. All of these are syntactically legal:

• very.unusual."@".unusual.com@example.com — a quoted local part containing an @
• "much.more unusual"@example.com — spaces inside quotes are fine
• user@[IPv6:2001:db8::1] — a domain literal instead of a domain name
• john.smith(comment)@example.com — comments were part of the grammar
• postmaster — technically a legal local-part-only address
• 用户@例子.中国 — internationalized addresses under EAI (RFC 6531)

Meanwhile every one of these is invalid, and typical regexes accept them all:

• a..b@x.com — consecutive dots
• .a@x.com — leading dot in the local part
• a.@x.com — trailing dot
• a@b — fine actually (bare domain is allowed), but probably not what your app wants
• a@x..com — consecutive dots in the domain

A pattern simple enough to read — [\w.+-]+@[\w-]+\.[\w.-]+, like the one in the library on the tester — sits awkwardly in the middle: it accepts several of the invalid forms and rejects the exotic valid ones.

Why the “correct” regex doesn’t save you

People have mechanically translated the RFC 5322 grammar into regex. The result runs about 6,000 characters, is essentially unmaintainable, and still only describes syntax. Knowing an address is grammatically legal tells you nothing about whether:

• the domain has an MX record (or even resolves),
• the mailbox exists and accepts mail,
• the person who typed it owns it.

Your sign-up form doesn’t need a syntax proof — it needs “can we reach this human”. Regex is the wrong layer entirely: it validates the shape of a string in a world where the question is about a remote system.

The two-line strategy that works

Real products settled this years ago:

// 1. shape check — generous on purpose
const looksLikeEmail = /^\S+@\S+$/.test(input);

// 2. proof check — the only one that matters
sendConfirmationLink(input); // clicking proves deliverability + ownership

The shape check exists to catch typos early (jane gmail.com), not to adjudicate RFC compliance. Generous beats precise here: a weird-but-legal address sails through and gets verified by the mail system; a fake one fails at step two where it was always going to be decided anyway. For extra UX, warn on obvious mistakes (double dots, missing TLD) without blocking on them.

When regex is the right tool

Extraction. Scanning logs for [\w.+-]+@[\w-]+\.[\w.-]+, mining addresses out of a document, pre-tagging form candidates — these are “find shapes” problems, and a readable pattern is perfect. The pattern library on the tester ships exactly this use case with its limits spelled out: it will over-match some invalid strings and under-match exotic valid ones, and for extraction that’s a fine trade because a human or a filter decides afterwards.

The meta-lesson

Email is the canonical example of a larger trap: using syntax validation to answer a semantic question. Phone numbers have the same disease — (415) 555-0199 can be perfectly shaped and unassigned — and so do URLs, dates and credit cards (Luhn passes on numbers that were never issued). The pattern to copy isn’t a better regex; it’s the habit of asking what am I actually trying to prove? If the answer involves a remote system, a real account or a real human, the regex is scaffolding at best — write it generous, write it honest about its limits, and put the real check where the truth lives.

Frequently asked questions

Is there a correct regex for email validation?

There is a famous ~6,000-character regex derived from the RFC 5322 grammar — and even it is a description of the address syntax, not of deliverability. It can't know the domain accepts mail, the mailbox exists, or the human typed their own address. So: a correct syntax regex exists and is still the wrong tool for sign-up validation.

What's the shortest 'good enough' email check?

The honest one used by real products: /^\S+@\S+$/ — non-space, an @, non-space — followed by sending a confirmation email. It accepts odd-but-legal addresses instead of inventing rules, and the only check that matters (can we reach you?) is done by the mail system.

Why does the RFC allow things like "a b"@example.com?

Because the 1982-era grammar supported quoted local parts for gateways and display-name transport, plus comments like john(comment)@x.com and domain literals like user@[192.168.1.1]. Mail software still must parse them; whether providers issue them is another matter — most never will.

Is the HTML5 email input validation safe to rely on?

As a UX convenience yes, as a gate no — browsers implement a deliberately loose pattern (the WHATWG spec literally says it 'deliberately violates the RFC'), and client-side checks are bypassable anyway. Keep it for instant feedback, do the real check server-side plus confirmation.

When IS an email regex the right tool?

Extraction, not validation. Pulling candidate addresses out of logs, documents or scraped text is exactly what regex is for — [\w.+-]+@[\w-]+\.[\w.-]+ finds them fast, and a downstream filter discards the junk. You're locating shapes, not adjudicating deliverability.

What about internationalized email (EAI)?

Newer standard (RFC 6531), wider grammar — UTF-8 in both local part and domain (用户@例子.中国). Almost no regex you copy handles it, and most mail infrastructure still doesn't either. If you need it, a shape check plus confirmation scales where a pattern can't.