What characters are allowed in email address?

Question

I'm not asking about full email validation.

I just want to know what are allowed characters in user-name and server parts of email address. This may be oversimplified, maybe email adresses can take other forms, but I don't care. I'm asking about only this simple form: user-name@server (e.g. [email protected]) and allowed characters in both parts.

I know that a-z, 0-9, _, -, . (dot) can be used but is there more allowed characters? Maybe +, $?

Hope I made my question clear ;-).

Update: if some characters are allowed, but only at specific positions (as is dot in user-name), then this character is just allowed. I don't want full email address validation but simple list (set) of all characters allowed at user-name and server parts. Please don't bother with additional contraints for special positions of specific characters. If character is allowed under some/any/none conditions then it is in the list of allowed chars.

Update2: please give as simple answer as possible - just describe available characters, do not just give link to specs.

Update3: Here is my motivation for exactly such question as I asked... My question may seem stupid as I ask for very simplified conditions of valid email addresses. But with proper answer and very simple implementation of validation with only checking if allowed characters were provided (or not) I will accept all valid email addresses (and many invalid too). I think it is more user friendly than the opposite (implement sophisticated validator that rejects some proper email addresses). Consider + that Dan Herbert and laura are talking about in comments. This is just example of too constrained implementation of email address validation - and that is annoying!

Second reason is just curiosity - what are the allowed characters taken apart from other validation constraints?

Answer 1

See RFC 5322 and, to a lesser extent, RFC 5321.

RFC 822 also covers email addresses, but it deals mostly with its structure:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

And as usual, Wikipedia has a decent article on email addresses:

The local-part of the e-mail address may use any of these ASCII characters:

• Uppercase and lowercase English letters (a-z, A-Z)
• Digits 0 to 9
• Characters ! # $ % & ' * + - / = ? ^ _ ` { | } ~
• Character . (dot, period, full stop) provided that it is not the first or last character, and provided also that it does not appear two or more times consecutively.

For validation, see this.

The domain part is defined as follows:

The Internet standards (Request for Comments) for protocols mandate that component hostname labels may contain only the ASCII letters a through z (in a case-insensitive manner), the digits 0 through 9, and the hyphen (-). The original specification of hostnames in RFC 952, mandated that labels could not start with a digit or with a hyphen, and must not end with a hyphen. However, a subsequent specification (RFC 1123) permitted hostname labels to start with digits. No other symbols, punctuation characters, or blank spaces are permitted.

Answer 2

You can start from wikipedia article:

• Uppercase and lowercase English letters (a-z, A-Z)
• Digits 0 to 9
• Characters ! # $ % & ' * + - / = ? ^ _ ` { | } ~
• Character . (dot, period, full stop) provided that it is not the first or last character, and provided also that it does not appear two or more times consecutively.

Answer 3

Wikipedia has a good article on this and the official spec is here. From wikipdia:

The local-part of the e-mail address may use any of these ASCII characters:

• Uppercase and lowercase English letters (a-z, A-Z)
• Digits 0 to 9
• Characters ! # $ % & ' * + - / = ? ^ _ ` { | } ~
• Character . (dot, period, full stop) provided that it is not the first or last character, and provided also >that it does not appear two or more times consecutively.

Additionally, quoted-strings (ie: "John Doe"@example.com) are permitted, thus allowing characters that would otherwise be prohibited, however they do not appear in common practice. RFC 5321 also warns that "a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form".

Answer 4

Hi there!

Check out atext in RFC5322 might be what you are looking for..

Answer 5

Watch out! There is a bunch of knowledge rot in this thread (stuff that used to be true and now isn't).

To avoid false-positive rejections of actual email addresses in the current and future world, and from anywhere in the world, you need to know at least the high-level concept of RFC 3490, "Internationalizing Domain Names in Applications (IDNA)". I know folks in US and A often aren't up on this, but it's already in widespread and rapidly increasing use around the world (mainly the non-English dominated parts).

The gist is that you can now use addresses like mason@日本.com and wildwezyr@fahrvergnügen.net. No, this isn't yet compatible with everything out there (as many have lamented above, even simple qmail-style +ident addresses are often wrongly rejected). But there is an RFC, there's a spec, it's now backed by the IETF and ICANN, and--more importantly--there's a large and growing number of implementations supporting this improvement that are currently in service.

I didn't know much about this development myself until I moved back to Japan and started seeing email addresses like hei@やる.ca and Amazon URLs like this:

www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/b/ref=topnav_storetab_e?ie=UTF8&node=3210981

(And no, ha ha, Stack Overflow couldn't deal with that link. But paste it into a modern Chrome or Safari and try it.)

I know you don't want links to specs, but if you rely solely on the outdated knowledge of hackers on Internet forums, your email validator will end up rejecting email addresses that non-Enlish users increasingly expect to work. For those users, such validation will be just as annoying as the commonplace brain-dead form that we all hate, the one that can't handle a + or a three-part domain name or whatever.

So I'm not saying it's not a hassle, but the full list of characters "allowed under some/any/none conditions" is (nearly) all characters in all languages. If you want to "accept all valid email addresses (and many invalid too)" then you have to take IDN into account, which basically makes a character-based approach useless (sorry), unless you first convert the internationalized email addresses to Punycode.

After doing that you can follow (most of) the advice above.