What Makes an Email Address Valid: Rules and Limits

Two parts and an @

RFC 5322, the format for email messages, defines an address as local-part "@" domain. The domain says which mail system receives the message; the local part says which mailbox there. RFC 3696 tells applications to pass unusual but valid forms on to the mail system, so the destination host can judge them, instead of filtering them out.

The local part

The usual form is a dot-atom: one or more runs of allowed characters separated by single dots. RFC 5322 lists the allowed characters, called atext: letters, digits and these symbols:

! # $ % & ' * + - / = ? ^ _ ` { | } ~

The grammar puts a dot only between two runs, so a local part cannot start or end with a dot or contain two in a row. jane.doe, o'brien and jane+news are all valid; .jane and jane..doe are not.

Anything else needs the quoted form: the whole local part in double quotes, inside which spaces and most punctuation are allowed, and a backslash escapes a quote or a backslash. RFC 3696 gives "Fred Bloggs"@example.com and "Abc@def"@example.com as examples. They are valid but rare. RFC 5322 says the plain dot-atom form should be used whenever it can be, and RFC 5321 advises mail hosts not to create mailboxes that require quoting.

Case is a trap. RFC 5321 says the local part must be treated as case-sensitive, so Jane and jane could in theory be different mailboxes, but it also calls exploiting that discouraged. The domain is not case-sensitive.

The domain

The domain is usually a host name such as example.com: labels of letters, digits and hyphens, separated by dots. The WHATWG HTML Standard notes that each label is limited to 63 characters by RFC 1034. RFC 5322 also allows a domain literal, an address in square brackets such as jane@[192.0.2.1]. Nothing in the grammar requires a dot: jane@localhost is syntactically valid, even though it cannot be reached from the public internet.

Length limits

The limits come from SMTP, the protocol that carries mail, and RFC 5321 states them in octets, that is, bytes:

Adding the first two parts and the @ gives 64 + 1 + 255 = 320, the total RFC 3696 mentions. But the SMTP path wraps the address in angle brackets, <jane@example.com>, and those two characters count toward its 256 octets. The verified erratum 1690 corrects RFC 3696 on this point: an address in the MAIL and RCPT commands is limited to 256 − 2 = 254 characters. A form field should accept addresses up to 254 characters.

Plus addressing

The plus sign is ordinary atext, and many mail systems use it to add a tag to an address. RFC 5233 calls this subaddressing and gives the example ken+sieve@example.org, which reaches user ken with the detail sieve. The RFC also says the encoding of such addresses is site or implementation specific, so a form must not strip the tag or assume what it means. Reject the plus sign and you reject real users. To pull every address, tagged or not, out of a pasted list, the Email Extractor finds them, removes duplicates and filters by domain.

Internationalized addresses

RFC 6531 defines an SMTP extension, announced with the keyword SMTPUTF8, under which the local part may contain non-ASCII characters and the domain is an internationalized domain name. It does this by extending atext with UTF-8 characters. Both the sending and the receiving server need the extension. The octet limits still apply, and in UTF-8 a character outside ASCII takes more than one octet:

So a local part made of such characters reaches the 64-octet limit with fewer than 64 characters. Count bytes, not characters, if you enforce the limit.

Why input type=email is simpler

The browser check on <input type="email"> follows the WHATWG HTML Standard, which defines its own "valid email address" and calls it a willful violation of RFC 5322. It describes that RFC as too strict before the @, too vague after it and too lax about comments, whitespace and quoted strings for practical use. The standard gives this JavaScript-compatible regular expression:

/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

It allows atext and dots in any order before the @, then one or more labels of up to 63 characters. It does not require a dot in the domain. With the multiple attribute the field accepts a comma-separated list. Here is how the two rules judge some addresses, tested with the regular expression above and a simplified RFC 5322 pattern without comments or obsolete forms:

The HTML rule lets through dot patterns RFC 5322 forbids, and turns away quoted local parts and domain literals that RFC 5322 allows. Neither accepts the address with an accented letter; that takes the RFC 6531 extension. For a sign-up form it is a sensible middle ground. Try either pattern in the Regex Tester; to put one into a JSON config or a string literal in code, Text Escape and Unescape doubles the backslashes for you.

Confirm by sending, not by regex

A syntax check answers one question: could this be an address? It cannot tell whether the mailbox exists or belongs to the person typing it. jane@gmial.com passes every rule on this page. The OWASP cheat sheet on email validation warns that strict regex validation often rejects valid addresses, recommends a well-tested library over a custom pattern, and says ownership is proven by sending a message with a random token that is single-use and time-limited.

• Check loosely. One @, something on each side, at most 254 characters. The browser's type=email rule is enough.
• Then send a confirmation link. The click proves that the address works and that the person controls it.
• Store what was typed. Do not remove dots, tags or capitals; OWASP advises against provider-specific rewriting, and RFC 5233 says tag handling depends on the site.

Frequently asked questions

Sources

• RFC 5322, Internet Message Format (3.4.1: addr-spec = local-part "@" domain, local-part as dot-atom or quoted-string, domain as dot-atom or domain-literal, the dot-atom form SHOULD be used; 3.2.3: the atext characters)
• RFC 5321, Simple Mail Transfer Protocol (2.4: local part case-sensitive, exploiting it discouraged, domains not case-sensitive; 4.1.2: hosts SHOULD avoid mailboxes that need quoting; 4.5.3.1: 64 octets local part, 255 octets domain, 256 octets path including punctuation)
• RFC 3696, Application Techniques for Checking and Transformation of Names (Informational; section 3: 64 plus 255 characters, backslash and double-quote quoting with examples, filters should not reject quoted forms)
• RFC Editor, verified erratum 1690 to RFC 3696 (the path limit means an address in MAIL and RCPT commands is limited to 254 characters, because the path includes the two angle brackets)
• RFC 5233, Sieve Email Filtering: Subaddress Extension (subaddressing with a separator such as +, the example ken+sieve@example.org, encoding is site or implementation specific)
• RFC 6531, SMTP Extension for Internationalized Email (the SMTPUTF8 keyword, non-ASCII characters in the local part, atext extended with UTF8-non-ascii, domains under IDNA rules)
• WHATWG HTML Living Standard, the Email state of input type=email (the valid email address ABNF, a willful violation of RFC 5322, the JavaScript-compatible regular expression, labels limited to 63 characters, the multiple attribute)
• OWASP Email Validation and Verification Cheat Sheet (strict regex validation often rejects valid addresses; prefer tested libraries; verify with single-use, time-limited tokens; define an explicit comparison policy)

Written by Tobias. Updated November 2, 2026.