The regex matching the full grammar in RFC 5322 is famously several thousand characters long, because the specification permits quoted strings, comments, nested parentheses and address forms nobody has used since the 1980s. Implementing it correctly produces something unreadable and still does not check anything real.
Short patterns fail in the opposite direction and that failure is more expensive. A regex written a decade ago rejects new top-level domains, plus addressing, and hyphens in positions that are perfectly legal. Those rejections are real customers being turned away at a form.
A practical check fits in one line of intent. Exactly one at-sign, something before it, a domain after it containing a dot, no spaces, total length under 254 characters. That catches the mistakes users actually make.
Where it belongs is the browser, before submit, giving instant feedback on a missing at-sign. Every question after that shape check needs a network: does the domain resolve, does it publish a mail server, does that server accept this recipient.
Pair it with a typo suggestion for the largest return. Someone who typed gmial.com is better served by an offer to correct it than by a red border, and that recovers signups a stricter pattern would have lost.
Seven addresses against a pattern people copy
Here's a pattern you'll find pasted into many signup forms: ^[a-z0-9._]+@[a-z0-9.]+\.[a-z]{2,4}$. Run seven addresses through it and see what happens.
It rejects maria+news@gmail.com because of the plus sign. Next to fail is sam@studio.photography, since that ending is longer than four letters. The apostrophe sinks o'brien@example.ie, and the hyphen does the same to lee@north-side.co.uk. All four are legal, working kinds of address. Those are four customers your form turned away.
The same pattern accepts ada@gmial.com, a typo that will never deliver. It accepts bob@closedstartup.io at a company that shut down two years ago. And it accepts test@test.com, which is what people type when they don't want to give you an address. So the pattern blocked four real people and waved through three bad entries, and nothing on your side ever reported either kind of mistake.
The cost you never see, and how to look for it
A false rejection is invisible. Nobody writes to tell you that your form refused their address. They leave, and your analytics record one more abandoned signup with no reason attached.
You can look for it. If your form logs failed submissions, pull the last 50 rejected strings and read them. You're hunting for plus signs, hyphens, apostrophes and long endings like .photography or .technology. Every one you find is a real person your pattern turned away. If the form logs nothing, add the logging for a month and then read what it caught.
Order your checks by price. The shape check runs in the browser and costs nothing. A typo suggestion comes next and is nearly free. The domain lookup and the mailbox check need a server and a network call, so run them last, on strings that passed the cheap checks. Keep the first check loose, because a real address should never fail it.
Related questions
What is the best email regex?
A permissive one: one at-sign, non-empty local part, a domain with a dot, no spaces, under 254 characters. Strict patterns reject valid addresses.
Should a form reject plus addressing?
No. Plus signs are legal and widely used, and rejecting them turns away users who filter their mail carefully.
What is the maximum email address length?
254 characters overall, with the local part capped at 64.
Does HTML5 email validation suffice?
As a first pass in the browser, yes. It checks shape only, and the shape was never the part that mattered.