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 original headers, not a forward

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. Whether you grab just the headers or the whole message, on the other hand, doesn't matter: the tool reads only up to the first blank line and flags a body that came along as a note.

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 (each server adds its line above the others). The Mail Header Analyzer flips that, so the timeline starts with Written (the Date field) and runs from hop 1 (green) to the last hop (blue). If the order in the raw text and in the Route tab seem opposite — that's exactly right.

The bottom of the header is where forgery starts

Each server can only vouch for its own Received line. The topmost lines were written by your own provider, the lower ones come from servers along the way — and the very first ones the sender can make up freely. So read the Received lines in the raw header from the top down (in the Route tab, that means from the last hop backwards) to the point where the message entered your provider's infrastructure: the server that handed it over there is the sender you can rely on. The Sending server entry in the Overview is a good place to start — it names the oldest hop with a non-internal IP — but with forged lower lines it's no more than a starting point.

Only the topmost Authentication-Results counts

A message can carry several Authentication-Results fields: one from your provider and more from stations along the way — or written in by the sender. That's why the Security tab shows each field on its own and marks only the topmost one green as "topmost — from your provider"; all others carry an orange "added on the way — can be forged". A dkim=pass in an orange card proves nothing. The badges in the Overview and the findings rely solely on the topmost field.

"pass" doesn't mean "trustworthy"

SPF, DKIM, and DMARC only prove that the message really comes from the domain it names — not that this domain belongs to the company it claims to be. A scammer with their own, properly configured domain passes all three checks. So watch the warnings in the Findings: a display name hiding a different address ("service@bank…" in front of an entirely different sender address), a Reply-To on another domain, or a DKIM signature that doesn't match the sender's domain. A diverging Return-Path, on the other hand, is usually harmless — newsletter services and mailing platforms routinely set it to their own domain.

Findings are hints, not a verdict

The Findings card collects anomalies according to fixed rules — red for errors, orange for warnings, purple for notes. Some of them are triggered by legitimate mail too: a Message-ID can be missing from a simply configured script, and clock skew comes from servers with wrong clocks. And the green check mark on a message without findings explicitly says only that no known warning signs showed up — it's no proof of authenticity.

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 ("waited … at …"). 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. If the clocks are more than a minute apart, it also shows up as a note in the findings. 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 and the Date (local) row in the Overview are converted to your local time zone — convenient for direct comparison. Next to each sits the original offset the server logged (e.g. UTC+01:00 or UTC-08:00). 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. If the Date field says -0000 or names an unknown zone, the tool reads the time as UTC and tells you so in the findings.

Missing results are not a failure

If the Security tab reports that there's no Authentication-Results field, or a DMARC check is missing from it, that doesn't mean the message failed — it means there's no result in the headers. The tool doesn't re-check anything itself: it only shows what the receiving servers 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).

A DKIM signature is not yet a DKIM result

The DKIM signatures table shows who signed the message (d=), with which selector, and which fields the signature covers. Whether the signature is valid isn't in there — only the receiving server checks that, and you'll find its result in the topmost Authentication-Results. The telling column is Matches From: an orange no means someone did sign, just not the sender's domain — a mailing service, for instance. For the DKIM part of DMARC, only a signature that matches the sender's domain counts.

Spam score: higher is worse

With SpamAssassin and Rspamd, a higher score means more spam suspicion; a negative value like -2.1 is good. What matters is the distance to the threshold the respective server set — required=… in X-Spam-Status for SpamAssassin, the second number in X-Spamd-Result for Rspamd. For Rspamd the tool compares score and threshold itself; for SpamAssassin it takes the server's Yes/No from the start of X-Spam-Status. Either way it shows the verdict as a badge (spam/ham). Microsoft uses a scale of its own: an SCL of −1 marks the message as trusted, and from 5 the tool rates it as spam; a BCL value for bulk mail of 7 or more as bulk.

Encoded subject lines: read decoded, pass on raw

Subjects and sender names with accented characters appear in the message as =?UTF-8?B?…?= or =?UTF-8?Q?…?=. Overview and All Headers show them decoded, so you can read what the recipient saw. If you need the exact original value — say, for testing a filter rule or a bug report to the sender — turn on Show raw values in the All Headers tab and copy the value from there.

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. By default, nothing is stored at all. Only when you turn on Remember analysed headers in this browser does the tool keep up to ten header sections in localStorage. On a shared or borrowed machine, better leave the switch off — or click Forget when you're done.

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 — dig deeper into a suspicious sending or relay IP from the Received lines: calculate its subnet, identify special-purpose ranges, convert the address format.
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.