Mail Header Analyzer — Manual

Back to overview: Mail Header Analyzer · Open the live tool: 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:

Parse — the input view where you paste the headers and start the analysis.
Overview — a summary of the key fields.
Route — the delivery path as a timeline.
Security — SPF/DKIM/DMARC and the spam analysis.
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:

Get the headers — pull the raw headers from your mail client (see Getting the headers).
Paste or upload — paste into the large text area, pick a file via Upload, or drop one in.
Click Analyze (or Ctrl+Enter 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), 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 Ctrl+Enter 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.

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 → Ctrl+U → 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. Concrete walkthroughs are in the examples, strategy and pitfalls in the tips & tricks. You can try everything directly in the tool.