收件匣螢幕截圖很少包含足夠的證據來診斷身份驗證問題。從受影響郵箱中收到的確切郵件開始。保留獲取資訊的時間和地點，然後收集完整的原始訊息視圖。這使得後來的分析與產生所報告體驗的實際副本相關聯。
取得消息層級證據
參考： RFC 6376 §3.7.
Google 的瀏覽器說明是開啟電子郵件，使用“回覆”旁邊的“更多”，選擇“顯示原始內容”並複製完整的標題。選擇受影響的訊息而不是同一對話中的不同項目。當位元組保留導出可用時，單獨保存可用的原始訊息工件；單獨複製的標頭並不包含重新驗證所需的所有內容 DKIM. Gmail標頭說明.
記錄郵箱上下文、收集時間以及工件是否為原始匯出、複製文字或螢幕截圖。分析人員應該知道行結尾、折疊或MIME內容在收集過程中是否可能發生變化。不要內聯轉發訊息，並將產生的新訊息描述為未修改的原始訊息。
讀取身份和結果
參考： RFC 8601 §5.
谷歌解釋說，郵寄者和簽名者資訊可以幫助檢查身份驗證，而未經身份驗證的郵件不會自動成為垃圾郵件，並且經過身份驗證的郵件也不會自動安全。將視覺指標作為切入點，然後保留完整的證據進行技術分析。 Gmail身份驗證協助.
在值得信賴的 Authentication-Results 場，保留 SPF 結果及其評估身份、 DKIM結果和簽名域以及 DMARC 結果並且從網域中可見。不要將不相關的躍點的結果合併到一個想像的接收者判決中。一條訊息可能攜帶多個簽名或認證結果字段，因此請記錄它們的順序和範圍。 RFC 8601.
保留收到的證據，與複查不同
參考： RFC 6376 §3.6, RFC 6376 §6.
接收器的結果描述了其在處理時的評估。今天的本地DKIM檢查會評估目前可用的位元組和金鑰材料。密鑰輪換、更改的DNS答案或修改的導出可能會產生不同的結果，而不會證明原始接收者是錯誤的。標題文字記錄了聲稱的觀察結果；它本身並不是一種新的密碼驗證。 RFC 6376第 3 節和第 6 節.
隨附的合成訊息有兩個Authentication-Results欄位。解析器回傳兩者，而不是默默地選擇第一個。這是提取測試，而不是Gmail捕獲或信任演算法。在實際調查中，接收服務和可信任路由必須確定哪個結果是相關的。
分享最小有用的神器
參考： RFC 8601 §7.
保留原始限制。當不需要完整的訊息內容或個人地址時，建立單獨標記的診斷副本。保留問題所需的域關係和時間戳，並公開任何編輯。對於簽名驗證，請安排未修改位元組的授權安全傳輸，而不是假裝始終可以檢查經過編輯的副本。
谷歌還描述了一個線上標頭分析器，但將證據貼到任何分析器中都會將其傳輸到該服務。執行此操作之前，請檢查收件人、資料和組織共用規則。最後明確說明Gmail中觀察到的內容、推斷出的內容以及尚未測試的內容。
閱讀註釋的範例而不授予信任
參考： RFC 8601 §5.
保留的註解暫存器會依序列出每個原始欄位及其實際生成器、聲明的來源和信任限制。 From 是作者提供的身份；To 是顯示的收件人，而不是SMTP信封的證明。訊息 ID、日期和主題是寄件者控制的上下文。每個Authentication-Results欄位都聲明一個報告服務和結果，但trusted.example和untrusted.example都無法建立真正的接收者來源。 List-ID 命名所聲明的清單；取消訂閱欄位描述了操作機制，而不是清單所有權。在分類範例中，CAT、DIR、SCL 和 BCL 是 Microsoft 風格的判斷，而不是 Microsoft 的觀察結果。未建立接收鏈、 SPF信封身分或連接 IP。
使用此地圖作為註釋的教學範例。對於真實訊息，用收集和接收者證據替換每個假設的來源，並明確保留任何未經驗證的邊界未解決。