How to Read Email Headers: Trace Senders and Spot Phishing

The sender name and address you see in your inbox are just packaging. Where a message really came from, which servers relayed it, and whether the sending domain passed authentication are all recorded in the raw headers. A phisher can put anything they like in the display name and From address, but the lines stamped by your own receiving server are far harder to fake. Once you can read headers, you can decide in minutes whether that “message from your bank” is genuine.

This guide walks through opening the raw source in Gmail and Outlook, tracing the origin server by reading the Received chain bottom-up, spotting From/Return-Path/Reply-To mismatches, and decoding the SPF/DKIM/DMARC verdicts in Authentication-Results — finishing with a real phishing walkthrough. If you want the fast path, paste the whole header block into our email header analyzer and it will unpack the chain and authentication results for you.

Opening the raw headers — Gmail, Outlook and others

Every client hides the option under a slightly different name, but it is never more than a few clicks away.

• Gmail (web): open the message → click the ⋮ (More) menu at the top right → Show original. Gmail even shows an SPF/DKIM/DMARC summary at the top and offers a “Copy to clipboard” button for the full source.
• Outlook (web, outlook.com / Microsoft 365): open the message → ⋯ (More actions) → View → View message source.
• Outlook (desktop): double-click the message to open it in its own window, then File → Propertiesand copy from the “Internet headers” box.
• Apple Mail: View → Message → All Headers. Most other clients have a “view source” or “show original” item in the message menu.

Copy everything above the first blank line (the header block) — that is what tools like the header analyzer expect as input.

The Received chain — read it bottom-up; the first hop is the origin

Each server that handles a message prepends its own Received: line to the top of the headers, like a stack. That means the bottom-most Received line is the original sending server and the top-most is the server that delivered it to your mailbox. To trace a sender, read from the bottom up:

1. Look at the from hostname and the IP in parentheses on the bottom line — that is the claimed origin.
2. Walk upward, checking that each line's by server matches the next line's from.
3. Check the timestamps: they should get later as you move up. Out-of-order times suggest tampering.

One trust rule governs everything: lines written by the sender can be forged; lines stamped by your own infrastructure cannot. An attacker can pre-insert fake Receivedlines before handing the message off. But the entries added by your receiving server (say Gmail's mx.google.com) — including the connecting IP it observed directly — are reliable. In practice, the real origin is the IP recorded at the first hop where a server you trust accepted the message from the outside world.

From vs Return-Path vs Reply-To — three senders that should agree

An email does not have one sender; it has three, operating at different layers.

• From: — what your mail app displays. It is fully forgeable; the display name doubly so (“Your Bank <random@evil.com>” is trivial to send).
• Return-Path: — the SMTP envelope address where bounces go, recorded by the receiving server. SPF is evaluated against this domain. A Return-Path domain unrelated to the From domain is a warning sign (legitimate exceptions: newsletter platforms and ticketing systems).
• Reply-To:— where your reply actually goes. A classic phishing move is a plausible From plus a Reply-To pointing at the attacker's mailbox to hijack the conversation.

When all three domains differ and nothing explains why, treat the message as suspect until the authentication results say otherwise.

Authentication-Results — decoding SPF, DKIM and DMARC verdicts

Your receiving server summarizes its checks in a single Authentication-Results: line, e.g.:

Authentication-Results: mx.google.com; spf=fail smtp.mailfrom=evil.com; dkim=none; dmarc=fail (p=REJECT) header.from=yourbank.com

• spf — did the sending IP have permission to send for the Return-Path domain? Values: pass/fail/softfail/none. You can inspect any domain's published policy with the SPF lookup tool.
• dkim — is the cryptographic signature valid, and which domain signed (header.d=)? none means no signature at all. To check whether a domain actually publishes a DKIM public key, run its selector through the DKIM lookup tool.
• dmarc — did SPF or DKIM pass with a domain aligned to the From: domain? A DMARC fail is the closest thing headers give you to “the owner of the From domain did not send this.”

Alignment is the part people miss. spf=pass means nothing by itself if the pass was for evil.com (the Return-Path) while the From says yourbank.com. Always compare the domains in header.from=, smtp.mailfrom= and header.d=.

Worked example — dissecting a fake “bank security alert”

In the inbox it looks like: “First National Bank <security@firstnational.com> — [URGENT] Verify your account”. The key lines from the raw headers:

• From: "First National Bank" <security@firstnational.com>
• Reply-To: fn-verify@secure-check.top
• Return-Path: <bounce@mail-blast77.xyz>
• Received: from mail-blast77.xyz (203.0.113.45) by mx.google.com ... (the bottom, trusted hop)
• Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=mail-blast77.xyz; dkim=none; dmarc=fail header.from=firstnational.com
• Message-ID: <a91f...@mail-blast77.xyz>, X-Mailer: BulkSenderPro 2.1

Reading the evidence:

1. The From display name says “bank”, but the Return-Path, Message-ID and the actual origin server all point at an unrelated domain (mail-blast77.xyz).
2. spf=pass is a red herring — it passed for the attacker's own domain. The verdict that matters is dmarc=fail with header.from=firstnational.com: the bank's domain owner did not authorize this message.
3. Reply-To routes answers to yet another third domain — the classic reply-hijack pattern.
4. An X-Mailer identifying bulk-sending software is circumstantial but consistent.

Verdict: phishing. Do not click anything; report as spam and delete. To repeat this analysis without eyeballing raw text, paste the headers into the header analyzer.

Header field cheat sheet — what it tells you, and whether it can lie

The summary rule: treat sender-written fields (From, Reply-To, lower Received lines) as claims, and base your verdict on what your own server recorded (top Received lines, Authentication-Results). To cross-check what a domain has actually published, look up its SPF record and DKIM key directly.