DMARC 驗證失敗全解析：從 BestGuessPass 到對齊修復
許多 B2B 業務團隊在啟動開發信寄送前，才發現網域的 dmarc 驗證 失敗，導致信件大量落入垃圾信匣或直接被退回。DMARC 檢測 工具顯示的錯誤訊息往往令人一頭霧水，尤其是「dmarc check is only bestguesspass」這類提示，很多人根本不知道該從何下手排查。本文整理 DMARC 驗證失敗的常見技術原因與逐步排查方法，協助您在大量寄送前把網域驗證做對。
- DMARC 驗證失敗多半不是 DMARC 本身設定錯，而是 SPF 或 DKIM 對齊沒做對
- 看到 dmarc check is only bestguesspass，代表網域根本沒有發佈 DMARC 紀錄，收件伺服器只能用推測結果
- DMARC 政策應從 p=none 起步、觀察聚合報告，再逐步收緊，切勿一次跳到 p=reject
- 多組寄件工具（ESP、CRM、行銷平台）並行使用是對齊失敗最常見的隱藏原因
- 大量寄送開發信前，先用 dmarc check tool 確認驗證通過，再啟動名單，能大幅降低進垃圾信匣風險
為什麼 DMARC 驗證失敗會直接卡住開發信寄送
DMARC（Domain-based Message Authentication, Reporting and Conformance）是 Gmail、Outlook 等主要信箱服務用來判斷寄件網域是否可信的機制之一。當 dmarc 驗證 失敗，收件伺服器無法確認這封信真的來自您宣稱的網域，結果不是被拒收，就是被丟進垃圾信匣，B2B 開發信團隊常見的「明明名單很精準，回覆率卻趨近於零」，很多時候根源就在這裡。
與陌生大量發送不同，鎖定特定公司特定窗口的開發信本來就仰賴信任度：對方公司的郵件安全系統（多半是 Microsoft Defender 或 Google Workspace）會即時檢查 SPF、DKIM 與 DMARC 三項紀錄是否一致。只要其中一環對齊失敗，即便信件內容再有誠意、再個人化，也很難進到收件匣，這也是為什麼在啟動大量寄送前，先確認 DMARC 驗證通過，比優化信件文案更優先。
DMARC 如何運作：SPF、DKIM 與網域對齊
DMARC 本身不驗證信件內容，而是檢查兩件事：寄件網域是否通過 SPF 驗證、是否通過 DKIM 簽章驗證，以及這兩者所使用的網域，是否與信件「From」欄位顯示的網域「對齊」（alignment）。SPF 檢查的是寄件伺服器 IP 是否列在網域的 SPF 紀錄中；DKIM 檢查的是信件是否有效簽章，且簽章網域與 From 網域一致。DMARC 只要求 SPF 或 DKIM 其中一項通過並對齊即可判定通過。
多數 dmarc 驗證 失敗的案例，並非 SPF 或 DKIM 完全沒設，而是「對齊」出了問題——例如用第三方寄件平台代發，SPF 通過的是平台自己的網域，不是您公司網域，導致對齊失敗。這也是為什麼單看 SPF 或 DKIM 是否「通過」不夠，還要看對齊結果。
數字為排查實務中的概略分佈，非正式研究統計，僅供參考
DMARC 驗證失敗排查清單：五個最常見原因
- 網域完全沒有發佈 DMARC 紀錄，或紀錄放在錯誤的子網域（應在 _dmarc.您的網域）
- SPF 紀錄超過 10 次 DNS 查詢上限，導致 SPF 直接判定為 PermError
- 使用多個寄件工具（CRM、開發信平台、行銷自動化）卻只在其中一個設定了 SPF include，其餘平台寄出的信對齊失敗
- DKIM 金鑰在寄件平台後台已設定，但對應的 DNS TXT 紀錄沒有正確發佈或已過期
- From 顯示網域與實際簽章網域不同，例如用子網域寄送但 DMARC 政策未涵蓋該子網域
dmarc check is only bestguesspass 是什麼意思
許多人用 dmarc 檢測 工具查詢時，會看到「dmarc check is only bestguesspass」這樣的結果，第一反應常常是誤以為驗證已經通過。實際上正好相反：這代表您的網域根本沒有發佈任何 DMARC 紀錄，工具只是根據 SPF 與 DKIM 是否對齊，去「推測」如果您有設定 DMARC，結果大概會是通過還是失敗，這個推測結果不會被真正的收件伺服器採用。
換句話說，BestGuessPass 只是一個參考值，不是實際保護。沒有發佈 DMARC 紀錄的網域，等於把「這封信是不是我發的」這個判斷權完全交給收件方自行決定，各家信箱服務的處理方式並不一致，這也是不少開發信寄送不穩定、忽好忽壞的原因之一。
以某家台北的工業零件貿易商為例，該公司過去用內部 mail server 寄開發信，dmarc 檢測 工具長期顯示 BestGuessPass，業務團隊誤以為驗證沒問題；直到改用 dmarc check tool 實際查詢 _dmarc 子網域的 TXT 紀錄，才發現從未發佈過 DMARC 政策，補上 p=none 的紀錄並觀察兩週聚合報告後，才確認 SPF 對齊其實一直是失敗的。
排查與修復步驟
- 先用 dmarc check tool 查詢 _dmarc.您的網域 的 TXT 紀錄是否存在
- 若不存在，先發佈 p=none 政策並設定 rua 聚合報告信箱，用兩週左右觀察真實寄送情況，不要一開始就設 p=reject
- 檢查 SPF 紀錄是否包含所有實際會用到的寄件平台（開發信工具、CRM、公司信箱），並確認未超過 10 次查詢上限
- 確認每個寄件平台的 DKIM 金鑰都已在 DNS 正確發佈，且簽章網域與寄件網域一致
- 若使用子網域寄送開發信，另外確認 DMARC 政策是否涵蓋該子網域，或用 sp= 標籤單獨設定
- 修改 DNS 後至少等待 24–48 小時讓全球快取更新，再重新檢測，不要在幾分鐘內反覆判定失敗
常見錯誤：讓 DMARC 修復功虧一簣
最常見的錯誤是修完 SPF、DKIM 後立刻把政策改成 p=reject，結果因為還有沒對齊的寄件來源（例如公司內部還在用的舊行銷工具），導致合法信件被直接拒收，業務團隊反而收到更少的回覆，卻誤以為是內容問題，開始瘋狂改文案，浪費時間在錯誤的方向上。
另一個常見狀況是同時操作多個網域或子網域寄送開發信，卻只修好其中一個的 DMARC 對齊，其餘網域仍是 dmarc 驗證 失敗的狀態，導致寄送結果忽好忽壞，難以歸因；建議把所有會用來寄開發信的網域與子網域逐一列出並個別驗證，而不是假設主網域驗證通過，子網域應該也沒問題。
大量寄送開發信前的驗證檢查清單（LDM 作法）
在 LDM，任何鎖定特定公司窗口的開發信名單啟動前，都會先跑一輪網域驗證檢查，而不是等到寄出後才透過退信率回頭排查，這個順序很重要，因為 DMARC 對齊問題一旦在大量寄送中才發現，往往已經影響了網域的寄件信譽，修復需要更長時間觀察。
- 確認 dmarc 檢測 結果不是 BestGuessPass，而是真正發佈且對齊通過的紀錄
- SPF、DKIM 分別用不同的 dmarc check tool 交叉驗證，避免單一工具誤判
- 小批量測試寄送，例如先對 20–30 個真實但低風險的收件網域，觀察是否進入收件匣而非垃圾信匣
- 確認聚合報告（rua）有正常寄達並定期查看，及早發現新增寄件來源造成的對齊漂移
- 每季覆核一次 DMARC 政策與紀錄，尤其在更換寄件工具或新增行銷平台後
常見問題
DMARC 驗證失敗一定會讓信件進垃圾信匣嗎？
不一定，但風險大幅提高。部分收件系統對 dmarc 驗證 失敗的信件採取隔離而非直接拒收，可能仍會送達，但機率明顯較低，長期下來也會影響網域的整體寄件信譽。
dmarc check failed 跟 bestguesspass 是同一個問題嗎？
不是。dmarc check failed 通常代表已經發佈 DMARC 紀錄，但 SPF 或 DKIM 對齊沒有通過；bestguesspass 則代表根本沒有發佈 DMARC 紀錄，工具只是用 SPF／DKIM 結果做推測，兩者的修復方式不同。
修好 DMARC 後多久能看到效果？
DNS 變更通常需要 24–48 小時讓全球快取更新，之後建議再觀察一到兩週的聚合報告，確認所有寄件來源都對齊通過，才逐步收緊政策，不要期待當天就有明顯改善。
可以直接設定 p=reject 嗎？
不建議一開始就設。應先以 p=none 觀察聚合報告，確認沒有遺漏的寄件來源後，再視情況調整為 p=quarantine 或 p=reject，直接跳到 reject 容易誤擋合法信件。
有推薦的 dmarc check tool 嗎？
市面上多款線上 DNS 查詢工具都能查詢 _dmarc 紀錄與聚合報告內容，選擇能同時顯示 SPF、DKIM 對齊結果的工具即可，重點是定期查，而不是只查一次就假設一直有效。