问SPF永久错误: DNS查找过多

EN

"SPF永久错误: DNS查找次数过多“是一个非常具体的问题。您的记录太大，SPF检查器将拒绝执行足够的DNS查询来确定某些内容是否通过了SPF。

规范最多允许10次DNS查找。你的SPF记录是17.

RFC 4408 § 10.1 – Processing Limits声明：

DNS实现必须将执行

查找的机制和修饰符的数量限制为每次SPF检查最多10个，包括使用"include“机制或"redirect”修饰符引起的任何查找。如果在检查过程中超过此数字，则必须返回PermError。"include“、"a”、"mx“、"ptr”和"exists“机制以及"redirect”修饰符都不计入此限制。"all“、"ip4”和"ip6“机制不需要DNS查找，因此不计入此限制。"exp“修饰符不计入此限制，因为获取解释字符串的DNS查找发生在对SPF记录进行评估之后。

在遍历including之前，您的SPF记录有四次查找，包括您的a和mx

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

谷歌的SPF

Google对其支持的三个CIDR集合有三个DNS查找：

_spf.google.com (+3次查找)

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记录太大(其SPF记录fails Google's MX tester本身)：

bluehost.com (在进一步遍历之前进行5次查找)

v=spf1 include:spf2.bluehost.com include:_spf.qualtrics.com
  include:_spf.google.com include:_spf.salesforce.com
  include:sparkpostmail.com -all

spf2.bluehost.com (+0)

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 -all

_spf.qualtrics.com (+0)

v=spf1 ip4:139.60.152.0/22 ip4:162.247.216.0/22 ip4:54.186.193.102/32
  ip4:52.222.73.120/32 ip4:52.222.73.83/32 ip4:52.222.62.51/32
  ip4:52.222.75.85/32 ?all

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

_spf.salesforce.com (使用带有IP地址的SPF macro +1)

v=spf1 exists:%{i}._spf.mta.salesforce.com -all

sparkpostmail.com是一个重定向，然后是另一个exists宏和一堆指针(+6，哇)

v=spf1 redirect=_spf.sparkpostmail.com
v=spf1 exists:%{i}._spf.sparkpostmail.com include:_netblocks.sparkpostmail.com
  ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all

​

Danger! sparkpost.com inclusion引入了一些ptr条目，这些条目是简单伪造的(任何网络运营商都可以满足Sparkpost.com的SPF值，这意味着他们可以满足Bluehost.com的SPF值，因此也可以满足您自己的SPF值)，从而击败了SPF值的防伪设计。

_netblocks.sparkpostmail.com被前一个记录(+0)拉入

v=spf1 ip4:147.253.208.0/20 ip4:192.174.80.0/20 ~all

Bluehost曾经使用SendGrid，它实际上知道自己在做什么(他们的SPF记录没有额外的查找)，但显然他们已经用SendGrid交换了SparkPost，后者(基于他们的6个额外的查找加上不安全的ptr条目)没有。

由于总数为12 (使用include:bluehost.com时为13)，您不能包括Bluehhost SPF.

Bluehost's own suggested SPF record (以及它对所有客户的默认设置)也同样被破坏(有16次查找，包括一个容易伪造的ptr)。

Bluehost的解决方案:经过修剪且更安全的SPF记录

你好，蓝星。I 。这一节只为你而设。

Bluehost可以用以下SPF记录替换当前的SPF记录来修复此问题：

bluehost.com (7)

v=spf1 a include:spf2.bluehost.com include:_spf.google.com
  include:_netblocks.sparkpostmail.com ~all

但请注意，我不得不将include:sparkpostmail.com (7 +6= 13，太大，加上包括危险的ptr记录)降级为仅其网络块(7 +0≤10)。Bluehost需要对SparkPost大喊大叫，或者回到SendGrid。spf2.bluehost.com与其当前状态没有变化，应该是Bluehost客户唯一需要的包。

(我会使用A记录的IP来跳过查找，但是它经常更改，所以看起来像fast flux。)

Bluehost应该建议客户在所有Bluehost服务中只包含spf2.bluehost.com (假设他们参与发送邮件)。有关如何建议Bluehost客户的信息，请参阅下一节。

面向Bluehost客户的解决方案

如上一节所述，从这个基础开始(3次查找)：

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

最后的SPF值(“软故障”)表示邮件收件人应该对-yet仍然传递的邮件持怀疑态度。设置DMARC来找出在通往DMARC p=reject的道路上哪些是有效的，哪些是遗漏的(它将阻止所有伪造邮件)。

您必须添加您使用的任何托管电子邮件或Email Service Provider，以及您希望授权代表您的域发送邮件的任何其他主机。

在这个问题中，我看到了一个明确的IP地址和Google的托管邮件，因此您需要：

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

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