“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 软件包:
为什么施加 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
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。