Is this email a phishing attempt?
A message’s headers record who actually handled it, which is a different question from what the From line says. Here is how to read them — and why a row of green ticks is not the end of the question.
Read this part first
Headers can tell you a message is not what it claims. They cannot tell you a message is safe. Everything below is for the first job; the section at the end explains why the second one is not available from headers at all.
If you are being asked to move money, change payment details, or enter a password, do not resolve it by reading headers. Contact the organisation through a number or address you already had.
The walkthrough
1. Get the raw headers, not a screenshot
Every mail client hides them somewhere different. In Gmail, open the message, then the three-dot menu and Show original. In Outlook on the web, the three-dot menu and View message source; in the desktop app, File then Properties. In Apple Mail, View, then Message, then Raw Source. On mobile you generally cannot get at them — forward the message to yourself and open it on a computer.
Copy the whole block. The headers are everything above the first blank line, and the useful ones are usually at the top.
2. Paste them into the analyzer
The Email Header Analyzer parses the block in your browser and lays out the delivery path along with the authentication results each server recorded. Nothing is uploaded, which matters here: message headers carry addresses, internal hostnames and subject lines you may not want to hand to a website.
3. Read the authentication results — and check who stamped them
SPF asks whether the server that sent the message was authorised by the sending domain. DKIM checks a cryptographic signature over the message, proving it was signed by that domain and not altered afterwards. DMARC ties them to the address you actually see, which is the part that matters: a message can pass SPF for one domain while displaying a completely different From address.
Now the step almost every guide leaves out. Find the Authentication-Results header and look at the name at the very start of it — the identity of the server that wrote the line. Trust only the one added by the provider that delivered the message to you. Anything below it was already in the message when it arrived and could have been typed by the sender.
4. Follow the Received chain from the bottom up
Received headers stack: each server adds one to the top, so the oldest hop is at the bottom and the most recent is at the top. Read upward and you are reading the message's journey forward in time.
Only the hops added by servers you or your provider control are trustworthy. The lower ones were supplied by whoever sent the message, and a sender can invent as many plausible-looking hops as they like. Large unexplained time gaps between hops, or a first hop in a place that makes no sense for the claimed sender, are worth noticing — but neither is proof on its own.
5. Compare the addresses that are supposed to match
There are at least three senders in a typical message and they do not have to agree: the From address you are shown, the Return-Path the bounce would go to, and the domain in the DKIM signature. DMARC alignment is the requirement that the visible From matches one of the authenticated ones.
A message that passes SPF for a sending platform, carries a Return-Path at that platform, and displays a From address at a bank you use is exactly what a well-configured newsletter looks like — and also exactly what a spoof looks like when DMARC is not enforced on the bank's domain. The alignment is the thing to look at, not the individual passes.
Email Header Analyzer
Free, no signup, and it parses everything in your browser.
Why passing every check is not proof
This is the part worth remembering after you have forgotten the rest. Authentication answers “did this really come from that domain”. It does not answer “is this domain who I think it is”, and it cannot answer “is this message honest”.
A look-alike domain passes its own checks perfectly
Authentication proves a message came from the domain it claims, not that the domain is the one you think. A phisher who registers a near-identical name publishes real SPF and DKIM records for it and gets a clean pass on every check. Read the domain character by character — especially where a letter could be a digit or a different alphabet.
A compromised real account passes everything
If someone is sending from inside a genuine mailbox, the message IS genuine by every technical measure. Authentication cannot distinguish the real owner from someone who has their password. This is why an unexpected request from a colleague's real address is still worth confirming through another channel.
A missing result is not the same as a failure
Plenty of legitimate senders are configured badly, so 'none' or 'no result' is common and weak evidence of nothing in particular. A genuine FAIL is a much stronger signal than an absence.
The analyzer reports what the headers say
It reads the verdicts out of the message rather than re-running SPF and DKIM against the internet, and no browser-based tool can do otherwise — checking a DKIM signature means fetching a public key over DNS, which a page cannot do. So a message that never passed through a real mail server can claim any result it likes and be reported at face value. This is why step 3 is about who stamped the line, not about what it says.
If it is phishing
- Do not click, reply, or open attachments. Replying confirms the address is live.
- Report it in your mail client, which trains the filter for everyone on that provider.
- If it impersonates an organisation, forward it to their abuse or phishing address.
- If you already entered a password, change it now — and change it anywhere you reused it.
- If money moved, contact your bank immediately rather than waiting to be certain.
Want fewer of these in the first place? An alias per service means the address itself tells you which company leaked it, and you can switch one off without touching your real inbox. That is what Cloqd is for. You can also grade your own domain to see whether someone could spoof it.