SPF PermError: Too Many DNS Lookups - SPF 记录超过 10 次 DNS 查询极限原因以及解决办法

“SPF PermError：DNS查找太多”是许多SPF实现中常见的错误。 当超出经常被忽略的SPF 10-DNS查找限制时，将返回SPF PermError，即SPF永久性错误。 SPF PermError可能会影响您的电子邮件传送能力。

本文解释了SPF 10-DNS查找限制是什么，SPF记录与其相关的后果是什么，以及如何使用DMARCLY的安全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]
• [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解释为失败，因此，电子邮件可能不会落入收件箱中，具体取决于电子邮件服务器的设置。

因此，最好的办法是在您的SPF记录<= 10中保留DNS查询机制/修饰符。

但我不能。 我的SPF记录里有很多东西！

据我所知 - 现在几乎每家公司都将基本服务外包给第三方服务提供商，如电子邮件递送，营销等。 为记录中的每个服务添加一个包括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

本作品采用《CC 协议》，转载必须注明作者和本文链接