从退信提取三个值
- 被 Gmail 检查的 SPF 域，通常来自 SMTP MAIL FROM，而不一定等于可见
From:。 - 退信明确列出的实际发送 IP。
- 发送这类邮件的平台或服务器，例如交易邮件、营销系统或自建 MTA。
SPF 的问题是“这个域是否授权这个发送路径”。如果域和 IP 取错，即使 TXT 语法看起来正常，修复也不会命中真实故障。
检查唯一 SPF 与授权路径
- 域名应只有一条以
v=spf1开头的 SPF TXT 记录；多个记录会产生 PermError。 - 确认发件平台要求的
include:、ip4:、ip6:或redirect=存在且拼写准确。 - 确认没有在迁移或清理时删除仍在使用的发件源。
- 递归计算
include、a、mx、exists和redirect的潜在 DNS 查询，避免超过 10 次。 - 只在确认全部合法来源后选择
~all或-all；不要使用允许所有来源的+all。
不要把退信里的 Gmail IP 加进 SPF。退信 IP 应是被检查的发送端；若它与你的预期平台不一致，应先追踪实际发送链路或转发路径。
SPF 通过后还要看对齐
SPF pass 不自动等于 DMARC pass。通过 SPF 的 MAIL FROM 域还需要与可见 From: 域对齐；或者由一条通过且对齐的 DKIM 签名提供 DMARC 路径。批量发件人还必须同时满足 Google 当前列出的 DKIM、DMARC、PTR、TLS、退订和投诉率要求。
工具边界
公开扫描可以识别重复 SPF、机制结构、递归查询预算和明显授权缺口，但没有真实发送 IP时不能替代完整 SPF 求值。最终证据来自新发出的邮件、接收方 Authentication-Results 和新的 SMTP 响应。
SPF flatten 会把动态服务商授权冻结成一组 IP。除非有可靠的自动更新与回滚机制，否则不要盲目复制第三方 flatten 结果。