RFC4408 定义发件人策略框架 (SPF)。
SPF 具有限定符（“-”、“~”、“+”、“？”），分别定义为（失败、软失败、通过、中性）。
网上关于 - 和 ~ 的用法的信息有些混乱。我需要专家的帮助。
我的假设是 Google 使用 ~all 而不是 -all，因为他们的 _spf.google.com 解析为 _netblocks 主机，这是一个动态记录（根据 Google 网站，因为他们在描述 _netblocks 时使用了“当前”一词），因此，由于 DNS 传播延迟，使用了 ~ 而不是 -。
但是，当我查找有关 SendGrid 支持的内容时，我得到了使用 - 和 ~ 的示例，用于相同的场景（相同的主机等等）。唯一的区别是 - 和 ~。
我猜想大多数电子邮件客户端都经过了正确的配置，以至于软失败传递会导致标记消息，表明发件人可能不合法。这是一个安全的假设吗？大型 smtp 公司似乎做出了这样的假设。
https://support.sendgrid.com/hc/en-u...cles/202517236<-- 说使用 -
https://sendgrid.com/docs/Glossary/spf.html<-- 说使用 ~
提前谢谢朋友们。
答案1
软失败（~all）确实应该被视为域所有者认为主机未获得授权但又不愿意做出强有力的政策声明的迹象。这鼓励电子邮件处理器在接受邮件之前对邮件进行进一步审查。
使用 -all 的问题是：
- 损坏的 DMARC 架构可能完全导致消息失败，而无法完成 DMARC 评估，从而违反 DMARC 规范并导致传递问题。
- 当大型 SMTP 运营商进行 IP 更改时，DNS 传播延迟更有可能对其产生影响，因为邮件接收者更有可能在过去几分钟内从这些 DNS 记录中收到电子邮件。
- Google 使用的 TTL 为 5 分钟，但鉴于有超过 500 万家企业使用 Google Apps，Google 会定期向某些服务器发送电子邮件，而 DNS 延迟可能会成为问题。
- 对于使用 DMARC 的域，使用 -all 会导致非 DMARC 兼容第三方处理电子邮件的方式出现明显差异。如果 DKIM 通过并与 DMARC 域一致，则兼容 DMARC 的第三方仍可能接受邮件。但是，如果使用 -all，非 DMARC 兼容的第三方根本不会运行 DMARC/DKIM 检查，而是在 SPF 检查时直接拒绝。组织可能更愿意信任针对其域使用的强 DMARC 断言，因为它涵盖了 EHLO、DKIM 和发件人：域，因此更加全面。
由于上述原因，组织可能不愿意相信仅使用 SPF 断言来对付他们及其邮件流。
谷歌向其客户推荐部署 DMARC减少域名欺骗并建议使用 SPF 中的 ~all 来防止投递问题。