A practical pattern that covers the vast majority of real addresses
^[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}$
Reading it apart: one or more word characters, dots, plus signs, or hyphens (the local part before @), then @, then a domain name segment, a literal dot, and a top-level domain of at least 2 letters. This catches the overwhelming majority of real-world addresses people actually type.
Why the "fully correct" pattern is enormous
RFC 5322, the actual specification for email address syntax, permits far more than most people expect: quoted local parts ("very.unusual.@.unusual.com"@example.com is technically valid), comments, and characters most simplified patterns reject outright. A regex that fully implements RFC 5322 runs to hundreds of characters and is notoriously difficult to read, maintain, or debug — and even then, largely validates addresses that no real mail provider would ever actually issue, since the practical universe of real addresses is much narrower than what the spec technically allows.
Why format validation alone never proves an address is real
This is the more important point than pattern complexity: no regex, however precise, can confirm an email address actually exists or that the sender controls it. format-looks-right@example.com passes any syntactic check while being completely undeliverable or belonging to someone else entirely. The only way to confirm an address is real and reachable is to actually send something to it — a verification email with a confirmation link is the standard, and really the only reliable, approach.
What this means practically
| Check | What it confirms |
|---|---|
| Regex format validation | The string is shaped like an email address |
| Verification email sent | The address exists and the recipient can receive mail there |
| Verification link clicked | The person submitting the form actually controls that inbox |
A reasonable regex is still worth having — it catches obvious typos immediately, improving user experience before a submission even reaches the server — but it should never be treated as proof of a valid, controlled address. That confirmation always requires an actual email round-trip.
Common mistakes
- Chasing a "perfect" RFC 5322-compliant regex as if stricter pattern matching solves a problem only a verification email can actually solve.
- Rejecting technically valid but unusual addresses (like ones with a
+for inbox filtering:user+tag@example.com) with an overly restrictive pattern — this is a common source of legitimate user frustration. - Treating passed regex validation as proof the address is real or owned by the submitter. It only confirms the shape; existence and ownership require an actual verification step.
FAQ
Is it worth writing a fully RFC 5322-compliant regex?
Rarely — the complexity cost is high, it validates many addresses no real system would issue, and it still can't confirm an address is real or reachable, which is what actually matters for most use cases.
Can a regex confirm an email address exists?
No — only sending an actual message (typically a verification link) and confirming it's received and acted upon can establish that.
Should a simple email regex reject addresses with a + in them?
No — user+tag@example.com is a valid, common convention (many providers support it for inbox filtering) and rejecting it is a common, avoidable validation mistake.
Test email validation patterns against real sample addresses with the Regex Tester — entirely in your browser.