为什么在SPF为“硬失败”的情况下仍可以正常发送电子邮件？

我试图弄清楚为什么即使将伪造的电子邮件标记为SPF，伪造的电子邮件仍会传递给主要电子邮件提供商（gmail.com，outlook.com）hardfail。该电子邮件也将传递给Microsoft Exchange，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？还是我在这里想念的东西...

SPF的配置如此之差，以至于接收MTA的站点通常hardfail仅被视为建议，而只是将其计入垃圾邮件检测分数中。最后，由MTA的管理员决定如何处理SPF故障。

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

-all验证发件人地址时，甚至SPF策略拒绝（）都不可靠。在许多情况下，拒绝此类邮件是不合适的，包括：

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

我运行的服务器相当小，可以在发生严重故障时进行延迟。这使我可以将合法的失败列入白名单。如果发件人注意到邮件未送达，他们可以修复其配置。在某些情况下，我会尝试与相关的联系postmaster，但许多域都没有postmaster地址。

想要实施更强策略的用户可以使用DMARC，这不是一个标准。邮件仍然有可能被传递，但是可以按照该策略中的规定进行隔离或拒绝。未能通过该策略的邮件可能会传递到垃圾邮件文件夹，而不是普通的收件箱。

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

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