Email Header Analyzer

What an email header can: and cannot: show

Internet email uses named header fields followed by a blank line and the message body. RFC 5322 defines the message format, including field folding: a line beginning with whitespace continues the previous field. This analyzer unfolds those continuations before interpreting the data. It stops at the first blank line, so body text and attachments are not analyzed.

Mail transfer agents normally prepend a Received field as a message crosses each server. That means the fields appear newest-first in the raw source. The report reverses them into an origin-first timeline. A timestamp difference is shown only when both adjacent timestamps parse successfully. A negative difference is reported as possible clock skew and prevents a total transit-time calculation; it is never silently changed to zero.

Reading the authentication section

RFC 8601 defines Authentication-Results, a field added by a receiving system to record outcomes such as spf=pass, dkim=pass, or dmarc=fail. The analyzer preserves duplicate Authentication-Results fields because a message can pass through more than one administrative domain. It also keeps associated properties such as smtp.mailfrom, header.d, and header.from as reported.

A DKIM-Signature contains metadata such as the signing domain (d=), selector (s=), algorithm (a=), identity (i=), and large cryptographic values (b= and bh=). This report records useful tags and whether signature values are present, but deliberately excludes signature blobs from JSON exports. No DNS lookup or cryptographic verification occurs.

RFC 8617 defines Authenticated Received Chain (ARC). An ARC instance is structurally complete when it contains an ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results member with the same i= value. “Complete” here describes those three members only; it does not mean the chain is valid or trustworthy.

Worked routing example

Suppose the raw source contains two Received fields. The lower field says an origin handed the message to a relay at 10:00:03 +0000; the upper field says the relay reached the recipient at 10:00:10 +0000. The report displays the origin event first and calculates a 7-second observed interval. Time-zone offsets are honored: 10:00:03 +0000 followed by 12:00:06 +0200 is a 3-second interval, not two hours. If the second normalized timestamp is five seconds earlier, the report flags clock skew and leaves the total unavailable.

Trust boundaries and common pitfalls

RFC 5321 describes SMTP transport and the trace information servers add. Headers received from outside a trusted mail system can be invented. Start trust at a receiver you control, then work downward only as far as that receiver’s records and policies justify. A mismatch between visible From and Return-Path domains is common for mailing lists, forwarding services, and transactional platforms; it is an observation, not evidence of impersonation.

Encoded subjects and display names can use RFC 2047 encoded words. The analyzer decodes common UTF-8, ISO-8859-1, and Windows-1252 Base64 or quoted-printable forms, while leaving unsupported encodings visible with a warning. It caps very large field and hop collections to keep the browser responsive. For incident response, retain the original message separately: exports are concise reports and intentionally do not contain the raw input, body, attachments, or DKIM signature blobs.

Privacy and exports

Parsing, selection, copying, and export creation happen locally in the current tab. Funnel steps use tab-scoped session storage, not a URL, so raw header data is not sent through Livewire or exposed in navigation parameters. The input limit is 512 KiB. Timeline CSV uses UTF-8 with a byte-order mark and CRLF rows, and cells beginning with spreadsheet formula characters are neutralized. JSON includes parsed observations and the report caveat rather than the original header.