分離 DKIM 透過郵件流發送金鑰可以使輪換、事件遏制和故障排除變得更加容易。它不會自動建立單獨的網域信譽或將金鑰限制為一類訊息。圍繞每個簽署者收到的權限和使用該權限的實際服務進行設計。
定義可操作的流
列出事務訊息、活動和員工郵件背後的應用程式和提供者。包括計劃作業和小批量關鍵訊息。對於每個路由，記錄寄件人域、預期簽章域、 選擇器、私鑰託管人、 DNS所有者和業務恢復要求。
在平台支援的情況下使用不同的選擇器。在下面 RFC 6376 §3.1，選擇器識別簽章域下的驗證數據，因此不同的選擇器可以防止獨立管理的金鑰在一個查找名稱上發生衝突。不要假設重命名選擇器會創建新的私鑰，或者平台允許獨立旋轉每個流。
確定域是否也需要分離
選擇器組織鍵查找，而不是訊息目的。在d=brand.example下授權的私鑰不受發票或行銷活動的選擇器標籤的限制。如果需要更精細的權限邊界，請考慮支援的簽章子網域以及存取控制和明確寄件者網域選擇。
DMARC 結盟 必須保留該設計的一部分。當組織域關係合格時，子域的簽章可以在寬鬆的規則下與父作者域保持一致。嚴格對齊需要精確的域 RFC 9989 §3.2.10.2。組織域發現必須遵循 RFC 9989 §4.10.2 而不是天真的最後兩個標籤比較。
透過一個隔離範例進行工作
說明性設計：交易郵件使用選擇器 tx1，行銷活動使用 mk1，員工郵件使用 emp1，所有郵件均具有d=brand.example ，但私鑰不同。撤銷 mk1 不需要刪除 tx1 或 emp1 的公鑰。然而，持有 mk1 私鑰的攻擊者仍然可以對brand.example下的訊息進行簽署；名稱 mk1 不強制執行僅限行銷的權限。
這意味著單獨的選擇器減少了一些操作耦合，同時保留了共享域權限。更強的邊界需要單獨的憑證、批准的寄件者控制以及可能的簽名域。這些是建議的控制措施，而不是聲稱每個提供者都公開它們。
按流計劃輪換和故障恢復
為每個流提供獨立的變更視窗和測試集。事務測試應包括對時間敏感的帳戶訊息；活動測試應包括範本和取消訂閱處理；員工測試應運用相關的出站網關。確保內容變更元件在最終預期簽署者之前起作用。
對於普通輪換，保留必要的舊驗證材料，直到滿足批准的隊列和到期條件。對於受損的密鑰，讓遏制要求決定退役，而不是盲目保留重疊。共享私鑰抵消了單獨選擇器名稱的大部分好處。
測量你所建立的邊界
保留路由到密鑰暫存器和註明日期的接收訊息證據。測試旋轉一個流是否會影響另一個流，但不要聲稱發生了這種情況，除非您實際執行了測試。檢查提供者下線的選擇者記錄和帳號權限。
成功是一組可解釋的獨立監護人、變革和復原路徑。聲譽和收件匣放置需要自己的證據； DKIM選擇器架構也無法保證。
檢查混凝土隔離模型
綜合暫存器將 tx1/key-T 指派給應用程式團隊，將 mk1/key-M 指派給活動供應商，將 emp1/key-E 指派給郵件作業。全部標記為brand.example 。在此說明性庫存模型中，刪除 mk1 會將 tx1 和 emp1 保留在保留集中。這次審查沒有執行真正的輪換或檢查私鑰。它不能證明私鑰在真實租戶中不同，或者這些路由仍然發送。如果所有選擇器都使用相同的私鑰，則這種庫存層級分離將無法提供獨立的密鑰材料遏制。
及時收到並不能證明DKIM金鑰隔離。在對設計進行測試之前，請驗證每個實際流的金鑰保管、支援的輪換控制和接收訊息結果。
下一步決定所需的證據
在批准此範例之前，請詢問 tx1、mk1 和 emp1 是否具有不同的公共驗證資料、單獨控制的簽章存取和獨立輪調支援。公共指紋可以比較材料，但不能證明提供者有隔離的私人保管或憑證。如果共用管理，請記錄剩餘的常見故障路徑，而不是呼叫完全隔離的流。