注册表单里的无效邮箱不仅污染数据库，更会拉低邮件送达率。高硬退回率让 Gmail、Outlook 等提供商降低对你发信域的信任，连带所有后续邮件一起遭殃。多数团队只挂一个正则检查就以为完成了验证，但正则只能判断格式是否合法，无法确认邮箱是否存在。
真正的验证需要依次检查三个层面：
第一层：语法验证。按 RFC 5321/5322 结构确认 local-part@domain.tld 格式，拒绝明显错误的输入（如 miss@、@domain.com、缺少 TLD）。直接用维护好的库或 API，不必手写完整的 RFC 正则。
第二层：MX 记录验证。通过 DNS 查询 @ 后的域名是否配置了邮件服务器。不存在 MX 记录（也无 A 记录）的域名可以直接拒绝——该域无法收信。
第三层：SMTP 握手验证。连接目标域的 MX 服务器（端口 25），执行 HELO→MAIL FROM→RCPT TO→QUIT（不发 DATA），根据响应码判断邮箱是否存在。这是最准确的层，但容易触发速率限制和 IP 信誉问题，批量验证时通常用专门的邮件验证 API 替自己扛。
Catch-all 域的处理：如果 SMTP 对任意本地部分都返回 250，说明该域配置了 catch-all，此时 SMTP 无法区分真实邮箱与不存在的邮箱。验证管道应把这种结果标记为 catch-all 或 unknown，不能当作肯定有效。
自建 vs API：低流量（每天几个注册验证）可以自建；批量清理列表时，IP 声誉、灰名单延迟以及维护垃圾域名/角色地址列表的开销会让自建变得不划算。一个专门的验证 API 能一站式处理语法、MX、SMTP、catch-all 和一次性域名检测。
Node.js 示例：自建语法和 MX 两层的代码简洁（见素材中的 JavaScript 代码），而 SMTP 层建议交给 API 处理。
邮件验证不能保证零退回（邮箱可能被删除、配额满、垃圾过滤器软退），但能大幅减少硬退回。SMTP 验证在 RCPT TO 之后停住，不发送 DATA，因此不会让收件人看到测试邮件。如果验证工具返回 unknown，通常是 catch-all 域、服务器临时不可达或反爬策略所致。
#开发者 #工具 #邮件验证 #SMTP #MX #DNS #API #Nodejs #MailValid
@DevToolboxHub