檢查 SPF 記錄：誰能以這個網域的名義寄信？
SPF 是一種 DNS 記錄，網域會在其中列出獲准替它寄信的伺服器。如果沒有 SPF，或 SPF 有錯誤、過於寬鬆，別人就更容易以該網域的名義寄出假郵件。輸入網域、電子郵件地址或連結，我們會讀取它的 SPF 並為你說明。
使用方式
- 輸入你要檢查的網域，或貼上電子郵件地址或連結：我們只會使用其中的網域。
- 按下「檢查 SPF」。我們會讀取 SPF 記錄，並像收件伺服器一樣追蹤每一個 include。
- 看看記錄的結尾和查詢次數：理想的結果是「-all」或「~all」，且查詢次數不超過 10 次。
每種結果代表什麼
- 這個網域沒有 SPF
- 它沒有說明哪些伺服器可以替它寄信，因此更容易被冒充。如果這是你的網域，請發布 SPF 記錄。
- SPF 記錄有錯誤
- 收件伺服器無法套用它，所以對它們來說，這個網域等於沒有 SPF。下方的訊號會說明問題所在。
- 任何人都能以這個網域的名義寄信
- 記錄以「+all」結尾，等於授權全世界所有伺服器。這樣設定的 SPF 毫無保護作用。
- SPF 沒有完全保護這個網域
- 記錄沒有說明該如何處理不在清單上的伺服器，因此以這個網域名義寄出的假郵件不會被標記。
- SPF 設定正確
- 這個網域列出了可以替它寄信的伺服器，並要求收件端標記或拒收其餘的郵件。單靠 SPF 無法阻止冒充：告訴收件端該怎麼做的是 DMARC。
每個訊號代表什麼
- 這個網域沒有發布任何 SPF 記錄。
- 某個網域（這個網域或被引用的網域）發布了不只一筆 SPF 記錄。規定只能有一筆，因此收件端會將其視為錯誤。
- 記錄中有項目寫錯了，因此收件端會將其視為錯誤。
- 連同所有 include 一起計算，這筆記錄需要超過 10 次 DNS 查詢。超過 10 次時，收件端會將其視為錯誤。
- 有一個 include 指向沒有 SPF 記錄的網域，因此收件端會將整筆記錄視為錯誤。
- include 形成了迴圈：某個網域最後引用了自己。
- 它以「+all」結尾：全世界任何伺服器都能以這個網域的名義寄信。
- 它以「?all」結尾：沒有說明如何處理不在清單上的伺服器，所以沒有保護作用。
- 它以「~all」結尾：來自其他伺服器的郵件會被標記為可疑，但不會被拒收。這是最常見的設定。
- 它的結尾沒有「all」，因此不在清單上的伺服器會得到中立結果，沒有任何保護。
- 它使用了「ptr」，這是標準不建議使用的緩慢機制。許多收件端會略過它。
- 它使用了巨集（含 % 的項目），內容會隨每封郵件而改變，因此我們無法追蹤這部分，實際查詢次數可能更多。
相關工具
涵蓋哪些國家
適用於任何國家的網域。我們會像收件伺服器一樣讀取記錄（RFC 7208）：它的機制、結尾方式、最多 30 次查詢範圍內的每一個 include 和 redirect，以及 DNS 查詢次數與 10 次上限的比較。
我們讀取的是該網域的公開 DNS 記錄。如果你輸入電子郵件地址或連結，只有其中的網域會離開你的瀏覽器。你查詢的網域不會被儲存。
常見問題
什麼是 SPF？
Sender Policy Framework：一種 DNS 記錄，網域會在其中列出獲准替它寄信的伺服器。收到郵件的伺服器會檢查投遞這封郵件的伺服器是否在這份清單上。
「-all」和「~all」哪個比較好？
「-all」要求收件端拒收來自清單外伺服器的郵件；「~all」則要求將這些郵件標記為可疑。兩者都有保護作用，許多網域會使用「~all」，再交由 DMARC 決定如何處理。「+all」和「?all」則沒有保護作用。
為什麼 10 次查詢的上限很重要？
每一個 include、a、mx、ptr、exists 和 redirect，都會讓收件伺服器查詢一次 DNS。如果整筆記錄需要超過 10 次，就會被視為錯誤，SPF 也會失效。請移除不再使用的服務，或請你的供應商提供更精簡的 include。
SPF 能單獨阻止假郵件嗎？
不能。SPF 檢查的是隱藏的信封寄件者，而不是你在「寄件者」中看到的地址。將兩者連結起來、並要求收件端隔離或拒收未通過驗證之郵件的，是 DMARC。也請一併檢查該網域的 DMARC。