What is the maximum length of a valid email address?

Question

What is the maximum length of a valid email address? Is it defined by any standard?

Photoflood

What kind of email address? Internet, X.400, or other? – Egotist

Note that the length limit your app should impose for email addresses might not be the same as the theoretical maximum (which is longer than this whole comment). Other answers discuss that question, e.g.: stackoverflow.com/questions/1297272 – Bowleg

I tried to create a gmail address with 245 chars (minus 10 chars for @gmail.com), and gmail tells me: Sorry, your username must be between 6 and 30 characters long. – Luminary

Another important information to consider is whenever you're looking strictly at the email address portion (user@domain) or an email address as formatted in the From:, Sender: , Reply-To:, To: and Cc: headers. – Araucaria

Longer email addresses are more likely to be used by spammers, according to some security researchers ... I can't find the reference right now, but I remember seeing this sometime in the last few months. This sort of test is already available in spam filtering systems like SpamAssassin, in this case the HEAD_LONG rule you can apply. I've been using this for years ... my wife gets tons of spam and I had to put this in front of gmail when we were using this as they started throttling our mail. (We've since switched to protonmail, which we pay for ... it's better!) – Hallah

Answer 1

An email address must not exceed 254 characters.

This was accepted by the IETF following submitted erratum. A full diagnosis of any given address is available online. The original version of RFC 3696 described 320 as the maximum length, but John Klensin subsequently accepted an incorrect value, since a Path is defined as

Path = "<" [ A-d-l ":" ] Mailbox ">"

So the Mailbox element (i.e., the email address) has angle brackets around it to form a Path, which a maximum length of 254 characters to restrict the Path length to 256 characters or fewer.

The maximum length specified in RFC 5321 states:

The maximum total length of a reverse-path or forward-path is 256 characters.

RFC 3696 was corrected here.

People should be aware of the errata against RFC 3696 in particular. Three of the canonical examples are in fact invalid addresses.

I've collated a couple hundred test addresses, which you can find at http://www.dominicsayers.com/isemail

Vacillating

What about the new RFC standard which allows Unicode in email addresses? – Aloisius

The new RFCs do not alter the fact that SMTP imposes this limit on the envelope. They have been designed for backward compatibility with existing MTA software. – Vacillating

How many characters before the @ and how many after, or does it not matter? – Reeve

What if SMTP is superseded? Does this mean we are technically incapable of implementing the standard in RFC 3696? 254 practically, 320 future proof? Going with 254 now anyway :) – Buitenzorg

@Buitenzorg RFC 3696 isn't a standard, it just tries to help people interpret the underlying standards correctly. Unfortunately, in his attempt to clarify the situation, Klensin included some gross errors that were corrected in the Errata. But nobody reads the errata so RFC 3693 ends up being very unhelpful, ironically. – Vacillating

Good luck printing 254 characters in one line in a PDF-document. – Garvey

I believe with internationalized e-mail addresses, it would be more correct to define the limit as 254 octets, not characters. But I'm not sure. RFC 6531 extends the RFC 5321 reverse- and forward-path to allow UTF-8 characters, but RFC 5321 specifically says the limit is "256 octets", including separators (a deliberate change from RFC 2821 which said "characters"). I believe the 256-octet limit (minus 2 for 254) is not superseded, and the effective character limit is reduced for addresses with multi-byte UTF-8 characters. – Philippeville

Does that include emails that are formatted like user+inbox@domain? – Misbegotten

@Arin: yes it does – Vacillating

Is anyone else confused as to why the limit for the domain (255) is larger than the limit for the full address (254)? Is there a justification (or at least, explanation) for that scenario? – Pendent

@Pendent because domains are used for other purposes besides emails and are defined by different RFCs. I'm sure Jon Postel wished he could make it more consistent but at the time most domains were very short and it would have been overkill to break the envelope addresses in to two or more packets simply to take account of the potential for very long domain names. – Vacillating

I have stumbled across the same issue as @AndreD, and I agree with him. On the other hand, dominicsayers.com/isemail still says it is 254 characters. Does anybody know more? I believe it is octets and not characters, but that would mean that theoretically the maximum number of characters could be 63. I can't believe that the new RFC 6531 does not deal with that problem, so I am unsure. – Headcheese

When I do find that one psycho who has 254 characters in their email should I care? Do I want this kind of person using my service? – Slippery

@Geoffrey, the errata linked in the answer above answers your question: "a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. However, there is a restriction in RFC 2821 on the length of an address in MAIL and RCPT commands of 256 characters." So max 64 octets before the @, max 255 after the @, BUT with an overall limit of 254 octets, including the @. – Magill

I absolutely love that the errata rectifies the errata, specially looking at their cool name: Internet Engineering Task Force. I imagine they saying this like in a presidential conference: "The email should be X", then "I am sorry. It should be Y", then "I am so sorry. It should be Z". – Helsell

Answer 2

320

And the segments look like this

{64}@{255}

64 + 1 + 255 = 320

You should also read this if you are validating emails: I Knew How To Validate An Email Address Until I Read The RFC

Lifeblood

However according to this spec (for student loan data) nchelp.org/elibrary/ESC/CommonRecord-CommonLineDocumentation/… on page 20: "The e-mail length changed to reflect current ANSI standards. The E-mail address is a maximum length of 128 characters." Hmm. – Billington

Can you reference what RFC you got this from? – Billington

Here's a lovely article dispelling various myths about email including "max len == 320". The limit is actually 254. – Packing

Where is the lovely article? – Lifeblood

This answer correct. This emails valid, but absolutely unusable, because 2821 restrict MAIL/RCPT commands to 256 with <> brackets... – Cake

Does that include emails in the format user+inbox@domain? – Misbegotten

The "user+inbox" portion still needs to fit in 64 characters. Its still the localpart and the '+' does not add any magic to it. – Exude

This answer misses references. It probably comes from RFC3696, but this part of the standard was amended in errata to include a total limit of 254 characters. See the accepted answer for details and links to the errata. – Immunotherapy

Answer 3

user

The maximum total length of a user name is 64 characters.

domain

Maximum of 255 characters in the domain part (the one after the “@”)

However, there is a restriction in RFC 2821 reading:

The maximum total length of a reverse-path or forward-path is 256 characters, including the punctuation and element separators”. Since addresses that don’t fit in those fields are not normally useful, the upper limit on address lengths should normally be considered to be 256, but a path is defined as: Path = “<” [ A-d-l “:” ] Mailbox “>” The forward-path will contain at least a pair of angle brackets in addition to the Mailbox, which limits the email address to 254 characters.

Lonesome

Cool, ancient rfc of 1982... There is rfc5321 for SMTP – Cake

+1 here's the direct link to the part of RF5321 which defines the limit (note that its in BYTES/OCTETS rather than "characters" - see Unicode and email). – Bedpost

Answer 4

To help the confused rookies like me, the answer to "What is the maximum length of a valid email address?" is 254 characters.

If your application uses an email, just set your field to accept 254 characters or less and you are good to go.

You can run a bunch of tests on an email to see if it is valid here. http://isemail.info/

The RFC, or Request for Comments is a type of publication from the Internet Engineering Task Force (IETF) that defines 254 characters as the limit. Located here - https://www.rfc-editor.org/rfc/rfc5321#section-4.5.3

Fry

Where are you reading "254 characters"? I see in the link you provided, "The maximum total length of a reverse-path or forward-path is 256." Ctrl+F on "254" finds nothing, also. – Edea

@Edea There: rfc-editor.org/errata_search.php?rfc=3696&eid=1690 "However, there is a restriction in RFC 2821 on the length of an address in MAIL and RCPT commands of 254 characters. Since addresses that do not fit in those fields are not normally useful, the upper limit on address lengths should normally be considered to be 254." – Collarbone

@MichaelGroße Thanks! That info is actually listed in my answer (in fact, I list exactly #3696, among others), ended up answering after I couldn't get a response, but thanks for confirming my hunch about this answer. – Edea

Answer 5

According to the below article:

https://www.rfc-editor.org/rfc/rfc3696 (Page 6, Section 3)

It's mentioned that:

"There is a length limit on email addresses. That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. Systems that handle email should be prepared to process addresses which are that long, even though they are rarely encountered."

So, the maximum total length for an email address is 320 characters ("local part": 64 + "@": 1 + "domain part": 255 which sums to 320)

Unless

could you please provide me regular expression in javascript to validate 320 characters email id? Thanks in advance. – Decoct

This part of the standard was amended in errata to include a total limit of 254 characters. See the accepted answer for details and links to the errata. – Immunotherapy

It is actually on Page 4, Section 3 (Restrictions on email addresses) tools.ietf.org/html/rfc3696#section-3 – Kinghood

Answer 6

The other answers muddy the water a bit. Simple answer: 254 total chars in our control for email 256 are for the ENTIRE email address, which includes implied "<" at the beginning, and ">" at the end. Therefore, 254 are left over for our use.

Sidewheel

Answer 7

TLDR Answer

Given an email address like...

[email protected]

The length limits are as follows:

• Entire Email Address (aka: "The Path"): i.e., [email protected] -- 256 characters maximum.
• Local-Part: i.e., me -- 64 character maximum.
• Domain: i.e., example.com -- 254 characters maximum.

Source — TLDR;

The RFC standards are constantly evolving, but if you want a 2009 IETF source in a single line:

...the upper limit on address lengths should normally be considered to be 256. (Source: RFC3696.)

Source — The History

SMTP originally defined what a path was in RFC821, published August 1982, which is an official Internet Standard (most RFC's are only proposals). To quote it...

...a reverse-path, specifies who the mail is from.

...a forward-path, which specifies who the mail is to.

RFC2821, published in April 2001, is the Obsoleted Standard that defined our present maximum values for local-parts, domains, and paths. A new Draft Standard, RFC5321, published in October 2008, keeps the same limits. In between these two dates, RFC3696 was published, on February 2004. It mistakenly cites the maximum email address limit as 320-characters, but this document is "Informational" only, and states: "This memo provides information for the Internet community. It does not specify an Internet standard of any kind." So, we can disregard it.

To quote RFC2821, the modern, accepted standard as confirmed in RFC5321...

4.5.3.1.1. Local-part

The maximum total length of a user name or other local-part is 64 characters.

4.5.3.1.2. Domain

The maximum total length of a domain name or number is 255 characters.

4.5.3.1.3. Path

The maximum total length of a reverse-path or forward-path is 256 characters (including the punctuation and element separators).

You'll notice that I indicate a domain maximum of 254 and the RFC indicates a domain maximum of 255. It's a matter of simple arithmetic. A 255-character domain, plus the "@" sign, is a 256-character path, which is the max path length. An empty or blank name is invalid, though, so the domain actually has a maximum of 254.

Edea

Answer 8

Sadly, all the other answers are wrong. Most of them cite RFC 2821 or newer, which does not even define e-mail addresses. What it does do is define paths. E-mail addresses are defined by RFC 2822 (or newer) and can be much longer. Examples of valid addresses that are not valid paths are:

(Firstname Lastname) user@domain
Firstname Lastname <user@domain>

Both of these are the same mailbox written differently. So if your goal is to store e-mail addresses in a database, a limit of 254, 256 or 320 octets might be too low, although in practise, this is rarely going to be a problem.

Chatelaine

2822 doesn't define "e-mail address". The string "mail address" appears only once, in an irrelevant context. It has an "address specification", which is a mailbox or a group of mailboxes. A group is clearly not an "e-mail address". An "e-mail address" must surely be what you send to an SMTP server to deliver an email (the forward path), or the destination for failure reports (the reverse path), as everyone else says. – Calaverite

@Calaverite This answer is absolutely valid and RFC2822 defines very well email addresses, see section 3.4. Address Specification, specifically address, name-addr, angle-addr and addr-spec. – Araucaria

@Calaverite ignoring RFC details, and to clarify a bit: an e-mail address is what people type into the To:, is given as a From: header, and is stored in their contacts list (at least traditionally, modern graphical programs sometimes deviate a bit, but usually still support full addresses and not only paths on input). All of these places use addresses defined in RFC 2822, which defines the format of e-mail messages, so these are literally "e-mail addreses". – Chatelaine