開發信轉寄後才驗證失敗，該把哪些原始標頭交給 IT？

轉寄後才驗證失敗，先確認是自動轉送、使用者另開新信轉寄，還是附件形式轉交，再保存前後兩個可追查的原始樣本。把 From、Return-Path、DKIM 簽署資料與可信任的 Authentication-Results 分欄交給 IT，不只看一個 pass。這份比對表用來定位差異，不讓業務因一次結果就改 DMARC 政策。

先確認轉寄方式，決定要比的是哪兩個樣本

問清楚對方所說的轉寄：是信箱規則自動送到另一個帳號、郵件清單重新分送，還是使用者按下轉寄並加了自己的內容？若原信只是變成附件，外層新信與附件裡的信也不是同一個評估對象。先分類，才能知道要取得哪些標頭。

對自動轉送，請有權限的管理者說明已確認的路徑，以及原收件系統和最終收件系統。對手動另開新信的情況，記錄它是新郵件，不能把新寄件者的驗證結果直接解讀為原寄件者的結果。若還不清楚，就先保留轉寄方式待確認，不急著比較數字。

Google 的官方轉寄建議指出，轉寄可能影響 SPF，而對受簽署內容的修改也可能影響 DKIM。這說明路徑與內容值得查核，並不表示每次轉寄都一定失敗。先取得實際樣本，再讓管理者判斷這次是否屬於相關情形。

• 轉寄型態：自動轉送、清單分送、另開新信或附件轉交。
• 已知路徑：原收件服務、轉送服務與最終收件服務。
• 樣本關係：同一傳遞鏈，或不同的新郵件物件。
• 未確認處：誰能補足原始資料與路徑。

保留原始郵件和取得方式，不用截圖代替全部資料

分別保存轉寄前與轉寄後的原始郵件，記錄來源帳號、取得時間與保管位置。若對方只願提供遮罩標頭，也要註明缺少哪些部分，不能把它說成完整原始信。業務不需要公開原檔，但 IT 應知道能向哪位獲准人員補件。

每個樣本附上投遞時間、時區與事件索引，並說明何以認定兩者有關。主旨相同不夠，Message-ID 也不能在不同轉寄模式下被機械視為唯一判準。讓管理者結合平台紀錄確認關係，避免把兩封內容相近但無關的郵件拿來做前後對照。

不要複製畫面文字再寄一封，當成轉寄前的原始樣本。複製、編輯或重新封裝可能改變要查核的內容。保存原始版後，再製作對外分享版；對照表只先呈現必要欄位，客戶內文、附件與完整識別碼留在受控位置。

將可見寄件人、傳輸身分與簽署資料分欄

From 欄位要分清楚顯示名稱和實際地址網域。「某公司業務」只是顯示文字，不能代替地址。Return-Path 可作為相關線索，但它可能隨路徑改變；如果要判讀 SPF 的身分，仍須由管理者對照投遞資料與相應驗證結果，不靠單一欄位猜測。

DKIM 資料則保留 d= 與 s=，並將每組簽章分列。原服務的簽章、轉送服務新增的簽章，以及它們各自的結果，不能全合併成一個 DKIM 正常欄位。若某組缺少對應結果，就寫待確認，避免把另一組成功的結果借過來填。

DMARC 關心的是驗證身分與作者網域的對齊，不是看見任意一個 SPF 或 DKIM 通過就足夠。RFC 9989 說明了相關身分與對齊概念；實際比對由管理者按適用條件判斷。本文不提供只憑名稱相似就自行放行的規則。

• From：地址網域，顯示名稱另註。
• Return-Path：原始值或受控代號，並註明樣本。
• DKIM：各組 d=、s= 與可對應的結果。
• SPF、DMARC：評估對象、來源與管理者判讀，不能只抄 pass。

辨認 Authentication-Results 是哪個系統寫的

同一封信可能帶有不同系統留下的 Authentication-Results。先保留完整欄位，再請管理者指出哪個評估來源可被目前收件端採信。RFC 8601 說明，標頭存在本身不代表其內容有效，可信任關係仍需要判斷。業務不宜把最上方或第一個找到的結果自動當成最終結論。

比較 A、B 時，把評估系統、對應方法、結果及相關身分逐項並列。如果 A 的 pass 是原收件端寫的，而 B 的 fail 是另一個系統寫的，這是不同時點與路徑的觀察。應先核對評估對象，不能直接寫「同一系統忽然判錯」。

缺少某項結果時，也不代表該項一定失敗。可能是資料沒有保留、評估方式不同，或需要更多紀錄。用「未見欄位」描述觀察，和「已確認未通過」分開，讓接手人知道下一步應補標頭、查平台事件，還是請評估來源解釋。

把可能變動的位置交給管理者，先不修改驗證政策

將已看到的差異列出，例如轉送後傳輸身分不同、主旨增加標記、內文加入頁尾，或出現另一組簽章。這些是觀察到的變動，不等同於已證明的根因。管理者可以依原始資料查核哪項變動與驗證有關，再決定由原寄件、轉送或收件服務處理。

不要為了測試就把整個網域的 DMARC 政策改寬，也不要隨意把第三方來源加進授權設定。這會把單一路徑排查變成影響其他郵件的變更。若確實需要設定調整，應另列範圍、責任與驗證條件，而不是把一個 fail 當成修改授權的充分依據。

虛構停止案例：只有轉寄後的一張紅色驗證截圖，原信、路徑和評估來源都缺失。此時停止原因判定與政策修改，先取得可核對樣本。若出現安全疑慮，交給有權限的人依公司程序處理，不靠重複轉寄到更多帳號來碰運氣。

• 已觀察差異：標頭、內容或傳遞路徑的可見變動。
• 未證實假設：可能影響的驗證項目。
• 負責窗口：原寄件、轉送、收件或內部管理者。
• 下一步：需要的原始資料、查核方法與停止條件。

交付雙樣本摘要，讓每個判斷能回到原始資料

交接摘要包含轉寄型態、A/B 樣本關係、各欄位差異、可信任評估來源和待確認事項。原始資料另存受控位置，分享摘要遮罩帳號和不必要識別碼，但保留 IT 判讀所需的網域關係；若網域也敏感，則另外確認安全交付方式，不任意改值後仍宣稱真實結果。

管理者回覆後，把根因與修復措施填回摘要，並標示哪些仍只是推測。若安排重測，應先得到相關帳號持有人同意，固定可比較條件並保存新的事件索引。沒有取得新證據前，不把修復完成寫成所有轉寄情況都能通過。

Inbox Check 的獲准落點觀察可以補充投遞結果，不能代替 A/B 原始標頭與轉送路徑的判讀。若測試沒有包含同一轉寄鏈，它也不能證明那條鏈已修好。工具觀察和標頭查核分開記錄，才知道下一次問題出在哪裡。

官方資料查閱於 2026-10-18：Google「將電子郵件轉寄至 Gmail 的最佳做法」，https://support.google.com/mail/answer/175365?hl=zh-Hant；RFC Editor「RFC 9989」，https://www.rfc-editor.org/rfc/rfc9989.html；「RFC 8601」，https://www.rfc-editor.org/rfc/rfc8601.html。本文引用轉寄影響、身分對齊與結果可信任範圍；雙樣本表和交接流程為編輯整理。

實際上可以用免費的收件匣到達率測試（check.live-direct-marketing.online）來驗證。

常見問題