1276

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

Improve this question
5
  • What kind of email address? Internet, X.400, or other? Commented Feb 19, 2018 at 14:53
  • 2
    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 Commented Jun 7, 2018 at 7:36
  • 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. Commented Nov 16, 2022 at 4:58
  • 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. Commented Aug 18, 2023 at 3:58
  • 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!) Commented Aug 30, 2023 at 17:52

8 Answers 8

Reset to default
1525

TL;DR

👉 An email address must not exceed 254 characters.
This was accepted by the IETF following the submitted erratum for RFC 3696.

Technical details

The question of the maximum allowed email address length was supposed to be addressed in RFC 3696 "Application Techniques for Checking and Transformation of Names", specifically in the Section 3 "Restrictions on email addresses".

The original version of RFC 3696 described 320 characters as the maximum length (see Section 3), but John Klensin subsequently submitted the erratum 1003 to change this value to 256 characters.

But this also was not precisely correct. And this situation was finally fixed after Dominic Sayers submitted the erratum 1690. In this erratum it was noted that the Mailbox element, i.e. the email address, has the maximum length of 👉 254 characters. Here is the quote of the "Note" left in this erratum:

I believe erratum ID 1003 is slightly wrong. RFC 2821 places a 256 character limit on the forward-path. But a path is defined as

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

So the forward-path will contain at least a pair of angle brackets in addition to the Mailbox. This limits the Mailbox (i.e. the email address) to 254 characters.

Aside from RFC 3696, the maximum length of the Path element is also specified in RFC 5321, specifically in the Section 4.5.3.1.3:

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

NOTE: the below section was left by the original author of this answer.

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

Improve this answer
Sign up to request clarification or add additional context in comments.

16 Comments

What about the new RFC standard which allows Unicode in email addresses?
How many characters before the @ and how many after, or does it not matter?
@Lodewijk 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.
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.
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.
|
81

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

Improve this answer

8 Comments

Here's a lovely article dispelling various myths about email including "max len == 320". The limit is actually 254.
Where is the lovely article?
This answer correct. This emails valid, but absolutely unusable, because 2821 restrict MAIL/RCPT commands to 256 with <> brackets...
The "user+inbox" portion still needs to fit in 64 characters. Its still the localpart and the '+' does not add any magic to it.
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.
|
42

RFC 2821 specifies:

local-part

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

domain

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

However, there is a further restriction reading:

path

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

As Dominic Sayers explains in his verified and accepted erratum on RFC 3696:

RFC 2821 places a 256 character limit on the forward-path. But a path is defined as

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

So the forward-path will contain at least a pair of angle brackets in addition to the Mailbox. This limits the Mailbox (i.e. the email address) to 254 characters.

Improve this answer

2 Comments

Cool, ancient rfc of 1982... There is rfc5321 for SMTP
+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).
28

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

Improve this answer

3 Comments

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.
@HoldOffHunger 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."
@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.
28

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)

Improve this answer

3 Comments

could you please provide me regular expression in javascript to validate 320 characters email id? Thanks in advance.
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.
It is actually on Page 4, Section 3 (Restrictions on email addresses) tools.ietf.org/html/rfc3696#section-3
23

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.

Improve this answer

Comments

12

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.

Improve this answer

Comments

0

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.

Improve this answer

3 Comments

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.
@EML 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.
@EML 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".

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.