Defaults.Exposed › 修復 › Guides
"SPF 記錄未找到"——但你明明有一條？真正的五個原因（2026）
發布於 2026-07-08
資料截至 2026-06-29 · 方法論 v7。 基於 261 百萬個已評分網域的彙總普查資料。參見我們如何評分。
如果檢測工具說“SPF 記錄未找到”，但你確定自己發布過一條，這條記錄通常不是缺失，而是變得不可見了：根據 Defaults.Exposed 對 261 百萬個網域的普查，有 1,013,416 個網域——大約每 138 個嘗試設定 SPF 的網域裡就有 1 個——發布了兩條或以上的 SPF 記錄，這是一種 PermError（RFC 7208 §3.2），很多檢測工具會把它報告成“未找到”。
真正的原因有五個，都能在一次坐下的時間裡修好：主機名錯誤、記錄重復、DNS 類型錯誤或引號被弄乱、網域伺服器不一致，或者是長度/CNAME 冲突。以下內容：每個原因對應的 60 秒測試方法，按檢查順序排列，然後是修復步驟。
你確定這條記錄真的存在嗎？
先從最不體面的可能性說起，因為它是目前為止最常見的一種：在 Defaults.Exposed 普查評分的 261,086,232 個網域中，有 121,145,609 個——占 46.4%——根本沒有 SPF 記錄。很多“但我明明配過”的情况，最後發現是記錄加在了一個測試區域，或者加在了一個已經不再是權威伺服器的舊 DNS 服務商那裡。檢查一下你的網域伺服器實際指向的那個 DNS 服務商（往往不是你的註冊商），看看有沒有一條以 v=spf1 開头的 TXT 記錄。如果確實沒有，就別再當偵探了，直接去看修復你的 SPF 記錄。
怎麼正確檢查一條 SPF 記錄？
網頁版檢測工具是通過自己的快取解析器查詢 DNS 的。要看到真相，得直接問你網域的權威網域伺服器：
# 找出權威網域伺服器
dig NS yourdomain.com +short
# 直接向其中一台查詢 TXT 記錄
dig TXT yourdomain.com @ns1.yourdnshost.com +short
Windows 上：nslookup -type=TXT yourdomain.com ns1.yourdnshost.com。
有兩條解讀規則。第一，數一數有多少行以 v=spf1 開头——數量和內容一樣重要。第二，檢查你查詢的是不是正確的名字：接收方是對照 **Return-Path（RFC5321.MailFrom，也就是“信封發信人”）**裡的網域來評估 SPF 的——不是收件人看到的 From 位址。如果你的通讯工具是經由 bounce.yourdomain.com 退信的，那麼根網域上一條完美的記錄，並不是接收方真正會查詢的那一條。
真正的五個原因是什麼？
| # | 原因 | 60 秒測試方法 | 修法 |
|---|---|---|---|
| 1 | 記錄放在了錯誤的主機名上（子網域 vs 根網域） | 對你 Return-Path 裡那個確切網域跑 dig TXT | 發布在真正用來發信的那個名字上 |
| 2 | 兩條或以上的 v=spf1 記錄 = PermError | dig TXT 返回 2 條或以上的 v=spf1 行 | 合併成恰好一條記錄 |
| 3 | 發布成了記錄類型 99，或者引號被弄乱了 | 檢查記錄的類型和多余的引號 | 重新發布為一條干淨的 TXT 記錄 |
| 4 | 快取到期未刷新 / 網域伺服器不一致 | 直接查詢每台網域伺服器，比對答案 | 修好落後的網域伺服器，等舊 TTL 到期 |
| 5 | 超過 255 字元的拆分問題，或 CNAME 冲突 | 查看有沒有被截斷的字串片段，或同名下有沒有 CNAME | 讓服務商正確拆分字串；把記錄移出被 CNAME 占用的名字 |
資料截至 2026-06-29。
1. 記錄是不是放錯了主機名？
經典情况：SPF 加在了 mail.yourdomain.com 上，而郵件却自稱來自 yourdomain.com，或者反過來。SPF 不會向下繼承——根網域上的記錄對子網域沒有任何意義，反過來也一樣。要發布在你 Return-Path 裡那個確切的名字上。一個用自己退信子網域發信的服務商，需要在那個子網域上有一條記錄——通常是服務商提供的一條 CNAME 或 TXT（GoDaddy SPF 設定指南 展示了這些字段在哪裡）。
2. 你是不是有兩條 SPF 記錄？
這是头號原因，也是郵件驗證領域裡最容易誤導人的錯誤提示。RFC 7208 §3.2 說得很直白：一個網域必須恰好有一條 SPF 記錄。兩條或以上就是 PermError——接收方會把你的 SPF 當作作廢處理。有些檢測工具會如實報告這種狀態（“發現多條記錄”）；另一些則報告最終效果：未找到有效的 SPF 記錄。你在面板裡明明看得到一條記錄，於是斷定是檢測工具壞了。其實不是——是你多了一條記錄。
普查發現有 1,013,416 個網域攜帶著兩條或以上的 SPF 記錄——大約每 138 個嘗試設定 SPF 的網域裡就有 1 個，每一個的 SPF 實際上都已經被關掉了。這通常發生在更換服務商的過程中：新服務商的設定向導新增了一條全新的記錄，而不是編輯舊的那條。修法是合併，絕不能是加第二條記錄：把所有內容合併成一行 v=spf1 … ~all，刪掉其余的。我們的資料報告兩條 SPF 記錄等於零 拆解了上百萬個網域是怎麼走到這一步的；如果這是在一次遷移之後開始出現的，見換服務商之後 SPF 就壞了。合併的時候，不要盲目地把每一個 include: 都拼接進去——每一個都要消耗 DNS 查詢次數，逼近 SPF 硬性上限 10，那樣就是把“未找到”換成了PermError：DNS 查詢次數過多。
3. 你是不是發布了錯誤的記錄類型——或者是界面把它弄乱了？
早期的 SPF 有自己專屬的 DNS 記錄類型（類型 99，字面意思就叫“SPF”）。它已經被棄用了：RFC 7208 要求必須用 TXT，接收方不會查詢類型 99。一些 DNS 面板的記錄類型下拉菜單裡仍然提供“SPF”這個選項；選了它，你的記錄就是真實存在、格式正確，却對誰都不可見。檢查一下類型這一列，重新發布為 TXT。
更隱蔽的一個近親是引號問題。把一個已經帶引號的值粘贴進一個自己也會加引號的字段，會產生 ""v=spf1 …""——這已經不是以 v=spf1 開头了，所以對驗證方來說它根本不存在。你的 dig 輸出會顯示真相；DNS 面板往往在外觀上把它遮住了。
4. 真的還“在傳播”嗎？
“再等 24–48 小時讓它傳播一下”是 DNS 領域裡被開得最濫的處方。所谓傳播，其實就是快取到期：一旦記錄的 TTL 到期（通常 1 小時，很少超過 24 小時），每個解析器都能看到新答案。24 小時之後還是找不到？那就不是傳播的問題。
兩個真正的元凶：負快取——一個解析器在你新增記錄之前就查詢過你，把“沒有這條記錄”的答案快取了下來，直到負快取的 TTL 到期為止——以及遷移之後的網域伺服器不一致，網域同時還挂著舊服務商的網域伺服器和新的，導致世界上一半的人讀到的是你已經不再編輯的那個區域。直接查詢每一台列出的網域伺服器；如果答案不一樣，問題就找到了。修好註冊商那邊的 NS 委托，讓只有你真正在編輯的那個服務商才是權威的。
5. 記錄是不是太長，或者被 CNAME 挡住了？
一個 TXT 記錄裡的單個字串最多 255 個字元。更長的 SPF 記錄是合法的，但必須在一條記錄內拆分成多個帶引號的字串——而 DNS 服務商的界面經常把這個拆分搞砸，要麼截斷了值，要麼在某個機制中間把它切斷，導致无法解析。如果你的記錄很長，檢查 dig 輸出裡有沒有一個突然中斷的值。
另外，DNS 規定一個已經有 CNAME 的名字上不能再有 TXT 記錄。如果 mail.yourdomain.com 是指向你服務商的一條 CNAME，你就不能同時在那裡放 SPF——有些面板會接受這個操作，然後只提供 CNAME 那一部分服務。要麼把記錄放在 CNAME 指向的地方（如果你能控制它），要麼重新規划結構，讓發信用的名字不再被 CNAME 占用。TXT 處理得比較干淨的服務商能讓這兩件事都更簡單——見 Cloudflare SPF 設定指南。
怎麼一步步修復？
- 在 defaults.exposed 執行免費掃描——在你動任何東西之前，它會讀取你實時的 DNS，告訴你屬於五種狀態裡的哪一種。
- 確認哪些網域伺服器是權威的（
dig NS），並檢查它們的答案是否一致。 - 在權威網域伺服器上查詢你 Return-Path 裡那個確切網域的 TXT 記錄。
- 數一數
v=spf1的行數：零條 → 發布一條；兩條或以上 → 合併成一條。 - 核實類型是 TXT，值恰好以
v=spf1開头，沒有混入多余的引號或被截斷。 - 等過一個 TTL 周期，再重新掃描，確認它在各處都能干淨地解析出來。
常見問題
為什麼我在自己的 DNS 面板裡能看到記錄，檢測工具却說“未找到”？
通常是原因 2 或原因 4：第二條 v=spf1 記錄會讓兩條都作廢——這是一種 PermError，有些工具會報告成“未找到”，截至 2026-06-29，有 1,013,416 個網域正處在這種狀態——或者你的面板根本不是真正權威的那個 DNS 服務商。
我修好之後，檢測工具要多久才能看到？ 一個 TTL 周期——通常是一小時，最多 24 小時。超過這個時間，“傳播”就不是原因了；重新檢查這五個原因，先從網域伺服器一致性開始。
我該用 DNS 面板提供的“SPF”記錄類型嗎？ 不該。類型 99 已被棄用；RFC 7208 只要求 TXT。類型 99 的記錄對現代接收方來說是不可見的。
記錄現在能找到了——為什麼我的郵件還是 SPF 失敗？ 因為 SPF 檢查的是 Return-Path 網域，不是 From 標头，而且記錄必須真正列出為你發信的伺服器。“能找到”只是第一步；修復你的 SPF 記錄 這篇指南讲的是怎麼通過檢查。
完全沒有 SPF 記錄真的這麼常見嗎？ 是的——在 Defaults.Exposed 普查評分的 261,086,232 個網域中（截至 2026-06-29），有 121,145,609 個網域、占 46.4%，完全沒有發布 SPF。“未找到”才是互聯網的默認狀態。
把報告發給老板
一旦記錄能干淨地解析出來，重新執行掃描，把評分報告轉發給這個網域所屬的企業負責人或客戶。它會用大白話說明之前哪裡壞了、你修了什麼、這個網域現在處於什麼狀態——這正是網路保險續保和供應商安全問卷會要求提供的證據。這份報告就是這項工作的收據。
免費檢查你的 SPF 記錄
私密、僅網域所有者可見地看看你的網域屬於五種“未找到”狀態裡的哪一種。
檢查你的網域 → · 修復 SPF → · 換服務商之後 SPF 就壞了 → · 我們如何評分 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。