什麼是 SPF——以及我該如何修復我的 SPF 記錄？（2026）

發布於 2026-07-01

數據截至 2026-06-29 · 方法論 v7。 對 261 百萬個已評級域名的彙總普查數據。SPF（發件人策略框架，Sender Policy Framework）是一條 DNS 記錄，列明允許哪些服務器代表你的域名發送郵件。參見我們如何評級。

SPF 是你 DNS 中的一行內容，它宣告「這些服務器可以以我的名義發送郵件——其餘的都視為可疑」。 在 261 百萬個域名中，有 53.21% 發佈了 SPF 記錄。這聽起來很健康，但僅有一條記錄並不能保護你：真正決定未列出的發件人是被拒絕還是被放行的，是那個末尾限定符，而相當大一部分記錄設置得過於寬鬆，實際上什麼都沒改變。以下是 SPF 的真正作用、我們最常見的錯誤，以及如何修復你自己的記錄。

什麼是 SPF 記錄？

當一台郵件服務器收到一封聲稱來自你域名的郵件時，它會查找你的 SPF 記錄，並檢查發送方服務器是否在你的批准列表中。記錄會以一條針對不在列表中的一切內容的指令結尾：

-all（硬失敗，hardfail）——拒絕未列出的發件人。這才是動真格的設置。
~all（軟失敗，softfail）——接受但標記為可疑。大多數郵件仍會被投遞。
?all（中立，neutral）——什麼也不做；等同於沒有任何立場。
+all——接受來自任何人的任何郵件。這是主動製造危險，絕不應發佈。

在發佈 SPF 的 139 百萬個域名中，只有 39.3% 使用了嚴格的 -all，而 55.8% 使用了較寬鬆的 ~all。並且有 36,014 個域名發佈了 +all——這是一封公開邀請函，告訴全世界任何人都可以以它們的名義發送郵件。

悄悄讓 SPF 失效的那些錯誤

DNS 查詢次數過多。 SPF 的查詢次數上限為 10 次（RFC 7208）；一旦超過，整條記錄就會以 “permerror” 失敗並被忽略。有 7,958 個域名（佔擁有 SPF 域名的 0.01%）觸碰了這個上限——通常是因為為第三方發件人串聯了過多的 include: 語句。
發佈 +all。 罕見但災難性——它徹底禁用了 SPF，並為偽造者背書。
以為 SPF 能阻止冒充。 單靠它並不能。SPF 檢查的是技術層面的發送路徑，而不是人們看到的「發件人（From）」地址。在所有域名中，有 32.4% 發佈了 SPF 但沒有 DMARC——因此可見的發件人仍然可以被偽造。SPF 是管道，DMARC 強制策略才是那把鎖。參見沒有 DMARC 的 SPF。

我該如何修復我的 SPF 記錄？

只發佈一條 SPF 記錄——一條以 v=spf1 開頭的 TXT 記錄。絕不要發佈兩條；那會自動導致失敗。
列出每一個合法發件人——你的郵箱服務商、營銷平台、CRM、客服系統——使用它們文檔中給出的 include: 值。
以 -all 結尾——當你確信列表已完整時。如果需要留出安全余地，可先從 ~all 起步，然後逐步收緊。參見修復 SPF。
保持在 10 次查詢以內——如果接近上限，就展平或合並 include。
然後添加 DMARC——SPF 和 DKIM 共同支撐 DMARC，這才是真正能阻止他人以你的域名發送郵件的控制手段。

常見問題

SPF 記錄長什麼樣？ 一條 DNS TXT 記錄，例如 v=spf1 include:_spf.google.com -all。其中的 include: 條目是你批准的發件人，而末尾的 -all 會拒絕其他所有人。

~all 和 -all 哪個更好？ -all（硬失敗）更強——它告訴收件方拒絕未列出的發件人。~all（軟失敗）通常仍會投遞郵件。截至 2026-06-29，39.3% 的 SPF 記錄使用 -all，55.8% 使用 ~all。

SPF 能阻止別人偽造我的域名嗎？ 單靠它不能。SPF 不管理可見的「發件人（From）」地址。你需要將 DMARC 設為強制執行。有 32.4% 的域名有 SPF 但沒有 DMARC，因而仍然可被偽造。

為什麼我的 SPF 記錄看起來沒問題卻「失敗」了？ 最常見的原因是它超過了 10 次查詢的上限並返回 permerror。有 0.01% 擁有 SPF 的域名遇到了這個問題。請減少 include: 查詢的數量。

修復 SPF 費用高嗎？ 不高——這是一次免費的 DNS 更改。真正的功夫在於把發件人列表做得完整而準確，而不是花錢。

免費檢查你域名的 SPF

查看你的 SPF 記錄、它的末尾限定符，以及它是否完整——私密進行，且僅域名所有者可見。

檢查你的域名 → · 修復 SPF → · 修復 DMARC → · 我們如何評級 → · 僅彙總數據。數據在歐盟境內存儲與處理。