Email Header Analyzer
Paste raw email headers to see the delivery path, the time at each hop, and the SPF, DKIM and DMARC results.
Read the chain from your side, not the sender’s side
The trust boundary is the point where the message entered infrastructure you control or believe. Every Received header added after that point was written by a server you trust and is reliable. Everything before it was written by a party you do not control, and a spammer will happily add three plausible-looking hops to make a message appear to originate somewhere respectable.
So read from the bottom of the delivery-order list upward, and stop where the trust ends. Anything below that is a claim.
Headers worth knowing
| Header | What it tells you |
|---|---|
| Return-Path | The envelope sender, which is what SPF checks. Frequently differs from the visible From |
| Authentication-Results | The receiving server’s own verdicts on SPF, DKIM, and DMARC |
| Message-ID | Unique per message, usually containing the originating domain |
| X-Originating-IP | Client address, added by some providers and omitted by most modern ones |
| List-Unsubscribe | Present on legitimate bulk mail, and required by major providers for bulk senders since 2024 |
What it cannot tell you
It cannot tell you who wrote a message, and it cannot geolocate a person. The earliest address in a chain, if it is genuine, belongs to a mail server or a provider, and mapping it to a subscriber requires records only that provider holds. If a message is a threat, the headers are evidence for law enforcement rather than something to act on yourself.
About this tool
Paste the full raw headers of a message and the analyzer rebuilds the Received chain in delivery order, shows the time spent at each hop, extracts the originating address where it is visible, and reads the Authentication-Results header for the SPF, DKIM, and DMARC verdicts. Parsing happens in your browser and nothing is uploaded, because headers carry internal hostnames and recipient addresses.
How to read the result
- Received chain order
- Each server prepends its own Received header, so the raw list runs newest first and the analyzer reverses it into delivery order. The bottom header in the raw text is the first hop, the one closest to the sender, and usually the most informative.
- Time at each hop
- The difference between adjacent Received timestamps. Clock skew between servers is common and can produce a negative or absurd interval, while a gap of several hours at one hop is usually greylisting or a queue and is genuine.
- Originating address
- The address in the earliest Received header that a receiving server added. Headers written before the message entered a server you trust can be forged outright, so an address at the start of an internal chain is a claim, not evidence.
- SPF result
- Whether the sending host is authorised to send for the envelope sender domain, as recorded in Authentication-Results. pass means authorised, fail means not, softfail means the domain publishes ~all, none means there is no SPF record, and permerror usually means the ten-lookup limit was exceeded.
- DKIM result
- A cryptographic signature check against a key published in DNS, where pass means the signed headers and body were not modified since signing. DKIM survives forwarding and SPF does not, so a message that fails SPF and passes DKIM has usually been forwarded rather than forged.
- DMARC result and alignment
- The check that ties the other two to the From domain you see in your mail app, which makes it the one that matters for spoofing. DMARC passes when SPF or DKIM passes and the passing domain aligns with the visible From domain, so both can pass while DMARC fails.
Questions people ask
- Can I find the sender's real IP address from email headers?
- Sometimes. Mail sent through a webmail interface generally shows the provider's servers, not the user's connection, because Gmail, Outlook, and most others stopped including the client address years ago. Mail sent from a desktop client through a small server often does reveal the submitting address in the earliest trusted Received header.
- Can email headers be faked?
- The ones the sender adds, yes, entirely. Received headers are prepended in order, and anything added before the message reached a server you trust can be fabricated. Read the chain from your own mail server backwards, and stop trusting at the first hop you do not control.
- The message passed SPF and DKIM but DMARC failed. How?
- Alignment. DMARC requires the domain that passed SPF or DKIM to match the domain in the visible From header. A message sent through a bulk provider can pass SPF for the provider domain and DKIM for the provider domain while the From header shows a different domain, so nothing aligns and DMARC fails.
- Where do I find the raw headers?
- In Gmail, open the message, then the three-dot menu and Show original. In Outlook on the web, the three-dot menu and View message details. In Apple Mail, View, Message, All Headers. In Thunderbird, View, Headers, All, or Ctrl+U for the source.
- Does this upload my email?
- No. The parser runs in your browser and no request carries the text. Headers frequently contain internal hostnames, recipient addresses, and routing details, so keeping them local is the only sensible design.
Related
Last reviewed 2026-09-05.