SPF 的 "all" 机制用 ~all（softfail）还是 -all（hardfail）？各有什么风险？

两种机制的定义：RFC 7208 §5.1 定义了 all 机制的两个限定符——-all（hardfail）表示"不在我 SPF 记录里列出的就是伪造，直接拒绝"；~all（softfail，RFC 7208 §2.5）表示"不在记录里的可能是伪造也可能是我忘了添加，不要完全信任"。两者之差不在于是否做检查，而在于收件方看到不匹配时采取什么动作。

-all（hardfail）的风险：最安全但也最危险。如果云邮件服务商更换了发信 IP 而未通知你，或第三方邮件服务（营销平台、CRM 自动触发邮件、客服系统）的发信源不在 SPF 中，正常邮件会被拒收——且你不会收到任何提醒，因为拒收发生在收件方一侧。已经有多起企业因为改 -all 导致客户收不到订单确认邮件的事故。

~all（softfail）的风险：安全兜底更弱——垃圾邮件伪造你的域时，收件方可能因为 softfail 而不直接拒绝，伪造邮件进入收件箱的概率更高。但这一风险可以通过外挂 DMARC 策略（p=reject）来抵消：即使 SPF 返回 softfail，只要 DMARC 要求 fail 对齐，收件方仍会拒收。

推荐落地策略：以 ~all 起步，部署 DMARC 报告（rua 标签）后观察 2-4 周。逐项确认所有合法出站源（包括第三方代发、内部应用自动发信、子域业务邮件）的 IP 都已通过 include 或 ip4 纳入 SPF。确认无误后，再改为 -all 并同步设置 DMARC p=reject。不要在生产域上直接一步到位设 -all。