Understand what your scan results mean / Headers
A practical guide to reading email headers without getting lost
Raw email headers look like noise, but they follow a consistent structure once you know what to look for — here's the order to read them in, and which parts actually matter for troubleshooting.
Headers are added by every server a message passes through, and — this is the part that trips people up — they stack in reverse order: the topmost "Received:" header is the last hop (closest to you), and the bottommost is the first hop (closest to the sender). Reading top-to-bottom actually walks the delivery path backward in time.
For troubleshooting a specific problem, most of the noise can be ignored. Start with "Authentication-Results": this single header usually summarizes the SPF/DKIM/DMARC verdicts the receiving server already computed, saving you from re-deriving them by hand. Then check whether the visible "From:" domain matches the domain that actually passed SPF/DKIM (alignment) — a mismatch here is the single most common reason a legitimately-authenticated message still gets flagged as suspicious.
The "Received:" chain is worth reading when the authentication looks fine but delivery was slow or took an unexpected path — each hop includes a timestamp, so subtracting consecutive timestamps shows exactly where time was lost. A single hop that took much longer than the others is usually where to look first.
What to do: rather than reading raw headers by hand, Korantix's Header Analyzer reconstructs this into a visual timeline, a plain alignment verdict, and a deterministic list of anomalies — entirely client-side, nothing sent to a server — which is the same information this guide describes, just pre-parsed.