Email Header Analyzer

Raw headers record what every server that handled a message said about it. Reading them answers the two questions a phishing triage actually turns on: where did this really come from, and did the sending domain authorise it.

Direction matters

Each server prepends its own Received header, so the raw order is reverse-chronological — reading top to bottom describes the journey backwards. The hops below are reversed, so hop 1 is the origin and the last hop is your own infrastructure. Time between hops is shown where both timestamps parse.

Trust matters more

Every hop before the first server you control was written by a party you do not control, and can be invented wholesale. Nothing here is presented as established fact: these are the headers' claims. The portion worth weight begins at your own boundary server, and that is the portion the authentication results speak to.

Authentication

SPF, DKIM and DMARC verdicts are read from Authentication-Results and Received-SPF, as recorded by the receiving server. A mechanism with no recorded result was not evaluated — which is not a failure, and is reported as its own state rather than folded into one. No DNS lookup is performed and no signature is verified here; that verification already happened at delivery, and this reports what it concluded.

Folding

A Received header wrapped across five lines is one value. Continuation lines are joined per RFC 5322 §2.2.3 before anything is parsed, and parsing stops at the first blank line so a body line containing a colon is never mistaken for a header. Blocks that do not parse as Name: value are listed rather than dropped.

A message whose From is a bank and whose Reply-To is a free webmail address is flagged — that mismatch is the mechanical signature of a reply-chain or business-email-compromise attempt. A Return-Path that differs from From is flagged more softly, because mailing lists and bulk senders do it routinely and calling it an attack would be wrong most of the time.