# Email Address Syntax: What the RFCs Allow and Forms Accept

URL: https://email-validation.org/guides/email-address-syntax/
Updated: 2026-11-06

> Documentation index: https://email-validation.org/llms.txt

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](https://www.rfc-editor.org/info/rfc5322/), 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.

```text
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.

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

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](https://www.rfc-editor.org/info/rfc3696/), 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](https://email-validation.org/guides/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](https://www.rfc-editor.org/info/rfc5321/), 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](https://email-validation.org/guides/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:

| Element | Limit | RFC 5321 section |
|---|---|---|
| Local part | 64 octets | 4.5.3.1.1 |
| Domain | 255 octets | 4.5.3.1.2 |
| Path (the address in angle brackets, as sent in MAIL FROM or RCPT TO) | 256 octets, punctuation included | 4.5.3.1.3 |
| Whole address, in practice | 254 octets | follows from the path limit |

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](https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address) 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](https://email-validation.org/guides/email-typos/) instead of rejecting the address.

Then let a verification step decide the rest. Our [signup form validation guide](https://email-validation.org/docs/guides/signup-form-validation/)
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](https://email-validation.org/docs/statuses/invalid/#syntax)
explains, because almost no mail system takes them.

## Common invalid patterns

| Input | What is wrong |
|---|---|
| `jane.doe.example.com` | No `@` at all |
| `jane@doe@example.com` | A second `@` outside quotes |
| `jane doe@example.com` | A space outside quotes |
| `.jane@example.com`, `jane.@example.com`, `jane..doe@example.com` | A dot at the start or end of the local part, or two in a row |
| `jane@example,com` | A comma, which is only allowed inside quotes |
| `jane@my_company.com` | An underscore in a domain label (RFC 5321, section 4.1.2) |
| `jane@-example.com` | A domain label that starts or ends with a hyphen |
| `Jane Doe <jane@example.com>`, `mailto:jane@example.com` | A display name or a link prefix pasted with the address |

A mail server can refuse such an address without looking for a mailbox, for example with
[553 5.1.3](https://email-validation.org/bounce-codes/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](https://email-validation.org/glossary/#mx-record), whether or not a mailbox named `jane` exists, and whether or not that mailbox is
full. A [syntax check](https://email-validation.org/glossary/#syntax-check) is only the first step of
[email verification](https://email-validation.org/guides/what-is-email-verification/). In our results,
[`invalid_syntax`](https://email-validation.org/docs/statuses/invalid/#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`](https://email-validation.org/docs/statuses/invalid/#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](https://email-validation.org/guides/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](https://email-validation.org/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](https://email-validation.org/bulk-email-verification/).

## Related

- [The invalid status: address syntax we accept](https://email-validation.org/docs/statuses/invalid/#syntax).
- [Signup form validation](https://email-validation.org/docs/guides/signup-form-validation/).
- [Glossary: syntax check](https://email-validation.org/glossary/#syntax-check).
- [Bounce code 553 5.1.3](https://email-validation.org/bounce-codes/553-5-1-3/).

## Related guides

- [Email typos and did you mean suggestions](https://email-validation.org/guides/email-typos/)
- [Plus addressing explained](https://email-validation.org/guides/plus-addressing/)
- [Internationalized email addresses explained](https://email-validation.org/guides/internationalized-email-addresses/)
- [What is email verification?](https://email-validation.org/guides/what-is-email-verification/)
- [Verify an email address without sending a message](https://email-validation.org/guides/verify-email-without-sending/)
- [All guides](https://email-validation.org/guides/)

## Sources

- [RFC Editor: RFC 5322, Internet Message Format](https://www.rfc-editor.org/info/rfc5322/): 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](https://www.rfc-editor.org/info/rfc5321/): 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](https://www.rfc-editor.org/info/rfc3696/):
  section 3 (characters in local parts, quoting, the original 320 figure).
- [RFC Editor: Erratum 1003 for RFC 3696](https://www.rfc-editor.org/errata/eid1003): the 256-character correction.
- [RFC Editor: Erratum 1690 for RFC 3696](https://www.rfc-editor.org/errata/eid1690): the 254-character correction.
- [RFC Editor: Errata for RFC 3696](https://www.rfc-editor.org/errata/rfc3696): erratum 246, backslash quoting only
  inside quoted strings.
- [WHATWG: HTML Standard, valid email address](https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address):
  the browser definition and why it departs from RFC 5322.

## Get up to 500 free credits. No card needed.

New accounts get 500 free credits (100 when you sign up with a free email provider such as Gmail, Outlook or Yahoo, or another personal mailbox such as a paid one like Fastmail or one from your internet provider). Try it on your own list before you buy. [Create your account](https://email-validation.org/signin/?new=1) or [open the free email checker](https://email-validation.org/email-checker/).