Status

—

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).
Where a suspicious sending domain is registered and when it was created — newly-registered domains are a strong phishing signal. Use the WHOIS Lookup to check.
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.

The story email headers actually tell

Every email you send or receive carries a chain of headers that document its journey from origin to inbox. Most email clients hide almost all of these behind a "show original" or "view source" option. When something goes wrong — mail landing in junk, delayed for hours, delivered to the wrong recipient, or rejected outright — the headers usually contain the story of what happened. Reading them well is one of those specialized skills that separates admins who can debug email problems from admins who can't.

I've spent a lot of time reading email headers in customer troubleshooting cases. Half the time the answer is obvious from a careful read; the other half requires knowing what's normal and what's not, which comes with practice. This tool exists to make the read easier by parsing out the structure and highlighting suspicious patterns.

The Received chain: reading the trail backwards

The most important part of an email header is the sequence of Received: lines. Each server that handles the message adds one Received line to the top, so the chain builds up in reverse order — the most recent hop is at the top, the original sending server is at the bottom.

Reading the chain from bottom to top tells you the actual message flow. The bottom line shows where the message originated (or where the sender's outgoing mail server delivered it into the wider mail system). Each line up from there shows the next hop, with timestamps. If a message took eight hours to arrive, comparing timestamps between adjacent hops tells you where the delay was — usually at one specific hop that took much longer than the others.

Each Received line contains a lot of information beyond just the timestamp:

from: the identity the sending server presented (its HELO/EHLO name, and often its actual IP)
by: which server received the message
with: what protocol was used (ESMTP, ESMTPS for TLS-encrypted, LMTP for local delivery, etc.)
id: a unique identifier this server assigned to the message, useful for finding it in that server's logs
for: the envelope recipient (which can differ from the To: header if there were mailing list expansions or forwards)
date: the timestamp

Authentication results: what SPF, DKIM, and DMARC say

The receiving server records the results of authentication checks in one or more Authentication-Results headers. These headers are added by the receiving server and are trusted only within that server's domain. Reading them tells you whether the message passed or failed each authentication mechanism.

SPF result

SPF (Sender Policy Framework) checks whether the sending IP is authorized to send mail for the envelope-from domain. Common results:

spf=pass: the IP is in the domain's SPF record. Legitimate.
spf=fail: the IP is not authorized. Bad sign — either forged sender or misconfigured legitimate sender.
spf=softfail: the IP is not authorized but the domain uses ~all instead of -all, which asks receivers to accept but flag.
spf=neutral: the SPF record explicitly declines to make a policy statement about this IP.
spf=none: no SPF record exists for the domain.
spf=permerror: syntactically invalid SPF record.
spf=temperror: transient DNS lookup failure during SPF check.

DKIM result

DKIM (DomainKeys Identified Mail) checks a cryptographic signature that the sending server added to specific headers and (usually) the body. Common results:

dkim=pass: the signature verifies correctly. Good.
dkim=fail: signature failed to verify. Message was modified in transit, or the signature was forged.
dkim=none: no DKIM signature was present.

DMARC result

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together by requiring that the From: header domain aligns with a passing SPF or DKIM result. Common results:

dmarc=pass: at least one of SPF or DKIM passed with alignment.
dmarc=fail: neither SPF nor DKIM passed with alignment. Either forged mail or misconfigured legitimate sender.
dmarc=none: domain has no DMARC record.

Timing patterns that reveal problems

Long gap between two adjacent Received lines

Usually indicates the message queued at that hop, either because the next hop rejected it temporarily (grey-listing, rate limiting) or because that server had a backlog. A gap of a few minutes is normal on busy mail systems; a gap of hours indicates a real problem.

Clock skew between hops

Timestamps that go backwards (a later hop showing an earlier time than the previous hop) usually mean one of the servers has wrong clock time. Not a security issue but sometimes a sign of a poorly-maintained mail server, which correlates with other problems.

Very fast delivery through many hops

Legitimate mail flow through five or six hops in under a minute is fine. Legitimate mail flow through fifteen hops in ten seconds is unusual and might indicate an open relay chain or a specifically-configured routing that's worth investigating.

Received-SPF older than Received

SPF checks happen at delivery time. If an SPF result was added long before the message actually arrived (based on Date: or other timestamps), something was retried or forwarded strangely. Worth investigating.

Common suspicious patterns

Message-ID from a domain that doesn't match the sender

Message-IDs are supposed to be assigned by the originating mail system. Legitimate mail from user@example.com should have a Message-ID like <random-string@example.com>. If the Message-ID's domain is different from the sender's domain, that's not always suspicious (some sending platforms assign their own Message-IDs) but it can indicate spoofing.

Return-Path different from From

These often differ legitimately — mailing lists set Return-Path to the list address for bounce handling, sending platforms use their own Return-Path domains for bounce tracking. But a Return-Path pointing to a completely unrelated domain from an otherwise-legitimate-looking sender is worth flagging.

DKIM signature over headers only, not body

DKIM can sign just the headers, or the headers and body. Signing only headers means the message body was modified after signing was possible (a common but not universal indicator of intermediate manipulation).

Received from IP that doesn't reverse-resolve

Most legitimate mail servers have reverse DNS. A Received line "from unknown [1.2.3.4]" or with a generic ISP reverse hostname is a weaker legitimacy signal than a proper mail server hostname. Not by itself an indicator of anything specific, but worth noting.

Multiple different HELO/EHLO names for the same IP

If the sending IP claims to be different names in different messages, that's suspicious. Legitimate mail servers usually present a consistent identity.

Anti-spam headers to know about

X-Spam-Status, X-Spam-Score

SpamAssassin and similar filters add these headers with the numerical score and which rules matched. Reading these tells you exactly why a filter thought a message was spam. Useful for understanding false positives on legitimate mail.

X-Report-Abuse, List-Unsubscribe

Legitimate bulk senders add these to help recipients report abuse and easily opt out. Their absence on a large-volume sender is a mild suspicion signal.

ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results

ARC (Authenticated Received Chain) records the results of authentication checks by intermediate servers, so that downstream servers can trust "this was authenticated by a legitimate intermediate" even if the original sender's authentication was broken by the intermediate. Mailing lists use ARC to preserve DKIM validity through list processing.

What headers can't tell you

Whether the sender is the real person

Headers can be forged. Even DKIM-signed and SPF-passing mail isn't proof that the human it claims to be from actually wrote it — it's proof that the sending server was authorized to send for that domain. If the domain's mailbox was compromised, or if someone with legitimate access is sending malicious mail, all the authentication checks pass and the mail looks legitimate.

What the recipient will actually see

Mail clients often re-encode headers, hide attachments differently, apply their own security warnings, and display sender information in idiosyncratic ways. The raw headers are the ground truth of what happened during delivery; what shows up in the recipient's actual mail app is filtered through the client's rendering choices.

Whether attached files are safe

Headers describe attachment presence and MIME types but not attachment safety. Files can claim to be one type and actually be another. Sandbox-based scanning is the right defense against attachment-based threats, not header analysis.

Related tools

If you're troubleshooting delivery for a specific domain rather than a specific message, the Email Health Check examines the domain's MX, SPF, DKIM, and DMARC records for configuration problems that affect all outgoing mail. If you're checking whether a specific IP is on any blocklists, the DNSBL Blacklist Check queries six major blocklists in parallel.

For understanding sending-server ownership, running the Received-line's sending IP through the IP Lookup tool tells you what ASN and organization owns it, which sometimes reveals that a supposedly-legitimate sender is actually operating out of an unexpected network.

Privacy

Header parsing happens entirely in your browser. Headers you paste are not sent to any server. This matters because email headers often contain private information — internal server names, timestamps, IP addresses of intermediate hops — that shouldn't be sent to third parties. You can verify by opening browser developer tools before pasting and confirming no network activity when you click parse.