我深刻体会到 SPF 真正的含义。一个星期五的下午，我将我们的生产域名从软失败模式切换到硬失败模式，完全忘记了几个月前我们搭建的一个事件平台。结果邮件就这样消失了。那天让我明白了一个关键点：你是否真正了解你的邮件来自哪里？如果搞错了，你是否准备好应对投递失败的后果？

从那以后，我对待 SPF 变更的态度就像飞行员对待检查单一样——有条不紊，设有保障，从不仓促行事。

让我拆解一下底层实际上发生了什么。SPF (发件人策略框架)是一种基于 DNS 的电子邮件验证系统。你在你的域名下发布一个 SPF 记录，作为 DNS TXT 记录，告诉接收服务器哪些主机被允许代表你发送邮件。这些服务器会检查你的机制 (ip4、ip6、a、mx、include) 和限定符，然后生成一个结果：通过、无、中立、软失败、硬失败、临时错误或永久错误。

关键的区别在于那个终端限定符。软失败 (~all) 表示“这看起来未授权，但请谨慎处理”。硬失败 (-all) 表示“只有列出的主机是合法的——阻止其他所有”。这个字符的不同，决定了邮箱提供商如何处理你的邮件。

这里变得实际了。使用软失败时，通常会被放入垃圾邮件文件夹或隔离区。使用硬失败，尤其是在启用了 DMARC 对齐的情况下，可能会在邮件服务器端直接拒绝。Microsoft 365 和 Outlook 通常会结合 SPF、DKIM 和内容过滤。Google 和 Yahoo 则更依赖 DMARC 和发件人声誉。因此，软失败可能会落入“推广”文件夹；而硬失败配合 DMARC 对齐，则可能会被果断阻挡。

我从不直接跳到硬失败。我的流程始终是：中立 (?all) → 软失败 (~all) → 硬失败 (-all)。在发现阶段，当我不确定遗留的邮件流或供应商 IP 范围时，我会用软失败。它可以标记域名滥用而不影响投递，同时让我清点所有发信源——CRM、营销自动化、工单系统、人力资源、财务，甚至打印机。

一旦验证了所有授权发信人，确保 DKIM 在各处一致后，我就会切换到硬失败。风险是存在的：软失败在清点期间能提高投递率，但也更容易让钓鱼邮件伪装成正常邮件而未被阻挡。硬失败提供更强的安全性，但如果漏掉了某个发信人，可能会导致合法邮件被拦截。

我见过团队因为过度嵌套 include 导致超出 10 次 DNS 查询限制，也见过他们忘记季节性供应商，比如 Livestorm 或 Prismic 的 webhook。还见过有人以为 DMARC 会拯救一个有问题的 SPF 记录——其实不会，除非对齐。

真正的教训是：把 SPF、DKIM 和 DMARC 当作一个系统来看待，而不是孤立的部分。转发会破坏 SPF，因为连接的 IP 会变化。如果你使用 SRS (发件人重写方案)，就没问题；否则，软失败可能是阻止误发的唯一屏障。这也是我会 obsessively 监控 DMARC 汇总报告，读取 Authentication-Results 头部信息的原因。

我的安全部署流程是：先映射所有邮件服务器和工作流程，验证每个 DKIM 设置，启用 p=none 的 DMARC 进行监控，然后将 SPF 设置为软失败，观察两轮发信情况，调查所有未授权的发信人，再在正式切换到硬失败前进行拒绝策略的模拟。

过去几年，Google 和 Yahoo 加强了验证要求。策略执行变得多信号：SPF 模式、DKIM 签名、DMARC 策略、内容和声誉都很重要。这也是我绝不单独对待 SPF 的原因。没有强固 DKIM 的硬失败，可能在转发频繁的场景下反而影响投递。

我仍然看到的最大错误是：团队在 DKIM 普及之前就切换到硬失败，或者一直依赖软失败，任由攻击者适应，电子邮件伪造在这种模糊状态中繁荣。这需要平衡，但只要有条不紊，路径就很清晰。