Skip to main content
Toollyz

Search tools

Search for a command to run...

Email Header Analyzer

Paste raw email headers (view source / show original) to parse the Received chain hop-by-hop, surface SPF / DKIM / DMARC verdicts with the verified domain, and measure transit timing. RFC 5322 unfolding included. 100% offline.

What is the Email Header Analyzer?

Email Header Analyzer parses raw RFC 5322 email headers (the 'View Source' / 'Show Original' content in your mail client) and turns them into a readable forensic view. It unfolds continuation lines, splits the Received chain into individual hops (reversed so index 0 is closest to the sender), extracts the from/by/with/protocol/timestamp from each hop, and computes the inter-hop latency where timestamps are present. SPF / DKIM / DMARC verdicts are pulled from `Authentication-Results`, `Received-SPF` and `DKIM-Signature` headers — each with the method, verdict (pass / fail / softfail / neutral / permerror / temperror), and the domain the verdict applies to. ARC chain authentication is recognised and labelled. The standard identifiers (From, To, Cc, Reply-To, Subject, Date, Message-ID) are extracted to the top. Useful for: investigating delivery issues, hunting phishing, verifying a forwarded message's origin, or just understanding how email actually flows.

How to use it

  1. In your mail client, find 'Show Original' (Gmail), 'View Source' (Outlook), 'Show Raw Source' (Apple Mail), 'View → Message Source' (Thunderbird).
  2. Paste the raw headers — only the part before the first blank line matters.
  3. Read the Received chain (sender → receiver), authentication results, and identifiers in the structured view.
  4. Drill into the all-headers table to inspect anything we didn't surface.

Benefits

  • Parses raw RFC 5322 with proper continuation-line unfolding.
  • Splits the Received chain into hops with from/by/with/protocol/timestamp extracted.
  • Computes inter-hop latency (where timestamps allow) and total transit time.
  • Pulls SPF / DKIM / DMARC verdicts from `Authentication-Results`, `Received-SPF`, `DKIM-Signature`.
  • Verdict colour-coding: pass = green, fail/permerror = red, softfail/temperror = amber.
  • ARC chain authentication recognised and labelled.
  • Standard identifiers (From, To, Subject, Date, Message-ID, Reply-To) extracted to the top.
  • Full headers table for manual inspection.
  • Sample headers loaded by default for safe exploration.
  • Runs 100% in your browser — Toollyz has no server.

Frequently asked questions

Where do I find the raw email headers?

Gmail: open the email → ⋮ menu → 'Show original'. Outlook web: 'View → View message source'. Apple Mail: 'View → Message → Raw Source'. Thunderbird: 'View → Message Source'. Outlook desktop: 'File → Properties → Internet headers'.

What's the Received chain?

Each SMTP server that handles the message prepends a `Received:` header with where it came from, where it's going, and when. The bottom-most Received line is the OLDEST hop (closest to the sender); the top-most is the NEWEST. We reverse the display so the order matches the message's actual path.

What does SPF check?

Sender Policy Framework — verifies that the sending server's IP address is authorised by the sender's domain DNS records. SPF=pass means the envelope sender's domain authorises that IP. SPF=fail means it does not (a common red flag for spoofing).

What does DKIM check?

DomainKeys Identified Mail — verifies a cryptographic signature attached to the email by the signing domain. DKIM=pass means the signature is valid (the message hasn't been modified since signing). DKIM=fail can mean the signature is bad OR the message was modified in transit.

What does DMARC check?

Domain-based Message Authentication, Reporting & Conformance — combines SPF and DKIM with alignment policy. DMARC=pass requires SPF or DKIM to pass AND the authenticated domain to align with the From header domain. Domains with strict DMARC are much harder to spoof.

Why are the latency numbers sometimes weird?

Server clocks drift. Inter-hop latency assumes timestamps are accurate — if a relay's clock is 10s ahead of the previous, that hop will show negative latency. We clamp to 0 in the display. For accurate timing, look at consistently-running relays in the chain.

What's ARC?

Authenticated Received Chain — a newer standard that preserves authentication results across forwarding. When a mailing list forwards your message, the original SPF/DKIM may break; ARC lets the forwarder vouch for the original authentication so the receiver doesn't reject it.

Can it detect phishing?

Yes for the obvious cases: SPF=fail with DMARC=fail and a From-domain that doesn't match the Return-Path is a classic phishing pattern. But sophisticated phishing uses compromised legitimate accounts where everything passes — header analysis alone won't catch those.

What about the IP addresses?

Pull them from the 'Received from' fields. The earliest hop's IP is the actual sender; later hops show the relay chain. Cross-reference with WHOIS / reverse DNS to confirm the sender's identity claim.

Is my email content uploaded?

No. The parser only processes the header text you paste — it doesn't fetch the body. Everything runs locally.

Will it work on Microsoft Exchange headers?

Yes — Microsoft adds extra X-MS-* headers that are passed through to the all-headers table. The core RFC 5322 fields (Received, Authentication-Results, From, etc.) are universal.

See all seo tools