Email Header Analyzer
Turn the unreadable block of headers at the top of an email into a clear report: who sent the message, every server it passed through with timestamps and delays, whether it passed SPF, DKIM and DMARC, and any inconsistencies that suggest spoofing.
- Runs in your browser
- No sign-up
- Free to use
How to use Email Header Analyzer
- Open the original message in your mail program (in Gmail: the three-dot menu, then Show original) and copy the headers, or save the message as an .eml file.
- Paste the headers or open the .eml file here.
- Select Analyse headers.
- Read the authentication results and the route table, and expand All headers for the complete list.
Email Header Analyzer features
Hop-by-hop route
Every Received header in chronological order with sending host, receiving host, protocol and time.
Delay per server
The time each hop took, which shows where a slow message was held up.
Authentication summary
SPF, DKIM and DMARC results from the Authentication-Results header, explained.
Spoofing indicators
Flags a Reply-To on another domain, a mismatched return path and signatures from unrelated domains.
Readable subjects and names
Decodes encoded words so non-English subjects and sender names display properly.
Fully private
Parsing happens in your browser. The message is not sent anywhere.
When to use Email Header Analyzer
- Deciding whether a suspicious message really came from the organisation it claims to be from.
- Finding out why an email arrived hours late.
- Checking that your own outgoing mail passes SPF, DKIM and DMARC at a recipient.
- Gathering the sending server and addresses for an abuse report.
Email Header Analyzer FAQ
How do I find the headers of an email?
In Gmail, open the message, select the three-dot menu and choose Show original. In Outlook on the web, use the three-dot menu, View, then View message source. In Outlook for Windows, open the message and choose File, Properties, and copy the Internet headers box. In Apple Mail, choose View, Message, All Headers. In Thunderbird, press Ctrl+U.
Which headers can I trust?
Headers are added from the bottom up as the message travels. The ones written by your own mail provider, at the top, are trustworthy, including its Authentication-Results. Everything below the point where the message entered your provider's network could have been invented by the sender, so treat early Received lines of a suspicious message with caution.
What do SPF, DKIM and DMARC results mean?
SPF pass means the sending server was authorised for the return-path domain. DKIM pass means a domain's digital signature on the message is valid. DMARC pass means at least one of the two succeeded for the domain shown in the From address. A message that fails DMARC for a domain that publishes a strict policy is very likely forged.
Why is the return path different from the From address?
The return path is where bounces go. Newsletter platforms and transactional mail services use their own bounce domain there so that they can process failures. It is normal, and DMARC still passes when the DKIM signature belongs to the From domain.
Why do some delays show “clock difference”?
Each server stamps the time from its own clock. If one clock is slightly off, a hop can appear to take negative time. Small differences are harmless and are labelled rather than shown as a negative number.
Is the message uploaded for analysis?
No. The headers are parsed by a script in your browser. Links to the SPF, DMARC and DKIM checkers pass only the domain name.
Reading the story a message carries with it
Every email records its own journey. Each server that handles the message adds a Received line to the top, noting which machine handed it over, which one accepted it and when. Read from the bottom to the top, these lines describe the route from the sender's system to your mailbox. The analyzer reverses the order for you, extracts the host names, addresses and timestamps, and calculates how long each step took. A message that sat for an hour at one hop shows exactly where the delay happened, which is the first thing a mail administrator will ask.
The second story is about identity. The From line that your mail program displays is just text supplied by the sender and can say anything. What counts is the verdict of the receiving server, written into the Authentication-Results header: did the sending server pass SPF, was a DKIM signature valid, and did either of them match the From domain so that DMARC passes. Three passes for the domain you expect are strong evidence that a message is genuine.
The absence of a pass is not proof of fraud, since many legitimate senders are poorly configured, but certain combinations are warning signs. A Reply-To address at a different domain means your answer would go to someone other than the apparent sender. A DKIM signature from an unrelated domain shows that some system signed the message, but not the organisation named in the From line. The analyzer points these out so you can weigh them together with the content of the message.
When you report phishing or spam, the headers are what the recipient of your report needs. The sending address in the first external hop and the return-path domain identify the network and the service that should take action.