# Mail Header Analyzer — Manual

> Full reference for the Mail Header Analyzer: all five tabs, Received routes, SPF/DKIM/DMARC, spam analysis, file upload, and privacy.

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

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/)

This manual describes the **Mail Header Analyzer** in full: how the interface is laid out, what each of the five tabs shows, how the tool breaks down the headers internally, and what limits pure browser operation brings. The tool's interface is in English, so the labels appear here in their original spelling.

## Interface layout

The tool is a single card with five tabs:

1. **Parse** — the input view where you paste the headers and start the analysis.
2. **Overview** — a summary of the key fields.
3. **Route** — the delivery path as a timeline.
4. **Security** — SPF/DKIM/DMARC and the spam analysis.
5. **All Headers** — a searchable table of every header.

On start, **only the Parse tab is active**; the four analysis tabs are greyed out and unlock only once you've analyzed successfully. After you click **Analyze**, the tool jumps automatically to the Overview tab. Clicking **Clear** disables the four tabs again and returns you to the input.

## Workflow

The typical workflow has three steps:

1. **Get the headers** — pull the raw headers from your mail client (see [Getting the headers](#getting-the-headers)).
2. **Paste or upload** — paste into the large text area, pick a file via **Upload**, or drop one in.
3. Click **Analyze** (or <kbd>Ctrl</kbd>+<kbd>Enter</kbd> in the text area). The four analysis tabs fill up and you land in the Overview.

### Parse tab

The Parse tab is mission control. At the top sits a large, dark **monospace text area** (`Raw Email Headers`) where you paste the headers. Above it is a button group:

- **Upload** — opens a file dialog and accepts `.eml` and `.txt` files. The file is read locally, the header section extracted (see [File upload](#file-upload)), and analyzed immediately.
- **Example** — fills the field with a realistic sample header (a message delivered through Postfix to Google, with SPF, DKIM, DMARC, and spam headers). Great for getting acquainted; then click **Analyze** yourself.
- **Clear** — empties the field, resets all views, and disables the analysis tabs.

Below sits the **Analyze** button, which kicks off the actual analysis. The keyboard shortcut <kbd>Ctrl</kbd>+<kbd>Enter</kbd> in the text area does the same. You can also **drag a file straight onto the text area** — it highlights while you hover, and the content is loaded and analyzed when you drop.

At the very bottom, a help card (`How to get email headers`) explains where to find them — see [Getting the headers](#getting-the-headers).

If you paste nothing and click **Analyze**, a notice reminds you ("Please paste email headers first."). If not a single header can be read out of the text, you get "Could not parse any headers." with a pointer to the `Key: Value` format.

### Overview tab

The overview shows two blocks. At the top — if present — an **Authentication Summary**: compact badges for SPF, DKIM, and DMARC with their respective status. Below it the **Key Fields** card, a table with the central headers wherever they occur in the message:

`From`, `To`, `CC`, `Subject`, `Date`, `Reply-To`, `Return-Path`, `Message-ID`, `MIME-Version`, `Content-Type`, `X-Mailer`, and `User-Agent`.

Each value has a small **copy icon** to put it on the clipboard individually. Fields absent from the message are omitted; if all are missing, "No common header fields found." appears. If a field occurs more than once, the overview shows the **first** match — the full list including duplicates is in the All Headers tab.

### Route tab

The Route tab reconstructs the **delivery path** from the `Received` headers. Mail servers write these lines in reverse order on receipt (newest first); the tool flips them so the timeline runs from the **sender (hop 1, green)** to the **recipient (last hop, blue)**. Intermediate stops are numbered in grey.

Per hop, a card shows:

- **from** and **by** — the sending and the accepting server, extracted from the `Received` line.
- **Protocol** — the transport protocol after `with` (e.g. `ESMTP`, `ESMTPS`, `SMTP`; "Microsoft SMTP Server" is reported as `Microsoft SMTP`).
- **TLS status** — was the hop transmitted encrypted? When the tool spots signs of transport encryption (`ESMTPS`/`ESMTPSA`, `STARTTLS`, `SSL`, `version=TLS…`, `TLSv1.x`, `with HTTPS`), it shows a green lock with the TLS version (e.g. `TLS 1.3`); otherwise a yellow "No TLS".
- **Timestamp** — when this server accepted the message, **converted to your local timezone**. Next to it sits the **original timezone** the server logged (e.g. `UTC+01:00` or `UTC-08:00 (PST)`).

Between two hops the tool shows the **waiting time** as a gap: "Held at *server X* for *2m 14s* before *server Y* accepted it". A timestamp always marks when a server **accepted** the message — so the difference belongs to the wait at the previous server (queue, greylisting), not to a single hop. The gaps are colored by duration: up to 10 seconds "fast", up to 1 minute "normal", up to 5 minutes "slow", beyond that "very slow". If a difference is **negative**, the servers' clocks disagree; the tool then honestly reports a **clock skew** instead of an invented waiting time.

At the end, a line sums up the **total transit time** and the number of hops — and, if one station stands out, calls out the **longest wait** and where it happened. If no `Received` headers are present, "No Received headers found." appears instead.

### Security tab

The Security tab bundles authentication into three cards — **SPF**, **DKIM**, and **DMARC** — each with a colored status badge and the raw result string:

- **SPF** is read from the `Authentication-Results` header (`spf=…`); if it's not there, the tool falls back to the `Received-SPF` header. Recognized statuses: `pass`, `fail`, `softfail`, `neutral`, `none`, `temperror`, `permerror`.
- **DKIM** likewise from `Authentication-Results` (`dkim=…`; statuses `pass`, `fail`, `neutral`, `none`, `temperror`, `permerror`). If no result is found but a `DKIM-Signature` header is present, the tool reports it as "DKIM-Signature header present (no verification result found)" with status *neutral* — the message was signed, but nobody verified whether the signature is valid.
- **DMARC** from `Authentication-Results` (`dmarc=…`; statuses `pass`, `fail`, `none`, `bestguesspass`).

If a check is missing entirely, the card shows "NOT FOUND". Below comes the **Spam Analysis** card, fed from `X-Spam-Score`, `X-Spam-Status`, `X-Spam-Flag`, and `X-Spam-Level`. A present **score** is colored: up to 0 green, under 5 yellow, 5 and above red — because with SpamAssassin-style filters a higher value means more spam suspicion. At the very bottom, the **Raw Authentication-Results** card shows the unfiltered original header(s), so you don't miss anything the cards didn't evaluate.

### All Headers tab

Here you see **every** parsed header in the order it appeared in the message — numbered, with header name and value. Each value has a copy icon. Above the table:

- a **search field** (`Search headers…`) that filters the table live (matches in name *or* value; case-insensitive);
- **Copy All** — puts the complete raw header text on the clipboard;
- **Download** — saves the headers as a text file named `email-headers.txt`.

A line below the table reports the total number of headers found. Unlike the overview, this tab shows **duplicates** in full (repeated headers such as multiple `Received` lines).

## Getting the headers

The help card in the Parse tab summarizes how to obtain the raw headers:

- **Gmail** — open the message → **More** (three-dot menu) → **Show original** → copy the headers.
- **Outlook** — open the message → **File** → **Properties** → copy from **Internet Headers**.
- **Thunderbird** — open the message → <kbd>Ctrl</kbd>+<kbd>U</kbd> → copy the headers (above the blank line).

All that matters is the **header section** — everything up to the first blank line. You don't need the body; if you upload a full `.eml` file, the tool strips the body itself anyway.

## How parsing works

### Header format and unfolding

The tool breaks the text into `Key: Value` pairs line by line. First it performs **RFC 5322 unfolding**: lines starting with a space or tab are continuations of the previous header and are reattached to it — so long, wrapped headers (such as `Received` or `DKIM-Signature` lines) stay intact as a unit. Blank lines mark the end of the headers and are skipped. Order and **duplicates are preserved** — important, because `Received` occurs multiple times.

### File upload

**Upload** and drag-and-drop accept `.eml` and `.txt` files. The tool reads the file locally as text and splits off the header section at the **first blank-line break** (`\r\n\r\n` first, falling back to `\n\n`). If no blank line is found, the entire content is treated as headers. The body is discarded; a notice reports the number of header lines loaded and whether a body was removed. The analysis then starts automatically.

## Operating limits and privacy

- **Fully client-side:** parsing, route computation, authentication and spam evaluation, and file reading all run only in the browser. There is **no backend, no API, no upload endpoint** — your headers never leave the machine.
- **Local history:** analyzed headers are stored in a browser-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 machine.
- **Heuristic parsing:** the evaluation of `Received` lines, TLS hints, and timestamps targets common formats (Postfix, Exchange/Microsoft, Google). Exotic or malformed headers may be recognized incompletely — the All Headers tab still shows the raw value.
- **No live DNS check:** the tool only reads what the headers say. It does **not** query DNS records and does not cryptographically verify a DKIM signature — it shows the results the receiving mail server already noted in `Authentication-Results`.

For the introduction and target audiences see the [overview page](https://www.jpkc.com/db/en/tools/mail-header/). Concrete walkthroughs are in the [examples](https://www.jpkc.com/db/en/tools/mail-header/examples/), strategy and pitfalls in the [tips & tricks](https://www.jpkc.com/db/en/tools/mail-header/tips/). You can try everything directly in the [tool](https://www.jpkc.com/tools/mail-header/).