SPF 顯示通過，DMARC 仍可能失敗，因為 DMARC 還要確認驗證網域與讀者看到的 From 網域對齊。先讀一封實際收到的原始郵件，找出收件端的 Authentication-Results；不要只看 DNS 檢查工具顯示有一筆 DMARC 紀錄。
用同一封信完成四項比對
請從問題收件服務下載原始郵件，不要轉寄後再分析。轉寄可能改變傳遞路徑與部分驗證結果；寄件平台的樣板預覽也沒有真正收件端的判定。公開討論時遮蔽完整地址、Message-ID 與內部主機資訊，但保留用來比對的示範網域或經授權的必要欄位。
- 在 Gmail 電腦網頁版開啟郵件，從該封信的更多選單選擇顯示原始郵件，保存來源與寄達時間。其他服務請使用其原始郵件或完整標頭功能。
- 記下 From 的網域，以及收件端 Authentication-Results 中 SPF 使用的 smtp.mailfrom、DKIM 的 header.d 與 DMARC 結果。Return-Path 可作為線索，但仍要讀實際驗證欄位。
- 先判斷 SPF 或 DKIM 哪一項通過，再檢查通過那一項的網域是否符合 From 的對齊條件。放寬與嚴格對齊的要求不同，不要只比較字串是否看起來相似。
- 若通過的都是平台自有網域，請依寄件平台官方設定啟用自訂網域驗證或對齊的 DKIM。完成後由原本寄送流程寄一封新信，再檢查新標頭，勿拿舊信當修改結果。
假設案例：顯示品牌，驗證卻屬於平台
假設 From 是 notice@shop.example，而收件端顯示 SPF 通過的網域是 bounce.vendor.example，DKIM 通過的 d=vendor.example。這兩個通過結果本身沒有證明 shop.example 的身分；若不存在其他對齊且通過的驗證，DMARC 仍可能失敗。此處網域僅為示意，不能複製進 DNS。應將標頭交給實際寄件服務，確認哪個自訂簽署或退信網域設定尚未完成。
相反地，若對齊的 DKIM 已通過，SPF 因轉寄而失敗，也不能只憑 SPF 一欄就判定 DMARC 一定失敗。請看收件端 DMARC 結果及整體路徑；涉及轉寄、郵寄清單或閘道改寫時，交由熟悉該郵件系統的管理者檢查。不要為了消除畫面上的紅字，一次刪除所有驗證紀錄。
通過後仍要確認實際落點
DMARC 解決的是寄件身分與網域對齊，不能保證郵件進收件匣。顧客是否期待這封信、過去互動、內容及收件端政策仍會影響結果。診斷表應同時記錄驗證結果與資料夾位置，不要把兩個問題合成一個「通過率」。
如果商店同時使用客服系統、電商平台與電子報服務，必須逐一測試，某一條寄送路徑通過不能證明其他路徑都已完成。變更 DMARC 處置政策前，先盤點合法寄件來源並確認回復方式；本文提供判讀流程，無法取代你對實際 DNS 權限及寄件設定的核對。
若同事只能提供截圖，先要求補上這封信的寄達時間與驗證網域；只看到綠色通過標記，無法確認是哪個網域被驗證。請讓資訊管理者保留完整原始檔，以便在修改設定後追查。
官方參考資料
需要觀察其他收件服務的樣本落點？開始郵件測試，先確認介面當下提供的收件服務，再使用不含顧客個資的測試內容。結果只描述這次樣本，不能代替實際收件者的確認。
閱讀測試方法與限制，比對樣本觀察與實際投遞證據的差異。