我通过艰难的方式了解了 SPF——在一个星期五下午将生产域名的 softfail 改成 hardfail，结果看到一整封邮件流完全消失。结果发现我忘记了几个月前设置的某个事件平台。这个错误让我学到了一些关键的东西：在修改你的 SPF 记录之前，你必须知道所有邮件的来源地点，并且如果搞错了，要接受后果。

让我来拆解一下真正重要的内容。SPF (发件人策略框架)（Sender Policy Framework）基本上是你的域名告诉接收服务器：这是我的 DNS TXT 记录，列出哪些主机可以合法代表我发送邮件。当一封邮件到达时，接收方会根据返回路径域名检查你的 SPF 记录，评估你的机制 (ip4、ip6、a、mx、include)，并决定下一步。这个决定取决于一个因素：你在最后设置的限定符——你选择的模式。

这里的核心差异容易让人混淆。软失败 (~all) 表示“这看起来未授权，但也许没问题——请谨慎处理。” 通常它会触发垃圾邮件过滤，而不是直接拒绝。硬失败 (-all) 表示“只有我列出的主机是合法的——阻止其他所有的。” 这是明确的，当它与 DMARC 一起使用时，可以实现真正的消息拒绝。

我把它比作 staging（测试环境）与 production（生产环境）。软失败是你在测试阶段的谨慎模式，等你还在摸索。硬失败则是在生产中切断电源，承担后果。

我遵循的实际路径是有条不紊的：先用 ?all 进行纯观察，等你开始监控 DMARC 汇总报告后，再切换到软失败 (~all)，只有在验证了每个授权发件人且误报几乎为零后，才切换到硬失败 (-all)。我从不急于一时。我会列出所有清单——CRM、营销自动化、工单系统、人力资源、账单，甚至奇怪的设备如打印机。我确认哪些供应商支持 DKIM 和 DMARC 一致性。我会记录每次变更的负责人。

有一件事会很快让你吃亏：SPF 有一个硬性限制——最多10次 DNS 查询。我见过有人把 include 嵌套得太深，突然超出限制，导致一切崩溃。要减少 include 的层级，优先考虑 IP 范围而非嵌套链，清理无用的服务。如果一个批量发件人频繁轮换 IP，建议用带有 SLA 的稳定 include。

转发也是个陷阱。它会破坏 SPF，因为连接的 IP 会变。如果转发器使用 SRS (发件人重写方案)，就没问题；否则，软失败可能是阻止误报的唯一手段。这也是我更依赖 DKIM 和 DMARC 一致性路径的原因。

我经过时间打磨的实际部署清单是：映射每个邮件服务器和工作流程，验证每个地方的 DKIM，启用 p=none 的 DMARC 以收集数据，逐步将 SPF 改为软失败 ~all 并观察至少两个发信周期，调查每个未授权的发件人，授权或终止流量，然后在正式切换到硬失败之前，逐步推出带有 DMARC 执行的拒绝策略。最后一步——只有在所有合法发件人都覆盖到位时，才切换到硬失败——这是绝对不能妥协的。

我还注意到：Google 和 Yahoo 已经大幅收紧了标准。邮件策略的执行现在结合了 SPF 模式、DKIM 签名、DMARC 策略、内容分析和声誉评分。这也是我绝不单独依赖 SPF 的原因。没有强有力的 DKIM 支持，单纯的 SPF 硬失败在转发频繁的环境中仍可能影响投递。

我看到的最大陷阱包括：嵌套 include 超过10次限制、忘记季节性供应商用你的域名发信、以为 DMARC 能拯救一个有问题的 SPF 设置、一直依赖软失败而攻击者不断适应，或者在 DKIM 还未普及时就切换到硬失败。尤其是最后一项——虽然安全性高，但在大量转发的情况下，投递率会变得非常糟糕。

如果你现在还在用 softfail，犹豫是否要切换，答案是：只有当你准备好了。你验证过每个发件人了吗？DKIM 是否对齐？误报几乎为零了吗？如果都确认无误，切换到硬失败是合理的；如果没有，还是耐心等待。软失败不是永久状态——它只是一个检查点。