Email Header Analyzer

Unfolds RFC 5322 continuation lines, pulls out From/To/Subject/Date/Message-ID, parses every Received line (reversed to chronological order) and computes the wall-clock delay between adjacent hops, and extracts the spf/dkim/dmarc verdicts from Authentication-Results. Useful for diagnosing why a message landed in spam, spotting forged Received chains, or pinpointing which MTA introduced a delay.

Received headers are prepended, so the newest hop sits at the top of the raw text and the path reads backwards. Reversing them is what makes a delay legible, but the timestamps come from the clocks of unrelated machines, which is why a hop occasionally appears to take negative time. A small negative gap means two servers disagree by a few seconds, not that a message travelled backwards; a large one is worth a closer look, since it is also what a fabricated header produces.

Only the hops inside your own infrastructure can be trusted at all. Anything before the first server you control was written by whoever sent the message, and forging a plausible-looking chain of earlier Received lines takes no special tooling. Read the chain from your boundary MTA outward and treat the rest as a claim.

Authentication-Results carries the same caveat in sharper form: it is an ordinary header that any host can write. It means something when your own inbound server added it and something else entirely when it arrived with the message, and a failing DKIM signature in particular tells you the message does not match what was signed, not who sent it. Note too that SPF authenticates the envelope sender rather than the From address a recipient sees, which is the gap DMARC alignment exists to close.

The analysis is textual and local. Nothing is looked up live, so a DNS-dependent question such as whether a published SPF record still authorises a given relay has to be checked separately.