Email Header Analyzer
Paste the raw header of an email and find out who really sent it — whether it passed your provider's authentication checks, which delivery lines can be trusted, and which were written by the sender.
How to get the raw header out of your email
Every email carries a block of technical lines above the message you actually read. Mail programs hide it, because almost nobody needs it — until the day an email looks wrong and you want to know where it really came from. Getting at it takes a different sequence of clicks in every mail program, which is most of the reason people give up.
- Gmail (web)
- Open the message. Click the three dots next to Reply, choose Show original, then Copy to clipboard.
- Outlook.com / new Outlook
- More actions (the three dots at the top of the message) → View → View message details. Microsoft removed the old "View message source" from the message list, which is why the instructions you may have read elsewhere no longer match.
- Outlook for Windows (classic)
- Double-click the message so it opens in its own window — the option is greyed out in the reading pane. Then File → Properties, and copy everything from the Internet headers box at the bottom.
- Apple Mail (Mac)
- View → Message → Raw Source. Do not use "All Headers" — it reformats for display and leaves some out, including Return-Path.
- Yahoo Mail
- Open the message, click the three-dot More icon, choose View Raw Message.
- Thunderbird
- Select the message, then More → View source, or press Ctrl+U.
- Phones
- The Gmail and Apple Mail apps on iPhone and Android have no way to show headers at all. Forward the message to yourself and open it on a computer.
You only need the header block — the part above the first blank line. Copying the whole message including the body works too; this email header analyzer stops reading at the blank line and ignores everything after it.
What the analyzer is actually reading
The delivery chain, and why only the top of it counts
Each mail server that handles a message adds a Received: line to the top of the header and leaves everything already there untouched. Read from the bottom up and you have the journey in order. That design has a consequence most guides skip: because servers only ever prepend, a sender can compose a message that already contains five convincing-looking delivery lines before it is sent at all. Those lines cost nothing to fake and they will sit in the header looking exactly like the real ones.
So there is a boundary in every header. Above it are the lines your own mail provider wrote, which are evidence. Below it is text that arrived with the message, which is a claim. This page draws that line explicitly. No other email header analyzer we tested does — they render forged lines and genuine ones with identical confidence, and cheerfully geolocate both.
One field resists forgery, for the hops above the line: the address in brackets after from. RFC 5321 requires the receiving server to take that from the TCP connection itself rather than from anything the sending machine claimed about itself. The last such address your provider recorded is the best available answer to "where did this come from".
SPF, DKIM, DMARC — and the alignment trap
Your provider records the outcome of its authentication checks in an Authentication-Results: header. Three checks matter.
SPF asks whether the server that delivered the message is on the list its domain publishes. Crucially it checks the envelope sender — the address in Return-Path: — and not the From address you see on screen. DKIM is a cryptographic signature over the message; if it verifies, the signed parts have not been altered since they were sent. DMARC ties the two to the address a human actually sees, and this is where people get stuck.
DMARC only counts an SPF or DKIM pass if it belongs to the same domain as the From address. That requirement is called alignment, and it is why a header can say spf=pass and dmarc=fail on consecutive lines without being broken. A newsletter sent through a marketing platform has an envelope sender at the platform's domain, so SPF passes — for the platform. It contributes nothing to DMARC, and the message stands or falls on whether there is a DKIM signature from the brand's own domain. This analyzer says which of those is happening in plain words instead of printing both results and leaving you to guess.
Return-Path not matching From is not evidence of anything
Plenty of security advice tells you that a Return-Path in a different domain from the From address means forgery. It does not. Every mailing list, every newsletter platform, every notification service routes bounces to its own domain. The mismatch has exactly one meaning: SPF is authenticating that other domain, so it cannot satisfy DMARC by itself. If there is an aligned DKIM signature, the message is fine.
Mailing lists, forwarding, and ARC
Forwarding breaks email authentication as a matter of course. Mail now arrives from the forwarder's server, which is not in the original domain's SPF record, so SPF fails. A discussion list that appends a footer or rewrites the subject changes bytes that DKIM signed, so DKIM fails too. DMARC then reports a failure on a message nobody tampered with.
ARC exists to record what happened before the relay: the intermediary states "when this reached me, the checks passed" and signs that statement so the next server can verify it. A DMARC failure alongside an intact ARC chain is the ordinary shape of list mail, not an attack. It is also invisible in every other header tool we looked at, which is how a perfectly normal message from a mailing list ends up looking like a spoof.
Signatures that only cover part of the message
A DKIM signature can carry an l= tag limiting it to the first so many bytes of the body. Anything appended after that point is unsigned, but the signature still verifies — and because most mail is HTML, appended markup can cover the original text completely. RFC 6376 flags this as a weakness. This analyzer flags it too, because "DKIM passed" reads very differently once you know only the first four kilobytes were signed.
What this tool cannot tell you
It reads what is in front of it. It cannot re-run the cryptography, because verifying a DKIM signature needs the message body and a DNS lookup — so when the header says dkim=pass, this page is reporting your provider's verdict, not repeating the check. It cannot look up who owns an IP address without sending that address somewhere, which would break the promise at the top of the page. And it cannot tell you whether the contents are honest. A message can authenticate perfectly and still be a scam, because scammers are entitled to buy domains and configure them correctly. Authentication answers one narrow question: is the sender who they say they are.
Frequently Asked Questions
How do I find the raw email header?
In Gmail on the web: open the message, click the three dots next to Reply, choose Show original, then Copy to clipboard. In Outlook.com and new Outlook: More actions → View → View message details. In classic Outlook for Windows: open the message in its own window, then File → Properties, and copy the Internet headers box. In Apple Mail on a Mac: View → Message → Raw Source. In Yahoo Mail: the three-dot menu, then View Raw Message. The Gmail and Apple Mail apps on phones cannot show headers at all — forward the message to yourself and open it on a computer.
Is it safe to paste an email header into a website?
Usually it is worth thinking about. A header contains your own address, the internal hostnames and addresses of your mail system, and often the envelope recipient — which can reveal who else was on a distribution list. Most email header analyzers post everything you paste to their servers. This one does not: the parsing runs in your browser and the header never leaves it. To be straight with you, the page does load ads and analytics the way the rest of this site does, so the network tab will not be empty — but nothing you paste is ever part of those requests. The check that actually proves it is simpler: load the page, disconnect from the internet, and analyze anyway. It still works.
Why does the header say SPF passed but DMARC failed?
SPF checks the envelope sender in the Return-Path, not the From address you see on screen. DMARC only counts an SPF pass if the envelope sender is in the same domain as the From address — that requirement is called alignment. Mail sent through a marketing platform has an envelope sender at the platform's own domain, so SPF passes for the platform and contributes nothing towards DMARC. Those messages depend on a DKIM signature from the From domain instead.
Does a Return-Path that does not match the From address mean the email is fake?
No, and it is the single most common piece of bad email-header advice. Nearly every newsletter, mailing list and notification service uses its own bounce domain while displaying the customer's domain in the From line. The mismatch matters only because it decides whether SPF can contribute to DMARC. With an aligned DKIM signature present, there is nothing wrong.
Can Received lines and authentication results be faked?
The ones below the trust boundary can, yes. Servers only ever add lines to the top, so a sender can include any delivery history they like before sending. The same applies to Authentication-Results: RFC 8601 warns explicitly that a sender can forge one using your own provider's name so that a mail program displays a reassuring pass. Only the headers your provider added are evidence, and this page marks where that boundary falls.
Why is there no IP address for the sender?
Because it was probably never recorded. Gmail does not include the IP address of someone who composed a message on the Gmail website, and other webmail services behave the same way. When a message is submitted by a mail program signed in to the account, the address does appear — and the protocol on that line ends in A, such as ESMTPSA, which means the sender authenticated with a password. That distinction is worth knowing: if an account's owner says they did not send a message that shows authenticated submission, the account itself is compromised.