Every mail client can show you the raw headers. In Gmail it is the three-dot menu, then "Show original." In Outlook, open the message and look for "View message source" or the message options dialog. Thunderbird shows everything with Ctrl+U. What appears is intimidating on first contact: dozens of lines of server names, timestamps, and cryptographic results. But only a handful of those lines matter for the question you usually care about, which is whether the message came from where it claims.
The Received chain: the message's travel log
Each mail server that handles a message prepends a Received: header to the top of the pile. Prepends, not appends, so the chain reads in reverse: the top Received line is your own provider accepting final delivery, and the bottom one is the earliest recorded hop, closest to the true origin.
A typical hop looks like this:
Received: from mail-sender.example.net (mail-sender.example.net [203.0.113.25]) by mx.yourprovider.com with ESMTPS id abc123 for <you@yourprovider.com>; Sun, 19 Jul 2026 09:14:02 +0000
Read it as "the server after by received this from the server after from, at this time." The name in parentheses with the bracketed IP is what the receiving server observed by reverse DNS lookup, which makes it more reliable than the name the sending server announced about itself. Walking the chain from top to bottom takes you backward through the delivery path, hop by hop.
Received headers are reliable only from your own provider downward. Everything below the first hop your provider recorded arrived as part of the message and could have been fabricated by the sender. A phisher can invent a plausible-looking chain of fake hops; they cannot forge the lines your provider's own servers stamp on top.
Three addresses that should agree
An email carries more than one notion of "sender," and phishing lives in the gaps between them.
| Header | What it is | What to check |
|---|---|---|
| From: | The address your client displays. Chosen freely by the sender. | The actual domain after the @, not the display name in front of it. Watch for lookalike domains. |
| Return-Path: | The envelope address bounces go to, recorded at delivery. | A Return-Path domain unrelated to the From domain is common for newsletters, and suspicious for a bank. |
| Reply-To: | Where your reply will actually go, if present. | The classic invoice-fraud tell: From shows a colleague, Reply-To routes to an outside mailbox. |
Legitimate mail has honest reasons for some divergence. Mailing lists rewrite envelope senders, a practice covered in our post on the Sender Rewriting Scheme, and marketing platforms send on behalf of brands from their own domains. The point is not that any mismatch is fraud. The point is that a mismatch is a question, and for a message asking you to click, pay, or log in, an unanswered question is a stop sign.
Authentication-Results: the verdicts, precomputed
You do not have to verify cryptographic signatures yourself. Your provider already did, and it wrote its findings into the Authentication-Results: header. A healthy one reads something like:
Authentication-Results: mx.yourprovider.com; spf=pass smtp.mailfrom=example.net; dkim=pass header.d=example.net; dmarc=pass header.from=example.net
Three verdicts, three different claims. SPF says the sending server's IP was authorized by the domain in the envelope sender. DKIM says the message carries a valid signature from the domain after header.d= and was not altered in transit. DMARC ties the two to the domain you actually see, passing only when SPF or DKIM succeeds for a domain aligned with the From header. That alignment step is what makes DMARC the verdict most worth reading, and our email authentication deep dive covers how the three interlock.
Some care in interpretation is warranted. A dkim=pass proves the signing domain signed it, not that the signing domain is honest; plenty of phishing passes all three checks from a throwaway domain registered yesterday. Alignment can also pass on replayed messages, an edge covered in our post on DKIM replay attacks. And spf=softfail or a missing DMARC verdict on mail from a major institution is itself informative, since every serious institution publishes these records now.
A worked habit: the ninety-second check
For any message that asks something of you, the routine is short.
- Open the raw headers from your client's menu.
- Find
Authentication-Results. Admarc=fail, or no DKIM signature at all on mail claiming to be from a bank or provider, ends the analysis. Delete it. - Compare the From domain, Return-Path domain, and any Reply-To. Unexplained divergence on a money-or-credentials message ends the analysis the same way.
- If it still looks plausible, skim the Received chain from the top. You are looking for the handoff into your provider: which network actually delivered this, and does that make sense for the claimed sender?
Headers will not catch everything. A compromised legitimate mailbox sends perfectly authenticated mail, which is why payment-change requests deserve a phone call regardless of what the headers say. And headers reveal things in the other direction too: X-Mailer lines, internal server names, and originating IPs have deanonymized senders who assumed email was anonymous. Received headers are also part of the metadata story we cover in metadata surveillance, since encryption of the message body leaves this routing information readable by every server on the path. Tracking of the reader happens below the headers as well, through tracking pixels in the body.
Still, the asymmetry favors you. Forging a display name costs a phisher nothing. Forging a coherent Received chain, aligned authentication verdicts, and a plausible delivery path into your specific provider is somewhere between expensive and impossible. Ninety seconds of reading moves the contest onto ground where the defender wins.