Mail Header Analyzer — Tips & Tricks

Back to overview: Mail Header Analyzer · Open the live tool: www.jpkc.com/tools/mail-header/

Reading headers is quickly learned — interpreting them correctly is the real craft. This page collects what matters in practice. The technical groundwork for it is in the manual.

Copy the headers, and only the headers

The most common pitfall is the source of the data. Always copy the raw header block — in Gmail via "Show original", in Outlook via File → Properties → Internet Headers, in Thunderbird via Ctrl+U. Simply forwarding a message produces a new message, not the original headers — and that loses exactly the information (delivery route, authentication) you want to analyze. If you upload a full .eml file, this doesn't matter: the tool strips the body itself at the first blank line.

The route reads top to bottom — but the headers run the other way

In the raw message, the newest Received header sits at the very top (the last server writes first). The Mail Header Analyzer flips that, so the timeline runs from hop 1 (sender, green) to the last hop (recipient, blue). If the order in the raw text and in the Route tab seem opposite — that's exactly right.

Where the message waited: the gap belongs to the previous server

A Received header's timestamp marks when that server accepted the message. The difference between two hops is therefore the time the message sat in the previous server's queue (queue, greylisting) before the next one accepted it. That's exactly how the tool labels the gap ("Held at … before … accepted it"). A red gap (5 minutes and up) is your prime suspect for a delayed delivery — usually greylisting on the receiving system.

Negative waiting time means clock skew, not "fast"

When the tool reports a clock skew between two hops instead of a waiting time, the servers' clocks disagree: the later server logged an earlier timestamp than the previous one. The real waiting time then can't be calculated. So don't be puzzled by "impossible" orderings — that's a statement about the servers' clocks, not about delivery speed.

You see times locally, the offset reveals the origin

All timestamps in the Route tab are converted to your local timezone — convenient for direct comparison. Next to each sits the original offset the server logged (e.g. UTC+01:00 or UTC-08:00 (PST)). That offset is often more telling than the time itself: it hints at the region a relay sits in. But don't lean on it alone for forensic conclusions — offsets can be forged.

"NOT FOUND" is not a failure

If SPF, DKIM, or DMARC reads "NOT FOUND" in the Security tab, it doesn't mean the message failed — it means there's no result in the headers. The tool verifies nothing itself: it only shows what the receiving server already noted in Authentication-Results (or Received-SPF). Internal messages, very old ones, or mail from servers that don't run authentication checks simply lack these headers. For a genuine check of the DNS side you need a DNS tool (see below).

DKIM "neutral" is a special case

If the tool finds no DKIM result entry but a DKIM-Signature header, it reports status neutral with the note "DKIM-Signature header present (no verification result found)". Read that literally: the message was signed, but whether the signature is valid was not (visibly) verified by anyone. That's different from a hard pass or fail.

Spam score: higher is worse

With SpamAssassin-style filters, a higher score means more spam suspicion. The spam analysis colors follow that: up to 0 green, under 5 yellow, 5 and above red. So a negative value like -2.1 is good. The concrete threshold (required=…) often sits alongside in X-Spam-Status and can differ from server to server.

Privacy: it all stays local — almost

The whole appeal of the tool is that your headers never leave the browser — no server sees IP addresses, recipients, or subjects. There is one caveat: analyzed headers land in a local history within the tool and can be restored after a reload. That stays on your device, but is worth a thought on a shared or borrowed machine — better to analyze someone else's phishing headers on your own system.

Combining with other JPKCom tools

DNS, SSL, Redirect & URL — the natural next step when the Security tab shows an SPF or DMARC problem: check the corresponding DNS records (TXT records) of the sender domain.
IP tools — look up and geographically place a suspicious sending or relay IP from the Received lines.
Hash generator — add a checksum to a header file saved via Download, for instance for an evidence archive.

The full reference is in the manual, concrete walkthroughs in the examples. You can try everything in the tool.