1203

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

Rodrigo
  • 483
  • 8
  • 14
volatilevoid
  • 12,605
  • 4
  • 21
  • 16
  • What kind of email address? Internet, X.400, or other? – Toby Speight Feb 19 '18 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.: https://stackoverflow.com/questions/1297272 – MGOwen Jun 07 '18 at 07: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.` – jumping_monkey Nov 16 '22 at 04: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. – Thomas Guyot-Sionnest Aug 18 '23 at 03: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!) – Mark McWiggins Aug 30 '23 at 17:52

8 Answers8

1435

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

Community
  • 1
  • 1
Dominic Sayers
  • 1,783
  • 2
  • 20
  • 26
  • 13
    What about the new RFC standard which allows Unicode in email addresses? – Pacerier Jul 11 '12 at 01:02
  • 1
    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. – Dominic Sayers Jul 16 '12 at 20:48
  • 4
    How many characters before the @ and how many after, or does it not matter? – Geoffrey Apr 20 '13 at 20:05
  • 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 :) – Lodewijk Feb 07 '14 at 18:22
  • 9
    @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. – Dominic Sayers Feb 12 '14 at 07:17
  • Good luck printing 254 characters in one line in a PDF-document. – doABarrelRoll721 Jan 04 '16 at 23:35
  • 5
    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. – Andre D May 05 '16 at 23:34
  • Does that include emails that are formatted like `user+inbox@domain`? – Aaron Esau Jan 08 '17 at 22:09
  • @Arin: yes it does – Dominic Sayers Jan 09 '17 at 09:52
  • 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? – JohnLBevan Jul 28 '17 at 09:32
  • 1
    @JohnLBevan 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. – Dominic Sayers Aug 07 '17 at 09:42
  • 2
    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. – Binarus Nov 01 '17 at 17:52
  • 2
    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? – Steven Eckhoff May 04 '20 at 20:57
  • @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 @. – Brendan Quinn Apr 09 '21 at 07:50
65

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

Community
  • 1
  • 1
Bob
  • 97,670
  • 29
  • 122
  • 130
  • However according to this spec (for student loan data) http://www.nchelp.org/elibrary/ESC/CommonRecord-CommonLineDocumentation/CRC-Ver_1-3-0-PDF.pdf 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. – Nathan May 18 '09 at 21:00
  • Can you reference what RFC you got this from? – Nathan May 18 '09 at 21:03
  • 13
    Here's a lovely article dispelling various myths about email including "max len == 320". The limit is actually 254. – Carl Jul 23 '09 at 17:01
  • 74
    Where is the lovely article? – Bob Jul 23 '09 at 17:18
  • 4
    This answer correct. This emails valid, but absolutely unusable, because 2821 restrict MAIL/RCPT commands to 256 with `<>` brackets... – vp_arth Jul 05 '15 at 14:18
  • 1
    Does that include emails in the format `user+inbox@domain`? – Aaron Esau Jan 08 '17 at 22:08
  • The "user+inbox" portion still needs to fit in 64 characters. Its still the localpart and the '+' does not add any magic to it. – Sperry Feb 10 '20 at 22:52
  • 3
    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. – Matthijs Kooijman Mar 13 '20 at 08:46
35

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.

Artem Kovalov
  • 1,102
  • 11
  • 10
  • 11
    Cool, ancient rfc of 1982... There is rfc5321 for SMTP – vp_arth Jul 05 '15 at 14:29
  • +1 here's the [direct link](https://www.rfc-editor.org/rfc/rfc5321#section-4.5.3.1.3) to the part of RF5321 which defines the limit (note that its in BYTES/OCTETS rather than "characters" - see [Unicode and email](https://en.wikipedia.org/wiki/Unicode_and_email)). – Eric Mutta Oct 19 '22 at 00:23
26

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

Community
  • 1
  • 1
Joshua Dance
  • 8,847
  • 4
  • 67
  • 72
  • 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 Jul 09 '21 at 20:18
  • @HoldOffHunger There: https://www.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." – Michael Große Sep 05 '21 at 09:42
  • @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. – HoldOffHunger Sep 05 '21 at 13:11
25

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)

Community
  • 1
  • 1
Waqar UlHaq
  • 6,144
  • 2
  • 34
  • 42
  • could you please provide me regular expression in javascript to validate 320 characters email id? Thanks in advance. – Kamlesh Sep 19 '19 at 15:27
  • 6
    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. – Matthijs Kooijman Mar 13 '20 at 08:44
  • It is actually on Page 4, Section 3 (Restrictions on email addresses) https://tools.ietf.org/html/rfc3696#section-3 – NeoH4x0r Oct 14 '20 at 09:12
22

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.

Forrest
  • 2,968
  • 1
  • 27
  • 18
6

TLDR Answer

Given an email address like...

me@example.com

The length limits are as follows:

  • Entire Email Address (aka: "The Path"): i.e., me@example.com -- 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.

Community
  • 1
  • 1
HoldOffHunger
  • 18,769
  • 10
  • 104
  • 133
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.

Remember Monica
  • 3,897
  • 1
  • 24
  • 31
  • 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 Jul 24 '23 at 09:01
  • @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`. – Thomas Guyot-Sionnest Aug 18 '23 at 04:02