A DKIM選擇器 範圍僅限於簽章域。兩個服務可以在不同的 d= 網域下安全地使用“default”一詞，但default._domainkey.example.com是一個DNS擁有者名稱。如果兩個獨立的服務需要具有相同名稱的不同金鑰，則新增第二個服務可能會破壞第一個服務的驗證。在更改DNS之前解決所有權衝突。
比較完整的名稱
從每個活動服務收集最近收到的簽名訊息並記錄 d= 和s=.將這些值與待處理的提供者設定指令進行比較。對於基於 DNS 的金鑰檢索，選擇器和簽章域決定查找名稱。設定畫面中的提供者標籤（例如「選擇器 1」）不足以識別真正的DNS擁有者。 RFC 6376 §3.5 和 RFC 6376 §3.6.2.1.
說明性範例：薪資和行銷都請求s=default和d=example.com,但各自持有不同的私鑰。兩個簽章都會將驗證者引導至default._domainkey.example.com 。用行銷金鑰替換薪資單的公鑰可能會導致薪資訊息無法驗證，包括已經在傳輸中的消息。相反， d=payroll.example.com下的預設值和d=marketing.example.com下的預設值是不同的查找名稱。 結盟 影響仍然需要單獨檢查。
選擇支援的分離設計
當提供者支援獨立簽章服務時，首選不同的選擇器。以自己的擁有者名稱發布新服務產生的公鑰記錄，對其進行驗證，然後啟用該簽署者並測試收到的郵件。如果服務修復了其選擇器名稱，請詢問它是否支援單獨的簽署子網域或其他記錄的配置。不要發明一個 CNAME 僅在DNS中定位或重新命名選擇器：簽署者必須發出匹配的 s= 值。
將 d= 變更為子網域可能會影響 DMARC。子域可能會在寬鬆的規則下對齊，而無法與父作者域嚴格對齊。在選擇命名解決方法之前確認預期的關係。 RFC 9989 §4.4.1 和 RFC 9989 §4.10.2.
不要依賴模稜兩可的關鍵答案
在下面 RFC 6376 §3.6.2.2、 TXT鍵記錄對於選擇器名稱必須是唯一的；多記錄結果未定義。在一個所有者處發布多個不同的金鑰違反了該發布規則，並且不是服務分離設計。 RFC 6376允許驗證者選擇一個傳回的金鑰或自行嘗試多個金鑰，但順序未指定。因此，在一個接收器上工作的配置在其他地方可能不可靠。單獨的選擇器提供明確映射，而不是依賴鍵選擇行為。 RFC 6376 §6.1.2.
一個TXT資源記錄中的多個帶引號的字串是一個不同的問題：它們可以是單一記錄的一部分。不要將提供者的顯示包裝誤認為是多個不同的按鍵。使用合適的DNS工具將實際DNS答案與提供者產生的值進行比較。
安全處理現有碰撞
如果衝突已經發生，則擷取目前DNS 、配置歷史記錄、受影響的 d/s 對和接收器故障。僅當安全且仍需要時才恢復先前的映射，然後在受支援的不同選擇器下使新服務上線。避免僅僅為了使不相關的服務符合一項公共記錄而在不相關的服務之間共享私鑰；擴大監管和事件影響。
根據安全考慮和提供者的輪換流程，保留舊的驗證記錄，以滿足您合法的延遲郵件路徑需求的重疊。密鑰洩漏則另一種情況，儘管會影響交付，但仍可能需要立即撤銷。更改後獨立測試這兩個服務，記錄其所有者並在清單中保留其選擇器名稱。驗收測試是兩個可驗證的、預期的身份，而不僅僅是兩個綠色的提供者設定畫面。
解決綜合兩項服務請求
假設薪資單目前使用s=default和d=example.com,並且行銷部門請求使用不同的金鑰對同一對進行簽名。查找所有者是相同的，因此請勿覆蓋它或在其旁邊發布第二個獨立密鑰。如果 marketing 支援s=marketing2026,請在marketing2026._domainkey.example.com發布其產生的金鑰，並在其簽署者中配置相同的選擇器。然後獨立測試工資/違約和行銷/marketing2026。如果僅支援簽署子網域選項，請在變更 d 之前檢查其對齊方式。這些是計劃步驟，而不是經過測試的提供者程序。