SPF記錄檢查器
分析 SPF 記錄以進行電子郵件身份驗證
如何使用SPF記錄檢查器
- 1輸入你的域名以查詢已釋出的 SPF DNS 記錄。
- 2輸入你期望看到的郵件伺服器或 include 機制。
- 3檢視解析出的 SPF 策略，以及是否通過或存在過多 DNS 查詢。
校驗 SPF 記錄
SPF = 'v=spf1 include:_spf.a include:_spf.b -all'（最多 10 次 DNS 查詢機制）SPF 告訴接收郵件的伺服器哪些 IP 可代表你的域名發信；缺失或錯誤的記錄會讓攻擊者冒用你的地址。
SPF 在所有 include 機制中最多允許 10 次 DNS 查詢，過度巢狀 include 會導致 permerror，郵件可能被拒收。
SPF 是一段 TXT 記錄，宣告「哪些伺服器有權以本域名發信」。收件方收到郵件後查詢發件域的 SPF，若發信 IP 不在列表中，結合 DMARC 策略決定拒收或進垃圾箱。**限定符決定嚴格程度**：`-all` 硬失敗（不在列表就拒絕）、`~all` 軟失敗（標記為可疑但可能接收）、`?all` 中立（無意見）、`+all` 全部通過（等於沒設定，極其危險）。生產環境推薦 `~all` 起步，穩定後改 `-all`；`+all` 絕不能用。
**SPF 有兩個硬性限制**：① 一條 SPF 記錄最多 10 次 DNS 查詢（include、a、mx、exists、redirect 都算），超限會報 PermError 導致整個 SPF 失效——這是大企業用多個郵件服務時最常見的問題，解決方法是扁平化（把 include 展開成具體 ip4 段）；② TXT 記錄總長不超過 255 位元組，超長需拆成多條字串，DNS 會自動拼接。**建議定期用線上工具驗證，尤其是增刪郵件服務後。**
| 機制 | 含義 | 示例 |
|---|---|---|
| all | 匹配所有（通常放最後） | -all（硬失敗） |
| ip4 | IPv4 地址或段 | ip4:192.0.2.0/24 |
| ip6 | IPv6 地址或段 | ip6:2001:db8::/32 |
| a | 域名的 A 記錄 | a:example.com |
| mx | 域名的 MX 記錄 | mx |
| include | 引用其他域的 SPF | include:_spf.google.com |
| ptr | 反向解析（已不推薦） | ptr（停用） |
| exists | 域名存在則匹配 | exists:example.com |
SPF 機制與限定符
常見問題
-all 是什麼意思？
硬失敗：拒絕策略外來源的發信。~all 是軟失敗，更寬鬆。
為何有 10 次查詢限制？
為限制 DNS 查詢負載；超出會導致 permerror，接收方可能拒收。
SPF 單獨能阻止冒用嗎？
不能，需配合 DKIM 與 DMARC 才能獲得真正防護與報告。
有 SPF 就夠了為什麼還要 DKIM 和 DMARC？
三者解決不同問題：**SPF** 驗證發信 IP 是否授權；**DKIM** 用私鑰對郵件簽名，收件方用公鑰驗證內容未被篡改（且能防轉發後失效）；**DMARC** 建立在前兩者之上，告訴收件方「驗證失敗時怎麼辦」（拒收 / 隔離 / 放行）並把結果回傳給發件人。單獨 SPF 的弱點很明顯：郵件被轉發後 SPF 會失敗（因為轉發伺服器不在授權列表），而 DKIM 簽名不受轉發影響。三者配合才能真正防住偽造和釣魚，這也是 Google、Yahoo 2024 年起對批次發件人的強制要求。
為什麼我發了郵件對方收不到？
按順序排查：① SPF 記錄是否包含實際發信伺服器（很多人配了企業郵箱卻漏了營銷平臺、CRM、網站表單的發信服務）；② 是否超過 10 次 DNS 查詢限制；③ DMARC 策略是否過於嚴格（p=reject 時未對齊的郵件會被直接丟棄）；④ 發信 IP 是否在黑名單（可用 mxtoolbox 查詢）；⑤ 內容是否觸發垃圾郵件規則。**最有效的排查手段是看 DMARC 報告**（彙總了各大郵箱的驗證結果），或先申請一個免費的 DMARC 報告服務。