How to read email headers to spot phishing

The name in the From: line is free text typed by whoever sent the message. Nothing checks it. The real sender — which server handed the message over, from which IP, which domain signed it — lives in the headers, the part your mail app hides by default. Reading them is the difference between trusting a display name that says "Microsoft Account Team" and noticing that the message started life on a residential connection halfway around the world. You can analyze email headers with the Docuboxer tool, which parses everything in your browser and uploads nothing.

Why the From: line proves nothing

Email works like postal mail: there is an envelope and there is a letter. SMTP handles the envelope, which carries its own sender address (what eventually surfaces as Return-Path). The letter is the message itself, and the From: you read is simply a line written inside it. Nothing in the protocol requires the two to match, and the sender controls both.

Mail clients make this worse by design. Almost all of them show only the display name and hide the actual address, especially on phones. That is why the cheapest trick in phishing still works: set the display name to IT Helpdesk or DocuSign, send from a throwaway free-mail address, and on a small screen the address never appears at all.

Getting the raw headers

• Gmail (web): three-dot menu on the message → Show original. You get the full source plus a download button for the raw message.
• Outlook (desktop): open the message → File → Properties → the Internet headers box. On Outlook for the web, the three-dot menu offers a view-source option.
• Apple Mail: View → Message → All Headers.
• Thunderbird: Ctrl+U shows the complete source.

One practical warning that saves a lot of wasted effort: do not forward the email to analyze it. Forwarding makes your own server generate a brand-new message with brand-new headers, and the original survives only as quoted text. You lose exactly the evidence you were after. Use Show original, save the .eml, or attach the message as a file.

Read the Received chain from the bottom up

Every server that handles the message adds a Received: line at the top. The result is a stack in reverse: the topmost line was written by your own provider on delivery, and the bottom one corresponds to the first hop — the origin. Reading upward from the bottom replays the journey.

What you want from the bottom of the stack is the originating IP and hostname, and whether they fit the infrastructure of the domain claiming to have sent it. A message supposedly from a payroll provider that begins on a cheap VPS, a residential ISP or a country unrelated to the business is a strong signal. Timestamps talk too: multi-hour gaps between consecutive hops, or time zones that make no sense for the claimed route.

Now the honest part: an attacker can fabricate Received lines and include them in the message before sending it. Only the lines added by servers that genuinely handled the message — the ones at the top — can be trusted. Read downward from the top and note where the chain stops making sense; that boundary is usually where the forgery begins.

Authentication-Results, decoded

Your provider checks authentication on arrival and records the verdict in an Authentication-Results header. It is the most valuable line in the whole set, because the sender did not write it — the receiver did. It usually looks like spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com. In one line each:

• SPF checks that the sending IP is authorized by the envelope domain (the Return-Path) — not by the address you see.
• DKIM verifies a cryptographic signature; the signing domain appears as header.d=.
• DMARC requires the visible From: domain to align with the SPF or DKIM domain. It is the only one of the three tied to what the user actually sees.

Watch for a subtlety: a message can carry several Authentication-Results headers, and an attacker can inject one of their own showing a fake pass. Only the header stamped with your provider's own identifier counts. To see what a domain actually publishes, run it through the SPF, DKIM and DMARC checker; if you want the sending side of the story, it is covered in the guide to SPF, DKIM and DMARC and why your email lands in spam.

Why "SPF: pass" is not a clean bill of health

This is the part most guides skip. Passing SPF, DKIM and DMARC proves the message really came from the domain it claims, and nothing more. Attackers register their own domains, publish proper SPF records, sign with DKIM and set DMARC exactly by the book. Their phishing mail authenticates perfectly. Authenticated is not the same as trustworthy: it certifies the sender, not their intentions.

The reverse happens too. A genuine message can fail SPF simply because a mailing list or an auto-forward rule relayed it, leaving a delivering server the original domain never authorized. A fail asks for a closer look; it is not a conviction.

And the worst case shows up in no header at all: a compromised real account. When an attacker gets into a supplier's mailbox and emails you from it asking to update the bank details on an invoice, the authentication is genuine, the Received chain is spotless, and the wire fraud is real. Headers describe the transport, never the intent.

The mismatches that actually give it away

What rarely survives a fraudulent email is not authentication — it is consistency. Real corporate mail is boring and coherent. The usual cracks:

• Reply-To on a different domain from the From address. Your reply goes to the attacker.
• Return-Path pointing somewhere with no relationship to the brand in the From:.
• DKIM signed (header.d=) by a domain unrelated to the mail provider the company normally uses.
• Brand name as display name paired with a generic or freshly registered domain.
• Near-identical domain: an extra hyphen, a swapped letter, characters from another alphabet that render the same. The link safety checker applies that same analysis to the links in the body.
• Origin geography that does not fit how the company operates.
• Bulk-sending headers such as X-Mailer or campaign platform traces on something presented as a hand-typed personal note.

A 60-second pass

1. Open the original and read the full From: address, not the display name.
2. Find your provider's Authentication-Results and read all three verdicts.
3. Compare the domains in From, Reply-To, Return-Path and header.d=. Do they tell the same story?
4. Drop to the bottom of the Received stack and see where it started.
5. Run the links in the body through an inspector before clicking anything.
6. If money or credentials are involved, confirm through a channel you chose — a phone number you already had, never the one in the email.

Why to parse them locally

A full header set is rich metadata: your address, every routing IP, unique message identifiers and, in corporate mail, internal hostnames that sketch out how your employer's network is built. Pasting that into a random web analyzer hands the map to a stranger. The Docuboxer header analyzer does all parsing in the browser, so nothing leaves your machine. And if you already typed credentials into whatever the email linked to before the doubt kicked in, check that password against known breaches with the breached password checker and change it everywhere you reused it.

Frequently asked questions

Related tools

• Analyze email headers — Received chain, SPF/DKIM/DMARC and Reply-To, all local.
• Check SPF, DKIM and DMARC — What a domain actually publishes in DNS.
• Check if a link is safe — Inspect the links in the body without opening them.
• Check if your password was breached — In case you typed it somewhere you shouldn't have.

You might also like: malicious QR codes and how to spot them — the same con, printed on paper.