☰

为什么尽管出现 SPF“硬故障”，电子邮件仍能正常投递？

tag-icon • tag-icon email exchange smtp spf
为什么尽管出现 SPF“硬故障”，电子邮件仍能正常投递？

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

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

  1. 由于，需要超过 10 个 DNS 查询才能解析整个 SPF 记录include:。
  2. 其中一个 SPF 记录中的语法错误，python-spf 抛出解析错误。
  3. SPF 记录包含规则~all和-all，均表示所有地址的集合应该softfail并且hardfail

发送到冒充 admin@SOME_DOMAIN.com 的 outlook.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？还是我遗漏了什么……

答案1

很多网站的 SPF 配置非常糟糕，以至于接收 MTA 通常hardfail只将其视为建议，并仅将其计入垃圾邮件检测分数。最终，如何处理 SPF 故障取决于 MTA 管理员。

答案2

SPF 错误条件不表明任何有关所需策略的信息。因此，它们不提供是否接受邮件的指导。预期的策略可能是+all。在这种情况下接受邮件是正常的。看来 Google 对该域名未能遵守标准的行为很宽容。

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

  • 签约邮寄者发送的邮件（这些人收了钱却违反政策。）
  • 从网络表单和其他此类自动化系统发送的邮件；
  • 通过邮件列表或其他转发机制转发的邮件；以及
  • 只是 SPF 记录的简单配置错误（不常见，但也不够罕见）。

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

想要执行更严格政策的用户可以使用 DMARC，但目前这还不是标准。邮件仍可能被投递，但可能会根据该政策被隔离或拒绝。不符合该政策的邮件可能会被投递到垃圾邮件文件夹，而不是正常的收件箱。

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

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

相关内容