MailAddress仅做RFC 5322基础格式校验，不验证邮箱真实存在；应结合前端快速过滤、异步发信验证与用户点击确认，避免SMTP探测等高风险手段。
用 MailAddress 解析格式，但别信它能验证邮箱存在
很多人以为调用 new MailAddress("xxx@yyy.zzz") 不抛异常就代表邮箱“有效”，其实它只做基础 RFC 5322 格式校验——比如允许 "test@localhost" 或 "a@b.c" 这种明显不可达的地址通过。它不发任何网络请求，也不查 DNS。
真正要筛掉明显错字（如缺少 @、双 @、结尾点号），可以用：
try {
var addr = new MailAddress(email);
return addr.Address == email; // 防止自动修正（如转小写、去空格）
} catch {
return false;
}
- 注意：某些合法邮箱含 + 号（
user+tag@gmail.com）或引号（"foo bar"@example.com），MailAddress支持，但很多前端正则会误杀 - 别用正则全量匹配邮箱——RFC 规范太复杂，正则要么漏放，要么误杀；交给
MailAddress更稳
查 MX 记录判断域名能否收信，但别指望 100% 准确
调用 Dns.GetHostEntry 或更准的 Dns.GetMXRecords（需第三方库如 DNSClient）能确认目标域名是否配置了邮件服务器。没有 MX 记录，基本可断定无法收信。
但要注意：
- 有些域名用 A 记录兜底（如直接指向邮件服务器 IP），此时无 MX 也不等于无效
- 公共 DNS（如 8.8.8.8）可能缓存过期记录；企业内网 DNS 又可能屏蔽外部查询
-
Dns.GetHostEntry查的是 A 记录，不是 MX，别混用 - .cn / .jp 等部分国家域名，MX 查询响应慢或被限频，超时设 3 秒较安全
SMTP 连接探测有风险，多数邮箱服务已禁用或限流
所谓“SMTP 探测”，是连上目标域名的 25/587 端口，发 HELO + MAIL FROM + RCPT TO，看是否返回 250 OK。但现实很骨感：
- Gmail、Outlook、Yahoo 等主流服务商一律返回
250 OK对所有RCPT TO，防止邮箱爬取——你根本分不清真假 - 腾讯企业邮箱、阿里云邮箱默认拒接未认证的
RCPT TO探测，直接断连或返回550 User not found - 频繁探测会被封 IP，尤其从云服务器出口（AWS/Azure 静态 IP 常被拉黑）
- .edu/.gov 域名常启用 SMTP TLS 强制策略，未完成 STARTTLS 就发命令会直接中断
真要试，至少加 timeout: 10000、随机 User-Agent（伪）、且单 IP 每分钟 ≤ 2 次——否则不是验证邮箱，是在给自己找封禁。
生产环境该怎么做：分层 + 异步 + 用户参与
真实项目里，没人靠一次后端请求“验证邮箱真实性”。靠谱做法是组合策略：
- 前端用
MailAddress快速过滤明显错误 - 注册/修改邮箱时，立即发带唯一 token 的验证邮件（用你自己可信的 SMTP 服务，如 SendGrid / SMTP 腾讯云）
- 把“邮箱有效性”和“用户是否点击验证链接”解耦——链接有效期设 24 小时，过期即失效
- 对高价值操作（如改绑、提现），再加二次确认（短信/APP 推送），别死磕 SMTP 探测
最易被忽略的一点：DNS 和 SMTP 探测都依赖网络稳定性，本地开发时用公司内网可能通，上线到容器或 Serverless 后因安全组、出向规则、DNS 配置不同而全挂——务必在目标环境实测，别只信 localhost。
