A 欺騙 投訴是一個線索，而不是一個完整的技術發現。記者可能看到了誤導性的顯示名稱、相似的地址、轉發的訊息或受損的合法帳戶。透過保留他們觀察到的內容、識別缺失的證據並保護任何受影響的業務行為來回應。不要僅僅因為螢幕截圖包含公司名稱就更改網域策略。
收集最小的有用證據集
盡可能使用經批准的安全通道索取原始郵件，以及大致的接收時間、受影響的郵箱和所請求操作的描述。保留編輯前的原始內容。記錄是誰提供的、何時獲得的以及是直接來自接收者還是透過中間人。轉發的正文可能會省略對調查至關重要的標頭。
將原始證據置於適當的存取控制之下。建立單獨的共用副本，刪除不必要的收件者詳細資料、個人內容或不相關的附件，同時保留相關的身分欄位。將兩個檔案雜湊處理並記錄修訂內容，以便審查者可以理解為什麼它們的位元組不同。哈希綁定 一個記錄 到位元組；它們不能證明內容是真實的或寄件者的身分被正確識別。
辨識可信的身份驗證證據
尋找在收到訊息時評估訊息的系統。一個 Authentication-Results 正如RFC 8601所解釋的，字段僅在其既定的信任邊界內才有意義。 認證結果。產生的或不受信任的標頭不應僅僅因為它使用有效的格式而被提升為接收方觀察。
比較 From、信封和 DKIM 身份，而不會將傳遞簽名與業務批准混為一談。 DMARC 解決對齊的網域身份驗證而不是所有形式的模擬。 RFC 9989。如果原始訊息或可信日誌不可用，請保留結果未解決，並描述哪些其他證據會改變它。
建立一個假設的事件分類賬
對於教學案例 DEMO-COMPLAINT-01，假設投訴人透過可見的 From billing@brand-pay.test報告付款更改請求。不提供實際訊息位元組、接收者時間戳記、可信任身分驗證結果和客戶詳細資訊。將原始雜湊記錄為不可用，而不是作為發明的摘要。在獲得相關證據之前，分類仍然是臨時的。
單獨分配建議的下一步操作：郵件操作獲取批准的原始導出和可信任接收上下文；財務透過已知管道驗證請求；事件負責人授權任何必要的共享或遏制。這些都是說明性的角色，而不是接受任務的真實人物。
對於以後的真實共享副本，請記錄原始引用、每個編輯欄位、目的、收件人、批准和結果文件雜湊。保持原始不變。更改的雜湊可以識別更改的字節，但無法確定誰創作了訊息或從未記錄的監管鏈。此書面範例未執行原始檔案、編輯樣本、雜湊計算或外部事件操作。
以有限的發現回應
有用的致謝說明已收到什麼、尚不清楚什麼以及誰正在調查。在身分和路線證據支持該結論之前，避免指責供應商或承諾解決問題。如果資金或憑證可能面臨風險，請在繼續收集證據的同時立即遵循組織的事件流程。聯邦調查局建議對付款請求和帳戶變更進行獨立驗證。 聯邦調查局指導.
為每個遺失的物品指定一個所有者和下一步操作。郵件團隊可以檢索接收者日誌，業務團隊可以驗證請求，安全主管可以協調遏制。將外部共享保持在批准的範圍內，尤其是當原始內容包含敏感資訊時。
僅關閉有證據支持的結論。已確認的相似請求可能會被分類，而提供者歸屬仍未解決。修復合法發送路由可能會彌補身份驗證缺陷，但無法解決業務危害。在最終的事件包中保留這些區別，以便下一個審閱者不會將部分發現誤認為是完整的解決方案。
將調查結果保留在證據範圍內
這些例子是防禦性決策輔助工具，而不是針對真實的人或目前提供者的觀察到的指控。分別保留認證證據、業務驗證和歸屬。目前協議來源描述了網域驗證和可信結果邊界；他們不提供缺失的帳戶證據或授權發布指控。