Email SPF永久性错误：DNS查找过多

我们注意到，我们的许多电子邮件被错误地标记为垃圾邮件。在线阅读后，解决此问题的一个好方法似乎是在DNS中添加一个SPF记录，因此我们添加了一个包含以下内容的TXT记录：

v=spf1 a mx ip4:162.123.189.010 include:_spf.google.com include:bluehost.com ~all

Bluehost是我们的主机提供商， 162.123.189.010是我们来自blue host的VPS IP地址， 而且_spf.google.com是必需的，因为我们使用GMail收发电子邮件

在上运行测试后，出现以下错误：

The SPF string can not be parsed, do you have any typos in it?
Decision    permanent error in processing
Explanation SPF Permanent Error: Too many DNS lookups
Record  v=spf1 a mx ip4:162.123.189.010 include:_spf.google.com include:bluehost.com ~all

---

有人知道问题是什么吗？

最明显的问题是IP地址中的

0

，这使得它无效。一个小问题是，将文字IP放在第一位被认为是最佳实践，因为对于接收者来说，文字IP的评估速度更快。尝试一下：

v=spf1 ip4:162.123.189.10 a mx include:_spf.google.com include:bluehost.com ~all

我建议不要使用google的checker，它更可能准确（Scott是SPF规范的作者之一），并发现了这个确切的问题。

“SPF永久性错误：DNS查找太多”是一个非常具体的问题。您的记录太大，SPF检查器将拒绝执行足够的DNS查询以确定是否有内容通过了SPF

SPF规范最多允许10次DNS查找。您的SPF记录有17条。

国家：

SPF实现必须限制机制和修改器的数量 每个SPF检查最多进行10次DNS查找，包括任何 使用“包含”机制或 “重定向”修饰符。如果在检查过程中超过此数字，则 必须返回PermError。“包括”、“a”、“mx”、“ptr”和 “存在”机制以及“重定向”修饰符不计数 反对这个限制。“所有”、“ip4”和“ip6”机制不适用 需要DNS查找，因此不计入此限制。 “exp”修饰符不计入此限制，因为DNS 查找以获取解释字符串发生在SPF记录之后 已经过评估

在遍历包含项之前，您的SPF记录有四次查找，包括

a

和

mx

：

v=spf1 a mx ip4:162.123.189.010 include:_spf.google.com include:bluehost.com ~all

谷歌的SPF 谷歌有三个DNS查找它所祝福的三个CIDR集合：

_spf.google.com（+3次查找）

_netblocks.google.com

v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19
  ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16
  ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17
  ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all

v=spf1 ip6:2001:4860:4000::/36
  ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36
  ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all

v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20
  ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19
  ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

_netblocks2.google.com

v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19
  ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16
  ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17
  ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all

v=spf1 ip6:2001:4860:4000::/36
  ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36
  ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all

v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20
  ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19
  ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

_netblocks3.google.com

v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19
  ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16
  ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17
  ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all

v=spf1 ip6:2001:4860:4000::/36
  ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36
  ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all

v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20
  ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19
  ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

蓝主机的SPF

bluehost.com

的SPF记录太大（其自身的SPF记录）：

bluehost.com（进一步遍历前进行5次查找）

spf2.bluehost.com（+0）

_spf.qualtrics.com（+0）

（参见上面的_spf.google.com的+3查找，尽管冗余查找不会添加到您的总数中）

_spf.salesforce.com（+1使用具有IP地址的）

sparkpostmail.com是一个重定向，然后存在另一个

宏和一堆指针（+6，哇）

危险sparkpost.com包含了一些
ptr
条目，这些条目是伪造的（任何网络运营商都可以满足sparkpost.com的SPF，这意味着他们可以满足bluehost.com的SPF，因此也可以满足您自己的SPF），从而击败了SPF的防伪设计

_netblocks.sparkpostmail.com被上一条记录（+0）拉入

Bluehost曾经使用过，谁知道他们在做什么（他们的SPF记录没有额外的查找），但显然他们用SendGrid交换了SparkPost，而SparkPost（基于他们的六个额外查找加上不安全的
ptr
条目）没有

由于总数为12（包括：bluehost.com在内的13个），因此不能包括Bluehhost的SPF。

（以及所有客户的默认设置）也同样被破坏（有16个查找，包括一个容易伪造的
ptr
）

Bluehost解决方案：一个修剪过的、更安全的SPF记录
“SPF永久性错误：DNS查找过多”是一种常见的SPF永久性错误。当您的SPF记录中有超过10个DNS查找时，就会发生这种情况

SPF施加10个DNS查找限制以缓解DDoS攻击

您可以使用任何在线工具检查您的SPF记录，并确保其不超过该限制

但是，如果您的SPF记录确实超出了限制，SPF身份验证将返回上面提到的永久性错误，该错误将被解释为失败（在DMARC或其他方式中）。这意味着电子邮件可能无法通过身份验证并被移动到垃圾邮件文件夹。如果没有采取进一步的行动，这将对您的电子邮件交付产生负面影响

要解决DNS查找过多的问题，可以使用DMARCLY的Safe SPF之类的服务
自动“展平”SPF记录的功能，使其永远不会超过限制

有关这方面的更多信息，请查看这篇文章：
该链接没有正确验证，尽管它是作者。如果你查找bluehost.com本身，它会因为DNS查找太多而失败（就像谷歌的工具无法查找bluehost.com一样）。如果您在这个答案中使用建议的记录查找example.com，它会通过，即使它不应该通过，因为通过包括bluehost.com记录，它显然有更多的查找。当给出这个答案时，这一点就不那么清楚了（当时，bluehost.com记录本身总共有九次查找，因此是有效的，但这里的记录加了五次，9+5>10。请参见我的答案。）
v=spf1 ip4:147.253.208.0/20 ip4:192.174.80.0/20 ~all