邮箱验证失败需分层排查：先验格式、域名、DNS MX记录；再测SMTP连通性与响应码；最后探查邮箱账户存在性及状态；同时标记防火墙、2FA、垃圾邮件过滤等现实干扰项。
邮箱验证失败，不是换个邮箱重试就完事。关键得看是哪一层卡住了——格式、域名、服务器响应，还是账户状态本身。User Checker 的思路就是把验证拆成可定位、可复现、可修复的检查步骤，而不是依赖一次性的“发送-点击”流程。
先过基础三关：格式 + 域名 + DNS
很多失败其实停在第一步。User Checker 会按顺序确认：
- 格式合规性：用 RFC 5322 兼容正则做初筛，不接受带空格、连续点号、缺失@或无域名的输入；
- 域名有效性：提取邮箱后缀（如 example.com），检查是否为合法域名（非纯数字、不含非法字符、长度合理）；
- DNS MX 记录存在性：发起 DNS 查询，确认该域名配置了至少一个可用的邮件交换服务器；没有 MX，说明该域根本无法收信。
再探通信层：SMTP 连通性与响应码
有 MX 不代表能连上。User Checker 会模拟轻量 SMTP 会话（不发邮件，只握手）：
- 连接目标 MX 主机的 25 / 587 / 465 端口，超时设为 10 秒；
- 收到 220 欢迎响应后，发送
HELO或EHLO，等待 250； - 若返回 554（被拒绝）、421（服务不可用）或连接直接被重置，说明服务器策略拦截或临时不可达。
最后查账户层：邮箱是否存在 & 状态是否开放
前两步都通过，才进入敏感环节——探测邮箱账号是否存在。User Checker 不暴力尝试，而是结合策略：
- 对支持 VRFY 或 EXPN 命令的旧式 SMTP 服务器，谨慎使用（多数已禁用）；
- 更常用的是 RCPT TO 阶段响应分析：发送
RCPT TO:<user></user>，观察返回码；250 表示邮箱存在且可投递，550 多数表示不存在或被拒收； - 若返回 450 或 421，倾向归因为灰名单、频率限制或临时策略，而非邮箱无效。
绕不开的现实干扰项
即使技术链路全绿，用户侧仍可能失败。User Checker 会标记这些非代码问题供人工介入：
- 企业防火墙屏蔽了出站 SMTP 端口（尤其 25）；
- 邮箱启用了强二次验证（2FA），但 OAuth 流程未完成授权；
- 验证邮件被内容过滤器识别为营销类，直接进垃圾箱；
- 域名 SPF/DKIM/DMARC 配置异常，导致发件方（如 ChatGPT 或 SaaS 平台）被拒收。
