【发布时间】：2020-12-24 06:13:59
【问题描述】：
v=spf1 include:spf.falconide.com include:sendgrid.net include:_spf.google.com ip4:xx.xxx.xxx.x ~all
以上是我的域的 SPF 记录，我正在使用外部工具来获取开源威胁情报，在工具中它说我的 SPF 配置不安全。目前无法获得支持。
配置看起来有什么不安全的地方吗？
【问题讨论】：
【发布时间】：2020-12-24 06:13:59
【问题描述】：
不，这看起来不错。我唯一要改变的是将ip4 机制放在首位。
您没有提供实际错误报告的任何细节，但如果它误报 ~all 是一个问题，我不会感到惊讶，即使它不太可能是。我们需要查看您的 DMARC 配置来判断。
【讨论】：
也许它只是不想让你使用软故障？
如果可能，尝试将~all 更改为-all
查看 Wikipedia 中 SPF 记录的失败策略和限定符项：
https://en.wikipedia.org/wiki/Sender_Policy_Framework#FAIL_and_forwarding
https://en.wikipedia.org/wiki/Sender_Policy_Framework#Qualifiers
【讨论】：
使用 softfail (~all)，因为 hardfail 根本没有可靠地执行，并且可能以意想不到且看似随机的方式运行（托管公司或邮箱提供商突然停止或开始接受 hardfail）。
只有少数邮箱提供商仅基于 SPF 硬故障而拒绝，这是一个不断变化的目标。因此，~ALL 是最佳实践。
如果您想告诉邮箱提供商拒绝未通过 DMARC 的邮件，则 DMARC 会更可靠地拒绝。要通过 DMARC，SPF 或 DKIM 必须失败并且域对齐。在。放松模式（迄今为止最常见），对齐意味着相同的组织域，因此 example.com 与 foo.example.com 对齐。
始终以 p=none 开头，这是 DMARC 中仅报告的政策，并且仅非常谨慎地升级为更激进的 DMARC 政策，例如 p=reject 或 p=quarantine，因为它们可能会破坏如果有合法邮件未通过 DMARC，则为合法邮件。
延迟部署更激进的 DMARC 政策，直到您确定所有合法邮件都已得到处理和验证。这样，只有未经您授权的邮件或纯域欺骗电子邮件（垃圾邮件发送者和网络钓鱼者）才会通过 DMARC。
另外，请注意，许多 ESP 默认情况下让您使用自己的 donain 作为标头，并使用他们自己的域作为信封。
如果您从域请求并设置自定义邮件，您通常可以获取域的子域，设置信封 FROM (example.example.com) 和 example.com 的标头（收件人实际看到）。
如果您的信封 from 不是 example.com 本身，而是 foo.example.com，那么在您的组织域中设置 SPF 用作标头 from 将没有用。 SFP 在信封中有用，而不是来自标头 FROM。
DKIM 由来自域（通常是您的组织域，example.com）的标头签名，而 SPF 仅在信封 FROM 域（例如，foo.example.com）中相关。
另外，请记住，SPF 记录仅允许 10 个 DNS 查找有效，因此请使用几个验证工具检查以确保其为 10 或以下。您设置的上述 SPF 使用 6/10 DNS 查找并且有效。
除非您的信封来自域是 example.com，否则您在组织域中的 SPF 不会有帮助。
再说一遍~ALL 不是问题。您可以通过一些网络搜索来确认这一点，了解在 SPF 中设置软故障与硬故障的风险和好处。
一些 ESP 使用他们自己的域作为信封，这意味着您需要明确使用您的 ESP 将 foo.example.com 配置为信封，以使域与 example.com、您的组织域和 DKIM 签名域保持一致.
一个复杂的问题是，许多 ESP 使用自己的域作为您的信封来自域，并提供服务/功能，例如“自定义发送域”，使您能够使用自己域的子域作为信封来自域。鉴于最近对齐策略变得更加严格，最好使用您自己域的子域作为 Envelope From Domain 而不是 ESP 域。例如，微软最近制定了一项政策，即域错位本身导致 SPF 或 DKIM 失败，这本身就足以将电子邮件路由到垃圾邮件。其他邮箱提供商一直在采取这种措施，以试图处理域欺骗以及随之而来的网络钓鱼和垃圾邮件。
信封来自域：收件人看不到此域。 Header FROM domain：收件人可以在可见的 FROM 行中看到此内容。
【讨论】：