Analys av e-posthuvuden

(Dokumentation på engelska)

What it does

Email Header Analyzer parses the raw headers of an email message (RFC 5322) and turns them into a readable forensic report: a verdict banner that rolls every finding into one at-a-glance call (spoofing indicators found / suspicious signs / clean), a hop-by-hop delivery timeline of every Received server the message passed through with the delay between hops, the SPF / DKIM / DMARC authentication verdicts, and the full list of anomalies — spoofing signals such as a From address that does not match Return-Path, a Reply-To pointing somewhere unexpected, suspicious mailer strings, or timestamps that go backwards.

The layout is split: raw-header input on the left, the live analysis report in a sticky panel on the right that stays in view while you scroll the findings. It is the tool you reach for when a message looks phishing-y and you want evidence instead of a hunch.

How to use it

1. Get the raw headers: in Gmail, open the message → ⋮ → Show original, then copy everything above the message body. Outlook: File → Properties → Internet headers.
2. Paste them into Raw email headers (or press Sample to load a built-in demonstration message).
3. Press Analyze headers. The report appears on the right, under the verdict banner.
4. Read the verdict banner first: red (danger) = at least one critical spoofing indicator, amber = warnings only, green = no anomalies. Severity counts sit on the right of the banner (critical × 1, warnings × 2, notices × 1).
5. Work through the sections: Delivery path (oldest hop first, delay badges color-coded), Authentication (SPF/DKIM/DMARC rows), Anomalies (every finding with its evidence), and All headers (the full unfolded header table).
6. Press Copy share link to get a URL that carries your exact input — anyone opening it sees the same analysis.

Reading the authentication rows. Each row shows the mechanism name, its result word, and the evidence clause it came from:

• SPF — did the sending server’s IP get authorization from the domain in the envelope (smtp.mailfrom)? pass = authorized; softfail = not authorized but the domain only asks receivers to treat it as suspicious; fail = explicitly not authorized, spoofing likely; neutral = the domain makes no claim; none = no policy published; temperror = transient DNS failure; permerror = broken/malformed record. The row’s extra text shows the envelope address that was checked.
• DKIM — was the message cryptographically signed, and does the signature verify? pass = signature valid (the row shows the signing selector and, when published, the signing domain from header.d); fail = signature present but broken — headers or body were modified in transit; none = unsigned; temperror/permerror = the public key could not be retrieved. The detail line shows the raw clause, e.g. dkim=pass header.s=sel2026 header.b=AbCdEf.
• DMARC — did the visible From: domain’s policy accept this message? pass = alignment and the underlying checks satisfied (the row shows the evaluated header.from domain and the domain’s p= policy: none, quarantine, or reject); fail = the message claims an identity whose own policy does not accept it; none = the From domain publishes no DMARC record.

A crucial caveat the sample demonstrates: all three can pass and the message can still be a phishing lure. SPF/DKIM/DMARC verify that the sending domain really sent this message — not that the sender is trustworthy, and not that Reply-To goes where you think. That is why the anomaly list matters even on a fully “green” authentication panel.

Reading the Received chain. Mail servers prepend each Received header, so the tool parses them bottom-up: hop 1 is the origin server, the last hop is your mailbox. Between consecutive hops it shows a delay badge — the elapsed time computed from the two hops’ timestamps:

• green, under 1 second (rendered in milliseconds): normal relay.
• amber, 1–60 s: some queuing or greylisting — usually fine.
• orange, over 60 s: slow relay, mail-provider throttling, or a message that sat in a queue.
• grey “unknown delay”: the hop has no parseable timestamp, so this leg cannot be measured (also raised as an info anomaly).

Timestamps that go backwards (hop N dated before hop N−1) get their own warning: either two servers’ clocks disagree, or someone forged a Received header.

Examples

Load the built-in Sample and press Analyze headers to see every feature at once. Verified output for the sample:

• Delivery path — 3 hops, oldest first: sender.evil.example → mail.relay.example (ESMTP), then mail-sor-f41.google.com → mx.google.com (ESMTPS, +7.0 s), then mx.google.com (SMTP, +3.0 s).
• Authentication — all pass: SPF pass for billing@legit-shop.com, DKIM pass with selector sel2026, DMARC pass with policy quarantine for legit-shop.com.
• Verdict banner — red: critical × 1, warnings × 2, because the anomalies are:

From: "Legit Shop Support" <support@legit-shop.com>
Reply-To: billing@evil.example
Return-Path: bounce@evil.example
X-Mailer: SuperBulk Mass Mailer 4.2

→ Critical: Return-Path (bounce@evil.example) does not match From (support@legit-shop.com) — the envelope sender differs from the displayed sender. Plus warnings for the diverted Reply-To and the bulk-mailer X-Mailer. Authentication passed because legit-shop.com genuinely sent it — the message is still crafted to look like something it is not.

A clean message (envelope matches From, signed, authenticated):

Received: from mail.example.com by mx.google.com with ESMTPS; Tue, 12 Aug 2026 10:15:42 -0700
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=billing@legit-shop.com; dkim=pass header.s=sel2026; dmarc=pass (p=quarantine) header.from=legit-shop.com
From: Billing <billing@legit-shop.com>
Return-Path: <billing@legit-shop.com>

→ Green verdict, “No spoofing indicators found”, zero anomalies.

A failing panel — all three mechanisms render red:

Authentication-Results: mx.example.com; spf=softfail smtp.mailfrom=spoof@wrong.example; dkim=fail header.s=sel1; dmarc=fail (p=reject) header.from=bank.example

→ SPF softfail for spoof@wrong.example, DKIM fail (selector sel1), DMARC fail with policy reject — a message a strict receiver should have bounced.

A forged hop — timestamps that go backwards:

Received: by mx.example.com; Tue, 12 Aug 2026 10:15:40 -0700
Received: from a.example by b.example; Tue, 12 Aug 2026 10:15:50 -0700

→ Warning: Hop 2 is timestamped 10.0s BEFORE hop 1 — clock skew between servers or a forged Received header.

Good to know

Every signal the analyzer checks (severity in parentheses):

1. Return-Path vs From mismatch (critical) — the envelope sender (Return-Path, where bounces go) uses a different address than the displayed From. Classic spoofing; also common in legitimate mailing-list relay.
2. Reply-To differs from From (warning) — replies would be diverted to a third address. Legit for support desks, damning when the From is your bank.
3. Suspicious mailer string (warning) — X-Mailer or User-Agent contains a token associated with bulk-sending tools: bulk, mass mail, massmail, storm, flood, bomber, grabber, harvest, spambot, stealth, anonymous, dark, crack (matched case-insensitively as substrings).
4. Hop without a parseable timestamp (info) — that leg’s delay cannot be computed; shown as an “unknown delay” badge.
5. Time going backwards (warning) — a hop timestamped before the previous hop: clock skew or a forged Received header.
6. No Authentication-Results header (info) — SPF/DKIM/DMARC status cannot be verified from this message at all.

Parser details worth knowing:

• Private: all parsing is 100% client-side — your headers never leave the browser.
• Headers are unfolded per RFC 5322 (continuation lines start with whitespace); parsing stops at the first blank line (the body separator); non-header garbage lines are skipped.
• When a message carries several Authentication-Results headers, the first verdict for each mechanism wins; the rest are ignored.
• Hop timestamps are read after the last ; of each Received line (with a fallback to the first date-looking token), and trailing zone comments like (PDT) are ignored.
• A missing piece is reported, never guessed: unknown delays, unverifiable authentication, and chain gaps all surface as explicit findings rather than silent blanks.
• Related tools: PII Redactor, Defang / Refang,

  Base64Base64An encoding representing binary data as 64 safe ASCII characters, so it survives transport through text-only channels. It encodes — it does not encrypt.

  .