使用TLS+RCPT TO验证邮箱时，无效地址仍返回250状态的问题

核心问题是你没有连接目标邮箱域名对应的MX服务器，和TLS无关，具体原因如下：

1. Gmail SMTP服务器的定位是「邮件转发/发送代理」，而非「邮箱有效性验证节点」。它在接收RCPT TO命令时，只会校验邮箱格式是否合法，不会实时去目标域名的MX服务器验证该邮箱是否存在——它的逻辑是先接收你的邮件请求，后续再自行尝试投递，投递失败才会返回退信，所以不管目标邮箱有效与否，只要格式正确，都会返回(250, b'2.1.5 OK ... - gsmtp')。
2. 原方法的有效性在于：直接连接目标域名的MX服务器，该服务器是目标邮箱的直接处理节点，能准确知晓自身管理的邮箱是否存在，因此RCPT TO命令能返回真实的有效性结果。

核心逻辑回归：基于目标MX服务器验证 #

回到直接连接目标域名MX服务器的方案，同时解决安全和稳定性问题：

• 强制使用TLS/SSL连接：优先尝试STARTTLS（端口587），失败后再尝试SSL直连（端口465），避免明文传输。
• 模拟真实客户端行为：
  • 每次验证前先执行HELO/EHLO命令，传递合理的客户端标识；
  • 控制请求频率，短时间内不对同一MX服务器发起大量请求，防止IP被封禁；
  • 随机生成HELO参数，不要使用固定字符串。
• 统一错误码判断规则：不同邮箱服务商的SMTP错误返回码存在差异，比如550 5.1.1 User unknown、550 Invalid recipient都代表邮箱不存在，需要整理常见错误码集合来判定结果。

辅助验证手段（提升准确率） #

• 格式预校验：先用正则表达式过滤格式明显无效的邮箱地址，减少后续SMTP验证的压力；
• MX记录校验：先查询目标域名的MX记录，若无MX记录，直接判定该域名下所有邮箱无效；
• 合规使用：不要将工具用于垃圾邮件发送或大规模批量验证，遵守服务商条款，避免IP被列入黑名单。

备选方案（无法直接连接MX服务器时） #

如果因网络限制无法连接部分MX服务器，可考虑：

• 发送测试邮件，通过后续的退信反馈判断邮箱有效性，但存在延迟；
• 搭建自有中转SMTP服务器，模拟真实投递流程，依靠退信结果验证，但实现成本较高。

内容的提问来源于stack exchange，提问作者codiac