What Makes an Email Address Valid? RFC Syntax Rules, Weird Edge Cases, and Why Regex Fails

Ask ten developers what makes an email address valid and you will get ten regular expressions, most rejecting addresses the standards allow and accepting addresses no server will deliver to. The real rules live in RFC 5321 and RFC 5322, and they are stranger than most validation code assumes. This guide walks the specification in plain language: the exact character rules, the weird-but-valid edge cases, the regex failure gallery, and the two-line approach that beats them all.

The Local Part: Stranger Than You Think

Everything before the @ is the local part, and the specification is far more permissive than intuition suggests. In the ordinary dot-atom form, every letter and digit is allowed alongside these specials: ! # $ % & ' * + - / = ? ^ _ ` { | } ~. Dots may appear between characters but not at the start, at the end, or doubled. That makes user.name+tag@example.com, customer/department=shipping@example.com, and !def!xyz%abc@example.com all fully standards-compliant.

Then there is the quoted form, the part of RFC 5322 that breaks the most validators: wrap the local part in double quotes and nearly anything goes, including spaces. "john smith"@example.com and "very.unusual.@.address"@example.com are legal addresses. Almost no mainstream provider will let you register one, but the syntax is valid, and mail systems that meet the standard must parse it.

The Domain Side: Labels, Hyphens, and DNS

The domain is a sequence of labels joined by dots, each label 1-63 characters of letters, digits, and hyphens, with hyphens forbidden at a label's edges. The full domain caps at 255 characters. Syntax, though, is only the entry ticket on this side: a domain that parses perfectly but has no MX record (and no fallback A record) cannot receive mail, which makes DNS resolution the first genuinely semantic check in any validation pipeline. Whether a syntactically fine domain actually routes mail is a one-second question for a domain email verification check.

Two details trip up validators here. Top-level domains longer than four characters are routine now (.museum, .technology, .international), so any regex with a {2,4} TLD quantifier rejects real customers. And a trailing dot (example.com.) is technically a valid fully qualified DNS name, another case where the standard is looser than the folklore.

Weird but Valid: The Edge Case Gallery

The gallery teaches one lesson: well-formed and deliverable are different properties. A validator can be perfectly faithful to the RFC and still tell you nothing about whether mail will arrive.

Provider Conventions: Plus Tags, Gmail Dots, and Case

Several famous email behaviors are provider conventions, not syntax rules. Plus-addressing (user+newsletter@gmail.com routing to user@) is a subaddressing convention many providers implement; the RFC just sees + as another legal character, so stripping tags is a business decision about identity, not a validation step. Gmail additionally ignores dots in local parts (u.ser@ and user@ reach the same inbox), a Gmail-specific behavior that is wrong to generalize: on most mail systems those are different mailboxes. And while RFC 5321 technically permits case-sensitive local parts, virtually every provider treats User@ and user@ identically, so lowercasing on intake is safe in practice and universal in deduplication pipelines.

Internationalized Addresses and Punycode

Internationalized domains (münchen.de, 日本.jp) travel through DNS as ASCII punycode (xn--mnchen-3ya.de), so a validator that rejects non-ASCII domains rejects real registrable names; the conversion, not rejection, is the correct handling. Fully internationalized local parts (用户@example.cn) go further, requiring the SMTPUTF8 extension end to end, and support remains uneven across providers in 2026. The pragmatic policy for most systems: accept internationalized input, convert domains to punycode for DNS work, and let mailbox verification report whether the receiving infrastructure actually supports the address, because that varies server by server in a way no syntax rule can encode.

Why Regex Fails: The Failure Gallery

Every popular email regex is wrong in both directions at once, and the classic patterns fail predictably:

import re

# The regex everyone copies from a forum answer
naive = re.compile(r"^[\w.-]+@[\w-]+\.[a-z]{2,4}$")

# FALSE REJECTS: all of these are valid addresses
print(naive.match("user+tag@example.com"))        # None: rejects plus
print(naive.match("o'brien@example.ie"))         # None: rejects apostrophe
print(naive.match("team@company.technology"))    # None: TLD {2,4} myth
print(naive.match("info@mail.example.co.uk"))    # None: multi-label domain

# FALSE ACCEPTS: these pass and can never receive mail
print(naive.match("user@nonexistent-domain-xkcd.com"))  # matches: no DNS check
print(naive.match("a" * 99 + "@example.com"))       # matches: no 64-char limit

# The two-line check that beats every clever regex:
def plausible(addr):
    local, sep, domain = addr.rpartition("@")
    return bool(sep) and 0 < len(local) <= 64 and "." in domain and len(addr) <= 254
# ...then hand plausible addresses to real mailbox verification

Tightening the pattern never wins. A regex that fully encoded RFC 5322 runs thousands of characters, remains unreadable, and still validates only syntax: it will approve every well-formed address at a dead domain and every gibberish local part at Gmail. The failure is architectural, not a matter of finding a better pattern.

The Right Architecture: Permissive Syntax + Real Verification

Production systems that get this right all converge on the same split: a deliberately permissive syntax gate (has one @, sane lengths, a dotted domain) that never rejects a real customer, followed by verification that answers the question regex never could: does this mailbox exist and accept mail. The verification layer performs the DNS resolution, MX lookup, and live SMTP conversation, and returns syntax failures, dead domains, and nonexistent mailboxes as distinct results (the three layers separate visibly when you run any address through an instant email verification check), via a real-time email verification API call at capture or a bulk email list verification pass for existing data.

The division of labor is clean: syntax rules reject the structurally impossible instantly and for free, and the mailbox probe settles everything syntax cannot see. The response schema and event codes for the verification side are documented in the email verification API docs; primary sources for the syntax side are the specifications themselves, RFC 5321 for the SMTP transport rules and RFC 5322 for the message format grammar.

Frequently Asked Questions

The Bottom Line

The RFC rules are worth knowing precisely so you stop trying to enforce them with patterns: the specification is permissive in ways that break strict validators and silent on the one thing senders care about, whether mail arrives. Validate structure loosely (one @, sane lengths, a dotted domain), and delegate the real question to a mailbox probe.

Your O'Briens sign up, your .technology customers get through, and the perfectly formed garbage gets caught by the only check that can catch it.