Email Header Analyser
Read the Received chain in order, and the SPF, DKIM and DMARC results underneath it. The From line is the one thing in an email anyone can write; these are the parts that were checked.
Processed on your device — no upload
Paste a message above and its route appears here.
How to use it
- Paste the headers, or choose the .eml file.
- Read the hops from the top: hop 1 is nearest the sender.
- Compare the From line with the domain that actually passed.
How it works
The From line is the one part of an email that anybody can write, and it is the only part most people ever look at. It is typed by whoever composed the message, the same way the name on the outside of an envelope is written by whoever posted it. Nothing about delivery depends on it being true. What is worth reading sits above it, in the lines your mail app hides behind “show original”.
Received lines are the route, written backwards. Every server that handles a message adds its own line to the top of the headers, so the file lists the journey in reverse: the last Received line in the file is the first machine that touched the message. They are shown here the other way round, earliest first, because reading them in file order inverts the answer to the only question anyone is asking.
Those lines are only as honest as the machine that wrote them, and a forger can invent as many of the early ones as they like. The line you can rely on is the one your own provider added when it accepted the message, which is at the top of the file and last in the list here — everything below it is testimony from strangers.
SPF, DKIM and DMARC are three different questions. SPF asks whether the machine that made the connection is one the sending domain permits, and it checks the envelope sender rather than the visible From line. DKIM asks whether a signature over the message body verifies against a key published by the signing domain; it survives forwarding, where SPF does not. DMARC is the one that ties them to the From line: it asks whether the domain that passed SPF or DKIM is the domain the message claims to be from.
That is why a message can pass SPF and DKIM and still be a forgery. Both passed for the sender’s own domain; neither of them ever looked at the name in bold at the top of your screen. Email spoofing lives in that gap, and the row labelled From in the report is the comparison that closes it, made explicit.
One caution about all of it: these results were written by whichever server recorded them, so the report names that server too. An Authentication-Results line in a message that has not yet been through your own provider is a claim by a stranger about a stranger.
A worked example
Press Load a sample. It is a fake invoice, of the shape that actually works. The From line says no-reply@example-bank.test and the subject says a payment is due on Friday.
The first three rows read SPF passed, DKIM passed, DMARC failed. Read the detail beside the first two and the reason appears: both passed for supplier-invoices.test. Nothing is wrong with that domain’s mail — it sent this message correctly and its own records say so.
The fourth row is the one that matters. The From line claims example-bank.test, and what passed was a different domain. DMARC is the check that compares those two, and it failed, with a published policy of p=QUARANTINE in its note — the real bank has asked for messages like this to be held. A mail app that shows you the display name and nothing else shows you a bank.
The table underneath is the route. Hop 1 is workstation.lan at 198.51.100.7, a machine on somebody’s desk, handing the message to the sending server. Hop 2 waited 18 seconds. Hop 3 is your own provider accepting it. The address in square brackets is the one clause in a Received line the sending machine did not get to choose, because it is what the receiving server observed.
To see what the same message looks like to a reader, open it in the viewer — the link in the body does not go to the bank either.
Questions
Where do I find the headers of an email?
In Gmail, open the message, then the three-dot menu and Show original. In Outlook, File then Properties, and copy the internet headers. In Apple Mail, View, Message, All Headers. Or save the message as .eml and choose the file here.
Which Received line shows the real sender?
Hop 1 in this report — the last Received line in the file. It is the machine that first handled the message. Be careful with it, though: everything below the line your own provider wrote can be invented by a forger.
What do SPF, DKIM and DMARC each check?
SPF checks whether the connecting machine is permitted to send for the envelope sender’s domain. DKIM checks a cryptographic signature against a key published by the signing domain. DMARC checks whether either of those domains matches the visible From line.
SPF and DKIM passed but DMARC failed — what does that mean?
It means the message was sent correctly by some domain, and that domain is not the one in the From line. This is the ordinary shape of a convincing forgery, and it is exactly what DMARC exists to catch.
Can the Received lines be forged?
The early ones, yes — a sender can put any lines it likes at the bottom of the chain before handing the message over. The line added by the server that accepted the message cannot be, and it is the top one in the file.
Does everything passing mean the message is safe?
No. It means the message really was sent by the domain it says it was. A domain registered yesterday to look like your bank can pass all three checks perfectly, because the checks are about identity rather than intent.
What does softfail mean?
It means the sending domain publishes a rule this message breaks, but has asked receivers not to reject on that basis yet. It is a fail with the enforcement turned off, which usually means the domain owner is still finding all the systems that send on their behalf.
Why is there no SPF or DKIM result at all?
Because no server that handled the message wrote one. That is normal for a message taken straight from a sender’s Sent folder, and it is worth noticing on a message that supposedly arrived from outside — there is then nothing here that was checked by anybody.
Can I find the sender’s IP address in the headers?
The address in square brackets on each hop is what the receiving server saw at the other end of the connection. On hop 1 that is often the sender’s own machine or their provider’s outbound server, but a message relayed through a large mail service will show that service rather than the person. Headers trace email as far as the machines that carried it, and no further.
Are the headers sent anywhere to be analysed?
No. The parsing happens in your browser. Message headers name real people, real servers and real times, which is precisely why a tool that reads them should not be a form that posts them to someone else.
Why do the timestamps on different hops disagree?
Each server stamps its own clock, in its own time zone, and not all of them are accurate. The times are shown here in UTC so they can be compared, and the waiting column is the gap between one hop and the next.
Is Email Header Analyser free to use online?
Yes — free, with no account, no daily limit and no watermark. It runs online in your browser, and because the work happens on your own device it keeps working offline once the page has loaded.
Related Email tools
Extract Email Attachments
Pull the files out, nothing else
open$termiva mail open archive.mboxMBOX Viewer
Open a Gmail Takeout archive
open$termiva mail csv archive.mboxMBOX to CSV
Every message as a row
open$termiva mail split archive.mboxSplit MBOX into EML Files
One file per message
open