Why it matters
Every server that handles an email adds a Received header, and the receiving server records whether SPF, DKIM and DMARC passed. Those headers explain almost every delivery question: why a message took an hour, why it went to spam, whether it really came from the bank it claims to. They are just hard to read, because they are listed newest first and folded across lines.
This analyser unfolds them, puts the hops in travel order with the delay between each, and lays out the authentication verdicts with DMARC alignment worked out. It then lists anything suspicious or broken, from a DKIM body hash failure caused by a mailing list footer to a display name that pretends to be an address. Dates and encoded subjects are parsed exactly as Python's email library parses them.
How to use it
- Open the message's raw source (Gmail: Show original; Outlook: View message source; Apple Mail: All Headers).
- Copy the headers, or the whole source, and paste them in.
- Read the summary and findings.
- Use the hop table to find delays, and the authentication table to see why DMARC passed or failed.
FAQ
How do I read email headers?
Read the Received headers from the bottom up: the lowest is the first server, the top is your mailbox. Authentication-Results near the top records the receiving server's SPF, DKIM and DMARC checks.
Why did DMARC fail when SPF passed?
DMARC needs SPF or DKIM to pass for a domain aligned with the From address. SPF often passes for a mailing service's bounce domain, which isn't aligned.
Why does DKIM fail with body hash did not verify?
The message body was changed after it was signed, usually by a mailing list adding a footer or a gateway rewriting links.
Can headers be faked?
Headers added before the message reached your provider can be forged, but your own provider's Received and Authentication-Results headers at the top can be trusted.
