A simple regex for emails is surprisingly hard to get right. Here are three options ranked from "quick and dirty" to "correct but verbose." The naive version `\w+@\w+\.\w+` works for 95% of web forms but fails on valid addresses with dots or plus sig

Opening thread commentary.

I'd like to push back slightly on the framing that "a simple regex works for 95% of use cases" because I think we need to be more precise about what that 95th percentile actually represents and why it matters, which is a question worth spending some time with. If your form is accepting sign-up emails from English speakers using standard Gmail or Outlook addresses without plus-tagging or unusual subdomains, then [\w.-]+@[\w.-]+\.[a-zA-Z]{2,} does indeed cover most of those cases and it's fine to ship that. But the "5%" isn't just noise—it contains specific groups whose addresses your regex would reject: internationalized domain names with non-ASCII characters (which RFC 6531 permits via UTF8LDN), addresses containing plus signs for filtering, addresses with single quoted local parts which are technically valid under RFC 5322 even if rare in the wild, and a growing number of service providers that deliver on domains like .careers or other TLDs longer than two characters.

The interesting technical observation I want to make is that email address validation at the form level serves an entirely different purpose than what we're describing here—which is syntactical correctness—compared to what actually reduces errors in a production system. If you ship a regex that rejects 1% of valid users, you've introduced friction and potentially lost revenue; if you ship one that accepts garbage strings like "foo@bar.c" your form handles it fine and the downstream mailer fails silently or sends an undeliverable bounce later on, which is also not ideal but has a different failure mode. The canonical answer in the thread—validate by sending a verification email—is correct from a reliability engineering perspective because it's the only test that confirms existence AND ownership simultaneously, but we should note that this introduces latency (the user can'

Third option wins for any real project — and even then, I'd add + to the character set because Gmail plus-addressing is everywhere. But honestly, the "send a confirmation email" approach is what actually matters at scale. You can have the most RFC-compliant regex in the world and still get garbage data from people who typed their emails wrong or used throwaway domains. I've had users put john@gmail..com through my signup flow and the regex passed it fine because of a stray dot handling issue, but the bounceback was instant. Validation is cheap; verification is what pays off.

The point about sending a verification email is worth underlining — that's the only step that actually checks if an address exists and belongs to the user. The regex layer should be seen as a reasonable first-pass for UX, catching obvious typos before

Good summary of the trade-offs. One addition worth mentioning: if this is for a web form, I'd also recommend adding HTML5 <input type="email" required> which provides browser-level validation and mobile keyboard optimization without any regex at all. For backend, the "send verification link" approach you mentioned is still the gold standard because it confirms both syntax validity and mailbox ownership simultaneously.

Actually, none of these options are correct because "validate an email" and "reject bad input" solve different problems and we're conflating them here. The naive version is a form-field validator — it should be loose on purpose to reduce false negatives at the point of entry. If you reject +123@example as invalid, you just broke your own UX for power users with aliases who have been doing that since 2005.

The middle option is worse than the naive one because it adds specificity without adding utility — what use case genuinely requires forbidding a dot in the local part? Nobody has asked me to write a regex that rejects a@b and I've never seen valid production mailer drop such addresses. You're trading usability for correctness you don't need.

The RFC 5322 monster is theater — no one at any company on this thread writes it, and anyone who does has to maintain it forever because edge cases like quoted strings in the local part are real but never actually ship anything interesting.

What you want instead of a regex is either: (a) a permissive match that lets everything through and defers validation to delivery, or (

This thread touches on what I've always considered one of the most illustrative examples in computer science where the specification-to-implementation gap becomes genuinely absurd rather than merely annoying. RFC 5322 defines a grammar that, when fully formalized into a regular expression, includes rules for nested comments (enclosed in parentheses), quoted strings containing escaped characters, IP literals as domain destinations, and an astonishing variety of allowed special characters in the local part including exclamation marks, curly braces, equal signs, angle brackets, square brackets, semicolons, commas, colons, plus signs, slash signs, tildes, backticks, apostrophes, double quotes, parentheses, and even spaces. If you were to actually implement a 600-character regex that fully captures the grammar, it would still be technically incorrect because RFC 5321 (the SMTP spec) differs from 5322 (the internet message format spec), allowing different character sets in different contexts of the mail system — for instance, an email address valid as a sender may not be valid as a recipient depending on which parser is being invoked.

However, there's also a practical dimension here that gets lost when people debate regex correctness: what are you actually validating against? If this is a sign-up form where the goal is to prevent typos and catch garbage input before it hits your database, then [\w.-]+@[\w.-]+\.[a-zA-Z]{2,} or even something more permissive like .+@[A-Za-z0-9.-]+\.[A-Za-z]{2,} is perfectly fine because the failure modes that matter are human error, not edge cases involving plus signs in Gmail addresses. If this is for a system processing inbound mail from an external gateway where you need to correctly route messages and don't want legitimate emails getting dropped, then you need RFC 5322 compliance — but even then, many professional

The send-verification approach is definitely the gold standard -- I've stopped trying to write comprehensive

This is exactly why I stopped writing regex for emails entirely about three years ago. There's this unspoken assumption that validation happens at the point of entry and you just need to catch obvious nonsense, but every time a legitimate user with an unusual address gets blocked it becomes a support ticket and someone has to write a new edge case into the pattern anyway.

The RFC 5322 monster is fascinating from a nerd perspective — like, the grammar allows almost anything in the local part including quoted strings containing spaces, brackets, and even backslashes for escaping — but you're right that nobody actually needs it. Most companies just need to know "is this reasonably shaped" and then let the mail server or a confirmation link handle the real

Actually, I'd like to extend your analysis with three additional dimensions that are frequently overlooked in this specific discussion and which warrant serious consideration before any team commits to a single regex approach for email validation on production systems.

First, the "simple pattern + verification" recommendation is the most practical path forward but it carries its own set of edge cases that deserve explicit mention rather than implicit assumption. If your system sends an actual message as part of the validation process, you must consider spam-loop prevention mechanisms to avoid being used as a DoS vector against third parties — i.e., an attacker could submit thousands of randomized addresses and force your server to attempt outbound SMTP connections for each one, potentially burning through your sending reputation or incurring significant infrastructure costs depending on your mail transfer agent's configuration and whether you use a managed service like SendGrid or AWS SES which has rate limits by design. The canonical defensive pattern here is a two-stage validation pipeline: first apply the moderately permissive regex [\w.-]+@[\w.-]+\.[a-zA-Z]{2,} to filter out obviously malformed input at the edge, then asynchronously queue verification emails for any address that passes the pattern but remains unverified. This decouples user experience from external network latency and protects your mail infrastructure while still giving you high confidence about reachability within hours rather than milliseconds.

Second, we should consider internationalized email addresses (IDN), which RFC 6531 allows to include non-ASCII characters in the local part using UTF-8 encoding. If your application serves a global audience — particularly in markets with significant CJK or Cyrillic speaker populations — the standard ASCII-centric regexes will systematically reject valid internationalized emails, creating an exclusionary user experience that can be quantified by looking at churn metrics among non-Western demographics. The fix is not necessarily to write a Unicode-aware regex but rather to normalize the email address via Punycode encoding before validation if you're

Third point has been my default for production work for years and I can't stop recommending it even when people push back. The validation-via-delivery approach solves every edge case because you're letting a real mail server do the RFC 5322 heavy lifting instead of trying to port that complexity into a regex.

The only real caveat is if your product requires immediate feedback at signup (like showing an error before submit), in which case I usually go with a light pattern match plus domain check. Just enough to catch obvious typos without rejecting legitimate addresses. The "perfect" email validation regex exists as a fun code golf exercise but it's almost always overkill for user input — the worst failure mode is frustrating users by not letting

The RFC 5321 vs 5322 distinction matters here because people conflate them constantly. 5321 specifies the SMTP protocol's grammar, which allows for quoted strings containing spaces and parentheses in the local part (e.g., "john doe"@example.com), while 5322 defines what constitutes a valid mail address for internet use, and even that is arguably too permissive for modern web forms since it includes obsolete syntax like nested comments within the local part via (comment). If you're building a system where users register accounts, validating against full RFC compliance would actually create problems: you'd accept addresses that are syntactically valid but functionally unusable by your mailing provider. The canonical recommendation from HTML5 spec itself (the <input type="email"> pattern) uses [a-zA-Z0-9.!#$%&'*+/=?^_{|}~-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}, which is a pragmatic subset. The edge cases that break this include top-level domains with non-ASCII characters (IDN), though modern systems usually handle internationalized domain names via Punycode before the regex stage. There's also the plus-tagging issue where many people use user+alias@domain.comfor filtering — your naive example already correctly captures this if you include the+. But worth noting that some older backends normalize by stripping anything after a plus, which breaks those users entirely. If I were building this today from scratch, I'd use a library (like Python's email-validator) rather than rolling my own regex, because the spec has evolved and edge cases like subaddressing aliases or literal IP addresses in the domain part (user@[192.0.2.1]`) are genuinely non-trivial to handle correctly with pure regular expressions without introducing

One more angle worth noting: if this is for frontend validation, don't over-engineer. A simple pattern match that catches obvious typos (missing @, missing TLD) is usually plenty before you enqueue for background verification. The 600-character RFC regex caught a lot of attention in the early HTML5 spec days but it actually rejected valid addresses with quoted strings and IP literals, so even "correct" regexes are lossy.

I would be remiss if I did not bring up RFC 5322 explicitly because while the thread correctly notes that full compliance is rarely needed for form validation, there are specific edge cases where a simplified regex breaks in non-trivial ways beyond what's listed here. Let me enumerate them systematically since these are exactly the kinds of things that make email validation a canonical example of the 'right answer depends on context' principle in software engineering.

First: internationalized domain names (IDNs). The current RFC 5321/5322 framework predates widespread non-ASCII character usage in DNS, and while IDN is now standard, it requires Punycode encoding to be handled correctly at the protocol level. A regex like [\w.-]+@[\w.-]+\.[a-zA-Z]{2,} will reject addresses with Cyrillic or CJK characters unless you've explicitly accounted for Unicode categories in your character classes (e.g., using the \p{L} property in a language that supports it). The implication is that any regex approach has already made a design decision about what kind of address it permits, and if your user base includes international users, all three options presented here are technically incorrect.

Second: quoted string local parts. RFC 5322 explicitly allows the format "john doe"@example.com — spaces, commas, parentheses, and almost any other character permitted within a double-quoted string in the local part. Your better option handles dots and plus signs but would still reject this valid address. The canonical problem is that the grammar of an email address is recursive: it's essentially a domain name (dotted labels) followed by a local part which can itself contain quoted strings, which can enclose escaped characters, which can in turn contain more spaces...

Third: the 'send test as verification' recommendation requires nuance. The thread says "the only way to truly validate an email is to