做邮件服务的人，大概都经历过这种时刻：用户发来工单，说密码重置邮件又进了垃圾箱，明明"什么都没改"。然后你打开DMARC聚合报告，开始一天漫长的排查。

市面上关于邮件认证的资料，要么是服务商向导让你直接粘贴一条记录，要么是晦涩的RFC文档。这篇文章试图填补中间那块空白：每个机制到底干什么、什么情况下会出问题、按什么顺序配置。

打开网易新闻 查看精彩图片

问题的根源：SMTP天生不设防

SMTP协议设计于1982年，压根没有认证的概念。邮件服务器接受连接，然后相信对方说的一切。具体来说，一封邮件里其实带着两个不同的发件人地址：

  • 信封发件人（MAIL FROM）：SMTP层面的路由信息，退信发到这里
  • 头部From：用户实际看到的发件人，比如 support@yourbank.com

你的邮件客户端显示的是后者，而SMTP协议本身完全不关心这两者是否匹配。这意味着什么？攻击者随便找台VPS连上Gmail，在邮件头里写上 From: support@yourbank.com，一封看似来自银行的钓鱼邮件就诞生了。

下面要讲的每个机制，都是在堵这个漏洞的不同部分。三个缺一不可——SPF和DKIM单独使用时，认证的都是用户根本看不到的东西。

SPF：声明"谁有资格替你发信"

SPF就是在域名根上放一条TXT记录，列出被授权的发信服务器。比如：

example.com. IN TXT "v=spf1 include:amazonses.com include:_spf.google.com ip4:203.0.113.7 -all"

这条记录从左往右读，第一个匹配的机制生效。其中唯一值得认真决策的，是最后的限定符：

  • 还在摸索哪些系统在替你发信时，用 ~all（软失败）
  • 确认无误后，切换到 -all（硬失败）

别永远停在~all。一旦DMARC进入强制执行阶段，-all才是让未授权中继真正失败的关键，而不只是"看起来有点怪"。

SPF的隐形陷阱：10次DNS查询上限

RFC 7208 §4.6.4规定，SPF评估最多执行10次DNS查询。include、a、mx、ptr、exists和redirect都算数，而且是递归计算的。超过上限结果就是permerror，大多数接收方会把它当作"SPF未通过"处理。

ip4:和ip6:机制不消耗查询次数——这就是你的逃生通道。

下面这条记录看起来人畜无害，其实已经坏了：

"v=spf1 include:_spf.google.com include:amazonses.com include:servers.mcsv.net include:_spf.salesforce.com include:spf.protection.outlook.com ~all"

光是_spf.google.com自己就展开了三个include。五个厂商include轻松就能达到12到15次查询。这个失败是无声的：不会有退信，只是投递率慢慢变差，而且影响的是该域名发出的所有邮件，不只是把你推过线的那家厂商。

修复顺序，按优先级排列

改动上线前先数一数查询次数。用 dig +short TXT example.com 查看当前记录，再用校验工具算一下总查询数。别等出了问题再回头查。

优先用ip4/ip6直写IP，把include数量压到最低。如果厂商的include展开后查询数太大，考虑用a机制指向一个专门的A记录，或者干脆把该厂商的IP段直接写进SPF。

最后，别忘了DMARC。SPF和DKIM只是认证手段，DMARC才是那个告诉接收方"认证失败该怎么处理"的裁判。没有DMARC，SPF和DKIM的结果对收件方来说只是参考信息，而