尽管存在 SPF“硬故障”，为什么电子邮件仍能正常发送？

Question

我试图弄清楚为什么即使电子邮件标有 SPF ，也会将伪造的电子邮件发送给主要电子邮件提供商（gmail.com、outlook.com）hardfail。该电子邮件还会发送到 Microsoft Exchange，它会PermError为相同的 SPF 记录抛出一个。

我使用 SOME_DOMAIN.com 域发送电子邮件，该域定义了损坏的 SPF 记录。该电子邮件是从我自己的 IP 地址传输的，该地址未在 SOME_DOMAIN.com 的 SPF 记录中明确列出。SOME_DOMAIN.com 的 SPF 记录具有以下三个属性，前两个违反了 SPF RFC-4408：

1. 由于include:.
2. SPF 记录之一中的语法错误，python-spf 引发解析错误。
3. SPF 记录包含规则~all和-all，两者都表示所有地址的集合应该softfail和hardfail

发送到 Outlook.com 地址冒充 admin@SOME_DOMAIN.com 的电子邮件将在已发送电子邮件的 SMTP 标头中包含以下错误。此电子邮件已正常发送到用户的收件箱：

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail 还会将电子邮件发送到用户的收件箱，但会引发不同的 SPF 错误：

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

那么这里发生了什么？尽管有 SPF，为什么仍能发送电子邮件hardfail？SPF 记录损坏是否意味着其他 SMTP 服务器完全无视 SPF？或者我在这里遗漏了什么......

Answer 1

SPF 被如此多的站点配置得如此糟糕，以至于接收 MTA 通常hardfail仅被视为建议，并且仅将其计入他们的垃圾邮件检测分数。最后，如何处理 SPF 故障取决于 MTA 的管理员。

Answer 2

SPF 错误条件并不表示有关所需策略的任何信息。因此，它们不提供关于是否接受消息的指导。预期的策略可能是+all。在这种情况下接受邮件是正常的。谷歌似乎对不符合标准的域名很宽容。

-all在验证发件人地址时，即使 SPF 策略拒绝 ( ) 也不可靠。在许多情况下，拒绝此类邮件是不恰当的，包括：

• 由签约邮寄者发送的邮件（这些人因违反政策而获得报酬。）；
• 从网络表格和其他此类自动化系统发送的邮件；
• 通过邮件列表或其他转发机制转发的邮件；和
• 只是 SPF 记录的简单配置错误（不常见，但并不罕见）。

我运行一个相当小的服务器，在那里我可以推迟硬故障。这允许我将合法失败列入白名单。如果发件人注意到邮件未送达，他们可能会修复他们的配置。在某些情况下，我会尝试联系相关的postmaster，但许多域没有postmaster地址。

想要执行更强大策略的用户可以使用 DMARC，这还不是标准。邮件仍有可能被投递，但可能会按照该政策的规定被隔离或拒绝。未通过策略的邮件可能会被传送到垃圾邮件文件夹，而不是正常的收件箱。

SPF 硬故障似乎确实可以可靠地验证发送服务器的身份。我不久前做了一些研究，发现即使是 HELO 名称上的软失败也是失败或延迟传入消息的合理原因。

许多邮件服务器没有 SPF 记录。如果邮件服务器没有 SPF 记录，我会对照父域检查 SPF 记录。这是非标准的，但有效。我鼓励电子邮件管理员确保 PTR 记录中列出的服务器 IP 有一个 SPF 记录。您的服务器也应该通过其 PTR 记录返回的名称来标识自己。验证您有相应的 A 记录用于反向 DNS 验证。