Email Header Analyzer

What a header block is

RFC 5322 defines a message as a header block, a blank line, and a body. Each header is a name, a colon and a value, and a long value may be folded across several lines by starting the continuation with a space or a tab. Unfolding has to happen before anything else is parsed — a wrapped Received line otherwise looks like two hops, and a wrapped Authentication-Results header loses half its verdicts.

Beyond a handful of required fields, anything can be a header. Filtering products, mailing platforms and mail servers all add their own, which is why a real message has forty or fifty of them and most begin with X-. Those carry spam scores, campaign identifiers, tenant names and routing decisions, in formats that are specific to each vendor and standardised nowhere, so they are shown raw.

The three addresses a message has

A message carries at least three sender identities and they do not have to agree. The envelope sender, recorded as Return-Path, is where bounces go and is what SPF checks. The From header is what the reader sees. Reply-To, if present, is where a reply is addressed. Every bulk mail platform separates the first two legitimately — bounces go to their infrastructure while the From shows the client's domain — and so does every spoofing attempt.

What distinguishes them is DKIM alignment. A legitimate platform signs with a key for the From domain, or one the From domain has authorised, so DMARC passes despite the mismatch. A spoof cannot do that without the domain's cooperation. This is why a Return-Path mismatch on its own is only worth a note, while a DMARC failure is worth an alert.

Reply-To pointing at an unrelated domain is the sharpest single signal in an ordinary header block. It is the mechanism of business email compromise: the message looks like it came from a colleague or a supplier, and the reply — with the changed bank details in it — goes to the attacker.

Reading the timings

Each Received line ends with a timestamp written by the server that added it, from that server's own clock. Subtracting consecutive timestamps gives the delay at each hop, and that is what turns a header block into an answer to "why did this take four hours".

A gap of seconds is normal. A gap of a few minutes at one hop is usually greylisting, where a receiving server deliberately defers a first delivery attempt from an unknown sender and accepts the retry. A gap of hours is a queue after a temporary failure, and it is generally the receiving side that was unavailable rather than the sender being slow.

Because the clocks are independent, small negative gaps appear routinely and mean a clock is off rather than that anything is wrong. A large negative gap is different: it is also what a fabricated Received chain looks like, so it is worth a second look rather than a shrug.