邮件被转发后 SPF 就失败，这是配置问题还是协议固有限制？

SPF 的评估对象是当前正在投递这封邮件的那台主机的 IP，配合信封发件人的域来判断是否获得授权。

转发场景下，邮件由中介主机再次投出，此时的发送 IP 是中介的 IP。如果中介仍然保留了原始的信封发件人域，那么接收方拿「原始域的 SPF 记录」去校验「中介的 IP」，结果必然是不通过——因为原始域从未授权过这台中介主机。

这不是任何一方配置错误，而是机制本身的边界。理解这一点，才不会在错误的方向上反复调整 SPF 记录。

RFC 7208 第 10.3 节（Mediators）讨论了邮件中介这一角色，并明确指出：若中介使用的地址与原始邮件相同、且原始邮件有对应的 SPF 记录，则 SPF 评估将会失败，除非采用相应的缓解措施。规范把这些措施集中放在附录 D（SPF/Mediator Interactions），并分为发起方、中介方、接收方三个视角分别说明。

第 2.2 节（Checking Authorization）也提到，几乎所有邮件列表都会重写信封发件人身份，但部分不改动邮件中的其他身份标识——这从侧面说明了「重写信封域」正是中介侧的通行做法。

中介侧最直接的缓解方式，是把信封发件人改写为自己的域，从而让 SPF 校验的对象与实际发送主机匹配。

实施要点：

• 改写后的信封域必须由中介自己维护 SPF 记录，且授权其实际发送出口。
• 必须保证退信可达。改写信封发件人意味着退信会回到中介，中介需要有能力处理这些退信并将状态回传给原始发送方，否则会造成投递状态黑洞。
• 注意对 DMARC 的连带影响。信封域改成中介域后，SPF 即便通过，也与原始 From 域不再对齐，DMARC 的 SPF 侧仍然算失败。

因此重写信封只解决了 SPF 本身，没有解决 DMARC。这是必须建立的认知。

既然 SPF 在转发后不可靠，DKIM 就必须承担起对齐的主要责任：

1. 确保所有外发邮件都带有以自有域签名（d= 与 From 域对齐）的 DKIM 签名。DKIM 随邮件内容一起传递，只要邮件未被实质修改，转发多少次都能验证通过。
2. 规范化选 relaxed/relaxed，提高对中转环节格式调整的容忍度。
3. 收敛 h= 覆盖范围，减少因头字段被改写而失效的概率。
4. 在收紧 DMARC 策略前，先确认转发路径上 DKIM 的实际存活率，可从聚合报告中「SPF 失败但 DKIM 通过」的记录量来观察。

判断标准：如果你的域在转发场景下只能靠 SPF 通过 DMARC，那就还不具备收紧到 reject 的条件。

• SPF fail 不应单独构成拒收理由。转发是完全正常的邮件行为，据此直接拒绝会造成大量误伤。
• 优先看 DMARC 综合结论，而不是任一单项机制的结果。
• 对已知的中介来源可结合 ARC 结论判断，参考经过验证的转发链上游认证结果。
• 把 SPF 结果作为综合评分的一个输入，而非一票否决项。

• 不要把中介 IP 加进自己的 SPF 记录。这会授权一台你并不控制的主机代表你的域发信，扩大冒用面，且中介 IP 变化时你需要持续跟进——收益低、风险高、还消耗查询预算。
• 不要因为转发失败就把 -all 退回 ~all。这削弱了本域的授权边界，却没有解决转发问题——问题的解药在 DKIM，不在 SPF。
• 不要在 DKIM 覆盖率不足时强上 reject。转发流量会成为第一批牺牲品。