Start with the identities
Record the visible From address, Reply-To, Return-Path and DKIM signing domain before deciding what the message means. These fields can legitimately differ when a third-party sender is involved, but the relationships between them matter for authentication and impersonation analysis. Treat a mismatch as evidence that needs context, not automatic proof of fraud.
Read Authentication-Results as receiver-stamped evidence
Authentication-Results tells you what a receiving system says it observed for SPF, DKIM and DMARC. It is more useful than re-running a public DNS check when you are trying to understand a historical delivery because DNS may have changed since the message arrived. At the same time, forwarding and intermediate systems can complicate the path, so authentication evidence should be read together with ARC and the Received chain.
Reconstruct the route from Received fields
Each receiving system normally adds a Received line. Because new lines are added at the top, the chronological route is read from the oldest accepted hop toward the newest. Timestamps can expose a message that spent seconds or minutes at one intermediary while every other hop was nearly immediate. That distinction is critical when the user describes a problem as “email is slow.”
Separate provenance from content safety
A message can be correctly authenticated and still be malicious if an authorized account is compromised or the sender intentionally sends harmful content. Header analysis answers questions about identity, routing and receiver observations. It does not make links or attachments safe by itself. Keep that boundary explicit when using an authenticity score or forensic report.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.