我试图找出为什么伪造电子邮件正在交付给主要的电子邮件提供商（gmail.com，outlook.com），即使电子邮件被标记为SPF hardfail 。 该电子邮件也被传递给Microsoft Exchange，它为相同的SPFlogging抛出一个PermError 。
我正在使用SOME_DOMAIN.com域发送电子邮件，该域定义了SPFlogging损坏。 该电子邮件是从我自己的IP地址传输的，这个IP地址没有在SOME_DOMAIN.com的SPFlogging中明确列出。 SOME_DOMAIN.com的SPFlogging具有以下三个属性，前两个属性违反了SPF RFC-4408：
include: 。 hardfail和-all两个规则，都表示所有地址的集合应该是hardfail和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 xxxx as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM
那么这里发生了什么？ 为什么尽pipeSPF hardfail电子邮件正在交付？ 有SPFlogging损坏意味着其他SMTP服务器完全忽略SPF？ 还是有什么我在这里失踪…
如此多的网站对SPF进行了严格的configuration，以至于接收MTA的人通常只会将hardfail计算在咨询范围内，而仅仅将其归入垃圾邮件检测分数。 最后，由MTA的pipe理员来决定如何处理SPF故障。
SPF错误情况不表示所需的策略。 因此，他们没有提供关于是否接受消息的指导。 预期的政策可能是+all 。 在这种情况下接受邮件是正常的。 谷歌似乎对这个域名不遵守这个标准感到宽慰。
即使SPF策略拒绝（ -all ）在validation发件人地址时也是不可靠的。 有很多情况下拒绝这样的邮件是不合适的，包括：
我运行一个相当小的服务器，我可以推迟硬失败。 这使我可以列出合法的失败。 如果发件人注意到邮件未送达，他们可能会修正其configuration。 在某些情况下，我会尝试联系相关的postmaster ，但很多域名没有postmaster地址。
想要执行更强策略的用户可以使用尚不是标准的DMARC。 邮件仍然可能会被发送，但可能会按照该政策的规定被隔离或拒绝。 邮件失败的政策可能会被传递到垃圾邮件文件夹，而不是正常的收件箱。
SPF硬核失败对于validation发送服务器的身份似乎是可靠的。 前段时间我做了一些研究，发现即使HELO名称软失败也是导致失败或推迟接收消息的合理原因。
许多邮件服务器没有SPFlogging。 如果邮件服务器没有SPFlogging，我检查父域的SPFlogging。 这是非标准的，但有效的。 我鼓励电子邮件pipe理员确保PTRlogging中列出的服务器IP存在SPFlogging。 您的服务器应该通过PTRlogging返回的名称来标识自己。 validation您有相应的Alogging反向DNSvalidation。