SPF 永久错误：DNS 查找过多

Question

我们注意到我们的很多电子邮件都被错误地标记为垃圾邮件。在网上看了一下，解决这个问题的一个好方法是在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 发送/接收电子邮件。

在Google 的 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

有谁知道问题是什么？

Answer 1

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

SPF 规范最多允许 10 个 DNS 查找。您的 SPF 记录为 17。

RFC 4408 § 10.1 – 处理限制规定：

SPF 实现必须将进行 DNS 查找的机制和修饰符的数量限制为每次 SPF 检查最多 10 个，包括由使用“包含”机制或“重定向”修饰符引起的任何查找。如果在检查过程中超过了这个数字，必须返回 PermError。“include”、“a”、“mx”、“ptr”和“exists”机制以及“重定向”修饰符不计入此限制。“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

谷歌的 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

的 SPF 记录bluehost.com太大（它的 SPF 记录本身就无法通过 Google 的 MX 测试器）：

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（+1 使用带有 IP 地址的SPF 宏）

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

危险！sparkpost.com 包含的一些ptr条目是简单伪造的（任何网络运营商都可以满足 sparkpost.com 的 SPF，这意味着他们可以满足 bluehost.com 的，因此也可以满足您自己的），从而破坏了 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，后者（基于他们的六个额外查找加上不安全的ptr条目）不知道。

由于总数为 12（13 与include:bluehost.com），因此您不能包括 Bluehhost 的 SPF。

Bluehost 自己建议的 SPF 记录（以及所有客户的默认记录）同样被破坏（有 16 次查找，包括一个容易伪造的ptr）。

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

你好，蓝主机。我在你的推特上发了这个。本节专为您准备。

Bluehost 可以使用以下 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来跳过查找，但它经常变化，看起来像快速通量。）

Bluehost 应该建议客户只包括spf2.bluehost.com所有 Bluehost 服务（假设他们参与发送邮件）。有关如何为 Bluehost 客户提供建议的信息，请参阅下一节。

Bluehost 客户的解决方案

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

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

最后一个~all（“软失败”）表示邮件收件人应该对 SPF 失败的邮件持怀疑态度，但仍然会投递。设置DMARC以找出在通往 DMARC 的道路上有效和遗漏了什么p=reject（这将阻止所有伪造的邮件）。

您必须添加您使用的任何托管电子邮件或电子邮件服务提供商，以及您想要授权代表您的域发送邮件的任何其他主机。

在这个问题的情况下，我看到一个明确的 IP 地址和谷歌托管的邮件，所以你需要：

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

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