SPF 失败与软失败的优缺点

Question

题

在我的 SPF 记录中使用Fail 和 SoftFail 的优缺点是什么？

我在这个主题上发现了什么

早在 2007 年，知识渊博的人似乎就说 SoftFail 只是为了测试，并鼓励在您正确设置所有内容后将其更改为拒绝（此处和此处）

该论坛帖子称 SoftFail“配置错误”，但随后表示 Google 使用了它。我信任 Google 的最佳实践，而不是随机的论坛海报！我查了一下，确实，Gmail~all在他们的 SPF 记录中使用了（一个 SoftFail）。

在发件人方面，电子邮件送达率专家似乎鼓励使用 SoftFail：

失败“[比 SoftFail] 更具侵略性，并且众所周知会产生比解决的问题更多的问题（我们不推荐这样做）。”

—邮戳 SPF 指南

那比较含糊。

“我通常建议~all为我的客户发布记录。发布 -all 并没有太大的好处，有时邮件会被转发。有一次我推荐 -all 记录是当域被伪造为垃圾邮件时。域伪造可能会导致很多退回。退回的数量可能足以关闭邮件服务器，尤其是那些用户群较小的服务器。许多 ISP 会在发回退回之前检查 SPF，因此 -all 记录可以减少对域的反吹量主人必须处理。”

— 电子邮件送达率顾问Word to the Wise

然而，网站管理员如何知道是否存在大量域伪造？为最坏的情况做准备并提前预测伪造不是最佳做法吗？

在接收端，从事企业垃圾邮件过滤工作的Terry Zink为防止网络钓鱼电子邮件通过的 hard Fail提供了强有力的案例，并表示大多数人使用 SoftFail 是因为组织更害怕电子邮件丢失而不是伪造电子邮件。SPF SoftFails 将伪造的网络钓鱼电子邮件实际发送到某人的收件箱的可能性有多大？

Answer 1

桑德拉，你已经找到了一个相关的问题，但在我看来，得分最高的答案并不能正确回答你的问题。

让我从您的最后一个问题开始：SPF SoftFails 伪造的网络钓鱼电子邮件实际上到达某人的收件箱的可能性有多大？ 巨大的！结合 DMARC 隔离/拒绝策略和 Office 365、Outlook.com、Gmail、雅虎或其他主要托管商的接收邮箱，可能性很小。

您的第一个问题：故障转移软故障 SPF 记录的优势是什么。 正如您在自己的研究中提到的，缺点是转发的电子邮件将被拒绝，除非转发器重写退回地址（返回路径）。一个优势是可以更好地保护域免受欺骗，但仅适用于最简单的尝试。

如上所述，SPF 的警告是它检查了保存在邮件头字段中的SMTP信封发件人Return-Path。实际收件人不知道此字段，因为大多数电子邮件客户端只会向他们显示另一个字段，即 header From。例如：我发送了一封带有 header 的电子邮件From: Satya@microsoft.com，但我SpoofedYou@example.com用作信封发件人。即使microsoft.com发布了Fail SPF 策略，它也不会因为example.com没有发布 SPF 记录而使 SPF 失败。收件人只会看到来自 的电子邮件Satya@microsoft.com。

这就是 DMARC 的用武之地。DMARC 要求身份验证与From标头中使用的域一致，无论是 SPF 还是 DKIM。这意味着信封发件人 ( Return-Path) 中使用的域和标头From:应共享一个组织域。DMARC 只关心底层身份验证机制（SPF 或 DKIM）的 PASS 结果，因此，对于 SPF 在这方面~all并被-all完全相同对待。

Terry Zink 发表了多篇关于 DMARC 的文章，其中一篇： 在 Office 365 中使用 DKIM 和 DMARC 增强电子邮件保护

关于 SPF、DKIM 和 DMARC，人们可以了解很多，这超出了本答案的范围。DMARC 既不容易实施也不容易完美，但它确实可以保护您的域免受欺骗，比仅使用 SPF 好得多。此外，一切都取决于接收方以及他们如何处理 SPF 和 DMARC（如果有的话）。