2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
你有一份地址列表。这些地址可能来自注册表单、合作伙伴的客户关系管理系统（CRM）、数据丰富化处理流程，或是上一季度的网络研讨会。在将这些地址投入营销活动并毁掉你的发件人信誉之前，你希望知道哪些地址是真实有效的。
你搜索“电子邮件验证”，找到了上百个服务，其落地页均声称准确率高达 99%。你安装了那个最显而易见的软件包，在你的列表上运行它，结果 95% 的地址返回“有效”。你发送了邮件。其中四分之一被退回，主要的收件箱服务提供商开始标记你的域名。
发生了什么？这是以下情况的某种组合：语法正确但实际不存在的地址、撒谎的邮件服务器、全收域名、灰名单以及反探测行为。“这是一个真实的邮箱”比看起来要难证明得多。以下是该协议的实际工作原理、它在何处失效，以及一个严肃的验证器必须如何应对。
语法检查仅能过滤明显的垃圾内容，别无他用
对 [email protected] 运行正则表达式，你会捕获那些明显格式错误的字符串。使用真正的 RFC 5322 解析器，你会捕获更多一些（john..doe@example.com、前导空白字符、包含控制字符的地址）。
import re
EMAIL_RE = re.compile(r"^[^@\s]+@[^@\s]+\.[^@\s]+$")
EMAIL_RE.match("definitelynotreal@gmail.com") # 匹配成功
definitelynotreal@gmail.com 能通过所有曾编写过的语法检查。但它并不存在。语法验证只能告诉你一个字符串可能是一个地址；它无法告诉你它是否真的是一个地址。
你仍然希望将其作为第一道关卡——在 不是电子邮件 的地址上浪费网络调用毫无意义。但是，任何将正则表达式作为其电子邮件验证器发布的人，所解决的问题与他们自以为的不同。
DNS 仅证明域名接受邮件（别无他用）
dig +short MX example.com
# 0 mail.example.com.
如果一个域名没有 MX 记录（也没有根据 RFC 5321 规定的备用 A 记录），它根本不接受邮件。将该地址标记为无效是正确的。这能捕获拼写错误的域名、过期的域名以及从未配置用于电子邮件的域名。
但是 gmail.com 有 MX 记录。每家财富 500 强企业都有。每个全收垃圾邮件陷阱也有。MX 记录存在仅告诉你该域名从事邮件业务，而不是说你关心的那个地址存在于该域名上。
与服务器进行 SMTP 通信
这是每个“真正”的验证器发挥作用的地方。你连接到目标 MX 服务器，完成 SMTP 握手过程，并在实际发送电子邮件的前一步停止：
$ openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -crlf
220 mx.google.com ESMTP ready
EHLO verifier.example.com
250-mx.google.com at your service
...
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
