SPF永久错误：DNS查找过多

时间：2018-08-01 22:19:04

标签： email spf

我们注意到，许多电子邮件被错误地标记为垃圾邮件。在线阅读后，解决此问题的一种好方法似乎是在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是我们来自蓝色主机的VPS IP地址， 和_spf.google.com是必需的，因为我们使用GMail发送/接收电子邮件。

在Google's MX tester上进行测试后，我们收到以下错误：

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

有人知道这个问题是什么吗？

3 个答案:

答案 0 :(得分：1)

最明显的问题是IP地址前导0，这使其无效。一个小问题是，将字面IP放在首位被认为是最佳实践，因为接收者评估它们的速度更快。试试看：

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

我建议不要使用Google的检查器，而建议使用Scott Kitterman's site，它更准确（Scott是SPF规范的作者之一），并发现了这个确切的问题。

答案 1 :(得分：1)

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

SPF规范最多允许10个DNS查找。您的SPF记录中包含12。

RFC 4408 § 10.1 – Processing Limits状态：

  

SPF实现必须限制机制和修改器的数量     每个SPF检查最多进行10次DNS查找，包括     使用“包含”机制或     “重定向”修饰符。如果在检查期间超过了此数字，则     必须返回PermError。 “ include”，“ a”，“ mx”，“ ptr”和     “存在”机制以及“重定向”修饰符确实起作用     超过这个极限。 “ all”，“ 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

Google的SPF

Google为其祝福的三个CIDR集合进行了三个DNS查找：

_spf.google.com 

v=spf1 include:_netblocks.google.com include:_netblocks2.google.com
  include:_netblocks3.google.com ~all

_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

_netblocks2.google.com 

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

_netblocks3.google.com 

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"

Bluehost的SPF

bluehost.com的SPF记录非常大，在进一步遍历之前需要进行五次查找：

v=spf1 ip4:66.147.240.0/20 ip4:69.89.16.0/20 ip4:74.220.192.0/19
  ip4:67.222.32.0/19 ip4:70.40.192.0/19 ip4:67.20.64.0/18
  ip4:173.254.0.0/17 ip4:50.87.0.0/16 ip4:69.195.64.0/18 a mx ptr
  include:spf2.bluehost.com include:sendgrid.net ~all

Bluehost太大了，以至于他们有了第二条SPF记录，尽管它也表明他们并不真正知道自己在做什么，因为它具有ptr项（表示任何网络操作员可以成功伪造它们）和对SendGrid的冗余引用（不花任何费用），再添加一个查找：

v=spf1 ip6:2605:DC00::/32 include:_spf.google.com include:sendgrid.net ~all

这包括Google和Sendgrid，它们都很大，但是他们也很清楚DNS查找限制，因此在这方面很小。 Google有3个（如上所述），多余的条目不算作您），SendGrid的记录为零：

v=spf1 ip4:167.89.0.0/17 ip4:208.117.48.0/20 ip4:50.31.32.0/19 ip4:198.37.144.0/20
  ip4:198.21.0.0/21 ip4:192.254.112.0/20 ip4:168.245.0.0/17 ip4:149.72.0.0/16 ~all

由于总数为9，并将其包含在另一个SPF记录中，因此总数为10，
当前，如果它是唯一的DNS查找，则只能包括Bluehhost的SPF。

Bluehost's own suggested SPF record（以及所有客户的默认设置）类似地被破坏（使用14个查询）。

解决方案：更好的Bluehost SPF记录

您好，Bluehost。我tweeted this at you。本部分仅适合您。

Bluehost可以使用以下SPF记录代替其当前记录来解决此问题：

bluehost.com 

v=spf1 a include:_spf.bluehost.com include:_spf.google.com
  include:sendgrid.net ~all

_spf.bluehost.com 

v=spf1 ip4:66.147.240.0/20 ip4:69.89.16.0/20 ip4:74.220.192.0/19
  ip4:67.222.32.0/19 ip4:70.40.192.0/19 ip4:67.20.64.0/18 ip4:173.254.0.0/17
  ip4:50.87.0.0/16 ip4:69.195.64.0/18 ip6:2605:DC00::/32 ~all

这不包括危险的ptr条目。由于他们的MX记录全都在Google记录中，因此Google SPF收录内容涵盖了这些记录。 （我将为A记录添加IP，但是它变化得如此频繁，以至于看起来像fast flux。）现在，该替换记录不再包含9个查询，而是包含6个，并且客户包括_spf。 bluehost.com仅为包含内容本身添加一个。

所有这些都适合一个SPF记录，但是拥有两个SPF记录可以使Bluehost客户获得更多的保护，因为他们不一定需要祝福Bluehost的A或MX记录，当然也不必除非他们也是SendGrid客户，否则还需要包括SendGrid。

这样，Bluehost可能会建议客户像这样添加_spf.bluehost.com（3个查询）：

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

解决方法：本地Bluehost SPF记录

直到Bluehost共同行动，在您自己的域中创建辅助TXT记录（如果您是example.com，请创建此_spf.bluehost.example.com），并将_spf.bluehost.com的上述值用于其内容，然后将其包含在您自己的SPF记录中，如下所示：

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

您的DNS查找总数现在为7，因此您的SPF有效。

  

⚠警告：如果您手动创建本地Bluehost SPF记录，请确保在Bluehost更新其列表时对其进行更新！这仅在2018年12月13日正确。

答案 2 :(得分：0)

“ SPF永久错误：DNS查找过多”是SPF永久错误的常见类型。当您的SPF记录中有10个以上的DNS查找时，就会发生这种情况。

SPF施加10-DNS查找限制以减轻DDoS攻击。

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

但是，如果您的SPF记录确实超出了限制，则SPF身份验证会返回上述永久错误，而该错误又会（在DMARC或其他方式）解释为失败。这意味着电子邮件可能无法通过身份验证，并被移至垃圾邮件文件夹。如果不采取进一步措施，将会对您的电子邮件的可传递性产生负面影响。

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

有关此的更多信息，请查看这篇文章：Why SPF Authentication Fails

相关问题
最新问题