SPF 規範中的 10-DNS-lookup 限制是否通常強制執行？
我的理解是 SPF 規範指定電子郵件接收者不必進行超過 10 次 DNS 查找即可收集發件人所有允許的 IP。因此，如果一個 SPF 記錄具有
include:foo.com include:bar.com include:baz.com並且這三個域每個都有 SPF 記錄，這些記錄也有 3include個條目，那麼現在我們最多可以進行 3+3+3+3=12 次 DNS 查找。
- 我上面的理解正確嗎？
- 我只為我的域使用 2 或 3 個服務，而且我已經超過了這個限制。主要/次要電子郵件提供商是否通常（或曾經）強制執行此限制？
libspf2(C) 和Mail::SPF::Query(perl，在sendmail-spf-milter中使用)都實現了 10 個DNS 導致機制的限制，但後者不 (AFAICT) 應用 MX 或 PTR 限制。將mx和ptrlibspf2中的每一個也限制為 10。
Mail::SPF(perl) 有 10 個 DNS 導致機制的限制，並且每個機制、每個 MX 和每個 PTR 的查找限制為 10 個。（這兩個 perl 包通常在MIMEDefang中使用，但不是預設情況下。）
pyspf所有以下內容的限制為 10：“查找”、MX、PTR、CNAME；但它在操作期間顯式地將 MAX_LOOKUPS 乘以 4。除非在“嚴格”模式下，它還會將 MAX_MX 和 MAX_PTR 乘以 4。我不能評論商業/專有實現，但上面（除了
pyspf）清楚地實現了 10 個 DNS 觸發機制的上限（更多內容見下文），給予或接受，儘管在大多數情況下它可以在執行時被覆蓋 -時間。在您的特定情況下，您是正確的，它是 12 個包含並且超過了 10 個的限制。我希望大多數 SPF 軟體返回“PermError”，但是，失敗只會影響最終的“包含”提供程序，因為計數將計算為執行總數：SPF機制從左到右進行評估，並且檢查將“提前”通過，因此它取決於發送伺服器出現的順序中的哪個位置。
解決這個問題的方法是使用不觸發 DNS 查找的機制，例如
ip4andip6，然後mx儘可能使用，因為這樣可以讓您獲得多達 10 個其他名稱，每個名稱可以有多個 IP。由於 SPF 導致具有潛在指數擴展的任意 DNS 請求，它很容易被用於 DOS/放大攻擊。它故意設置了低限制以防止這種情況發生：它不會按照您想要的方式擴展。
導致DNS 查找的10 種機制（嚴格來說是機制 + “重定向”修飾符）與 10 次 DNS 查找並不完全相同。甚至“DNS 查找”也可以解釋，您事先不知道需要多少離散查找，也不知道遞歸解析器可能需要執行多少離散查找（見下文）。
SPF 實現必須將進行 DNS 查找的機制和修飾符的數量限制為每個 SPF 檢查最多 10 個，包括由使用“包含”機製或“重定向”修飾符引起的任何查找。如果在檢查期間超過了這個數字，則必須返回 PermError。“include”、“a”、“mx”、“ptr”和“exists”機制以及“redirect”修飾符不計入此限制。“all”、“ip4”和“ip6”機制不需要 DNS 查找，因此不計入此限制。
$$ … $$ 在評估“mx”和“ptr”機製或 %{p} 宏時，查找和檢查的 MX 或 PTR RR 不得超過 10 個。
因此，您最多可以使用 10 個觸發 DNS 查找的機制/修飾符。（這裡的措辭很差：它似乎只說明了限制的上限，確認實現的限制可能是 2。）
對於mx機制的 §5.4 和對於ptr機制的 §5.5 每個都有 10 次此類名稱查找的限制，並且僅適用於該機制的處理，例如：
為了防止拒絕服務 (DoS) 攻擊，在評估“mx”機制期間不得查找超過 10 個 MX 名稱（參見第 10 節）。
即您可能有 10 個 mx 機制，最多有 10 個 MX 名稱，因此每個可能會導致 20 個 DNS 操作（每個 10 MX + 10 A DNS 查找）總共 200 個。對於ptr或*%{p}，您可以查找 10 個ptr*機制，因此 10x10 個 PTR，每個 PTR 還需要 A 查找，總共 200 個。
這正是2009.10 測試套件檢查的內容，請參閱“處理限制”測試。
對於每次 SPF 檢查的客戶端 DNS 查找操作總數沒有明確規定的上限，我將其計算為隱式 210，給予或接受。還有一個建議是限制每次 SPF 檢查的 DNS 數據量，但沒有建議實際限制。您可以粗略估計一下，因為 SPF 記錄限制為 450 字節（遺憾的是，它與所有其他 TXT 記錄共享），但如果您大方的話，總數可能超過 100kiB。這兩個值顯然都可能被濫用為放大攻擊，這正是 §10.1 所說的你需要避免的。
經驗證據表明，在記錄中通常實現了總共10 種查找機制（查看 microsoft.com 的 SPF，他們似乎竭盡全力將其保持在 10 種）。很難收集太多查找失敗的證據，因為強制錯誤程式碼只是“PermError”，它涵蓋了所有類型的問題（儘管DMARC報告可能對此有所幫助）。
OpenSPF FAQ延續了“10 個 DNS 查找”的限制，而不是更精確的“10 個 DNS 導致機製或重定向”。這個常見問題解答可以說是錯誤的，因為它實際上說：
由於每個 SPF 記錄限制為 10 次 DNS 查找，因此請指定 IP 地址
$$ … $$
這與 RFC 不一致，RFC 對“SPF 檢查”操作施加限制，不以這種方式限制 DNS 查找操作，並明確指出SPF 記錄是單個 DNS 文本 RR。常見問題解答意味著您在處理“包含”時重新開始計數，因為這是一條新的 SPF 記錄。真是一團糟。
DNS 查詢
什麼是“DNS 查找”？作為使用者。我會認為“
ping www.microsoft.com”涉及單個 DNS“查找”：我希望將一個名稱轉換為一個 IP。簡單的？可悲的是沒有。作為管理員，我知道www.microsoft.com可能不是具有單個 IP 的簡單 A 記錄，它可能是一個 CNAME，它反過來需要另一個離散查找來獲取 A 記錄，儘管我的上游解析器可能會執行該記錄而不是我桌面上的解析器。今天，對我來說，www.microsoft.com是一個由 3 個 CNAME 組成的鏈，最終最終成為 akamaiedge.net 上的 A 記錄，這（至少）是某人的 4 個 DNS 查詢操作。SPF 可能會使用“ptr”機制查看 CNAME，但 MX 記錄不應該是 CNAME。
最後，作為DNS 管理員，我知道回答（幾乎）任何問題都涉及許多離散的 DNS 操作、單獨的問題和回答事務（UDP 數據報）——假設記憶體為空，遞歸解析器需要從 DNS 根開始並按其方式工作下：
.→→→com根據microsoft.com需要www.microsoft.com詢問特定類型的記錄（NS，A等），並處理CNAME。您可以在 中看到這一點dig +trace www.microsoft.com，但由於地理定位技巧，您可能不會得到完全相同的答案（此處的範例）。（由於 SPF 在 TXT 記錄上捎帶，並且 DNS 答案的 512 字節的過時限制可能意味著重試通過 TCP 的查詢，這種複雜性甚至還有一點點。）那麼 SPF 將什麼視為查找？它確實最接近管理員的觀點，它需要了解每種 DNS 查詢的細節（但不是到它實際需要計算單個 DNS 數據報或連接的程度）。