Email SPF记录不安全配置

v=spf1 include:spf.falconide.com include:sendgrid.net include:_spf.google.com ip4:xx.xxx.xxx.x~所有

上面是我的域的SPF记录，我正在使用一个外部工具获取开源威胁情报，在这个工具中它说我的SPF配置不安全。目前无法获得支持

---

配置有什么不安全的地方吗？

没有，这看起来没问题。我唯一想改变的是首先使用

ip4

机制

---

您没有提供实际错误报告的任何细节，但如果它将thé

~all

误报为一个问题，我也不会感到惊讶，尽管这不太可能。我们需要查看您的DMARC配置才能知道。

也许它只是不希望您使用软故障？
如果可能，尝试将

~all

更改为

-all

检查维基百科中SPF记录的失败策略和限定项：

使用softfail（~all），因为hardfail根本无法可靠实施，并且可能以意外和看似随机的方式（突然主机公司或邮箱提供商停止或开始接受hardfails）

只有少数邮箱提供商仅基于SPF硬失败而拒绝，这是一个移动目标。因此，~ALL是一种最佳做法

如果您想告诉邮箱提供商拒绝未通过DMARC的邮件，则DMARC可以更可靠地拒绝。要通过DMARC，SPF或DKIM必须失败，并且域必须对齐。在里面放松模式（目前最常见），对齐意味着相同的组织域，因此example.com与foo.example.com对齐

始终从DMARC中的

p=none

（仅报告）策略开始，并且只需非常谨慎地逐步升级到更激进的DMARC策略，例如

p=reject

或

p=quantial

，因为如果有合法邮件未通过DMARC，它们可以中断合法邮件

延迟部署更具攻击性的DMARC策略，直到您确定所有合法邮件都已被记录并验证。这样，只有未经您授权的邮件或纯粹的域欺骗电子邮件（垃圾邮件发送者和钓鱼者）才会导致DMARC失败

另外，请注意，默认情况下，许多ESP都让您使用自己的donain作为发件人的标头，并使用自己的域作为发件人的信封

如果您从域请求并设置自定义邮件，您通常可以从域的子域设置信封（example.example.com），从example.com设置邮件头（收件人实际看到的）

如果您的信封from不是example.com本身，而是foo.example.com，那么在您的组织域中设置SPF作为来自的标题将不会有用。SFP在信封中有用，而不是在标题中有用

DKIM由域（通常是您的组织域，example.com）的头签名，SPF仅与域（例如foo.example.com）的信封相关

另外，请记住，SPF记录只允许10个DNS查找有效，因此请使用两个验证工具进行检查，以确保其为10或10以下。您设置的上述SPF使用6/10 DNS查找，并且是有效的

您在组织域中拥有的SPF不会有任何帮助，除非您来自域的信封是example.com

再说一遍，一切都不是问题。您可以通过在SPF中搜索设置软失败与硬失败的风险和好处来确认这一点

一些ESP使用其自己的域作为来自的信封，这意味着您需要明确地与ESP合作，将foo.example.com配置为来自的信封，以便与example.com、您的组织域和DKIM签名域保持域一致

一个复杂的情况是，许多ESP使用自己的域作为来自域的信封，并提供诸如“自定义发送域”之类的服务/功能，使您能够使用自己域的子域作为来自域的信封。考虑到最近对齐策略变得更加严格，最好使用您自己域的子域作为域的封套，而不是ESP域。例如，微软最近颁布了一项政策，根据该政策，域错误对齐本身就足以导致SPF或DKIM失败，从而将电子邮件路由到垃圾邮件。其他邮箱提供商一直在采取这种措施，试图控制域欺骗以及随之而来的网络钓鱼和垃圾邮件

来自域的信封：收件人看不到此域。 域中的标题：收件人可以在“可见发件人”行中看到此标题