/ developer & network toolbox
← all tools

$ hdr

runs locally

Email Header Analyzer

Paste raw email headers to see the delivery hop timeline with delays, SPF/DKIM/DMARC results and key fields. All local.

headers — invoker.tools

Parsed entirely in your browser — headers can expose internal hosts and IPs, so nothing is sent anywhere.

About the Email Header Analyzer

This email header analyzer takes the raw headers from a message, the block you get from Gmail's Show original or Outlook's internet headers view, and turns them into a readable delivery timeline. It parses every Received line into a hop, in the order the message actually travelled, calculates the delay between each hop and the total transit time from the oldest timestamp to the newest, and pulls out the earliest non-private source IP it can find. It also reads the Authentication-Results and Received-SPF headers for the SPF, DKIM and DMARC verdicts the receiving server itself recorded, plus the key identifying headers (From, To, Subject, Date, Message-ID, Return-Path, Reply-To) and anything with spam or filter in its header name.

People search for this as a Gmail header analyzer, a Google email header analyzer or an online email header checker because Gmail's Show original view shows the raw text but does nothing to interpret it, and Google's own Admin Toolbox Messageheader tool requires leaving your workflow to paste headers into a separate site. This does the same job, hop timeline, delays, source IP, authentication results, without an account and without uploading anything.

Everything runs entirely in your browser as plain JavaScript parsing the text you paste. Nothing is sent to a server, which matters here specifically because raw headers routinely expose internal hostnames, private IP ranges and infrastructure details that shouldn't leave your machine just to check why a message was slow or whether it authenticated.

How to use it

  1. Open the message and copy its raw headers (Gmail: three-dot menu, Show original; Outlook: View source or message options).
  2. Paste the full header block into the input box, or click load sample to see the format expected.
  3. Run the analysis to parse every Received line into an ordered hop timeline.
  4. Read the per-hop delay and the total transit time, both computed from the timestamps each server recorded.
  5. Check the source IP the analyzer isolated as the earliest non-private address in the chain.
  6. Review the SPF, DKIM and DMARC results pulled from Authentication-Results, plus any spam or filter headers.

Examples

  • Paste headers from a message that took 40 minutes to arrive, and find one hop responsible for 38 of those minutes.
  • Trace a suspicious message back to its source IP and see SPF fail and DKIM show no signature at all, consistent with spoofing.
  • Confirm a transactional email passed DMARC and moved through every relay in under two seconds per hop.
  • See a negative delay between two hops and recognise it as clock skew between two servers, not an actual time-travel bug.
  • Check a newsletter's headers and find a spam-score header with a low, clean value.

What each part of the analysis is reading

  • Hop timeline: every Received header, oldest first, with the from/by hosts, the IP in brackets if present, and the timestamp after the final semicolon.
  • Per-hop delay: the difference between this hop's timestamp and the previous hop's, so one slow relay stands out from the rest.
  • Transit time: the gap between the very first and very last dated hop, the number that actually answers how long this took end to end.
  • Source IP: the earliest hop whose IP is not in a private range (10.x, 127.x, 172.16-31.x, 192.168.x, 169.254.x), falling back to the first IP found if every hop is private.
  • Authentication: SPF, DKIM and DMARC verdicts read from the Authentication-Results header, with SPF falling back to a Received-SPF header if present.
  • Key headers: From, To, Cc, Subject, Date, Message-ID, Return-Path and Reply-To, shown only when present.
  • Spam/filter headers: any header whose name contains spam, shown so you can see a provider's score or verdict without hunting through the raw block.

Getting raw headers from Gmail, Outlook and Apple Mail

  • Gmail: open the message, click the three-dot menu, choose Show original, then copy the text shown.
  • Outlook desktop: open the message, File then Info then Properties, and copy the Internet headers box.
  • Outlook web (OWA): open the message, click the options menu and choose View message source or view message details.
  • Apple Mail: open the message, View menu, Message, then All Headers.

Reading hop delays without getting misled

A delay is simply the difference between one Received timestamp and the previous one, and that arithmetic is only as good as the clocks on the servers involved. A negative or absurdly large delay almost always means clock skew between two mail servers rather than a real hold-up, especially across servers in different time zones with slightly wrong system clocks. Only the total transit time, computed from the oldest to the newest dated hop, tends to be reliable end to end. Treat any single hop's delay as a clue worth investigating rather than an exact figure.

What this analysis can't tell you

  • SPF/DKIM/DMARC results reflect what the receiving server already decided and wrote into Authentication-Results. This tool does not re-verify a DKIM signature cryptographically itself.
  • If a message has no Authentication-Results header at all, all three results show as unknown, not fail, since there is nothing to read.
  • A DKIM-Signature header being present only means the message claims to be signed. Whether that signature actually verified is what the pass/fail result, when available, tells you.
  • Hops added by internal relays behind a private IP are still parsed but excluded from the source-IP guess, so a message that never left an internal network can show no usable source IP.

Frequently asked questions

Is this the same as Google's email header analyzer?

No, it's not from Google, but it does the same job you'd get from Google's Admin Toolbox Messageheader tool or Gmail's Show original view: parsing the Received hop chain, delays and authentication results. This one runs client-side with no Google account required.

How do I open the header analyzer for a Gmail message?

There isn't a button inside Gmail itself. Open the message, click the three-dot menu, choose Show original, copy the raw text shown, and paste it into a header analyzer like this one to get the parsed timeline and authentication results.

Does this dmarc header analyzer also check SPF and DKIM?

Yes. It reads the Authentication-Results header for all three at once, SPF, DKIM and DMARC, since they're recorded together by the receiving server on most messages.

Is there an email header analyzer online that keeps my data private?

This one does. Parsing happens entirely in your browser's JavaScript. The header text you paste is never sent to a server, which matters because headers often contain internal hostnames and IPs.

Why do I see a negative delay between two hops?

That's clock skew, the two mail servers' system clocks weren't perfectly synchronized when they stamped their Received headers. It doesn't mean anything is broken. Check the total transit time instead for a reliable figure.

What's the difference between an email header checker and an email header analyzer?

In practice, nothing. Both terms describe the same job: parsing raw message headers into a readable summary of delivery path and authentication results.

Why does DKIM show as signed instead of pass or fail?

That happens when a DKIM-Signature header is present but there's no Authentication-Results header recording whether it actually verified. The tool reports that a signature exists without claiming to have validated it itself.

Can I check email headers on my phone?

Yes, the analyzer is a plain web page with a text box. Copy the raw headers from your mail app (most mobile Gmail and Outlook apps expose Show original or view source the same way as desktop) and paste them in.

What does the source IP actually tell me?

It's the tool's best guess at the originating mail server, the earliest Received hop whose IP address isn't in a private range. For a message sent through several internal relays before reaching the public internet, this is the point where it left the sender's network.

Why are there more Received headers than mail servers I'd expect?

Every hop a message passes through, including internal load balancers, spam filters and relay servers within a single provider, adds its own Received header, so a message can easily show more hops than there were meaningfully distinct mail systems involved.

More email / dns tools