SPF 的七种结果分别代表什么？temperror 和 permerror 该怎么处理？

RFC 7208 第 2.6 节（Results of Evaluation）及其子节逐一定义了评估函数的全部可能输出：第 2.6.1 节 None、第 2.6.2 节 Neutral、第 2.6.3 节 Pass、第 2.6.4 节 Fail、第 2.6.5 节 Softfail、第 2.6.6 节 Temperror、第 2.6.7 节 Permerror。

把它们简单二分为「过 / 不过」是运维事故的常见起点——尤其是把 temperror 当成 fail 处理，会造成本可正常投递的邮件被永久拒绝。

• none：该域没有发布 SPF 记录，或无法确定域名。没有任何授权信息可用，不能据此判定好坏，应交由其他机制与常规过滤决定。
• neutral：域名所有者明确表示不对该地址作断言（记录中的 ? 前缀）。处置上应等同于 none，不可视为不利证据。
• pass：该地址获得授权代表该域发信。注意这只说明「有权使用信封域」，不代表邮件内容可信，也不代表与 From 域对齐。
• fail：域名所有者明确表示该地址无权代表该域发信（记录以 -all 收尾）。这是可据以拒收的明确信号，但需考虑转发场景带来的误判。

softfail（记录以 ~all 收尾）表示域名所有者认为该地址可能无权发信，但态度不够确定，因此不希望接收方仅凭此就拒收。

正确处置：接收时应当接受但予以标记，纳入综合评分，而不是直接拒绝。

发布侧建议：~all 适合作为部署初期的过渡；当发送源盘点完成、确认无遗漏后，再切到 -all。长期停留在 ~all 意味着授权边界始终是模糊的，防冒充效果打折。

temperror 表示评估过程中遇到临时性错误，最常见的是 DNS 查询超时或临时性解析失败。

接收方处置：应当以临时性失败回应（4xx 类响应），让对方稍后重试，绝不能当作 fail 永久拒绝。这是最重要的一条。

发送方排查路径：

1. 检查权威 DNS 服务器可用性与响应延迟，是否存在间歇性超时。
2. 检查 SPF 展开链路上每一个被引用域的解析健康度——链上任一环临时故障都会导致整体 temperror。
3. 关注是否因记录过大导致响应被截断或需要回退重试。

permerror 表示域名的已发布记录无法被正确解读，属于永久性配置错误。常见成因：

• 超出 DNS 查询上限（第 4.6.4 节规定超限必须返回 permerror），或 void lookup 超限。
• 同一域发布了多条 SPF 记录——这是明确的语法错误，必须合并为一条。
• 语法错误：机制拼写错误、前缀非法、宏语法不合规。
• redirect 目标域没有有效 SPF 记录（第 6.1 节）。

处置优先级：permerror 应当按故障对待，而不是配置瑕疵。它意味着 SPF 这条腿完全失效，若此时 DKIM 也未覆盖全部发送源，DMARC 将大面积失败。

1. 先确认唯一性：本域是否只有一条 v=spf1 开头的 TXT 记录。
2. 再算查询数：逐层展开计数，确认未逼近 10 次上限。
3. 再查链路健康：展开树上有无解析失败或不存在的域。
4. 最后核对收尾：结尾是 ~all 还是 -all，是否与当前部署阶段匹配；若使用 redirect，确认记录中没有 all 机制。