我的理解是，SPF 规范规定电子邮件接收方不应进行超过 10 次 DNS 查找，以收集发件人的所有允许 IP。因此，如果 SPF 记录有include:foo.com include:bar.com include:baz.com且这三个域各自有 SPF 记录，并且这些记录也有 3 个include条目，那么现在我们最多需要进行 3+3+3+3=12 次 DNS 查找。
我的上述理解正确吗？
我仅使用 2 或 3 个服务来管理我的域名，但我已经远远超出了这个限制。主要/次要电子邮件提供商是否通常会（或曾经）强制执行此限制？
答案1
两个都libspf2（C）及Mail::SPF::Query（perl，用于sendmail-spf-milter）实施 10 的限制导致 DNS 的机制，但后者（AFAICT）不适用 MX 或 PTR 限制。libspf2限制每个麦克和指针到 10 也一样。
Mail::SPF(perl) 限制 10 个 DNS 引发机制，每个机制、每个 MX 和每个 PTR 的查找次数限制为 10 次。（这两个 perl 包通常（但不是默认）用于MIME去方。
pyspf对所有内容的限制为 10：“查找”、MX、PTR、CNAME；但它在操作过程中明确将 MAX_LOOKUPS 乘以 4。除非处于“严格”模式，否则它还会将 MAX_MX 和 MAX_PTR 乘以 4。
我无法评论商业/专有实现，但上述内容（除pyspf）明确实现了 10 个 DNS 触发机制的上限（更多内容见下文），或多或少，尽管在大多数情况下它可以在运行时被覆盖。
就您的具体情况而言，您说的没错，包含 12 个，超过了 10 个的限制。我预计大多数 SPF 软件都会返回“PermError”，然而，故障只会影响最终“包含”的提供商，因为计数将按累计总数计算：SPF机制从左到右进行评估并且检查将在传递过程中“提前结束”，因此它取决于发送服务器出现的序列位置。
解决这个问题的方法是使用不触发 DNS 查找的机制，例如ip4和ip6，然后mx尽可能使用，这样可以得到最多 10 个其他名称，每个名称可以有多个 IP。
由于 SPF 会导致任意 DNS 请求，并可能呈指数级增长，因此很容易被利用进行 DOS/放大攻击。它故意将限制设得很低，以防止这种情况发生：它不会按您想要的方式扩展。
10 种机制（严格来说，机制 + “重定向”修饰符）造成不过，DNS 查找与 10 次 DNS 查找并不完全相同。即使是“DNS 查找”也是可以有多种解释的，您事先并不知道需要进行多少次离散查找，也不知道您的递归解析器可能需要执行多少次离散查找（见下文）。
SPF 实现必须将执行 DNS 查找的机制和修饰符的数量限制为每次 SPF 检查最多 10 个，包括使用“include”机制或“redirect”修饰符引起的任何查找。如果在检查期间超过此数量，则必须返回 PermError。“include”、“a”、“mx”、“ptr”和“exists”机制以及“redirect”修饰符都计入此限制。“all”、“ip4”和“ip6”机制不需要 DNS 查找，因此不计入此限制。
[...]
在评估“mx”和“ptr”机制或 %{p} 宏时，查找和检查的 MX 或 PTR RR 必须限制为不超过 10 个。
因此，您最多可以使用 10 个触发 DNS 查找的机制/修饰符。（这里的措辞很差：它似乎只说明了限制的上限，确认的实现可能限制为 2。）
§5.4麦克机制，以及第 5.5 节指针每个机制对该类型名称的查找限制为 10 次，并且仅适用于该机制的处理，例如：
为了防止拒绝服务 (DoS) 攻击，在评估“mx”机制期间不得查找超过 10 个 MX 名称（请参阅第 10 节）。
例如，您可能有 10 个 mx 机制，最多有 10 个 MX 名称，因此每个机制都可能导致 20 个 DNS 操作（每个 10 个 MX + 10 个 A DNS 查找），总共 200 个。对于指针或者%{p}，你可以查找 10指针机制，因此有 10x10 个 PTR，每个 PTR 还需要进行 A 查找，总共 200 个。
这正是2009.10 测试套件检查，参见“处理限制“测试。
没有明确规定上限全部的每次 SPF 检查的客户端 DNS 查找操作数，我隐式计算为 210，大概如此。还有建议限制每次 SPF 检查的 DNS 数据量，但没有实际限制。您可以得到一个粗略的估计，因为 SPF 记录限制为 450 字节（遗憾的是与所有其他 TXT 记录共享），但如果您慷慨的话，总数可能会超过 100kiB。这两个值显然都可能被滥用为放大攻击，这正是 §10.1 所说的您需要避免的。
经验证据表明全部的记录中通常实现 10 次查找机制（查看 microsoft.com 的 SPF，他们似乎已经尽力将其保持在 10 次）。很难收集查找次数过多失败的证据，因为强制错误代码只是“PermError”，它涵盖了所有类型的问题（DMARC报告可能会有所帮助）。
OpenSPF 常见问题解答延续极限总共“10 次 DNS 查询”，而不是更精确的“10 次 DNS 导致机制或重定向”。此常见问题解答可能是错误的，因为它实际上说：
由于每个 SPF 记录的 DNS 查找限制为 10 次，因此指定 IP 地址 [...]
这与 RFC 对“SPF 检查”操作施加限制的规定不一致，不以这种方式限制 DNS 查找操作，并明确指出SPF 记录是单个 DNS 文本 RR。常见问题解答暗示您在处理“包含”时重新开始计数，因为这是一条新的 SPF 记录。真是一团糟。
DNS 查找
“DNS 查询”到底是什么？用户。我认为“ ping www.microsoft.com”只涉及一次 DNS“查找”：我希望将一个名称转换为一个 IP。简单吗？可惜不是。
作为行政人员我知道www.microsoft.com可能不是具有单个 IP 的简单 A 记录，而可能是 CNAME，反过来需要另一个离散查找才能获得 A 记录，尽管我的上游解析器可能会执行此操作，而不是我的桌面上的解析器。今天，对我来说，www.microsoft.com是 3 个 CNAME 的链，最终成为 akamaiedge.net 上的 A 记录，对于某些人来说，这 (至少) 是 4 个 DNS 查询操作。SPF 可能会使用“ptr”机制查看 CNAME，但 MX 记录不应是 CNAME。
最后，作为DNS 管理员我知道回答（几乎）任何问题都涉及许多离散的 DNS 操作、单独的问题和答案事务（UDP 数据报）——假设缓存为空，递归解析器需要从 DNS 根开始并向下工作：. → com→ microsoft.com→www.microsoft.com根据需要请求特定类型的记录（NS、A 等），并处理 CNAME。您可以在 中看到这一点dig +trace www.microsoft.com，但由于地理位置欺骗，您可能不会得到完全相同的答案（示例这里） （由于 SPF 搭载在 TXT 记录上，并且 DNS 答案的 512 字节的过时限制可能意味着需要通过 TCP 重试查询，因此这种复杂性还会进一步增加。）
那么 SPF 将什么视为查询？它实际上最接近于行政人员从某种角度来看，它需要了解每种类型的 DNS 查询的具体情况（但还不需要真正计算单个 DNS 数据报或连接的数量）。
答案2
RFC4408 s10.1正如您所指出的，确实对 DNS 活动施加了一些限制。具体来说：
SPF 实现必须将执行 DNS 查找的机制和修饰符的数量限制为每次 SPF 检查最多 10 个，包括使用“include”机制或“redirect”修饰符引起的任何查找。如果在检查期间超过此数量，则必须返回 PermError。“include”、“a”、“mx”、“ptr”和“exists”机制以及“redirect”修饰符都计入此限制。“all”、“ip4”和“ip6”机制不需要 DNS 查找，因此不计入此限制。“exp”修饰符不计入此限制，因为 DNS 查找以获取解释字符串发生在评估 SPF 记录之后。
此外
在评估“mx”和“ptr”机制或 %{p} 宏时，查找和检查的 MX 或 PTR RR 必须限制为不超过 10 个。
注意前者是机制，而不是执行的查找次数；但这仍然是一个限制。
据我所知，这些限制确实执行得相当严格。它们旨在阻止人们构建任意复杂的 SPF 记录，并利用这些记录对检查其记录的服务器发起 DoS 攻击，方法是在庞大的 DNS 查找链中让服务器陷入瘫痪，因此，对于实施 SPF 检查器的任何人来说，遵守这些限制都是最有利的。
您说得对，嵌套包含很可能是这些限制的最大问题，如果您决定包含多个域，而每个域都大量使用包含，那么您可以相当快地解决它们。这并不难找到这给他们带来了具体问题的例子。
结果似乎是，问题通常出现在人们决定使用两个都防晒指数
和几家截然不同的公司来处理外发电子邮件。从你的问题中我推断你属于这一类。 SPF 似乎并不是为那些选择这样做的人而设计的。如果您坚持这样做，则可能需要在 DNS 服务器上执行某种 cron 作业，以不断评估您希望包含的所有 SPF 记录，将它们表示为一系列ip4:和ip6:机制（其数量没有限制），并将结果重新发布为您的 SPF 记录。
不要忘记以 来结束-all，否则整个练习就毫无意义了。