更換 DKIM 金鑰時，如何核對新信簽署與舊信驗證？

正常輪替 DKIM 金鑰時，先把舊新 selector、簽署網域與寄件服務對好，再驗證新信使用新設定，並保留舊信查核所需的原始資料。新信成功一次，不足以決定舊紀錄立即退場；舊信原本顯示 pass，也不等於現在仍可驗證。本文提供輪替紀錄和測試矩陣，不要求業務操作私鑰或自行刪除 DNS。

先確認輪替範圍，避免把不同服務的 selector 混在一起

列出這次要換的是哪個服務的金鑰。員工信箱、CRM 和客服系統可能分別簽署，即使用同一個顯示寄件網域，也不代表共用同一組設定。由管理者指出這次改動的服務、帳戶範圍及操作原因，其他來源先維持原來的盤點狀態。

把目前信件中的 DKIM-Signature 與平台設定對照。d= 指向簽署網域，s= 是 selector；它們不是收件地址，也不是網址追蹤標記。取得原始信時保留完整版本，但工單只先分享必要欄位，不把私鑰、登入憑證或完整客戶往來內容放進紀錄。

本篇處理的是計畫性的正常輪替。如果已知或懷疑私鑰外洩、帳戶遭入侵，應立即交由資安與郵件管理者依事件程序判斷。那不是只要等足某個過渡期就能解決的維護工作，也不能把一般保留原則當成繼續信任遭疑慮金鑰的理由。

• 來源：實際簽署的寄件服務與帳戶範圍。
• 原設定：簽署網域、selector 與確認的樣本事件。
• 新設定：管理者核准的新 selector 及公鑰發布方式。
• 原因：正常維護或安全事件，指定不同處理窗口。

用一張對照表記錄發布、切換和退場

先由管理者確認舊新設定各自對應的公鑰位置和紀錄類型。RFC 6376 的 selector 設計允許在過渡期間讓不同公鑰並存，以便處理尚在傳遞的信件。這是輪替規劃的背景，不是叫業務把舊紀錄改成新值，也不是保證任何平台都提供相同操作介面。

對照表把三個時間分開：新公鑰發布、寄件服務開始使用新私鑰簽署，以及舊紀錄評估退場。每個時間附時區和執行人，並保存可回查的設定版本。若供應商代管金鑰或用 CNAME，保留其正式指示和目標，不把第三方文件的值照抄到自己網域。

同一 selector 直接換掉對應值，與用新 selector 進行過渡，是不同的變更方式。應按服務商支援的流程由管理者決定，並事先知道舊信會如何查核。本文的矩陣需要能區別舊新設定；若供應商不提供這種資訊，就把限制和替代查核方式寫進交接。

切換前先保存舊信樣本與基準，不重寄來冒充原始信

在獲准環境保存一封切換前的原始郵件及其投遞事件，記錄 d=、s=、收件系統和當時的驗證結果。原始格式要能讓管理者回查內容和標頭，而不是只有一張 pass 截圖。檔案保管應限制權限，外部交接則使用必要欄位與代號。

轉寄、複製內文再寄出或重新另存成不同內容，都不等於保留了同一封原始信。若要對舊信作目前驗證，交由管理者在獲准的工具與方法中使用未改動的原始資料，記錄驗證時間和查核條件。不要自行對客戶重送一封舊信，再把新結果當成舊簽章仍可驗證的證據。

舊信的 Authentication-Results 記錄的是某個系統當時的觀察。它可以作為歷史基準，但不能證明現在公鑰仍能取得，或現在驗證仍得到同樣結果。把「當時結果」和「本次重驗結果」分成兩欄，未重驗就明確寫未執行。

• 舊樣本：原始檔案位置、事件索引與保存時間。
• 歷史結果：由哪個收件系統在何時記錄。
• 目前查核：工具或管理者方法、執行時間與結果。
• 限制：內容是否完整、能否重驗、是否只保留截圖。

切換後逐來源確認新簽章，不把 pass 當成全部驗收

新公鑰按服務程序準備好後，由管理者切換簽署，使用獲准的測試帳號取得一封新的郵件。核對它是否真的帶有預期的 d= 與新 s=，再看相應驗證結果。平台顯示設定完成，不代表本次郵件已走到那個簽署來源。

若同一封信有多個 DKIM 簽章，保留每組對應，不要只搜尋到一個 dkim=pass 就認定本次輪替成功。管理者應指出哪組結果對應這次服務與 selector；另一個中繼服務的成功結果，不能代替你正在驗收的那一組。

同一服務若有不同出口或工作類型，按事前盤點的範圍安排查核。例如一般業務回覆與系統通知可能不是同一條寄件路徑。沒有實際樣本的來源保留未測，不能因為一位同事的信箱通過，就把整個寄件服務都填成完成。

根據差異決定補件或暫停，不直接刪除舊紀錄

如果新信仍使用舊 selector，先確認是否查到正確服務、切換是否完成，以及平台是否還有未更新的來源。若使用新 selector 卻驗證失敗，保留完整錯誤及當時查核結果，交由管理者確認公鑰位置、內容與簽署設定。不要在沒有根因時反覆改多項 DNS 值。

如果新信通過，但舊樣本無法以現有方法重驗，先分清楚是原始資料不足、驗證條件不符，還是舊公鑰相關問題。未查明前不要把它簡化為「舊信無用」，也不要承諾永久保留某個結果。輪替紀錄應呈現限制，讓管理者決定下一步。

虛構停止情境：維護者只保留新信的成功畫面，卻找不到切換前的原始樣本，也不知道是否仍有佇列中的舊簽署郵件。此時先停止舊紀錄退場，補查來源與服務程序；如果同時發現安全事件，則切換到相應處置流程，而非照一般維護繼續等待。

• 仍用舊 selector：核對切換範圍及服務來源。
• 新 selector 失敗：保存錯誤，確認發布與簽署條件。
• 舊樣本不可重驗：標明缺件或方法限制，不編造成功。
• 疑似外洩：交資安與郵件負責人依事件程序處理。

由管理者核准正常退場，保存輪替前後的證據

RFC 6376 對正常換鑰的操作建議，是讓舊公鑰保留合理的驗證過渡區間。它沒有替你的業務流程訂一個所有環境通用的天數。實際退場應由管理者綜合服務程序、在途郵件和已完成查核決定，不能只以「等了一天」或「TTL 已過」作為唯一依據。

結案記錄包含新簽署確認、未測來源、舊樣本查核條件、退場核准與實際操作時間。保留必要證據，不保留不需要的客戶信件副本。日後若遇到驗證問題，能看出當時換了什麼、哪個來源被驗證，而不是只找到一張沒有事件編號的綠燈。

若還需要比較收件匣落點，可另安排獲准的 Inbox Check 觀察。DKIM 輪替驗證與落點是不同任務：落點工具不代管私鑰，也不決定舊 selector 何時退場；一封進收件匣的信不能代替簽章與來源對照。

官方資料查閱於 2026-10-18：RFC Editor「RFC 6376」，https://www.rfc-editor.org/rfc/rfc6376.html，參照 selector、簽章欄位與正常換鑰過渡的說明。本文的矩陣及停止條件為編輯整理；實際操作依管理者與服務商程序，不提供通用等待天數或投遞保證。

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

常見問題