北京
做邮件服务的人，大概都经历过这种时刻：用户发来工单，说密码重置邮件又进了垃圾箱，明明"什么都没改"。然后你打开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的结果对收件方来说只是参考信息，而
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
