几乎我见过的每一个正则表达式（包括一些Microsoft使用的正则表达式）都不允许通过以下有效电子邮件：simon-@hotmail.com

我刚刚有一个真正的客户，他的电子邮件地址是这种格式的，他无法下订单。

以下是我的决定：

不会有假阴性的最小正则表达式。或者，使用MailAddress构造函数进行一些附加检查（见下文）：检查常见的拼写错误.cmo或.gimal.com，并要求确认“您确定这是正确的电子邮件地址吗？看起来可能有错误。”如果用户确定，请允许他们接受键入的内容。在实际发送电子邮件时处理反弹，并手动验证它们以检查是否存在明显错误。

try
{
    var email = new MailAddress(str);

    if (email.Host.EndsWith(".cmo"))
    {
        return EmailValidation.PossibleTypo;
    }

    if (!email.Host.EndsWith(".") && email.Host.Contains("."))
    {
        return EmailValidation.OK;
    }
}
catch
{
    return EmailValidation.Invalid;
}

没有一个是真正有用的。我在回答“是否有用于电子邮件地址验证的PHP库？”时讨论了一些问题？，它也在电子邮件地址的正则表达式识别难吗？中讨论？。

简而言之，不要期望一个可用的正则表达式能够完成正确的工作。最好的正则表达式将验证语法，而不是电子邮件的有效性(jhohn@example.com是正确的，但它可能会反弹…）。

列表项目

我使用此功能

function checkmail($value) {
    $value = trim($value);
    if (stristr($value,"@") &&
        stristr($value,".") &&
        (strrpos($value, ".") - stripos($value, "@") > 2) &&
        (stripos($value, "@") > 1) &&
        (strlen($value) - strrpos($value, ".") < 6) &&
        (strlen($value) - strrpos($value, ".") > 2) &&
        ($value == preg_replace('/[ ]/', '', $value)) &&
        ($value == preg_replace('/[^A-Za-z0-9\-_.@!*]/', '', $value))
    )
    {

    }
    else {
        return "Invalid Mail-Id";
    }
}

HTML5规范建议使用一个简单的正则表达式来验证电子邮件地址：

/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[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])?)*$/

这故意不符合RFC 5322。

注意：这一要求是故意违反RFC 5322的，RFC 5322为电子邮件地址定义了一种语法，该语法同时太严格（在@字符之前）、太模糊（在@符号之后）和太松散（允许注释、空白字符和引用字符串以大多数用户不熟悉的方式），在这里无法实际使用。

根据RFC 3696勘误表1690，总长度也可以限制为254个字符。

根据W3C HTML5规范：

^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[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])?)*$

上下文：

有效的电子邮件地址是与ABNF生产[…]匹配的字符串。注意：这一要求故意违反了RFC 5322，RFC 5322为电子邮件地址定义了一种语法，该语法同时太严格（在“@”字符之前）、太模糊（在“@”字符之后）和太松散（允许注释、空白字符和引用字符串以大多数用户不熟悉的方式），在这里无法实际使用。以下JavaScript和Perl兼容的正则表达式是上述定义的实现。/^[a-zA-Z0-9.！#$%&'*+\/=？^_`{|}~-]+@[a-zA-Z0-9]？（？：\.[a-zA-Z0-9]（？：[a-zA-Z0-9-]{0,61}[a-zA-Z0-9]）？）*$/

没有人提到本地化问题（i18n）。如果你的客户来自世界各地呢？

然后，您需要按国家/地区对正则表达式进行分类，我看到开发人员最终构建了一个大型字典或配置。检测用户的浏览器语言设置可能是一个很好的起点。