什么是自动/动态 SPF 记录压平及其如何修复 SPF PermError: Too Many DNS Lookups 问题

当 SPF PermError: Too Many DNS Lookups问题出现的时候，由于 SPF 失败的原因，邮件抵达率会受到负面影响。我们将说明自动/动态 SPF 记录压平技术如何能够解决该问题。

越来越多的服务被用来跑在线业务，比如营销，销售，客服，人力资源等。结果是您需要把诸如 SendGrid, Mailchimp, Zendesk 等服务添加到您的 SPF 记录中。

但是迟早您会发现 SPF PermError: Too Many DNS Lookups 问题，因为您在 SPF 记录中包括了太多服务，以至于该 SPF 记录现在总共需要消耗超过 10 个 DNS 查询。

SPF 记录是层次化的

当需要授权第三方服务来为您的组织发送邮件的时候，只需要用 include 来把该服务包含到您的 SPF 记录中。比如，如果您需要用 Google 来投递邮件的话，把 Google 添加到您的 SPF 记录中：

v=spf1 include:_spf.google.com -all

从现在起，您的发自 Google 主机的邮件将会通过 SPF 验证，甚至在 Google 对 _spf.google.com 进行改动的情况下(比如添加更多的 IP 地址)。这些改动对您来说是透明的。

换句话说，SPF 用 include 机制把底层的改变隐藏起来了。

SPF 记录的层次化允许您使用第三方的服务，您只需要把该服务的 SPF 包括进来。当第三方服务的 SPF 记录变动时，您无需改动您的 SPF 记录。

但是需要注意一些问题。对于一些对 SPF 不是太熟悉的用户来说，添加下面看起来很简单的服务看起来一点问题也没有：

v=spf1 include:bluehost.com -all

这看起来像是一个完全有效的 SPF 记录，因此您的邮件将会正常通过 SPF 验证，对吧？

问题是，对 bluehost.com进行简单的检查您会发现该服务实际上消耗 11 次 DNS 查询。

换句话说，光是把该服务加入到您的 SPF 记录中就已经违反了 SPF 记录最多只能够消耗 10 次 DNS 查询的规定！

这是因为该服务包含其他的服务，包括：qualtrics.com，google.com，salesforce.com，sparkpostmail.com，以及 mailjet.com；并且这些服务还可以包含其他的服务，使得您的 SPF 记录消耗更多的 DNS 查询。

毫无疑问，这是一条"重量级的" SPF 记录。但在现实里，像这样包含其他第三方服务的 SPF 记录并不少见。

SPF 验证通过遍历 SPF 记录代表的层次化的树，并且检查树上是否有节点匹配连接主机的 IP 地址。如果节点是 a，mx，include，ptr，exists，和 redirect 其中之一，那么 DNS 查询次数加 1。

在验证过程中，如果 DNS 查询次数超过 10，该过程终止，并且 SPF 返回 SPF PermError: Too Many DNS Lookups。

SPF 记录压平

正如它的名字所暗示的那样，SPF 记录压平是一个把 SPF 记录中的层次压平的过程。这样使得压平后的 SPF 记录消耗少于 10 次 DNS 查询。这个过程有时也叫 SPF 记录压缩或者 SPF 记录优化。

这个过程遍历 SPF 记录中的树，并且把每一个节点翻译成一个或者多个 IP 地址，然后用这些 IP 地址创建一个新的 SPF 记录。

例如，如果记录中碰到 a的话， SPF 记录压平过程会查询指定主机的 IP 地址，然后将其加到列表当中。

例如，如果记录中碰到 mx的话， SPF 记录压平过程会查询指定主机的所有邮件服务器的 IP 地址，然后将其加到列表当中。

例如，如果记录中碰到 include的话， SPF 记录压平过程会调用一个递归的函数来压缩包含的子 SPF 记录。

如果碰到 ip4或者 ip6的话，直接拷贝到列表当中，因为它们并不消耗任何 DNS 查询。

https://dmarcly.com/blog/what-is-automatic-dynamic-spf-record-flattening-and-how-it-fixes-the-spf-permerror-too-many-dns-lookups-issue

自动/动态 SPF 记录压平

SPF 记录压平本身能工作得很好。但是，缺省状态下它是静态的。这意味着每次当一个第三方服务发生变动的时候，您需要重新执行这个过程，并且手动更新 DNS 中的记录。这种情况会频繁地发生，并且手动压平 SPF 记录相当乏味，更新 DNS 也容易出错。

幸好 SPF 记录压平过程是可以自动化的。自动化的 SPF 记录压平过程叫自动的 SPF 记录压平或者动态 SPF 记录压平。名称中的"动态"源自：任何第三方服务的变动都会反映在最终的 SPF 记录中。

DMARCLY 的 Safe SPF 功能实现了自动/动态 SPF 记录压平，并且设置只需花上几分钟。一旦设置好，您再也不需要担心出现 SPF 的 10+ DNS 查询问题了，也不需要手动更新 DNS 设置！

要使用 Safe SPF，登录到 DMARCLY 的控制面板，然后跳转到 DNS Records -> Safe SPF，再遵循 Safe SPF 向导在域名上设置自动/动态 SPF 记录压平。

如果您还没有 DMARCLY 帐号，您可以注册一个以获得 14 天的免费试用。

使用 Safe SPF 来解决 SPF PermError: Too Many DNS Lookups 问题。

自动/动态 SPF 记录压平如何解决 SPF PermError Too Many DNS Lookups 问题

考虑一下 SPF 验证如何在新的 Safe SPF 记录下工作。当一封新的邮件到达接收服务器时，服务器发现邮件的 return-path 域是 company.com。

接下来服务器查询位于 company.com 上的 SPF 记录。该记录有以下性质：

• 包含和原来的 SPF 记录相同的 IP 地址；
• 消耗少于 10 次 DNS 查询。

现在对于每一个在 Safe SPF 记录中的 IP 地址，SPF 检查连接主机的 IP 地址是否匹配。如果是，SPF 验证通过；否则 SPF 验证失败。

总而言之，SPF 验证在 Safe SPF 记录下的工作过程和普通的 SPF 记录相同。毕竟，Safe SPF 记录就是 SPF 记录。

注意自动/动态 SPF 记录压平兼具两边的好处：压平后的 SPF 记录依然保留了原来 SPF 记录的 IP 地址，同时把 DNS 查询降到了 10 次以下。

自动/动态 SPF 记录压平常见问题

我没有 include Google 的 SPF 记录，为什么在我压平后的 SPF 记录中有 Google 的 IP 地址？

因为 SPF 记录是层次化的，您原来的 SPF 记录中有些服务可能包含 Google 的 SPF 记录。在 SPF 记录压平过程当中，Google 的 SPF 记录被找到并且被加到压平后的 SPF 记录中。

比如，如果您原来的 SPF 记录包含 bluehost (bluehost.com)，您压平后的 SPF 记录会包含 Google 的 IP 地址，因为 bluehost.com 的 SPF 记录包含 Google 的 SPF 记录。

有了自动/动态 SPF 记录压平，当第三方服务发生变动时，我需要手动更新我的 SPF 记录吗？

不需要。自动/动态 SPF 记录压平每几分钟执行一次，任何第三方服务变动都会反映在 Safe SPF 记录中。

我如何才能把新的服务加到我的 Safe SPF 记录中？

参考这篇文章。

翻译自 What Is Automatic/Dynamic SPF Record Flattening and How It Fixes the SPF PermError: Too Many DNS Lookups Issue，来自 什么是自动/动态 SPF 记录压平及其如何修复 SPF PermError: Too Many DNS Lookups 问题，转载请保留完整内容。