# Mail Header Analyzer — Tips & Tricks

> Tips for the Mail Header Analyzer: copying headers correctly, timezones and clock skew, reading authentication, privacy, and combining it with other tools.

Source: https://www.jpkc.com/db/en/tools/mail-header/tips/

Back to overview: [Mail Header Analyzer](https://www.jpkc.com/db/en/tools/mail-header/) · Open the live tool: [www.jpkc.com/tools/mail-header/](https://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](https://www.jpkc.com/db/en/tools/mail-header/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 <kbd>Ctrl</kbd>+<kbd>U</kbd>. 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](https://www.jpkc.com/db/en/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](https://www.jpkc.com/db/en/tools/ip/)** — look up and geographically place a suspicious sending or relay IP from the `Received` lines.
- **[Hash generator](https://www.jpkc.com/db/en/tools/hash/)** — add a checksum to a header file saved via **Download**, for instance for an evidence archive.

---

The full reference is in the [manual](https://www.jpkc.com/db/en/tools/mail-header/manual/), concrete walkthroughs in the [examples](https://www.jpkc.com/db/en/tools/mail-header/examples/). You can try everything in the [tool](https://www.jpkc.com/tools/mail-header/).