全球 SPF 驗證檢查器
寄件者原則架構 (SPF) 是一種關鍵的電子郵件驗證協定，它透過發佈授權發送 IP 位址的加密白名單來防止網域欺騙 (spoofing)。雖然 SPF 協定本身對現代的郵件到達率 (deliverability) 至關重要，但專用的 SPF DNS 紀錄類型（Type 99）卻有著令人難以置信的混亂歷史，並且已正式棄用 (obsolete)。
Record Type 99 的興衰
當最初構思 SPF 協定時 (RFC 4408)，IETF 設計了一種特定的 DNS 資源紀錄（Type 99），明確設計用於將 SPF Payload 與標準 TXT 資料隔離。當時的理論是，維護專用的紀錄類型將會加速解析器的解析 (parsing) 速度。然而，這個推出是一個巨大的失敗。舊版的 DNS 伺服器、防火牆和硬體負載平衡器無法識別新的 Type 99 語法，並經常丟棄封包，導致廣泛的電子郵件中斷。認識到這種硬體不相容性後，IETF 發佈了 RFC 7208，正式宣告 Type 99 紀錄的棄用。今天，所有的 SPF 設定都必須以標準的 TXT 紀錄發佈。如果管理員繼續部署舊版的 Type 99 SPF 紀錄，現代的平台（如 Microsoft Exchange 和 Google Workspace）將會完全忽略它，從而導致立即的 DMARC 失敗。
機械性的 10 次 Lookup 限制
對於管理 SPF 的開發人員來說，最突出的技術失敗點是嚴格的 10 次查詢閾值。因為 SPF 紀錄允許管理員使用 include: 指令巢狀嵌套其他的網域原則（例如 include:_spf.salesforce.com），所以接收方的郵件伺服器必須執行遞迴 DNS 查詢以從該第三方供應商獲取 IP。為了保護 MTA 免受無限路由迴圈和針對性的 DDoS 放大攻擊，協定將執行硬性限制 (hard-cap) 在 10 次遞迴 DNS 查詢。如果一家公司將太多的 SaaS 供應商串聯在一起並達到了 11 次查詢，執行將會停止，並回傳 SPF「PermError」。這會立即導致合法的發送電子郵件遭到嚴重退回 (hard-bounce) 或落入隔離區 (quarantine)。
Flattening (扁平化) 與診斷
為了繞過查詢限制，網路工程師會使用「SPF Flattening」工具。這些腳本會每小時執行一次，透過 API 展開所有的 include: 指令，剝離主機名稱，並將原始的 IPv4/IPv6 區塊編譯成一個巨大、扁平的 TXT 紀錄。使用全球診斷檢查器可確保您的語法有效、您的巢狀 include 沒有默默地超過 DNS 閾值，並且您的原則明確地以限制性的 -all (fail) 或 ~all (softfail) 標籤結束，以拒絕被偽造的 Payload。