我并不是在询问完整的电子邮件验证。
我只想知道电子邮件地址的用户名和服务器部分允许使用哪些字符。这可能过于简单化，也许电子邮件地址可以采取其他形式，但我不在乎。我只问这个简单的表格：user-name@server（例如。wild.wezyr@best-server-ever.com)以及两部分中允许的字符。
当前回答
答案是（几乎）全部（7位ASCII）。如果包含规则“…在某些/任何/无条件下允许…”
仅通过查看RFC 5322第17页顶部“域文本”部分中允许文本的几种可能包含规则之一，我们就可以发现：
dtext = %d33-90 / ; Printable US-ASCII
%d94-126 / ; characters not including
obs-dtext ; "[", "]", or "\"
本说明中仅有的三个缺失字符用于域文字[]中，以形成引号对\和空白字符（%d32）。使用整个范围32-126（十进制）。类似的要求显示为“qtext”和“ctext”。也允许/使用许多控制字符。RFC 5322第31页第4.1节中出现了一个此类控制字符列表，称为obs NO WS CTL。
obs-NO-WS-CTL = %d1-8 / ; US-ASCII control
%d11 / ; characters that do not
%d12 / ; include the carriage
%d14-31 / ; return, line feed, and
%d127 ; white space characters
如第3.5节开头所述，允许使用所有这些控制字符：
.... MAY be used, the use of US-ASCII control characters (values
1 through 8, 11, 12, and 14 through 31) is discouraged ....
因此，这样的包含规则“过于宽泛”。或者，在其他意义上，预期规则“过于简单化”。
其他回答
Gmail只允许+符号作为特殊字符，在某些情况下（.），但Gmail不允许任何其他特殊字符。RFC说你可以使用特殊字符，但你应该避免用特殊字符向Gmail发送邮件。
检查@和。然后发送电子邮件让他们验证。
我仍然不能在互联网上20%的网站上使用我的.name电子邮件地址，因为有人搞砸了他们的电子邮件验证，或者因为它早于新地址的有效期。
为了简单起见，我在验证前删除了双引号内的所有文本以及与双引号相关的文本，并根据不允许的内容对电子邮件地址提交进行了过滤。只是因为有人可以拥有约翰。。“$$hizzle*Bizzle”..Doe@whatever.com地址并不意味着我必须允许它进入我的系统。我们生活在这样一个未来，获得一个免费的电子邮件地址可能比做好擦屁股的工作花费更少的时间。而且，电子邮件标准似乎没有贴在输入的旁边，说明什么是允许的，什么是不允许的。
在删除引用的材料后，我还清理了各种RFC特别不允许的内容。特别禁止的字符和模式列表似乎是一个要测试的更短的列表。
不允许：
local part starts with a period ( .account@host.com )
local part ends with a period ( account.@host.com )
two or more periods in series ( lots..of...dots@host.com )
&’`*|/ ( some&thing`bad@host.com )
more than one @ ( which@one@host.com )
:% ( mo:characters%mo:problems@host.com )
在给出的示例中：
John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com
John..Doe@whatever.com --> John.Doe@whatever.com
在尝试添加或更改电子邮件地址时，向剩余结果发送确认电子邮件是查看代码是否能够处理提交的电子邮件地址的好方法。如果电子邮件在所需的多轮消毒后通过了验证，则进行确认。如果请求从确认链接返回，则新电子邮件可以从保留的||临时||炼狱状态或存储中移出，成为真正的、善意的一流存储电子邮件。
如果您想考虑周到，可以将电子邮件地址更改失败或成功的通知发送到旧电子邮件地址。未经确认的帐户设置可能会在合理的时间后完全失败，从而退出系统。
我不允许在我的系统上发送臭邮件，也许这只是在浪费钱。但是，99.9%的人只是做了正确的事情，并且有一封电子邮件不会利用边缘案例兼容性场景将符合性限制推到边缘。小心regex DDoS，这是一个你可能会遇到麻烦的地方。这与我做的第三件事有关，我对处理任何一封电子邮件的时间设置了限制。如果它需要降低我的机器的速度以获得验证——它无法通过我的传入数据API端点逻辑。
编辑：这个回答一直被指责为“糟糕”，也许这是理所应当的。也许它仍然糟糕，也许不是。
在我的PHP中，我使用此检查
<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"
)){
echo "legit email";
} else {
echo "NOT legit email";
}
?>
自己试试看http://phpfiddle.org/main/code/9av6-d10r
在讨论电子邮件地址的有效本地部分时，公认的答案是维基百科的一篇文章，但维基百科并不是这方面的权威。
IETF RFC 3696是这一问题的权威，应在第3节中查阅。第5页对电子邮件地址的限制：
当代电子邮件地址由“本地部分”组成，与由at符号（“@”）表示的“域名部分”（完全限定的域名）。域部分的语法与前面的部分本节中确定的关于过滤和名称列表适用于电子邮件上下文中使用的域名好域名也可以替换为中的IP地址方括号，但除了测试和故障排除目的。本地部分可能使用所描述的引用约定出现在下面引用的表格在实践中很少使用，但却是必需的出于某些正当目的。因此，不应在过滤例程，但应改为传递到电子邮件系统以供目标主机评估。确切的规则是任何ASCII字符，包括控件字符，可以出现在引号中，也可以出现在带引号的字符串中。当报价为需要，反斜杠字符用于引用以下内容性格例如Abc公司\@def@example.com是电子邮件地址的有效形式。空白也可能出现，如中所示弗雷德\Bloggs@example.com反斜杠字符还可以用于引用自身。，乔\\Blow@example.com除了使用反斜杠字符引用外双引号字符可用于环绕字符串。例如"Abc@def“@example.com”“Fred Blogs”@example.com是上述前两个示例的替代形式。这些引用的表单很少被推荐，在实践中也不常见，但是必须由正在处理的应用程序支持电子邮件地址。特别是，引用的表格经常出现在与来自其他系统的转换相关联的地址上下文和背景；这些过渡要求仍然存在，因为接受用户提供的电子邮件地址的系统不能“知道”该地址是否与旧系统关联地址表格必须被接受并传递到电子邮件环境中。如果没有引号，本地部分可以由以下任意组合组成字母字符、数字或任何特殊字符! # $ % & ' * + - / = ? ^ _ ` . { | } ~句点（“.”）也可能出现，但不能用于开始或结束也不能出现两个或多个连续周期。换句话说，除了at符号（“@”）、反斜杠、双引号、逗号或方括号可能出现而不引用。如果排除了要显示字符，必须引用它们。表单，如用户+mailbox@example.com客户/部门=shipping@example.com$A12345@example.com!定义！xyz%abc@example.com_somename@example.com是有效的，并且很常见，但任何字符允许使用上面列出的。
正如其他人所做的，我提交了一个既适用于PHP又适用于JavaScript的正则表达式来验证电子邮件地址：
/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i
