Skip to content
AZ Tools

Email Header Analyzer

Unfolds RFC 5322 continuation lines, pulls out From/To/Subject/Date/Message-ID, parses every Received line (reversed to chronological order) and computes the wall-clock delay between adjacent hops, and extracts the spf/dkim/dmarc verdicts from Authentication-Results. Useful for diagnosing why a message landed in spam, spotting forged Received chains, or pinpointing which MTA introduced a delay.

  • From"Alice Sender" <alice@example.com>
  • Touser@recipient.com
  • SubjectHello there
  • DateMon, 02 Jun 2026 09:15:38 +0000
  • Message-ID<abc123@example.com>
Authentication
SPFpassDKIMpassDMARCpass
Hops (oldest → newest)
  1. #1
    from sender-host.example.com → by mail.example.com
    Mon, 02 Jun 2026 09:15:40 +0000 (UTC)
  2. #2+2s
    from mail.example.com → by mx.recipient.com
    Mon, 02 Jun 2026 09:15:42 +0000 (UTC)

Everything is parsed locally — no headers leave your browser.

How to use

  1. Paste the full raw headers (everything before the empty line that separates headers from the body).
  2. Read the metadata block, the auth badges, and the hop list.

Frequently asked questions

Where do I get the raw headers?
In Gmail: ⋮ menu on a message → "Show original". In Outlook: File → Properties → Internet headers. Most other clients have a "View source" or "Show original" option.
Why do hops sometimes show a negative delay?
Servers often disagree on clock by a few seconds, and some MTAs back-date their Received line. Tiny negatives are normal; large negatives (or a missing hop) can suggest a forged header.
How much of the Received chain can I trust?
Only the part added by infrastructure you control. Each server prepends its own line as it accepts the message, so everything above your first trusted hop was written by machines you do not run and can be fabricated wholesale. Read the chain from your side outwards and treat the earliest hops as claims rather than evidence.
The message passed SPF and is still obvious spam — how?
SPF checks the envelope sender's domain against the sending server's address, and that domain does not have to be the one the reader sees. A sender can pass SPF for a domain they own while showing a From address that imitates someone else. DMARC exists precisely to require that the visible From lines up with whatever SPF or DKIM actually authenticated.

Related tools