我并不是在询问完整的电子邮件验证。
我只想知道电子邮件地址的用户名和服务器部分允许使用哪些字符。这可能过于简单化，也许电子邮件地址可以采取其他形式，但我不在乎。我只问这个简单的表格：user-name@server（例如。wild.wezyr@best-server-ever.com)以及两部分中允许的字符。
当前回答
您可以从维基百科文章开始：
大写和小写英文字母（a-z，a-z）数字0至9字符！#$%&'*+-/=？^ _ `{ | } ~性格（点、句号、句号），前提是它不是第一个或最后一个字符，并且不连续出现两次或多次。
其他回答
检查@和。然后发送电子邮件让他们验证。
我仍然不能在互联网上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
请参阅RFC 5322：Internet消息格式，以及RFC 5321：简单邮件传输协议。
RFC 822也涵盖了电子邮件地址，但它主要涉及其结构：
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
和往常一样，维基百科有一篇关于电子邮件地址的文章：
电子邮件地址的本地部分可以使用以下任意ASCII字符：大写和小写拉丁字母A至Z和A至Z；数字0至9；特殊字符！#$%&'*+-/=^_`{|}~;点前提是除非被引用，否则它不是第一个或最后一个字符，并且除非被引用（例如。John..Doe@example.com不允许，但允许使用“John…Doe”@example.com）；空格和“（），：；<>@[\]字符允许有限制（它们只允许在带引号的字符串中，如下面的段落所述，此外，反斜杠或双引号前面必须有反斜杠）；注释允许在本地部分的两端加括号；例如john.smith（注释）@example.com和（注释）john.smith@example.com都相当于john.smith@example.com.
除ASCII字符外，截至2012年，您可以使用U+007F以上的国际字符，如RFC 6532规范所述，编码为UTF-8，并在维基百科上进行了解释。请注意，截至2019年，这些标准仍标记为“建议”，但正在缓慢推出。此规范中的更改基本上添加了国际字符作为有效的字母数字字符（atext），而不影响对允许和限制的特殊字符（如！#）的规则和@：。
有关验证，请参阅使用正则表达式验证电子邮件地址。
域部分定义如下：
协议的Internet标准（征求意见）要求组件主机名标签只能包含ASCII字母a到z（不区分大小写）、数字0到9和连字符（-）。RFC 952中主机名的原始规范规定，标签不能以数字或连字符开头，也不能以连字符结尾。然而，随后的规范（RFC 1123）允许主机名标签以数字开头。不允许使用其他符号、标点符号或空格。
谷歌用他们的gmail.com地址做了一件有趣的事情。gmail.com地址只允许字母（a-z）、数字和句点（忽略）。
例如。，pikachu@gmail.com与pi.kachu@gmail.com，两个电子邮件地址将发送到同一邮箱。PIKACHU@gmail.com也发送到同一邮箱。
因此，要回答这个问题，有时取决于实现者希望遵循多少RFC标准。谷歌的gmail.com地址样式与标准兼容。他们这样做是为了避免不同的人使用类似的电子邮件地址时产生混淆。
*** gmail.com accepting rules ***
d.oy.smith@gmail.com (accepted)
d_oy_smith@gmail.com (bounce and account can never be created)
doysmith@gmail.com (accepted)
D.Oy'Smith@gmail.com (bounce and account can never be created)
维基百科链接是关于电子邮件地址通常允许的内容的一个很好的参考。http://en.wikipedia.org/wiki/Email_address
