(문서는 영어)
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
- Get the raw headers: in Gmail, open the message → ⋮ → Show original, then copy everything above the message body. Outlook: File → Properties → Internet headers.
- Paste them into Raw email headers (or press Sample to load a built-in demonstration message).
- Press Analyze headers. The report appears on the right, under the verdict banner.
- 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). - 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).
- 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 signingselectorand, when published, the signing domain fromheader.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 evaluatedheader.fromdomain and the domain’sp=policy:none,quarantine, orreject);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), thenmail-sor-f41.google.com → mx.google.com(ESMTPS, +7.0 s), thenmx.google.com(SMTP, +3.0 s). - Authentication — all pass: SPF
passforbilling@legit-shop.com, DKIMpasswith selectorsel2026, DMARCpasswith policyquarantineforlegit-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):
- Return-Path vs From mismatch (critical) — the envelope sender (
Return-Path, where bounces go) uses a different address than the displayedFrom. Classic spoofing; also common in legitimate mailing-list relay. - 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.
- Suspicious mailer string (warning) —
X-MailerorUser-Agentcontains 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). - Hop without a parseable timestamp (info) — that leg’s delay cannot be computed; shown as an “unknown delay” badge.
- Time going backwards (warning) — a hop timestamped before the previous hop: clock skew or a forged
Receivedheader. - 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-Resultsheaders, the first verdict for each mechanism wins; the rest are ignored. - Hop timestamps are read after the last
;of eachReceivedline (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.
.