如何解决 SPF PermError: Too Many DNS Lookups 错误

“SPF PermError: Too Many DNS Lookups” 是许多 SPF 实现中常见的错误。当超出常常被忽略的 SPF的 10 次 DNS 查找限制时，将返回 SPF PermError，即 SPF 永久性错误。 SPF PermError 可能会影响您的电子邮件送达率。

本文解释了 SPF的 10 次 DNS 查找限制，违反该限制的后果是什么，以及如何使用 DMARCLY 的 Safe SPF 功能解决此问题。

SPF PermError: too many DNS lookups

在域上设置 SPF 时，有时会遇到 “SPF PermError：DNS 查找过多” 的 SPF 永久性错误。 这能够在具备兼容 SPF 支持的电子邮件服务器上看到，也能够在在线 SPF 记录检查器中看到。

DMARC 如何处理 “SPF PermError：DNS 查找太多”？

当在 SPF 检查期间返回 “SPF PermError：太多 DNS 查找” 时，DMARC 将其视为失败，由于它是永久性错误，而且全部 SPF 永久性错误都被 DMARC 解释为失败。

什么是 SPF DNS 查找限制？

根据官方 RFC 规范文档 RFC7208：

SPF 实现必须将进行 DNS 查找的机制和修饰符的数量限制为每 SPF 检查最多 10 个，包括使用 “包含” 机制或 “重定向”
修饰符致使的任何查找。 若是在检查期间超过此数字，则必须返回 PermError。 “include”，“a”，“mx”，“ptr” 和
“exists” 机制以及 “重定向” 修饰符确实计入此限制。 “all”，“ip4” 和 “ip6” 机制不须要 DNS
查找，所以不计入此限制。

换句话说，SPF 规范要求进行 DNS 查找的机制和修饰符的数量不得超过每 SPF 检查 10 个，包括使用 “包含” 机制或 “重定向” 修饰符致使的任何查找。 不然，将返回 SPF PermError，更具体地说是 “SPF PermError：DNS 查找太多”。

此限制强加于接收电子邮件服务器端。 如下是一些实现此限制的流行 SPF 软件包：

• libspf2
• Mail::SPF
• Mail::SPF::Query
• pyspf

为何施加 SPF DNS 查找限制？

为何施加这个看似人为的限制？实际上，实施 10-DNS 查找限制是为了阻止拒绝服务（DoS）攻击。考虑这样的场景：

恶意用户在域恶意网站上建立 SPF 记录，其中有许多引用另外一个域 victim.com;
而后他将不少电子邮件从 malicious.com 发送到由不一样电子邮件服务提供商（ESP）托管的邮箱，并实施了 SPF;
收到这样的电子邮件后，ESP 会在 DNS 上查询 victim.com;
因为涉及许多 ESP，他们放大了这种流量；这有效地变成了 victim.com 上的 DoS 攻击；
更重要的是，攻击的真正来源是隐藏的。
正如您所看到的，若是不当心，能够利用很是无辜的电子邮件身份验证机制进行恶意使用！ 虽而后果可能很严重，但这个问题的解决方案很简单：在 ESP 侧对每次检查的最大 DNS 查找次数进行限制能够大大减轻它，由于放大限制为 10，而不是可能更大。

个人 SPF 记录是否超过 SPF DNS 查找限制？

您可使用咱们的 SPF 记录查找工具来检查您的 SPF DNS 查找计数。 除了有关域中 SPF 设置的基本信息外，还会显示 DNS 查询机制 / 修饰符的数量。 如下是 microsoft.com 上的 SPF 检查结果，其 SPF DNS 查找次数刚好为 10：

我建议你对你的域名进行相似的检查，看看这个数目是多少。

若是超过 SPF DNS 查找限制会发生什么？

当接收电子邮件服务器上的 SPF 实如今发件人的域的 SPF 记录中遇到 10 个以上的 DNS 查询机制 / 修饰符时，它将返回 “SPF PermError：DNS 查找过多”。 如上所述，DMARC 将 SPF PermError 解释为失败，所以，电子邮件可能不会到达收件箱，具体取决于电子邮件服务器的设置。

如今几乎每家公司都将基本服务外包给第三方服务提供商，如电子邮件递送，营销等。 为记录中的每一个服务添加一个包括 1 的限制。 若是它们进一步包含 DNS 查询机制 / 修饰符，它会很快达到 / 超过限制。

SPF 记录展平

可是，这个问题有一个简单的解决方案。 经过 “展平” SPF 记录，能够将 DNS 查询机制 / 修饰符的数量减小到 1，远低于限制。

这就是 “SPF 记录展平” 的工做原理：对于每一个 DNS 查询机制 / 修饰符，查询 DNS 以获取 IP 地址，而后用 IP 地址替换原始机制 / 修饰符。 每次更换机制或修饰符时，总计数减 1. 在替换全部此类机制 / 修饰符后，总计数变为 1 - 只有最顶层的 SPF 记录须要 DNS 查询。

使用此 SPF 记录展平技术，您能够将包含超过 10 个 DNS 查询机制 / 修饰符的很是复杂的 SPF 记录转换为 “平坦” IP 地址列表，并在 “安全区域” 中保持温馨。

让咱们来看看平坦的 SPF 记录是什么样的。 如下是在 microsoft.com 上展平 SPF 记录的 IP 地址：

如您所见，这个扁平的 SPF 记录包含与 microsoft.com 上原始 SPF 记录中相同的 IP 地址，但它自己没有 DNS 查询机制 / 修饰符！

问题解决了？ 好吧，尚未。

若是其中一个包含机制的 IP 地址发生了变化怎么办？ 这意味着平坦的 SPF 记录如今在这些 IP 地址上不一样步，这将在 SPF 身份验证中产生不正确的结果。

固然，您能够再次手动压缩 SPF 记录，并在 DNS 中更新它。 不用说，这很是繁琐且容易出错，更不用说你必须一直监视它。

好消息是，DMARCLY 有一个名为 “Safe SPF” 的功能，它正是专门为解决这个问题而设计的。

用 Safe SPF 解决这个问题

使用 Safe SPF，一箭双雕：始终将 SPF 记录的 DNS 查询机制 / 修饰符保持为 1，而没必要担忧手动压平 SPF 记录并在 DNS 中更新它！

这就是 Safe SPF：

从上面能够看出，在指定域上激活了安全 SPF。

在域上激活安全 SPF 后：

安全 SPF 记录包含与原始 SPF 记录中相同的 IP 地址；
安全 SPF 记录没有 DNS 查询机制 / 修饰符；
当底层 IP 地址改变时，它老是被更新；
你不用手工维护。
本文翻译自 SPF PermError: too many DNS lookups. When SPF record exceeds 10-DNS-lookup limit