Valimail：为什么转发邮件会破坏 SPF（以及 DKIM 如何化解）
📖 原文翻译与解读。原文：Why forwarded emails break SPF (and how DKIM solves it)（Valimail，2026 年 7 月）
一、执行摘要
邮件认证本应是可靠的「后台核查」，但一旦邮件被转发，这些检查就会以令资深管理员都意外的方式失败。最常见的痛点就是 SPF：一封合法发出、合法转发的邮件，在收件人看来却像伪造品——「为什么我的转发邮件进了垃圾箱」「为什么 DMARC 突然开始失败」。
根源在于 SPF 只在邮件旅程中某个特定节点回答一个非常具体的问题，而转发会改变这些条件。理解 SPF 能证明什么、不能证明什么，是避免认证失败又不打乱正常邮件流的关键。
二、SPF 如何工作、为何依赖发送 IP
SPF（Sender Policy Framework）是一条基于 DNS 的策略，告诉全世界哪些邮件服务器被授权使用该域名的 return-path（信封 From / MAIL FROM）发送邮件。接收服务器在建立 SMTP 连接时，用两个主要输入评估 SPF：连接 IP 地址，以及 envelope-from 中的域名。接收方查询该域的 SPF 记录，检查连接 IP 是否被记录中的机制（ip4、ip6、a、mx、include、exists）授权，得出 pass / fail / softfail / neutral / none 等处置。
SPF 非常擅长阻止简单的域名仿冒：攻击方从未授权服务器发信却冒充合法域名时，接收方只需问「这个 IP 被允许为该域发信吗」并依答案执行本地策略。但它依赖连接 IP 的局限也很明显：每次接收都独立评估，而非端到端。它不验证邮件最初由谁撰写，也不提供在通过 SPF 检查的那台服务器之后仍然有效的证明。
三、为什么转发常导致 SPF 失败
转发在 SMTP 视角下创造了一次「新的投递事件」：转发服务器成为新的 SMTP 客户端，连接收件人邮件服务器并投递邮件。即便邮件内容未被修改，从收件人视角看，转发服务器现在是发信系统。
关键是大多数转发系统保留原始 envelope-from。于是接收方用「原始发件人的 return-path 域」评估 SPF，却检查「转发服务器的 IP」。除非原始发件人的 SPF 记录显式授权该转发服务器（通常不可能），SPF 就会失败。原始发件人既不应当也无法授权互联网上任意转发基础设施。因此标准转发即便所有系统都按预期运作，也会破坏 SPF：邮件初次到达转发服务时可能通过 SPF，但最终到达目的地时却失败，因为收件人只看到转发服务器 IP。
常见触发场景：托管邮箱的自动转发规则、ISP 提供的转发服务、大学校友转发地址、小企业经中央邮箱服务商再转发到个人收件箱。邮件列表视其处理方式也可能产生类似问题。
四、DKIM 如何撑过转发
DKIM（DomainKeys Identified Mail）走另一条路：它不验证连接 IP 是否被授权，而是验证邮件内容与所选头部是否由某个在 DNS 发布对应公钥的域签名。发送方添加 DKIM-Signature 头，含签名域（d=）、选择器（s=）、签名覆盖的头部（h=）以及对规范化后头部与正文的密码学签名。接收方从 selector._domainkey.example.com 取公钥校验。
由于签名随邮件走，DKIM 远比 SPF 抗转发。转发服务器 IP 不影响 DKIM 校验，只要签名覆盖的部分完好到达，DKIM 签名依然有效。在 DMARC 下这通常已足够：邮件只要 SPF 或 DKIM 任一通过并与可见 From 域对齐即可通过 DMARC。由于转发常破坏 SPF 对齐，DKIM 往往成为维持 DMARC 合规的机制。
五、邮件系统防护启示
对运维邮件系统的团队：① SPF 失败转发是「预期行为」而非记录配置错误，不应把转发服务全盘加进 SPF 记录（会不必要地放大仿冒面）；② 在所有出站邮件流部署 DKIM，并让 DKIM 与可见 From 域对齐，这是转发场景下最稳健的 DMARC 合规路径；③ 采用 relaxed 规范化容忍轻微格式改动，并避免签名后对出站邮件再做修改；④ 对邮件列表、网关免责声明、URL 改写等会破坏签名的环节重点监控。SRS（Sender Rewriting Scheme）可在自有转发设施下缓解 SPF 失败，但它把 SPF 认证转移到转发域，无法保留原始 From 域的 DMARC 对齐。详见 DMARC np= 标签 与 BIMI AVP 标签。
参考来源
了解更多行业资讯，请访问 行业资讯首页 或致电 021-69753778 获取安全咨询服务。
相关文章
—— ztpop.net 编辑团队 译