发件人策略框架限定符

RFC4408定义了发件人策略框架（SPF）。

SPF有限定符（“ – ”，“〜”，“+”，“？”），分别定义为（失败，软失败，通过，中立）。

网上有关使用 – 与〜的信息混淆。我需要专家的帮助。

我的假设是，谷歌使用〜全部，而不是 – 因为他们的_spf.google.comparsing为_netblocks主机，这是一个dynamic的logging（根据谷歌的网站，因为他们在描述_netblocks时使用“当前”一词），因此，由于DNS传播延迟，使用〜而不是 – 。

但是，当我看到SendGrid支持的东西，我得到的例子使用 – 和〜相同的情况（相同的主机等等）。唯一的区别是 – 和〜。

我的猜测是大多数电子邮件客户端已正确configuration，以便〜softfail通过导致标记的消息指示发件人可能不合法。这是一个安全的假设吗？这似乎是大smtp公司做出了这个假设。

https://support.sendgrid.com/hc/en-u…cles/202517236 < – 说使用 –

https://sendgrid.com/docs/Glossary/spf.html < – 说使用〜

在此先感谢朋友。

Softfail（〜all）确实应该被看作是表明域名所有者认为主机没有被授权，但不愿做出强有力的政策声明。这鼓励电子邮件处理程序在接受邮件之前对邮件进行进一步的审查。

使用的问题都是：

损坏的DMARC体系结构可能会失败，而不是完成DMARC评估，因此违反了DMARC规范并导致了交付问题。
DNS传播延迟更容易影响大型SMTP运营商进行IP更改，因为邮件接收者在过去几分钟内更有可能从这些DNSlogging收到电子邮件。
- Google使用的TTL时间为5分钟，但有500多万家企业使用Google Apps，Google为自己及其客户定期发送电子邮件给一些DNS延迟可能成为问题的服务器。
对于使用DMARC的域，使用-all将导致非DMARC兼容的第三方处理电子邮件的方式有明显的差异。如果DKIM通过并且与DMARC域一致，则符合DMARC的第三方仍然可以接受消息。但是，不符合DMARC标准的第三方根本不会运行DMARC / DKIM检查，而只需在SPF检查时拒绝使用-all。由于它涵盖了EHLO，DKIM和From：域，因此组织可能更愿意信任强大的DMARC断言来对其域使用，从而更彻底。

由于上述原因，组织可能不愿意信任SPF唯一的断言来对付他们和他们的邮件stream。

Googlebuild议他们的客户部署DMARC来减less域名欺骗，并build议在SPF中使用〜all以防止交付问题。