两个libspf2（C）和Mail::SPF::Query（Perl中，在所使用的sendmail-SPF-雄鱼）实现的10的限制DNS-引起机制，但后者不（AFAICT）应用MX或PTR限制。还将mx和ptr都libspf2限制为10。
Mail::SPF（perl）最多可以有10个DNS引起机制，每个MX和每个PTR最多可以有10个查询机制。（这两个perl软件包通常（但不是默认情况）在MIMEDefang中使用。）
pyspf下列所有内容的上限为10：“查找”，MX，PTR，CNAME；但是在操作过程中，它明确将MAX_LOOKUPS乘以4。除非在“严格”模式下，否则它还将MAX_MX和MAX_PTR乘以4。
我无法评论商业/专有实现，但以上（除外pyspf）明确实现了10个DNS触发机制（下文中将进一步介绍）的上限，即给予或接受，尽管在大多数情况下，它可以在运行时被覆盖-时间。
在您的特定情况下，您是正确的，它是12个include，并且超过了10个限制。我希望大多数SPF软件都返回“ PermError”，但是，失败只会影响最终的“ included”提供者，因为计数将被计算为运行总计：SPF 机制从左到右进行评估，并且检查将在通过时“尽早”进行，因此这取决于发送服务器出现的顺序。
解决此问题的方法是使用不会触发DNS查找的机制，例如ip4和ip6，然后mx尽可能使用，因为这样可以使您获得多达10个其他名称，每个名称可以具有多个IP。
由于SPF会导致任意DNS请求具有潜在的指数缩放比例，因此很容易将其用于DOS /放大攻击。它故意有较低的限制来防止这种情况：它无法按您想要的方式扩展。
但是，导致 DNS查找的10种机制（严格来说是机制+“重定向”修饰符）与10种DNS查找并不完全相同。即使“ DNS查找”是可以解释的，您也不预先知道需要多少离散查找，也不知道您的递归解析器可能需要执行多少离散查找（请参阅下文）。
RFC 4408§10.1：
SPF实现必须将进行DNS查找的机制和修饰符的数量限制为每次SPF检查最多10个，包括由使用“包含”机制或“重定向”修饰符引起的任何查找。如果在检查过程中超过了此数目，则必须返回PermError。“ include”，“ a”，“ mx”，“ ptr”和“ exists”机制以及“ redirect”修饰符均计入此限制。“ all”，“ ip4”和“ ip6”机制不需要DNS查找，因此不计入此限制。
[...]
在评估“ mx”和“ ptr”机制或％{p}宏时，查找和检查的MX或PTR RR不得超过10个限制。
因此，您最多可以使用10个机制/修饰符来触发DNS查找。（这里的措词很差：它似乎仅说明了限制的上限，一个确认的实现可能有2个限制。）
对于mx机制的第5.4节和对ptr机制的第5.5节，每个具有该名称的查找限制为10次，并且仅适用于该机制的处理，例如：
为了防止拒绝服务（DoS）攻击，在评估“ mx”机制时，不得查找超过10个MX名称（请参阅第10节）。
也就是说，您可能有10个mx机制，最多包含10个MX名称，因此每种名称都可能导致20个DNS操作（每个10 MX + 10个DNS查找），总共200个。对于ptr或％{p}来说，可以查找10个ptr机制，因此查找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 FAQ 永久限制了“ 10个DNS查找”的总数，而不是更精确的“ 10个DNS引起机制或重定向”。该FAQ可以说是错误的，因为它实际上说：
由于每个SPF记录最多可以有10个DNS查找，因此指定IP地址[...]
与RFC不一致的RFC限制了“ SPF检查”操作，不以这种方式限制DNS查找操作，并且清楚地指出SPF记录是单个DNS文本RR。FAQ暗示您在处理“包括”时重新启动计数，因为这是一条新的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，尽管由于地理位置的欺骗性，您可能无法获得完全相同的答案（此处示例）。（由于TXT记录上的SPF附带，并且DNS答案上的512字节已过时的限制可能意味着通过TCP重试查询，因此这种复杂性还要高得多。）
那么SPF会将其视为查找内容吗？它实际上是最接近管理员的角度，它需要了解每种类型的DNS查询的细节（而不是实际需要计算单个DNS数据报或连接的程度）。