定義三種安排
監控通常描述觀察和警報，但該術語本身並不承諾進行調查或補救。託管操作描述了人們執行商定的任務，但其邊界取決於協議。代理輔助工作描述了幫助完成任務的軟體；它沒有規定變更是經過批准的、安全的或自主的。寫下每個提議的安排可以執行的實際行動。
使用行動清單，將讀取、分析、建議、批准、執行和驗證作為單獨的功能。一個能夠推薦的系統 TXT記錄 不需要獲得發布它的許可。核准記錄的審閱者可能仍需要DNS管理員來執行核准的變更。保持存取設計和麵向使用者的狀態的區別。
透過負面控制行使權力
考慮一個假設的權限矩陣：監視器可以讀取和分析；運營商可以另外提出建議；執行需要特定操作的當前授權。在此提議的設計中，必須拒絕未經批准的DNS更改。這些是教學假設，而不是對指定產品的觀察許可或保證。
在實際評估中使用相同的模式：提出缺乏所需批准的變更請求，並檢查結果和稽核追蹤。然後在授權環境中批准範圍嚴格的無害測試，並驗證執行是否與批准的參數相符。測試更改的目標或值是否會使批准無效。如果日誌不能與確切的操作連結起來，則表示已批准的日誌是不夠的。
保留問責制和可逆轉性
對於每項行動，當輸入證據不完整時，請指定負責人。 總結報告 可以揭示身份驗證結果，但不能確定每個來源的業務合法性。自動推薦必須保留這種不確定性，而不是將所有未知流量轉換為未經授權的寄件者標籤。
在允許後續操作之前，需要匯出證據、更改來源、有限權限和復原程序。檢查系統如何處理陳舊資料、核准撤銷和部分失敗。特別是，區分提議的變更、嘗試的變更和已驗證的變更。此書面範例無法證明任何商業實現的安全性。使用建議的控制來定義實際服務必須在組織的存取和更改規則下顯示的行為。
範圍行動和工作量矩陣
虛構的需求矩陣將監控分析分配給內部管理員，將管理調查分配給簽約操作員，並將代理協助的建議分配給軟體，並由授權管理員批准變更。這三者都保留了一個內部服務所有者作為審批者、一個權限不匹配的安全所有者，以及導出開放案例和撤銷範圍訪問的退出要求。證據必須將提議的行動與批准的目標和價值結合起來。
例如，將說明性的 set_txt 授權綁定到_dmarc.brand.test和確切值v=DMARC1; p=none。預期的政策僅允許在其授權有效時執行該操作。改變目標、改變價值、撤回批准、到期或缺席補助金應拒絕執行。在單獨授權的測試中比較預期結果和觀察到的結果；本文不執行其中任何一個，也不向DNS寫入任何內容。
每月工作量假設分配監控 240 分鐘審查時間和 180 分鐘調查時間。託管工作在內部留下 180 分鐘調查時間和 60 分鐘監督時間。代理協助假設 120 次審查、180 次調查和 60 次監督，總計 360 分鐘。假設的審查工作減少量是無法衡量的。費用、入職和事件仍然不包括在內；此矩陣顯示了不同的保留職責如何改變預算，而不是哪種安排更快。
協議範圍和評估限制
RFC 9989第 4.4、5.3.5 和 5.4 節 區分經過身份驗證的標識符， 結盟 和接收器處理。單獨有效的簽名並不完整 DMARC 判決，而通行證並不驗證業務內容。 RFC 9990第 3.1、3.5.1、3.5.4 及 7 節 描述匯總證據、報告身分、副本和隱私。這裡提議的商業評估、人員配置和權限門限是編輯建議，而不是 RFC 規定的產品功能。閱讀這些書面範例不需要缺少可執行補充；操作聲明需要單獨授權的觀察測試。