“SPF 永久错误：DNS 查找过多”是一个非常具体的问题。您的记录太大，SPF 检查程序将拒绝执行足够多的 DNS 查询来确定某些内容是否通过了 SPF。
SPF 规范最多允许 10 次 DNS 查找。您的 SPF 记录有 17 个。
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（+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（+1 使用带有 IP 地址的 SPF macro）
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，后者（基于他们的六个额外查找加上不安全的 @ 987654347@ 个条目）没有。
由于总数为 12（include:bluehost.com 为 13），您不能包含 Bluehhost 的 SPF。
Bluehost's own suggested SPF record（以及所有客户的默认设置）同样被破坏（有 16 次查找，包括一个容易伪造的 ptr）。
Bluehost 解决方案：精简且更安全的 SPF 记录
? 你好，Bluehost。我tweeted this at you。本部分仅供您参考。
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 来跳过查找，但它经常更改，看起来像 fast flux。）
Bluehost 应该建议客户只为所有 Bluehost 服务添加spf2.bluehost.com（假设他们参与发送邮件）。请参阅下一节，了解如何为 Bluehost 客户提供建议。
Bluehost 客户解决方案
如上一节所述，从这个基础开始（3 次查找）：
v=spf1 a mx include:spf2.bluehost.com ~all
最后的~all（“软故障”）表明邮件收件人应该对未通过 SPF 的邮件稍有怀疑——但仍会投递。设置DMARC 以找出在通往 DMARC p=reject 的路上哪些有效，哪些遗漏（这将阻止所有伪造邮件）。
您必须添加您使用的任何托管电子邮件或Email Service Provider(s)，以及您想要授权代表您的域发送邮件的任何其他主机。
在这个问题的情况下，我看到了一个明确的 IP 地址和 Google 托管的邮件，所以你需要：
v=spf1 ip4:162.123.189.10 a mx include:spf2.bluehost.com
include:_spf.google.com ~all
您的 DNS 查询总数现在为 7，因此您的 SPF 有效。