責任矩陣只有在解決某人實際面臨的決策時才有用。当活动被阻止或DNS紧急更改时，说 IT、安全和营销部门都拥有自己的电子邮件会产生歧义。圍繞離散控制及其證據構建矩陣，而不是圍繞每個人對一切負責的廣泛聲明。
單獨的業務和技術決策
行銷人員或其他服務所有者確認需要寄件者的原因以及可以聯繫的人員。 IT 负责DNS 、邮件路由和技术测试。安全性評估濫用風險和未解決風險的處理。這些只是起點，而不是通用的部門分配：將它們對應到組織中具有權威的人員，包括擁有發送工作流程的財務、人力資源或產品團隊。
對於每項控制，指定一個負責角色、負責的操作員、諮詢方、批准範圍和保留的證據。單一負責角色是這裡用來減少歧義的操作慣例，而不是聲稱特定的合規框架強制要求這個確切的矩陣。 NIST CM-3 解決受控變更及其決策； CM-5 解決了進行更改的限制。 NIST SP 800-53.
將職責與真實工件連結起來
使用诸如批准发件人目的、授权DNS差异、应用批准的配置、验证接收者身份验证、审查未知来源和接受限时例外等行。每行應指向一個服務標識符、一個發現或更改標識符以及一個證據工件。会议邀请与批准不同， DNS导出也不是交付测试。
記錄切換條件。 DNS运营商需要准确的批准前后状态。驗證者需要預期的身份、路由和接收者範圍。風險負責人需要未解決的缺陷、業務影響和到期時間。 DMARC 提供技術領域驗證語義，但它不會分配這些組織角色或使通過的結果等同於風險接受。 RFC 9989.
當批准的範圍發生變化時測試移交
Consider a hypothetical billing change approved for one DKIM選擇器。在准备过程中，运营商发现供应商还请求更广泛的DNS更改。原來的批准不涵蓋該新範圍。運營商應保留建議的差異並獲得所需的決定，而不是將一般批准標籤解釋為對每個供應商請求的許可。
在審查變更的範圍時，驗證者仍然可以準備預期的訊息身分和測試計劃。當發生實際授權變更時，將其確切配置和最終路由證據連結到相同的服務和決策。來自不相關的行銷活動服務的正確測試無法關閉帳單的驗證行。本範例未進行任何更改、批准或加密測試。
明確處理缺勤和緊急狀況
在事件發生前指定代表和升級路徑。定義誰可以批准緊急變更、仍必須保留哪些證據以及事後何時進行審查。避免出現常設例外，這種例外會讓操作員在不做出新決定的情況下重新解釋批准並擴大範圍。在較小的團隊中，當角色分離不切實際時，可能需要進行補償性審查。
當服務、團隊、供應商或DNS所有權變更時，請查看矩陣。使用實際場景對其進行測試：未知服務通過身份驗證，或合法的計費訊息在更改後失敗。詢問誰決定、誰行動、什麼證明完成。僅當下一個人可以遵循記錄的交接而無需猜測時才結束練習。這比停電期間沒有人可以使用的大型矩陣更有價值。
透過一項具體更改來檢查交接情況
Before applying a proposed change, ask the operator to identify the approved scope and the verifier to identify the expected evidence. If either must guess, return the handoff for clarification. A later test result cannot retroactively authorize an unapproved change.