A DKIM 當服務簽署預期郵件並且收件人可以驗證它時，設定就完成了。僅綠色DNS狀態並不能確定任何結果。選擇TXT或 CNAME 來自提供者支援的金鑰管理模型，而不是將它們視為貼上金鑰的可互換方式。
確定誰管理密鑰
直接發表的 TXT記錄 攜帶DKIM驗證資料。透過CNAME安排， 選擇器 name 是管理驗證資料的另一個DNS名稱的別名。私有簽章金鑰屬於簽章系統，而非任何公用記錄。 RFC 6376 §3.6 和 RFC 6376 §6.1.2 描述密鑰發現和檢索； DNS別名行為定義在 RFC 1034 §3.6.2.
Microsoft 365的自訂網域流程 使用CNAME記錄和租戶產生的目的地。它目前的文檔是一個範例，說明了為什麼複製舊的目標模式是不安全的。取得為實際租戶和所選域顯示的值。此範例並不意味著不相關的服務接受相同的記錄。
在編輯DNS之前，記錄傳送帳戶、可見網域、預期簽章網域、選擇器名稱、記錄類型、確切產生的值和責任擁有者。詢問哪個系統執行輪調以及合約結束時由誰刪除委託。如果提供者無法使用所需的簽署網域，則變更DNS記錄類型將不會建立該功能。
以正確的所有者名稱發布
說明性簽名 d=example.com 和 s=billing 導致 billing._domainkey.example.com。此範例標識了DNS所有者名稱，而不是工作公鑰或生產CNAME目標。
檢查DNS介面是否需要該全名或僅 計費。 _domainkey。有些介面會附加區域名稱。讀回產生的擁有者名稱，而不是假設輸入框保留了它。更改名稱之前檢查現有資料。傳統的CNAME不能與單獨的TXT金鑰記錄共存；保留不相關的選擇器並遵循提供者支援的遷移過程。
對於TXT ，以支援的表示形式發布確切的公共值。對於CNAME ，請使用產生的目標，而不是今天在目標中發現的複製金鑰。在本地複製當前密鑰可能會破壞提供者以後的輪換模型。將螢幕截圖或匯出的記錄保留在更改記錄中，不包括憑證和私鑰。
分別驗證解析度和實際發送
根據權威DNS查詢確切的所有者名稱，然後透過收件者將使用的路徑檢查遞歸解析。對於CNAME ，依照別名到最終TXT結果並記錄任何逾時或遺失目標。在解釋分歧時，允許快取舊數據，包括否定答案。發布和全域快取收斂是不同的觀察結果。
接下來透過真實應用程式發送受控訊息。保留其原始標頭和可信任接收系統的身份驗證結果。記錄 d=, s= 和DKIM驗證。查看 結盟 與可見的 From 域分開。來自提供者擁有的網域的有效簽章可能與您想要驗證的客戶身分無關。
如果DNS解析但郵件未簽名，請調查服務啟動和路由。如果簽章指定了不同的選擇器，請檢查該選擇器，而不是重複編輯未使用的記錄。如果修改內容後驗證失敗，將TXT修改為CNAME並不能修復。
讓依賴負起責任
僅當記錄、簽名者和收到的證據同意時才關閉變更。在切換之前儲存先前的配置和授權的復原計畫。卸載時，停止發送整合並有意取消其驗證依賴性，考慮仍在傳輸中的合法郵件。不要無限期地保留無法解釋的提供者別名，也不要因為合約電子表格顯示服務已結束而刪除活動選擇器。
相關閱讀
DKIM DNS委託：評估授予提供者的控制範圍 · DKIM公鑰語法：辨識截斷或格式錯誤的DNS值.
應用差異
使用三部分驗收記錄：公佈的所有者/類型/值和觀察時間；實際收到的d/s和可信驗證；與預期的作者域保持一致。如果DNS正確但郵件未簽名，請調查啟動或路由選擇，而不是更改記錄類型。如果發出了不同的選擇器，請遵循該證據。此清單是建議的審查工作，而不是執行的DNS或郵件測試。