Analyze email headers
This page makes no network call at all (its security policy is connect-src 'none'): parsing happens in your browser, so private headers stay private. For the same reason it cannot look up DNS, so it reads the SPF, DKIM and DMARC results already written into the headers and does not re-verify them.
The two SAMPLE buttons load invented headers (example.org, example.net, example.com, documentation IP ranges) so you can see what a result looks like. They are not real messages. Ctrl+Enter also analyzes.
What this can and cannot tell you
- It reads, it does not verify. SPF, DKIM and DMARC results come from the Authentication-Results and Received-SPF lines. Only trust them if they were added by your own mail provider: a sender can forge such lines before delivery.
- Only the top of the chain is trustworthy. Each server adds a Received line above the previous ones, so the oldest hops (near the sender) are the easiest to fake.
- Heuristics, not verdicts. Mailing services, forwarders and mailing lists legitimately trigger several flags (different Return-Path, Reply-To on another domain, failed SPF after forwarding).
- Domain matching is approximate. Without the Public Suffix List offline, "same organisation" uses the last two labels (three for common cases like co.uk).