Characters in the local part of a mail address

RFC2821 and RFC2822 state clearly that only 7bit ASCII characters are allowed in Internet mail addresses. The following list shows all the ASCII characters and explains whether they can or should be allowed in the local part of a mail address. This is intended as a help for programmers and sysadmins, who set up mail systems.

There is also a PDF version.

Dec	Hex	Char	Usable?	Description
0-31	0x00-0x1f	Control chars	NO	Not allowed by RFC2822.
32	0x20	SPACE	NO	The SPACE character can be used in email addresses if quoted properly, but would be very confusing. Don't use it.
33	0x21	!	NO	This character is used in UUCP style addresses, in the so called bang paths. Example: host2 ! host1 ! user. Because there are still lots of mail systems who interpret this chars specially it should never be used in the local part of an email address.
34	0x22	"	NO	The double quotes are used for quoting. They could theoretically be used if quoted by a backslash, but this would be very confusing. Don't use them.
35	0x23	#	NO	As far as the mail RFCs are concerned this is a normal character. But the hash sign is used in many configuration files to denote the beginning of a comment. Used in the configuration of most MTAs it would probably not work. Don't use it.
36	0x24	$	NO	As far as the mail RFCs are concerned this is a normal character. Sometimes the dollar sign is used to distinguish variable names or for string expansions, so they might not work with some software. Don't use it.
37	0x25	%	NO	The percent sign is still in use for source routing in some systems. Although it is possible to use it in the local part of an email address, it might be interpreted specially by some email system. If it is used in a <mailto:> URL, it must be URL encoded.
38	0x26	&	MAYBE	As far as RFC2821 and RFC2822 are concerned this is a normal character. It is often used for company names like "Acme & Partners". Although this is hardly a reason, you may not want to use it, because the & sign is a UNIX shell special character. Another problem is that the & must be URL encoded when used in <mailto:> URLs.
39	0x27	'	MAYBE	Commonly used for names like O'Reilly but might be dangerous because this character is often used for quoting, chances are it might get lost on the way.
40-41	0x28-0x29	( and )	NO	These chars are used in address header fields to denote comments. They are normally used to separate the email address from the real name of the sender or recipient. Example: 'joe.doe@example.com (Joe Doe)'. RFC2822 allowes their use if they are inside double quotes, but this would be very confusing. Don't use them in the local part.
42	0x2a	*	MAYBE	The asterisk is widely used as a wild card character, often denoting "any local part" in a given domain. The use in an actual email address would preclude such a use. It is used by some mailing list servers to generate special addresses for detecting bounces.
43	0x2b	+	OK	The plus sign is allowed in mail addresses and there is no reason not to use it. A common usage is for defining sub-addresses. Example: The user 'joe' with the mail address 'joe@example.com' can set up mail addresses like 'joe+list@example.com' if he needs more then one address.
44	0x2c	, (comma)	NO	The comma is used in address header fields to separate email addresses from each other. Example: tarzan@jungle.org, jane@jungle.org. RFC2822 allowes their use if they are inside double quotes, but this would be very confusing. They are used in source routing, too. Don't use them in the local part.
45	0x2d	- (hyphen)	OK	Allowed in email addresses. Often used in mailing list addresses like list-request@example.com. Do not use as first character in email addresses, because it might look like a command line option to typical UNIX programs like sendmail.
46	0x2e	.	OK	Allowed in email addresses. Often used for addresses with the format 'firstname.lastname@example.com'. There is one restriction however: Two dots next to each other or a dot at the beginning or end of the local part are not allowed by RFC2822. The reason is that in RFC2822 the dot is used as a separator for tokenizing the mail address. Dots at the named locations would mean an empty token, which is not allowed. Still, there are people who use it. Some MTAs accept it, some don't.
47	0x2f	/	MAYBE	The forward slash is often used in email addresses used by X.400 gateways. Example: 'PN=Joe/OU=X400/@gateway.com'. Because the slash is used as a directory separator in UNIX and other operating systems, it is probably not a good idea to use it in local parts. If you ever want to save the mail in a mailbox named after the local part, you will have problems.
48-57	0x30-0x39	0-9	OK	Allowed without restrictions.
58	0x3a	:	NO	The colon is used in the source route syntax of RFC2821. Example: @mail.example.com:joe@sixpack.com. Although the colon is allowed if quoted properly, it could be very confusing. Don't use it.
59	0x3b	;	NO	The semicolon could theoretically be used, but must be quoted. Because of this you should probably not use it.
60	0x3c	<	NO	Used by RFC2821 and RFC2822 to enclose an email address. Example: <joe@sixpack.com>. Can be used if quoted, but would be very confusing. Don't use it.
61	0x3d	=	MAYBE	Really no reason not to use it. It is used by some mailing list servers to generate special addresses for detecting bounces.
62	0x3e	>	NO	Used by RFC2821 and RFC2822 to enclose an email address. Example: <joe@sixpack.com>. Can be used if quoted, but would be very confusing. Don't use it.
63	0x3f	?	MAYBE	If the question mark in an email address is used in a <mailto:> URL, it must be URL encoded. It could be confusing, because nobody expects it to be in an email address. Better not use it.
64	0x40	@	NO	The @ is the separator between local part and domain. Can be used if quoted, but would be very confusing. Don't use it.
65-90	0x41-0x5a	A-Z	OK	Allowed without restrictions.
91	0x5b	[	NO	The [ can be used in email addresses if quoted properly, but would be confusing. Don't use it.
92	0x5c	\	NO	The backslash is used for quoting special chars in RFC2821 and RFC2822. If it is used it must be quoted itself. Would be very confusing. Don't use it.
93	0x5d	]	NO	The ] can be used in email addresses if quoted properly, but would be confusing. Don't use it.
94	0x5e	^	MAYBE	There is really no technical reason, why the caret should not be used, but it might be confusing for people, because it is sufficiently exotic that nobody would expect it to be part of an email address.
95	0x5f	_ (underscore)	OK	Allowed without restrictions. Often used in mail addresses of the form firstname_lastname@example.com.
96	0x60	`	NO	This character (the backtick) is used in shell scripting for executing an "embedded" command, inserting the output of this command and the place the command was found. This is very dangerous, if the command can be supplied by anybody. For this reason, many email systems will filter this character. Don't use it.
97-122	0x61-0x7a	a-z	OK	Allowed without restrictions.
123	0x7b	{	MAYBE	There is really not much reason not to use this, although on the other hand, why should anyone want to have this in his email address. Could be confusing, because nobody expects it to be in an email address.
124	0x7c	|	NO	The vertical bar (pipe symbol) is a UNIX shell special character used for combining commands into a pipe. In MTA config files it is often used to denote delivering into a program. Example: jane@jungle.com: | /usr/bin/vacation. Some MTAs will filter addresses with the pipe symbol, because it has been used in attacking email systems. Don't use it.
125	0x7d	}	MAYBE	There is really not much reason not to use this, although on the other hand, why should anyone want to have this in his email address. Could be confusing, because nobody expects it to be in an email address.
126	0x7e	~	MAYBE	There is really no technical reason, why the tilde character should not be used, but it might be confusing for people, because it is sufficiently exotic that nobody would expect it to be part of an email address.
127	0x7f	DEL	NO	Not allowed by RFC2822.