電子郵件身分驗證風險登記冊應解釋哪些業務服務可能會受到損害以及哪些決策可以降低該風險。 “DMARC 「缺失」是一項技術發現，而不是完整的風險聲明。將這種情況與可信賴的威脅或故障路徑、受影響的流程、現有的保障措施和負責任的所有者聯繫起來。
描述服務和場景
對於每個條目，記錄服務、網域、應用程式擁有者、技術條件、舉證時間和可能的後果。保持不確定性明確。未被觀察到的寄件者是證據缺口，而經過驗證的未對齊合法寄件者是身分驗證缺陷。兩者都不能自動證明攻擊者已經利用了該服務。
RFC 9989 指定網域身份驗證和 結盟 行為。它的保護並不能確定每個經過身份驗證的請求都是合法的。風險登記冊必須區分直接冒充您的網域名稱與受損的授權帳號或 相似域名 本身經過身份驗證。
分離固有風險和剩餘風險
描述控制措施之前的場景，然後解釋每個現有防護措施的變化。對於發票指令，付款回調驗證可以解決僅網域身份驗證無法解決的詐欺性業務請求。不要暗示書面回調政策的存在證明人們始終遵守它。
使用組織商定的可能性和影響定義。避免在沒有證據的情況下呈現虛構的精確度，例如 17.3% 的年度詐欺機率。如果數據不足，請使用定性評級及其理由和審查觸發點。記錄誰有權接受剩餘風險，而不是將郵件管理員的技術簽字視為業務接受。
使用連結範例
假設假設條目 R-1 涉及工資單。該條件是在已註冊的關鍵服務上缺少當前對齊通過證據。如果未經測試的路線在執行過程中失敗，潛在的後果是錯過薪資通知。這是一個有條件的場景，而不是聲稱員工錯過了訊息。財務負責該服務，郵件團隊負責調查和關閉，需要當前的路由測試以及服務所有者的確認。
R-2 涵蓋透過攻擊者擁有的相似網域進行發票支付模擬。其提議的控制是透過已經可信的聯繫路線進行獨立驗證。在受害者的網域上發布更強的策略並不能滿足 R-2 的封閉測試。對於每個條目，在將提議的登記冊視為完整之前，需要有發現、所有者、決定和明確的結束證據。這是建議的審查規則，而不是執行的驗證或控制措施有效的證明。
保持登記冊可操作
明確選擇處理方法：補救、避免風險活動、在適當的情況下轉移確定的風險，或透過授權的決策流程接受剩餘的風險。設定截止日期並查看觸發器。治療計劃並不是完成的證據；單獨保留實際測試或決策記錄。
這些假設的條目說明了不同的場景，而不是觀察到的攻擊或可接受的業務風險。完整性審查可以識別缺少的字段，但無法驗證風險評級或確定真正的保障措施是否有效。將實際證據和授權接受決定與提議的治療分開。
在遷移、新寄件者、事件和業務變更後查看註冊表。僅關閉其證據滿足規定測試的特定場景，並保留足夠的歷史記錄來解釋關閉的原因。
NIST SP 800-30 Rev. 1 第 2.3 和 3.2 節描述了風險因素、評估方法和記錄評估結果。他們支援明確可能性、影響和不確定性；上述特定於電子郵件的註冊欄位和範例是建議的應用程序，而不是規定的合規性清單。 風險評估指南.