EmailAddressAttribute仅做基础正则校验，不能保证邮箱真实存在或格式完全合规，生产环境慎用作唯一验证手段。它使用宽松正则、不支持IDN、忽略新顶级域与+号兼容性问题，且不查MX或发DNS请求；推荐分层验证：前端严格正则+后端MailAddress解析+业务层异步投递验证。
直接说结论：C# 自带的 EmailAddressAttribute 仅做基础正则校验，不能保证邮箱真实存在或格式完全合规，生产环境慎用作唯一验证手段。
为什么 EmailAddressAttribute 经常“看起来没问题却通不过”
它底层用的是一个较宽松的正则（类似 ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$），不支持国际化域名（IDN）、不处理注释、不识别新顶级域（如 .app、.dev）长度超限等情况。比如 test+tag@sub.example.co.uk 会被接受，但某些老邮件系统会拒收带 + 的地址；而 用户@中文.com 直接被拒绝——尽管它是合法的 IDN 邮箱（需 Punycode 转换后传输）。
- 常见错误现象：
EmailAddressAttribute校验通过，但 SMTP 发信失败 / 用户收不到激活邮件 - 它不检查 MX 记录，也不发 DNS 查询，纯字符串匹配
- ASP.NET Core 6+ 中该特性仍沿用同一正则，未升级 RFC 5322 全量规则
怎么安全地补强邮箱验证（推荐组合）
单靠属性标记远远不够，必须分层验证：
-
前端：用更严格的正则（如
^[^\s@]+@[^\s@]+\.[^\s@]+$）+ 实时 onBlur 校验，避免用户输完才提示 -
后端模型绑定时：保留
[EmailAddress]作为第一道轻量过滤，但不依赖它拦截所有非法输入 -
业务逻辑层：对关键操作（如注册、改绑）额外调用
MailAddress构造函数尝试解析——它比正则更贴近 .NET 邮件栈的实际解析逻辑
try {
var addr = new MailAddress(email);
return addr.Address == email; // 防止构造时自动修正（如小写化）
} catch {
return false;
}注意：MailAddress 会自动标准化格式（如把 TEST@EXAMPLE.COM 转成小写），所以要显式比对原始字符串。
什么时候可以只用 EmailAddressAttribute
仅适用于非关键路径、容忍度高的场景，例如：
- 用户反馈表单中的“可选邮箱”字段
- 内部管理系统中仅供展示、不用于通信的联系人字段
- 配合第三方邮箱验证服务（如 Hunter.io、NeverBounce）做异步二次校验的前置过滤
若你的接口要对接银行、政务或企业 SSO 系统，它们常要求邮箱符合 RFC 5321/5322 子集，此时必须绕过 EmailAddressAttribute，改用 System.Net.Mail 或专业库（如 MailKit 的 MailboxAddress.TryParse）。
真正难的不是写对正则，而是搞清你校验的目的是“防止明显乱输”，还是“确保能投递成功”。后者永远需要 DNS + SMTP 层验证，而 C# 运行时从不碰网络——这点容易被忽略。
