Email address syntax explained

An email address is valid by the standards when it has a local part, one unquoted @ and a domain, each written in the forms that RFC 5322 and RFC 5321 allow and within their length limits: 64 octets for the local part and 254 for the whole address. The standards allow far more than people really use, such as quoted strings with spaces, comments and IP address literals, so a good form check is looser than a simple pattern and stricter than the full grammar. Syntax only says that an address is well formed. It says nothing about whether the domain receives mail or the mailbox exists.

The two parts of an address

RFC 5322, section 3.4.1, defines the address itself (the addr-spec) as a local part, the @ sign and a domain. The local part is read only by the receiving host, which decides which mailbox it names. The domain says where the mail goes.

jane.doe+news@mail.example.com
\___________/ \______________/
 local part       domain

Dot-atoms: the everyday form

Almost every real address uses a dot-atom local part: one or more runs of allowed characters joined by single dots. RFC 5322, section 3.2.3, lists the allowed characters (atext): letters, digits and these symbols.

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

Because a dot only joins two runs, a local part cannot start or end with a dot or contain two dots in a row. RFC 3696, section 3, gives examples that are valid and seen in practice, such as user+mailbox@example.com, customer/department=shipping@example.com and _somename@example.com. It adds that a program checking addresses cannot know which of these symbols a remote host treats specially, so it should accept them and pass them on. The + is the basis of plus addressing.

Quoted strings

Any other character, including a space, @, a comma or square brackets, can appear only inside a quoted local part, such as "Fred Bloggs"@example.com. A backslash inside the quotes escapes the next character. RFC 3696 first showed backslash escapes without quotes; verified erratum 246 on the RFC Editor site corrects those examples, for instance to "Abc\@def"@example.com. RFC 5322 says the dot-atom form should be used whenever it can express the address, and RFC 5321, section 4.1.2, tells hosts that receive mail to avoid mailbox names that need quoting.

Comments and the obsolete syntax

In a message header, RFC 5322 also lets comments in parentheses and folding white space surround the address. Section 4 goes further: older forms, such as white space or comments between the dot-separated parts and local parts that mix quoted and unquoted words, must not be generated but must still be accepted by a conforming parser. None of this belongs in a sign-up form. The address in the SMTP envelope, defined in RFC 5321, section 4.1.2, has no comments or folding white space at all.

The domain and domain literals

RFC 5322 notes that its own domain syntax is liberal and that implementations must follow the protocol where the address is used. For mail that protocol is SMTP. RFC 5321, section 4.1.2, allows only letters, digits and hyphens in domain labels, says outright that the underscore is not permitted, and requires each label to start and end with a letter or digit. Domains are written in ASCII in SMTP; addresses in other scripts need extensions, covered in internationalized email addresses.

Instead of a domain, an address can name a host by IP address in square brackets, a domain literal such as user@[192.0.2.1] or user@[IPv6:2001:db8::1] (RFC 5321, section 4.1.3). RFC 3696 calls this form strongly discouraged except for testing and troubleshooting.

Length limits: 64, 255 and 254

RFC 5321, section 4.5.3.1, sets the sizes every SMTP implementation must be able to handle, measured in octets (bytes) rather than characters:

The confusion comes from RFC 3696, section 3, which added 64 and 255 to get a total of 320 characters. Two verified errata correct it. Erratum 1003, filed by the RFC's author in 2005, points out that SMTP limits the address in MAIL and RCPT commands to 256 characters. Erratum 1690, verified in 2010, refines that to 254: the path always includes the angle brackets < and >, which leaves 254 octets for the address. Use 254 as your maximum. Since the limits count octets, an address with non-ASCII characters reaches them with fewer characters.

Is an address case sensitive?

The domain is not: it follows DNS rules. The local part is a different matter. RFC 5321, section 2.4, says SMTP software must treat the local part as case sensitive and preserve its case, because on some hosts smith and Smith are different users. The same section discourages relying on that, and section 4.1.2 tells hosts to avoid defining case-sensitive mailboxes.

In practice: store the address as the person typed it, lowercase the domain freely, and compare local parts without case to find duplicates, knowing that this is a convention and not a guarantee.

What a sign-up form should accept

The HTML standard does not use the RFC grammar for <input type="email">. The WHATWG HTML spec defines a valid email address as atext characters and dots, an @, and one or more domain labels of letters, digits and hyphens. It calls this a willful violation of RFC 5322, whose syntax it finds at once too strict before the @, too vague after it, and too lax in allowing comments, white space and quoted strings. Browsers also strip leading and trailing white space from the field.

That definition is a good baseline, with two gaps worth knowing. It accepts user@localhost with no dot in the domain, and it does not reject leading, trailing or doubled dots in the local part. A practical form check:

• trims white space at both ends, then rejects any space, control or invisible character left inside;
• requires exactly one @ and, for addresses on the public internet, a domain with at least one dot;
• accepts every atext symbol, especially +, ' and -, because people really use them;
• enforces 64 octets before the @ and 254 in total, and nothing shorter;
• offers a correction for an obvious typo in the domain instead of rejecting the address.

Then let a verification step decide the rest. Our signup form validation guide shows how. Note that our checker is stricter than the RFC on rare forms such as quoted local parts and address literals: they are answered invalid with the reason invalid_syntax, as the address syntax we accept explains, because almost no mail system takes them.

Common invalid patterns

A mail server can refuse such an address without looking for a mailbox, for example with 553 5.1.3, bad destination mailbox address syntax.

Syntax says nothing about deliverability

A well-formed address can still bounce. jane@example.org passes every syntax rule whether or not the domain has MX records, whether or not a mailbox named jane exists, and whether or not that mailbox is full. A syntax check is only the first step of email verification. In our results, invalid_syntax means the text is not a well-formed address, so no mail server could ever accept it. Answers such as invalid with no_mailbox come from looking at the domain and its mail server, which a syntax check never does.

Questions

What is the maximum length of an email address?

254 octets in practice: 64 for the local part, and the SMTP path limit of 256 minus the two angle brackets. The figure of 320 in the original RFC 3696 was corrected by errata 1003 and 1690.

Is a plus sign allowed in an email address?

Yes. + is an ordinary atext character, and many providers deliver name+tag@ to name@. Rejecting it turns away real customers; see plus addressing.

Should I use a long regular expression from the RFC grammar?

No. A full RFC 5322 pattern accepts comments, quoted strings and literals that real mail systems rarely handle, and it still cannot tell you whether the mailbox exists. A simple check like the one above, followed by verification, works better.

Try it

Paste an address into the free email checker to see the syntax check and the rest of the verification in one result, or clean a whole file with bulk email verification.

Related

• The invalid status: address syntax we accept.
• Signup form validation.
• Glossary: syntax check.
• Bounce code 553 5.1.3.

Related guides

• Email typos and did you mean suggestions
• Plus addressing explained
• Internationalized email addresses explained
• What is email verification?
• Verify an email address without sending a message
• All guides

Sources

• RFC Editor: RFC 5322, Internet Message Format: section 3.4.1 (addr-spec), 3.2.3 (atext and dot-atom) and section 4 (obsolete syntax).
• RFC Editor: RFC 5321, Simple Mail Transfer Protocol: section 2.4 (case of the local part), 4.1.2 (mailbox and domain syntax), 4.1.3 (address literals) and 4.5.3.1 (size limits).
• RFC Editor: RFC 3696, Application Techniques for Checking and Transformation of Names: section 3 (characters in local parts, quoting, the original 320 figure).
• RFC Editor: Erratum 1003 for RFC 3696: the 256-character correction.
• RFC Editor: Erratum 1690 for RFC 3696: the 254-character correction.
• RFC Editor: Errata for RFC 3696: erratum 246, backslash quoting only inside quoted strings.
• WHATWG: HTML Standard, valid email address: the browser definition and why it departs from RFC 5322.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.