Oldest observed handoff
All tools
DELIVERABILITY TOOL / 11Email header
Email header
analyzer
Turn raw headers into an evidence map. Read authentication at the correct trust boundary, reconstruct the delivery path, and keep identities distinct.
- Browser-only parsing
- Authentication and ARC
- Hop-by-hop timeline
Raw message headers
Raw headers can contain recipient addresses, internal hostnames, private IPs, message IDs, and campaign identifiers. Analysis stays in this browser and makes no network request.
Read the path, not one badge.
Authentication-Results records what one receiver observed. Received fields describe successive handoffs. DKIM-Signature describes what was attempted. They answer different questions and must be read together.
SignerRelaysReceiver verdictWHO WROTE THE VERDICT?
Authentication-Results is evidence only inside a defined trust boundary.
RFC 8601 records authentication work performed by a receiving system. The authserv-id identifies that system. Fields added before the message entered a trusted environment can be forged, so a parser cannot label every displayed “pass” authoritative. Start with the receiver you control or trust.
DKIM-Signature says what a signer attempted. Authentication-Results says what one verifier observed. DMARC says whether authenticated identifiers aligned with the visible From domain.
TRACE FIELDS ACCUMULATE
Received fields are newest first, but the journey reads oldest first.
Each receiving SMTP system prepends a Received field. The analyzer reverses their display into chronological order and compares parseable timestamps. Large gaps can locate queuing or retry delay; negative gaps can reflect clock skew, malformed dates, or untrustworthy trace data.
Intermediate systems
Receiving authentication
Newest local trace
ONE MESSAGE, SEVERAL IDENTITIES
Visible From, Return-Path, Reply-To, and DKIM d= are separate roles.
The visible From identity is authored message content. Return-Path exposes the final envelope reverse path used for bounce handling. Reply-To redirects human replies. DKIM d= identifies the signing domain. Differences can be legitimate; authentication and alignment rules determine which differences matter.
FromVisible authorDMARC reference
Return-PathBounce identitySPF identity
DKIM d=SignerDKIM identity
AUTHENTICATED RECEIVED CHAIN
ARC preserves handling evidence; it does not erase a final failure.
ARC groups an Authentication-Results snapshot, a message signature, and a seal into numbered sets. A receiver can use a valid chain when local policy evaluates mail modified by an intermediary. The analyzer inventories ARC structure and cv values but does not perform cryptographic chain validation.
COMMON QUESTIONS
Email header analyzer FAQ.
Can I paste a complete email?+
Yes. The analyzer reads content before the first empty line and ignores the body. For forensic work, export the original source from the mailbox rather than copying a UI summary.
Why are there several Authentication-Results fields?+
Different relays or trust domains can perform authentication. Read authserv-id and prefer the result added at the receiving boundary you trust.
Does a DKIM-Signature field mean DKIM passed?+
No. It means a signature was attached. A verifier must retrieve the key, validate the body hash and signature, and report the result.
Can Received timestamps prove exact latency?+
They provide useful evidence, but clocks can be skewed, fields can be malformed, and untrusted upstream trace fields can be forged. Treat the timeline as diagnostic evidence.
Does ARC override DMARC?+
No. ARC can provide authenticated evidence about prior handling. A receiver may use a valid ARC chain in local policy, but the final authentication results and disposition remain receiver decisions.
KEEP DIAGNOSING
TRACE THE MESSAGE
Keep delivery evidence searchable.
Inspect events, authentication, provider responses, and customer activity from one sending workspace.
Start for free