What this analysis does
The analysis reconstructs the visible transit path, summarizes SPF/DKIM/DMARC/ARC results already stamped by receiving systems, identifies identity fields and computes hop timing when timestamps are available.
A raw header records what receiving systems observed, in the order they observed it. Read correctly it answers three separate questions: which identities the message claimed, what each receiver concluded about authentication, and how the message actually travelled. Those answers should not be collapsed into one score.
Establish the identities before interpreting anything
A message carries several identities that are allowed to differ. The visible From address is what the recipient reads, the Return-Path is the envelope sender that SPF evaluates, the DKIM signing domain belongs to whoever signed the message, and Reply-To directs the response. Legitimate third-party sending routinely produces mismatches among them.
Record all four before drawing conclusions. A mismatch is evidence that needs context, not proof of fraud. The pattern that deserves attention is a Reply-To pointing somewhere unrelated to both the From domain and the signing domain, particularly in a thread that involves payment or credentials.
- From is display identity; Return-Path is the SPF-evaluated envelope.
- DKIM signing domain is frequently owned by the sending platform.
- Differences are normal for third-party senders and must be read in context.
Authentication-Results is receiver-stamped history
The Authentication-Results field records what a receiving system concluded at the moment of delivery. That is more reliable for historical analysis than re-running a live DNS check, because DNS may have changed since the message arrived. A live check tells you about now; the header tells you about then.
Trust the field only from systems inside your own trust boundary. Any sender can insert a header that looks like an authentication result, so a stamp added before the message reached your infrastructure proves nothing. Identify which hop added the field before relying on it.
Read Received lines from the bottom upward
Each system that accepts the message prepends a Received line, so the chronological route runs from the bottom of the block to the top. Reading downward reverses the delivery order and produces confident but inverted conclusions about where a message originated.
Timestamps across the chain expose latency that no single hop reveals. When one intermediary holds a message for minutes while every other hop completes in under a second, that hop is the answer to a complaint that mail is slow. Forwarding boundaries frequently appear here, and ARC sets attached at those boundaries record the authentication state before the transformation.
Visualize the hop-by-hop routeInspect ARC across a forwarding boundary
Example: SPF passes but DMARC fails
Evidence supplied
Authentication-Results reports spf=pass for a platform-owned Return-Path, dkim=pass for the platform signing domain, and dmarc=fail for the visible From domain.
How to read the result
The analysis separates the three results. SPF and DKIM authenticated identities belonging to the sending platform, but neither identity aligned with the domain in the From field, so DMARC could not pass. The fix is a custom bounce domain or custom DKIM signing, not a change to SPF syntax.
Known limits
- Headers added before the message entered your trust boundary can be forged and must not be treated as authoritative.
- A correctly authenticated message can still be malicious when a legitimate account has been compromised.
- Intermediate systems may rewrite or remove fields, so an incomplete chain is common rather than suspicious.
Common questions
Is the analysis performed in my browser or on the server?
The header you supply is transmitted for analysis and is not retained after the response is produced. Redact message bodies and personal content before pasting when the material is sensitive.
Why do the From and Return-Path domains differ?
Most sending platforms use their own envelope domain unless a custom bounce domain is configured. The difference only matters when DMARC alignment depends on that path.
Can a header prove a message is safe?
No. Header analysis establishes provenance and routing. Content safety is a separate question that authentication does not answer.