我的理解是，SPF规范指定一个电子邮件接收者不应该做超过10个DNS查找，才能收集发件人所有允许的IP地址。 因此，如果SPFlogginginclude:foo.com include:bar.com include:baz.com ，这三个域都有SPFlogging，其中也有3个include条目，现在我们可以达到3 + 3 + 3 + 3 = 12 DNS查找。
我的理解是否正确？
我只使用2或3个服务为我的域名，我已经超过这个限制。 主要/次要电子邮件提供商是否通常（或曾经）强制执行此限制？
libspf2 （C）和Mail::SPF::Query （perl，在sendmail-spf-milter中使用 ）实现了10个DNS引起机制的限制，但后者不适用（AFAICT）限制MX或PTR。 libspf2将mx和ptr的每一个限制为10。
Mail::SPF （perl）具有10个DNS引起机制的限制，并且每个机制，每个MX和每个PTR限制10个查找。 （这两个perl包通常在MIMEDefang中使用，但不是默认的。
pyspf对所有的“查找”，MX，PTR，CNAME都有10个限制。 但在操作过程中它明确地将MAX_LOOKUPS乘以4。 除非在“严格”模式下，它也将MAX_MX和MAX_PTR乘以4。
我不能评论商业/专有实现，但上面（ pyspf除外）清楚地实现了10个DNS触发机制的上限（下面更多），但是在大多数情况下，它可以在运行时被覆盖-时间。
在你的具体情况下，你是正确的，它是12包括，超过了10的限制。我希望大多数SPF软件返回“PermError”， 但是 ，失败只会影响最终的“包含”提供商（S），因为计数将作为运行总数来计算：SPF 机制从左到右进行评估，并且检查将在通过时“提前”，因此取决于发送服务器出现在序列中的哪个位置。
解决这个问题的方法是使用不触发DNS查找的机制，例如ip4和ip6 ，然后在可能的情况下使用mx ，因为这样可以获得多达10个其他名称，每个名称可以有多个IP。
由于SPF会导致任意的DNS请求，并可能以指数级别进行扩展，所以很容易被DOS /放大攻击利用。 它有故意的低限制来防止这种情况发生：它没有按照你想要的方式扩展。
导致 DNS查询的10个机制（严格的机制+“redirect”修改器）与10个DNS查找并不完全一样。 即使“DNS查找”也是可以解释的，事先并不知道需要多less次离散查询，而且您也不知道recursionparsing器可能需要执行多less次离散查找（请参见下文）。
RFC 4408§10.1 ：
SPF实现必须将执行DNS查找的机制和修饰符的数量限制在每个SPF检查至多10次，包括使用“包含”机制或“redirect”修改器引起的任何查找。 如果在检查过程中超过这个数字，则必须返回一个PermError。 “包含”，“a”，“mx”，“ptr”和“存在”机制以及“redirect”修饰符都会计入此限制。 “全部”，“ip4”和“ip6”机制不需要DNS查找，因此不计入此限制。
[…]
在评估“mx”和“ptr”机制或％{p}macros时，必须限制不超过10个MX或PTR RR的查找和检查。
所以你最多可以使用10个触发DNS查找的机制/修饰符。 （这里的措辞很差：似乎只说明了限制的上限，确认的实施可以限制为2）
§5.4为mx机制，§5.5为ptr机制每个都有10个这种名称查找的限制，并且仅适用于该机制的处理，例如：
为了防止拒绝服务（DoS）攻击，在“mx”机制的评估过程中不得查看10个以上的MX名称（参见第10章）。
也就是说，你可能有10个mx机制，最多10个MX名字，所以每个名字可能会导致20个DNS操作（每个10个MX + 10个DNS查询）总共200个。它与ptr或％{p}类似，可以查找10个ptr机制，因此10×10个PTR，每个PTR也需要一个A查找，总共200个。
这正是2009.10testing套件检查的内容，请参阅“ 处理限制 ”testing。
每个SPF检查的客户端DNS查询操作总数没有明确规定的上限，我将其计算为210。 也有build议限制每个SPF检查的DNS数据量，虽然没有提出实际的限制。 由于SPFlogging限制在450字节（与所有其他TXTlogging共享），所以可以粗略估计，但如果您慷慨，则总数可能会超过100 KB。 这两个值都明显地对潜在的滥用开放，作为放大攻击，这正是§10.1所说的你需要避免的。
经validation据表明， 共有 10个查找机制通常在logging中实现（请查看microsoft.com的SPF，他们似乎已经花费了一些时间将其保留到10）。 很难收集太多查找失败的证据，因为强制的错误代码只是“PermError”，它涵盖了所有的问题（ DMARC报告可能有帮助）。
OpenSPF常见问题永远延续了 “10个DNS查找”的限制，而不是更精确的“10个DNS引起的机制或redirect”。 这个FAQ可以说是错的，因为它实际上是这样说的：
由于每个SPFlogging有10个DNS查询的限制，因此指定一个IP地址[…]
与RFC中对“SPF检查”操作施加限制的RFC不一致，不以这种方式限制DNS查找操作，并且明确指出SPFlogging是单个DNS文本RR。 常见问题将暗示您在处理“包含”时重新启动计数，因为这是新的SPFlogging。 真是一团糟。
什么是“DNS查询”呢？ 作为用户 。 我会考虑“ ping www.microsoft.com ”涉及一个单一的DNS“查找”：有一个名字，我希望变成一个IP。 简单？ 可悲的是，
作为一名pipe理员，我知道www.microsoft.com可能不是一个简单的具有单个IP的Alogging，它可能是一个CNAME，它需要另一个离散查找来获得Alogging，尽pipe我的上游parsing器可能会执行而不是我的桌面上的parsing器。 今天，对于我来说，www.microsoft.com是一个由3个CNAME组成的链，最终成为akamaiedge.net上的Alogging，这是（至less）4个DNS查询操作。 SPF可能会使用“ptr”机制看到CNAME，但MXlogging不应该是CNAME。
最后，作为一个DNSpipe理员，我知道回答（几乎）任何问题都涉及到许多离散的DNS操作，个别的问题和回答事务（UDP数据报） – 假设一个空的caching，recursion的parsing器需要在DNS根开始，向下： . → com → microsoft.com → www.microsoft.com询问特定types的logging（NS，A等），并处理CNAME。 您可以通过dig +trace www.microsoft.com看到这个动作，但是由于地理位置欺骗（例如这里 ），您可能不会得到完全相同的答案。 （自从TXTlogging上的SPF搭载以及DNS答案中512字节的过时限制可能意味着重试TCP上的查询，这种复杂性还有一点点。
那么SPF认为什么是查找？ 它最接近pipe理员的angular度，它需要知道每种types的DNS查询的具体情况（但不是实际需要计算单个DNS数据报或连接的点）。
正如您所指出的， RFC4408 s10.1会对DNS活动设置一些限制。 特别：
SPF实现必须将执行DNS查找的机制和修饰符的数量限制在每个SPF检查至多10次，包括使用“包含”机制或“redirect”修改器引起的任何查找。 如果在检查过程中超过这个数字，则必须返回一个PermError。 “包含”，“a”，“mx”，“ptr”和“存在”机制以及“redirect”修饰符都会计入此限制。 “全部”，“ip4”和“ip6”机制不需要DNS查找，因此不计入此限制。 “exp”修饰符不计入此限制，因为在查询SPFlogging后，发生解释string的DNS查找。
而且
在评估“mx”和“ptr”机制或％{p}macros时，必须限制不超过10个MX或PTR RR的查找和检查。
请注意，前者是机制数量的限制，而不是执行的查找次数; 但这仍然是一个限制。
据我所知，是的，这些限制相当困难。 它们的目的是阻止人们构build任意复杂的SPFlogging，并将这些logging用于DoS服务器，这些服务器通过在大型DNS查找链中停顿来检查其logging，因此实施SPF检查程序的任何人的最佳利益尊重他们。
你应该注意到，嵌套包含可能会导致这些限制的最大问题，如果你决定包含几个域，每个域都被大量使用，那么你可以很快地将它们包括在内。 find造成具体问题的人的例子并不难。
结果似乎是，当人们决定同时使用SPF 和几家截然不同的公司来处理他们的电子邮件时，通常会出现问题。 我从你的问题推断你适合那个类别。 SPF似乎不是为那些select这样做的人而devise的 。 如果你坚持这样做，你可能需要在你的DNS服务器上做一些cron工作，不断地评估你希望包含的所有SPFlogging，并将它们expression为一系列ip4:和ip6:机制（在其数量没有限制），并重新发布结果作为您的SPFlogging。
不要忘记完成-all事情，否则整个演习都毫无意义。