Free IT Toolbox
Email header analyzer.
What path did this email take, and do its checks add up? Paste its raw headers and get the earliest route visible in them, the SPF, DKIM and DMARC verdicts recorded in the headers, and any mismatch between the address it claims and the addresses underneath. Everything is parsed in your browser: nothing you paste leaves your device, nothing is sent to our server, and the paste box and results are blocked from error-replay recording.
Paste the header block only (up to 256 KB). If the message body comes along, we stop at the first blank line and ignore it.
Your verdicts, the route the message took and the authentication results will appear here.
Getting the headers
Where to find them.
Headers sit above the message body, separated from it by one blank line. Copy from the very first line down to that blank line.
Gmail
Open the message, choose the three-dot menu, then "Show original". Copy everything from the top down to the first blank line. Gmail also shows its own SPF, DKIM and DMARC summary there, which should match what this tool reports.
Outlook (Microsoft 365)
In Outlook on the web, open the message, choose the three-dot menu, then View, then "View message source". In the desktop app, open the message, choose File, then Properties, and copy the "Internet headers" box.
Apple Mail
Select the message, choose View, then Message, then "Raw Source". Copy from the first line down to the first blank line; everything after that is the message body and is ignored here.
Reading the results
Three things headers can tell you.
Headers higher in the block were added later, by servers closer to you. Only trust verdicts recorded by your own provider's servers; anything below them could have been written by the sender.
The route, with delays
Every server that handled the message stamps a Received line. Read oldest first they show the path it took, and the gaps between stamps show where it sat waiting. A stamp that goes backwards usually means a relay with a mis-set clock.
Did it pass the checks?
The receiving server records its SPF, DKIM and DMARC verdicts in an Authentication-Results header (RFC 8601). We read those verdicts back to you in plain English. We do not re-run the checks: that would need DNS lookups, and this page makes none.
Do the addresses agree?
A forged message often shows a friendly From address while bounces (Return-Path) or replies (Reply-To) point somewhere else entirely. Bulk senders also split these on purpose, so a mismatch is a prompt to look closer, not a verdict on its own.
Sellers of forged invoices rely on nobody looking past the From name. If a message asks for money or credentials and anything here looks off, stop and confirm through a number or address you already trust. To check how records for your own domain look from outside, run the Free Technology Checkup.
See everything in the Free IT Toolbox
Related tools: DMARC Record Generator, SPF Record Generator.
A message look wrong?
Do not reply to it and do not use the contact details inside it. Book a free assessment and we will look at the headers with you and check whether your own domain could be spoofed the same way.
Prefer email? support@getwittco.com