About this tool

What gets parsed

The analyzer extracts and structures these RFC 5322 headers:

Received: headers (the hop chain) — every server that touched the message gets stamped, in reverse-chronological order. We reverse them to show sender → receiver and parse out source hostname, source IP, receiving host, protocol, TLS info, and timestamp per hop.
Authentication-Results: — the receiver's verdict on SPF, DKIM, DMARC, and ARC. We parse spf=, dkim=, dmarc=, and extract signing domains and mail-from domains.
Received-SPF: — older-style SPF result stamping, used as fallback if Authentication-Results isn't present.
DKIM-Signature: — the actual signature attached by the sender (parsed for d= domain, s= selector, a= algorithm).
From, To, Reply-To, Return-Path, Subject, Date, Message-ID — basic metadata, plus alignment checks between From and Return-Path / Reply-To.

What the findings mean

SPF passed — the connecting IP is authorized in the sender's SPF record.
SPF failed/softfail — connecting IP not authorized. Receiver may quarantine or reject.
DKIM passed — the signature in the message verifies against the sender's published public key. Message body wasn't tampered with in transit.
DMARC passed — both: (a) SPF or DKIM passed, and (b) the passing identifier aligned with the From: domain.
No TLS on a hop — message traveled cleartext on at least one link. Anyone on-path could have read it. Increasingly rare on the open internet but still happens with old systems.
Slow transit — a hop took >5 seconds. Usually queuing or greylisting; rarely indicates an attack.
Reply-To ≠ From — used legitimately for mailing lists (BCC group → reply goes to list), but also the #1 phishing pattern. Combined with auth failures, this is a strong phishing signal.

Privacy

Headers are sent to the worker for parsing and discarded immediately. Nothing is logged or stored. You can also disconnect from the internet, save this page, and run the JS-only parsing locally if you want — though that requires a small refactor (the current parser is in the worker for code-sharing reasons).

What this tool can't tell you

Whether the email body was actually malicious (we don't see the body).
Whether attached files are safe (no body, no attachments analyzed).
Whether the sender's domain has a good reputation overall (use Email Health Check for the sender domain instead).
Whether the URLs in the email lead to phishing sites (out of scope).

Pro tip

If a customer says "I got a suspicious email from us", paste their full headers here. You'll see in seconds whether: (a) it actually came from your servers (Authentication-Results) or (b) it's a spoof attempt, and (c) what receiver thought of it. Saves an hour of manual inspection.