Email Message Header Analyzer
Use the broader header analyzer to place ARC results in the full Received and Authentication-Results context.
Email SecurityEmail Header Forensics: Reading a Message Like an Investigator
Every delivered message carries its own transport log and authentication verdicts. Most of it can be forged by the sender — except the parts written by your own infrastructure, and knowing where that boundary runs is the entire craft.
The trust boundary in the Received chain
Received headers are prepended: each handling server stacks its line on top, so the chain reads top-down from your own edge back toward the claimed origin. The crucial discipline is that only the lines written by servers you trust are evidence. Everything below the first line your own infrastructure wrote arrived as part of the message and costs an attacker nothing to fabricate — plausible-looking hostnames, invented timestamps, an entire fake corporate relay path.
Practical reading therefore starts at the top: find the line where your edge accepted the connection, note the connecting IP recorded there, and treat that IP as the last provably real hop. From there work down with appropriate suspicion, using the Email Message Header Analyzer to parse the chain, timestamps, and per-hop deltas into something readable. Timestamp anomalies — negative hops, hour-long gaps inside one provider — are either clock skew or seams where a story was stitched together; both are worth understanding before drawing conclusions.
Authentication-Results without wishful thinking
The Authentication-Results header written by your own receiving system records the SPF, DKIM, and DMARC verdicts at evaluation time — and, like Received lines, any such header arriving inside the message from outside is just text. Anchor on the authserv-id: read the header written by your infrastructure, ignore lookalikes below the trust boundary.
Then read the verdicts precisely, because the details carry the story. SPF evaluates the envelope sender against the connecting IP — a pass for a domain that is not the visible From tells you about the return path, not the branding the user saw. DKIM names the signing domain in d=; a valid signature from a bulk-sender domain is not a signature from the claimed brand. DMARC is where alignment gets enforced — the verdict that finally connects authentication to the From header a human reads. A message can legitimately carry pass, pass, fail across those three, and that combination — technically authenticated, alignment failed — is the fingerprint of most competent spoofing. Verify a sending domain's published posture separately with the SPF/DMARC/DKIM Checker when the verdicts and the records seem to disagree.
Forwarding, mailing lists, and the ARC trail
Forwarded mail fails authentication for structural reasons: the forwarder is not an authorized SPF host for the origin domain, and list software that adds footers or subject tags breaks the DKIM signature. The receiving system then sees a DMARC failure on mail that was authentic at its source — the exact gap ARC exists to bridge. Each intermediary seals what it observed: ARC-Authentication-Results for the verdicts at that hop, ARC-Message-Signature over the message as it stood, ARC-Seal over the chain so far.
Reading ARC is reading a chain of custody. Instances must count 1, 2, 3 without gaps, the first seal carries cv=none and every later one cv=pass; the d= domains tell you which infrastructure actually handled the message, which is often the most informative fact in the whole header block. And the chain is only as credible as its sealers — cv=pass from a domain you have no reason to trust is a claim, not a credential. Walk the structure with the ARC Chain Validator, then let the transport story and the ARC story confront each other: when the Received chain and the seals disagree about the path, one of them is lying, and finding which one is usually the case.