詐欺回應團隊需要簡短說明訊息聲稱的身份、接收系統實際驗證的內容以及哪些業務操作仍然不安全。僅長標頭轉儲並不能回答這些問題。保留技術原件，然後充滿信心且未知地建立決策導向的摘要。
將四個身分分開
記錄可見的作者地址、回覆、信封身分和 DKIM 簽署網域（如果存在）。將顯示文本所代表的明顯個人或組織新增為單獨的聲明。看起來合法的顯示名稱可以與不同的網域共存。 DMARC 檢查 域對齊，而不是指定的高階主管是否批准了該訊息。 RFC 9989.
請勿用來源 IP 替換負責人或客戶。共享服務、轉送和網關使路由變得複雜。將基礎設施所有權視為需要與服務記錄和授權調查相關聯的線索，而不是現成的指控。
標記每個證據層
原始導出是捕獲的工件。接收器結果是來自特定身份驗證服務的聲明。業務驗證是透過組織授權的工作流程進行單獨確認。歸因是一個可能仍未解決的調查結論。將這些層放在不同的欄位中，這樣詐欺分析師就不會將一個欄位誤認為另一個欄位。
RFC 8601描述了信任邊界 Authentication-Results。從不受信任的來源複製的欄位不能僅透過包含在事件包中而變得具有權威性。 RFC 8601。保留有問題的欄位作為存在內容的證據，但將它們標記為不可信並要求接收者提供證實的記錄。
建立交接記錄
包括案例識別碼、集合所有者、接收者觀察到的可用時間、原始雜湊、共享副本雜湊、觀察到的身份、業務請求、已知影響和立即採取的下一步行動。說明是否已要求、發起或確認發送付款；不要從電子郵件的措詞中推斷損失。將不必要的個人或財務細節排除在廣泛分享的摘要之外。
對於財務請求，已知聯絡人支票屬於付款所有者。 FBI 建議透過已知管道獨立驗證帳戶和付款變更。 聯邦調查局指導。認證結果應告知該回應，而無需成為財務授權。
審查完整的假設切換
案例 DEMO-FRAUD-01 是一個書面範例，而不是被捕獲的事件。指定顯示名稱範例帳號並可見 From billing@brand-payments.test 。回覆, 信封寄件人 不提供DKIM簽章域。複製的標頭聲稱通過了brand.test，但其可信賴接收者來源未知；身份驗證和演員歸屬仍未解決。
原始檔案、集合時間戳記、原始雜湊、編輯副本雜湊和轉換日誌在此範例中均不可用。不要捏造任何這些價值觀。在實際情況中，授權收集者保留原始文件並準確記錄特定於收件人的派生文件的更改，然後計算每個文件的實際摘要。摘要辨識字節，而不是人類發送者。
假設業務請求是付款變更。資金是否已發起或發送尚不清楚，並且已知聯絡人驗證尚未完成。擬議的財務所有者保留驗證保留；提議的郵件所有者獲得可信的收件人證據；事件負責人批准任何特定共享。這些是不可接受的教學角色分配，而不是執行的回調、編輯或報告。
透過明確的決策請求結束交接：保留付款、調查帳戶、驗證供應商指示或等待指定的證據。這可以防止技術團隊無意中決定採取財務行動，並防止詐欺團隊假設每個未解答的技術問題都會阻止立即遏制。