RFC 5322 Email Syntax in Plain English

RFC 5322 allows an email address made of a local part, an @ sign and a domain. The local part may use letters, digits, dots between characters and twenty printable symbols, or a quoted string. The domain may be a dot-separated name or a bracketed IP address. Trueguard publishes this guide alongside its free email syntax checker.

The set of legal addresses is much wider than the set people actually use. The grammar admits spaces and @ signs inside quotes, and IP addresses in place of a domain name. The large mail providers publish far narrower rules for the usernames they let people register, and some publish none. A signup form sits between those two sets, and a validation pattern decides which side it errs on.

What is an email address made of?

RFC 5322 section 3.4.1 defines an address as addr-spec:

addr-spec  = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain     = dot-atom / domain-literal / obs-domain

Each half has three forms. The dot-atom is the ordinary form, as in jane.doe@example.com. The quoted string (for the local part) and the domain literal (for the domain) are the unusual forms. The obs- rules are the obsolete syntax. RFC 5322 calls the current syntax the "generating" syntax and the obsolete one the "interpreting" syntax, so software that writes addresses uses the current form.

A quoted local part can contain its own @ sign. The separator is the @ that sits outside any quotes. Code that splits an address on the first @ it finds will break on legal input.

The grammar also allows comments in parentheses and folding white space around a dot-atom, through the CFWS rule. The obsolete syntax goes further. In RFC 5322's own words, white space and comments "could be freely inserted between any syntactic tokens. This allowed many complex forms that have proven difficult for some implementations to parse."

Which characters can the local part use?

An unquoted local part is built from atext, which RFC 5322 describes as "Printable US-ASCII characters not including specials":

• letters A to Z and a to z
• digits 0 to 9
• the twenty symbols ! # $ % & ' * + - / = ? ^ _ ` { | } ~

Printable ASCII characters missing from that list include parentheses, angle brackets, square brackets, the colon, the semicolon, the comma, the @ sign, the backslash and the double quote. Any of those in a local part means the local part has to be quoted.

Where can dots go in an email address?

The dot is handled by its own rule:

dot-atom-text = 1*atext *("." 1*atext)

Read plainly, an unquoted local part starts with at least one atext character, and every dot must be followed by at least one more. That rules out a leading dot, a trailing dot and two dots in a row. jane.doe is legal. .jane, jane. and jane..doe are not, unless quoted.

Inside quotes the dot is an ordinary character. It falls within the qtext range, so "jane..doe"@example.com is legal.

What is a quoted local part?

A quoted local part is a local part wrapped in double quotes:

quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS]
qcontent      = qtext / quoted-pair
qtext         = %d33 / %d35-91 / %d93-126 / obs-qtext

The qtext ranges cover every printable ASCII character except the double quote (decimal 34) and the backslash (decimal 92). Those two can still appear. RFC 5322 says "the quote and backslash characters may appear in a quoted-string so long as they appear as a quoted-pair", meaning preceded by a backslash. White space is allowed through the FWS rule, so "Fred Bloggs"@example.com is a legal address.

RFC 5322 adds that "A quoted-string is treated as a unit. That is, quoted-string is identical to atom, semantically." RFC 3696, the IETF's informational guide to checking names, states the practical position: "The quoted forms are rarely used in practice, but are required for some legitimate purposes."

How long can an email address be?

RFC 5321, the SMTP standard, sets the limits in section 4.5.3.1:

Adding 64 and 255 gives 320, and RFC 3696 originally cited that figure. Verified erratum 1690 corrects it: the path limit applies to addresses in the MAIL and RCPT commands, and "the upper limit on address lengths should normally be considered to be 254." The two angle brackets around the address take 2 of the 256 octets.

The unit is the octet. RFC 5321 says so deliberately, because "Extensions to SMTP may involve the use of characters that occupy more than a single octet each." A length check that counts characters can pass a non-ASCII local part that exceeds 64 octets.

Can the domain be an IP address?

Yes. The domain-literal form puts the domain in square brackets, as in user@[192.0.2.1]. Its content is dtext, which RFC 5322 defines as "Printable US-ASCII characters not including "[", "]", or "\".

RFC 3696 permits the form and warns against it in one sentence: "The domain name can also be replaced by an IP address in square brackets, but that form is strongly discouraged except for testing and troubleshooting purposes."

Can an email address contain Unicode characters?

Yes, under two 2012 extensions. RFC 6532 extends the RFC 5322 grammar "in order to allow UTF-8 content", adding non-ASCII UTF-8 to atext, qtext and dtext, among other rules. An address like 用户@example.com is therefore legal under RFC 6532.

Transport is a separate matter. RFC 6531 defines the SMTPUTF8 extension, which a receiving server announces in its EHLO response, and it requires that strings "MUST be expressed in UTF-8." A non-ASCII local part depends on the servers in the delivery path supporting that extension. ICANN's ITHI metric surveys MX servers in gTLD second-level domains each quarter to test whether they announce SMTPUTF8 and accept non-ASCII addresses.

Domain names have their own mechanism. IDNA, defined in RFC 5890, gives every internationalized label two forms: the U-label in native Unicode, and the A-label, an ASCII string with the prefix xn-- followed by Punycode. The 63-octet DNS label limit applies to the A-label. RFC 3696 notes that the length of the converted form "may restrict the number of actual characters (in the original character set) that can be accommodated."

Is the plus sign valid in an email address?

Yes. + is an atext character, so it is legal anywhere in an unquoted local part.

RFC 5233, the Sieve subaddress extension, documents the convention built on it. It describes "email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., "ken+sieve@example.org")" and models the address as a user part, a separator and a detail part. The RFC treats the separator as implementation specific, with + as its example. How providers route and normalise subaddresses is a separate topic, covered in its own guide.

Which weird email addresses are valid?

RFC 3696 section 3 lists examples that pass the grammar. The quoted and symbol-heavy ones hold under RFC 5322 as written:

RFC 3696 also lists three backslash forms without quotes: Abc\@def@example.com, Fred\ Bloggs@example.com and Joe.\\Blow@example.com. Under the RFC 5322 grammar the backslash is not atext, and in a local part quoted-pair appears only inside a quoted string. Written in RFC 5322 form, the escapes belong inside quotes, as in the first two rows of the table.

What do mail providers let you create?

The grammar defines what is legal. Provider help pages define what their users can register. Gmail, Outlook.com, Yahoo and iCloud publish the following:

Gmail's page is the most explicit: "Usernames can contain letters (a-z), numbers (0-9), and periods (.)." It continues: "Usernames cannot contain an ampersand (&), equals sign (=), underscore (_), apostrophe ('), dash (-), plus sign (+), comma (,), brackets (<,>), or more than one period (.) in a row." It also says that "periods (dots) don't matter in Gmail addresses."

None of these pages documents whether the provider delivers mail to quoted local parts or IP-literal domains. That is a gap in the documentation, and it should be read as undocumented rather than unsupported. These rules also describe each provider's own usernames only. An address at a company or personal domain follows whatever that domain's operator allows, within the RFC grammar.

Check an address in seconds. The free email syntax checker runs 10 checks per day with no signup. For signup traffic, Trueguard's email validation API checks syntax, MX records and the mailbox. A free API key needs no credit card.

Why does HTML type="email" reject legal addresses?

The HTML Standard does not use RFC 5322 for this. The WHATWG defines its own grammar for <input type="email">:

email = 1*( atext / "." ) "@" label *( "." label )
label = let-dig [ [ ldh-str ] let-dig ]

The standard is direct about the choice: "This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here."

The WHATWG grammar has no quoted strings, comments or domain literals, so "Fred Bloggs"@example.com and user@[192.0.2.1] fail it. It is also looser in one place. Its local part is any run of atext and dots, so a leading dot, a trailing dot or a double dot passes the browser check while failing RFC 5322. Domain labels are letters, digits and hyphens, start and end with a letter or digit, and are limited to 63 characters. A single label such as user@localhost matches the grammar.

What should a signup form accept?

The sources point to a short set of rules for a validation pattern.

Accept every atext character. +, /, =, ', & and _ are all legal in an unquoted local part.

Do not reject quoted local parts in a filter. RFC 3696 says quoted forms "should not be rejected in filtering routines but, should instead be passed to the email system for evaluation by the destination host."

Split the address on the @ outside the quotes. A quoted local part may contain its own @.

Enforce dot placement only on unquoted local parts: no leading, trailing or consecutive dots outside quotes.

Count octets against the 64, 255 and 254 limits. Non-ASCII characters can occupy more than one octet each.

Treat Unicode as a delivery question as well as a syntax question. RFC 6532 makes the address legal, and RFC 6531 governs whether it can be sent.

Syntax is the first check. A syntactically perfect address can still sit on a domain with no mail server, which is what an MX record lookup answers. It can sit on a catch-all domain that accepts every local part, so the mailbox itself goes unconfirmed. It can also be a role-based address such as postmaster@. For browser-side checks before submit, see email validation in JavaScript.

Validate addresses before they reach your database. Try the free email syntax checker, or get a free API key for Trueguard's email validation API, which checks syntax, MX records and the mailbox. No credit card required.