如何解決 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