SPF 記錄在電子郵件驗證中的角色
寄件者原則框架（SPF）是電子郵件驗證的重要基石。當郵件伺服器收到宣稱來自您網域的郵件時，會透過查詢 DNS 中的 SPF TXT 記錄，來驗證寄信的伺服器 IP 位址是否包含在該記錄的授權清單中。
有效的 SPF 記錄能協助收件伺服器辨識偽造的垃圾郵件與釣魚郵件，進而提升網域的信譽與郵件送達率。然而，SPF 記錄有其嚴格的語法規範與查詢限制，一旦設定錯誤，可能導致合法的郵件被收件端拒收。
拆解 SPF 記錄語法與常見項目
一筆標準的 SPF 記錄是由多個項目（Terms）組成，這些項目可分類為版本、機制或修飾符（Modifiers）：
- 版本：SPF 記錄必須以
v=spf1開頭，且此宣告必須是記錄中的第一個項目，整筆記錄也只能包含一個v=spf1。 - 機制：常見的機制包括
include、ip4、ip6、a、mx、ptr、exists與all。機制通常會搭配限定符（Qualifiers）使用，例如+（Pass，預設值）、-（Fail）、~（SoftFail）或?（Neutral）。 - 修飾符（Modifiers）：例如
redirect或exp，用於引導評估流程或提供說明。修飾符不能帶有+、-、~或?等限定符。
關鍵的 10 次 DNS 查詢限制
在 SPF 評估過程中，為了防止阻斷服務（DoS）攻擊，標準規範限制了收件端伺服器在評估單一 SPF 記錄時，最多只能執行 10 次 DNS 查詢。
觸發 DNS 查詢的項目
在您貼上的記錄中，以下項目會被計入 DNS 查詢次數：include、a、mx、ptr、exists 以及 redirect。
永久錯誤（PermError）的後果
如果一筆 SPF 記錄在完整評估期間（包含所有巢狀的 include 與 redirect 鏈）觸發超過 10 次 DNS 查詢，收件端郵件伺服器必須將此評估結果視為永久錯誤（Permanent Error）。這通常會導致郵件驗證失敗，進而影響信件的遞送。
常見的 SPF 語法錯誤與政策風險
在設定 SPF 記錄時，以下是常見的語法錯誤與潛在的政策風險：
+all的濫用：+all會授權網際網路上的任何伺服器代表您的網域發送郵件，這通常會使 SPF 失去防護作用。?all的中性政策：?all會傳回中性（Neutral）結果，幾乎無法為接收端郵件伺服器提供明確的政策指引。- 無終端政策：如果記錄中既沒有
all機制，也沒有redirect修飾符，則不相符的寄件者一律會收到中性結果。 ptr機制的使用：不應發布ptr機制，因為此機制的查詢速度慢且不可靠。- 順序與重複問題：多個
all機制會使政策更難審查。此外，SPF 評估期間無法存取all之後的項目，且若記錄中同時包含all，則redirect修飾符會被忽略。
本機檢查與完整 DNS 查詢的差異
本工具提供的是本機語法檢查與首筆記錄的查詢次數估算。
| 檢查維度 | 本機檢查（本工具） | 完整 DNS 查詢 |
|---|---|---|
| DNS 查詢 | 不會查詢 DNS | 會向 DNS 伺服器發送查詢 |
| 巢狀展開 | 不會展開 include 和 redirect 目標 |
會遞迴展開所有巢狀記錄 |
| IP 測試 | 不會測試寄件者 IP | 會比對實際的寄件者 IP |
| 隱私保護 | 您的 SPF 記錄只會留在瀏覽器中，不會上傳或儲存 | 查詢紀錄可能會留在 DNS 快取中 |
本機檢查能快速找出語法錯誤與第一層的 DNS 查詢次數，但無法得知最終的遞迴查詢總數。因此，請將本工具的結果視為審查輔助，而非郵件送達的絕對證明。
常見問題
SPF DNS 查詢次數估算是如何計算的？
估算會計算所貼記錄中的 include、a、mx、ptr、exists 和 redirect 項目。include 和 redirect 指向的記錄可能增加更多查詢，因此本機檢查無法得知最終的遞迴查詢總數。
如果 SPF 需要超過 10 次 DNS 查詢，會發生什麼事？
SPF 接收端必須將超過 10 個項目的 DNS 查詢上限的評估視為永久錯誤。此上限涵蓋完整的 include 和 redirect 鏈，而不只是第一筆記錄。
檢查結果無問題，是否能證明我的 SPF 設定有效？
不能。此頁面只檢查您貼上的文字，不會查詢 DNS、展開服務供應商記錄、測試寄件者 IP，也不會確認收件郵件伺服器將傳回什麼結果。