Defaults.Exposed › 修復 › Guides

Fix guides

• “DKIM Signature Not Valid”——各種原因，按排查順序排列（2026）
  “DKIM signature not valid”有五個常見原因，從內容在傳輸途中被修改到金鑰被截斷。在 261 百萬個已評分網域中，只有 51.84% 發布了可發現的 DKIM 金鑰。資料截至 2026-06-29。
• "DMARC 政策未啟用"：檢測工具到底在說什麼，以及誠實的五分鐘第一步（2026）
  "DMARC 政策未啟用"意味著沒有 DMARC 記錄，或者記錄設成了 p=none。只有 10.59% 的網域強制執行 DMARC 政策——75.11% 干脆沒有發布任何記錄。該發布的確切 TXT 記錄、要避開的語法坑，以及第一周會是什麼樣子。資料截至 2026-06-29。
• "SPF 記錄未找到"——但你明明有一條？真正的五個原因（2026）
  SPF 記錄未找到，但你確定它存在？有 1,013,416 個網域發布了兩條或以上的 SPF 記錄——這是一種 PermError，很多檢測工具會把它報告成“未找到”。五個真正的原因、每個原因的 60 秒測試方法，以及修法。資料截至 2026-06-29。
• DKIM "No Key for Signature"：選擇器與金鑰轮換修復指南（2026）
  DKIM "no key for signature" 意味著你的簽名指向的選擇器記錄在 DNS 中不存在。如何找到選擇器、發布記錄並安全轮換金鑰——在 261 百萬個網域中，只有 3.87% 完成了 SPF+DKIM+DMARC 三件套。資料截至 2026-06-29。
• DKIM 通過但 DMARC 失敗：gappssmtp.com / onmicrosoft.com 默認簽名陷阱（2026）
  當郵件用 gappssmtp.com 或 onmicrosoft.com 簽名時，DKIM 通過但 DMARC 依然失敗——服務商默認簽名永遠无法與你的 From 網域對齊。在 12,145,313 個授權 Google 的網域中，只有 18.5% 強制執行 DMARC。資料截至 2026-06-29。
• DKIM“Body Hash Did Not Verify”——是什麼改動了你的郵件，以及怎麼修（2026）
  “Body hash did not verify”意味著郵件离開你時 DKIM 簽名是有效的——是傳輸途中有東西改寫了它。在 261 百萬個已評分網域中，只有 3.87% 具備 SPF + DKIM + DMARC 完整三件套。資料截至 2026-06-29。
• DMARC 失敗但 SPF 和 DKIM 都通過？對齊修復指南（2026）
  SPF 和 DKIM 都通過時 DMARC 仍可能失敗，因為兩項檢查驗證的都不是你的 From 網域——這就是對齊缺口。在 261 百萬個已評分網域中，只有 7.4% 在強制執行的 DMARC 政策下以對齊方式通過 SPF。資料截至 2026-06-29。
• Gmail "550-5.7.1 Message Blocked"——解讀退信原因並修復（2026）
  Gmail 550-5.7.1 解讀：政策拦截、沒有反向 DNS 的 IPv6、垃圾郵件與信誉拒收——以及 Google 已經遷移到新程式碼的那些字串。只有 10.59% 的網域強制執行 DMARC。資料截至 2026-06-29。
• Gmail 550 5.7.26 "The Sender Is Unauthenticated"：按要求順序排列的修復方案（2026）
  當你的郵件同時未通過 SPF 和 DKIM 時，Gmail 會返回 550 5.7.26。在通過 _spf.google.com 授權 Google 伺服器的 12,145,313 個網域中，只有 18.5% 強制執行 DMARC。5.7.26 系列（以及新程式碼 5.7.27/5.7.30）的解碼表，外加按順序排列的修復步驟。資料截至 2026-06-29。
• Mailchimp、Brevo 或 Klaviyo 郵件 DMARC 失敗？開啟真正的網域驗證（2026）
  通讯平台在以你的網域發信、却沒有以你的網域身份完成驗證時，就會 DMARC 失敗——修法是啟用自定義網域驗證。在授權 SendGrid 的 740,321 個網域中，只有 18.0% 強制執行 DMARC。資料截至 2026-06-29。
• Outlook 拒收你的郵件：550 5.7.515、550 5.7.509 和 compauth=fail，解讀與修復（2026）
  兩個不同的微軟系統會拒收郵件：消費者版 Outlook.com 會拒收未通過驗證的大宗發件方（550 5.7.515），Exchange Online 則是在執行你自己的 DMARC 拒收政策（550 5.7.509）。在授權 spf.protection.outlook.com 的 10,205,070 個網域中，只有 21.7% 強制執行 DMARC。資料截至 2026-06-29。
• SPF PermError：如何在不弄壞郵件的前提下修復"DNS 查詢次數過多"（2026）
  至少有 797,263 個網域超出了 SPF 10 次 DNS 查詢的上限，它們的 SPF 返回 PermError——作廢，且被算作 DMARC 失敗。修復順序：數清真實查詢次數、清理失效的 include、改用子網域，只在最後才靠自動化做扁平化。資料截至 2026-06-29。
• Yahoo 554 5.7.9 “Message Not Accepted for Policy Reasons”——發件方修復指南（2026）
  當郵件違反 Yahoo 的發件方政策時會返回 554 5.7.9——通常是 SPF/DKIM 驗證失敗或 DMARC 強制執行。在 261 百萬個已評分網域中，只有 10.59% 強制執行 DMARC。資料截至 2026-06-29。
• 你听說的那個發票詐騙故事——會不會發生在你公司？兩分鐘見分晓（2026）
  有人能不能發出一張看起來完全像來自你公司的假發票？89.41% 的已評分網域可能被這樣冒用——一次免費的兩分鐘檢查告訴你你的網域是否在其中。資料截至 2026-06-29。
• 你的 SaaS 工具 SPF 一直失敗？原因和修復順序——歐洲版（2026）
  當一個 SaaS 工具“SPF 失敗”時，真正的問題通常是 DMARC 對齊或 10 次 DNS 查詢上限——有 2,119,539 個網域只差一個 include 就會跌下懸崖。怎麼診斷，以及 HubSpot、Salesforce、Mailchimp 和 SendGrid 的修復順序。資料截至 2026-06-29。
• 保險續保表在問 SPF、DKIM 和 DMARC——該怎麼答（2026）
  網路保險續保表在問你的網域是否做過 DMARC、SPF 和 DKIM 掃描。只有 7.4% 的已評分網域具備保險公司真正想核查的對齊且強制執行的設定——兩分鐘內拿到一個真實、帶日期的答案。資料截至 2026-06-29。
• 在新網域上設定郵件：20 分鐘搞定 SPF、DKIM 和 DMARC 的清單（2026）
  用大約 20 分鐘在新網域上設定 SPF、DKIM 和 DMARC。46.4% 的網域從未發布過 SPF，只有 3.87% 完成了完整的驗證三件套。資料截至 2026-06-29。
• 客戶的安全問卷在問郵件驗證——一個下午答完（並補齊差距）（2026）
  供應商安全問卷在問 DMARC、SPF 和 DKIM。在已評分的網域中，只有 7.4% 的網域把郵件驗證完全對齊並強制執行——如何如實作答，並在一個下午內免費補齊差距。資料截至 2026-06-29。
• 從 p=none 到 p=reject 且不誤伤合法郵件：分階段上線方案（2026）
  分四個階段把 DMARC 從 p=none 推進到 p=reject——監控、修復來源、逐步提高 quarantine 比例、拒收。37,312,637 個網域停留在 p=none，已評分網域中只有 10.59% 強制執行。資料截至 2026-06-29。
• 換了郵件工具後 DKIM 失敗：CNAME 與選擇器遷移指南（2026）
  換了郵件工具後 DKIM 壞了？被 DNS 面板追加了區網域的 CNAME 目標和被過早刪除的選擇器，几乎解釋了所有遷移後故障。在 261 百萬個網域中，只有 3.87% 凑齊 SPF+DKIM+DMARC 三件套。資料截至 2026-06-29。
• 換了郵件服務商之後 SPF 就不好用了——遷移修復方案（2026）
  換郵件服務商之後 SPF 壞了？新記錄几乎肯定是加在舊記錄旁邊的——兩條 v=spf1 記錄會讓 SPF 整體作廢，目前有 1,013,416 個網域正處於這個狀態。十分鐘遷移修復方案，逐步讲解。資料截至 2026-06-29。
• 改名前留下的那個舊網域，是一扇你沒關上的門——如何鎖死不發郵件的網域（2026）
  一個從不發郵件的停放網域，照樣能被人拿來冒充你的企業發郵件。三條免費 DNS 記錄就能把它鎖死——而目前有 46.4% 的網域連 SPF 記錄都沒有。資料截至 2026-06-29。
• 有人在用你的網域發郵件：應急回應指南（2026）
  有人在冒用你的網域發郵件？先確認是精確網域冒用還是仿冒網域——兩者的修法完全不同。89.41% 的網域沒有強制執行的 DMARC 政策，46.4% 干脆沒有發布 SPF。資料截至 2026-06-29。
• 聯繫表單郵件進垃圾箱——Web 伺服器發件的修復方法（2026）
  聯繫表單和網站郵件進了垃圾箱？你的 Web 伺服器在以未驗證方式發送它們——應改為通過驗證 SMTP 發送站點郵件。46.4% 的網域根本沒有發布 SPF 記錄。真正有效的修復順序。資料截至 2026-06-29。
• 轉發郵件 SPF 失敗——為什麼你修不好它，以及真正有效的辦法（2026）
  轉發在設計上就會破壞 SPF——你寫不出能扛住轉發的記錄。誠實的解法是對齊的 DKIM。根據 Defaults.Exposed 普查，有 7,355,985 個網域單靠 Namecheap 的轉發 include 撑著。資料截至 2026-06-29。