Analyzed in your browser. Your headers are never uploaded.
How to get your email headers
Every email client hides them somewhere different. Pick yours:
- 1Open the email you want to check.
- 2Click the three-dot menu at the top right of the message.
- 3Choose "Show original".
- 4Click "Copy to clipboard", then paste it above.
What is an email header analyzer?
Every email carries a hidden set of headers recording where it came from, every server it passed through, and what each of those servers concluded about it. An email header analyzer reads that block and turns it into something you can actually act on.
Your mail client can already show you the raw text. The difficulty is that it runs to hundreds of lines of timestamps, hostnames and cryptographic fragments. This tool reads that for you: it tells you whether SPF, DKIM and DMARC passed, whether the authenticated domain matches the sender your recipients see, how long each hop took, and exactly what to fix.
Why read email headers?
1Find out why mail lands in spam
Headers record the receiving server's own verdict. When SPF passes but DMARC fails, the headers show you precisely which domain broke the alignment.
2Verify a suspicious email
A convincing display name proves nothing. The headers show the real sending server, where replies would go, and whether the signature actually belongs to the domain in the From address.
3Diagnose slow delivery
The delivery path shows how long each server held the message, so you can tell a sending problem from a receiving one.
4Confirm a configuration change
After updating SPF, DKIM or a custom bounce domain, one delivered message tells you whether the change is working in production.
How to analyze an email header
Open the message in your mail client and find the raw headers — in Gmail that's the three-dot menu, then "Show original".
Copy the whole header block and paste it into the box above.
Read the verdict and the summary first: they tell you in a few sentences whether the email authenticated and what stands out.
Work through the authentication and alignment sections to see which domain passed and whether it matches the visible sender.
Use the delivery journey and the fixes at the end to resolve anything that needs attention.
What headers reveal most often
SPF passes but DMARC fails
The sending platform authenticated its own bounce domain rather than yours. Set a custom return path, or sign with DKIM using your own domain.
DKIM signature won't verify
Almost always a rotated key that was never republished, or a selector that doesn't match the one in DNS.
Reply-To on an unrelated domain
Common in legitimate helpdesk setups and equally common in phishing. The headers let you tell which one you're looking at.
A hop that took minutes
Usually greylisting or a queue retry. Repeated across many messages, it points to throttling by the receiving provider.
Frequently Asked Questions
Yes, completely free with no sign-up, no daily limit and no account. The analysis runs in your browser, so there's nothing for us to meter.
No. The entire analysis runs locally in your browser using JavaScript — your headers are never sent to our servers, never logged and never stored. That matters because headers contain real recipient addresses, internal server names and IP addresses.
In Gmail, open the message, click the three-dot menu and choose "Show original", then "Copy to clipboard". In Outlook, open File → Properties and copy the "Internet headers" box. In Apple Mail, use View → Message → All Headers. The tabs above the analyzer cover every major client.
Because DMARC also requires alignment. It checks whether the domain that passed SPF or DKIM is the same domain shown in the From address. Sending platforms often authenticate their own bounce or signing domain, which passes both checks but aligns with neither, so DMARC fails. Our alignment section shows exactly which domain broke it.
They give you strong evidence, not proof. Failed authentication, a Reply-To on an unrelated domain, or a signing domain that doesn't match the sender are all warning signs. But headers alone can't confirm intent, which is why this tool reports risk signals and explains them rather than declaring an email malicious.
Usually nothing sinister. Greylisting, queue retries and batch sending all cause multi-minute waits on entirely legitimate mail. It's worth investigating when the same hop is slow across many messages, which can indicate the receiving provider is rate-limiting your sending IP.