“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軟體包：
為什麼強加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