Preserve the raw message before extracting conclusions
An .eml file contains the original message headers and MIME structure needed for a technical review. Work from a copy and calculate a hash when evidence integrity matters. Converting the message to a screenshot or copying only the visible body discards routing, authentication, Message-ID and attachment metadata that can explain how the message moved and which identity a receiver evaluated.
Establish the identity fields first
Record the visible From address, Reply-To, Return-Path, Message-ID domain and every DKIM signing domain before classifying the message. Legitimate third-party senders often use different domains for different roles, so mismatch is not sufficient proof of spoofing. The investigation asks whether those differences are expected, authenticated and consistent with the observed route.
Treat receiver-stamped authentication as historical evidence
Authentication-Results records what a receiver says it observed when the message arrived. That can be more relevant to a historical incident than rerunning DNS today because SPF, DKIM and DMARC records may have changed after delivery. At the same time, Authentication-Results fields from untrusted positions in a message can be forged; relate them to the trusted receiving boundary and to ARC or Received evidence rather than reading every occurrence as authoritative.
Reconstruct the transit chain and measure delay
Read Received fields from the oldest accepted hop toward the newest and extract timestamps, hostnames and IP evidence. Long gaps can identify a forwarding service, security gateway or delivery queue that introduced delay. An unexpected relay can also become a pivot for further investigation, but remember that header syntax varies and private/internal hostnames can legitimately appear inside an organization’s own path.
Inspect MIME structure without executing remote content
Enumerate text and HTML parts, attachments, content types, filenames, transfer encodings and hashes. Extract links and remote-image destinations as data rather than loading them during analysis. This avoids notifying a tracker or fetching potentially harmful content merely because the analyst opened the message. A privacy-focused forensic tool should not silently request remote images, redirectors or scripts embedded in the email.
Separate provenance findings from malware or fraud conclusions
A message can pass SPF, DKIM and DMARC and still be fraudulent if an authorized account or vendor is compromised. Conversely, forwarding can break authentication for legitimate mail. Conclude only what the evidence supports: sender identity relationships, receiver observations, route, structural anomalies and content indicators. Mailybox’s Email Deliverability Forensics Lab keeps those layers visible rather than converting them into an unsupported binary “safe/unsafe” verdict.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.