早在6月份，我就发现理论上我们也应该为EHLO主机名设置SPF记录。对此的传统解释(除了大型电子邮件提供商这么说，这是现代SMTP中做任何事情的通常原因)来自于，例如，这篇关于小型邮件服务器最佳当前实践的文章，是这样的(释义)：
人们使用SPF来验证信封发件人域(SMTP MAIL FROM)。但是，当您发送退回时，它的发件人为空，因此没有可用于SPF检查的发送域。因此，发送者域名取自EHLO主机名，因为没有更好的地方获取它(因为没有SMTP级别，退回声称是由Xdomain发送的，尽管这通常在消息报头中)。
这当然是一种虚假的说法。这里实际发生的情况是，接收邮件服务器正在尝试验证EHLO/HELO主机名本身不是伪造的，并为此使用SPF。这是对SPF的完全再利用，我们可以看到这一点，因为发件人就在发件人策略框架的名称中，并且在SMTP级别上可以看到退回的发件人(并且也没有完全标准的方式使其在邮件头中可见)，所以我们可以看到它的用途是完全不同的，因为发件人在发件人策略框架的名称中是正确的，并且在SMTP级别上可见的退回发件人是不存在的(并且也没有完全标准的方式使其在邮件头中可见)。
这里有一些与电子邮件相关的标准以及任何互联网标准的经验教训，我可以这样总结：如果人们认为有一个漏洞需要填补，那么附近的任何钉子都会被钉上，而不管钉子最初是为了什么而设计的。在这里，我可以这样总结：如果人们认为有一个漏洞需要填补，那么附近的任何钉子都会被钉进去，而不管钉子最初是为了什么而设计的。
PS：这详细介绍了我最近发布的一条推文，该推文为我们的EHLO主机名添加了SPF DNS记录(并为我们的记录写下了更改的官方解释)。
建议您始终(但要小心)检查HELO身份，并在检查“邮件发件人”之前这样做。
如果信封发件人为空发件人，邮件将被假定来自'；postmaster@<；Helo Name>；'；，这将用作邮件发件人检查(即使您已经检查了HELO身份)。
我还没有看过RFC 7208&39；关于做SPF检查的部分，看看它在算法上对待Helo和Mail From检查是否有些不同，因为坦白地说，我对此不够感兴趣。
这意味着RFC7208本身是我上面总结的常规解释的超集。在RFC 7208中，您有EHLO主机名的SPF记录，这既是因为退回，也是因为建议接收者始终检查它们。这意味着你所有的邮件发送机都应该有SPF记录，而不仅仅是那些可以发送退信的。
(现在我已经查过了，我可能需要更新一些DNS记录。(再次。)