How to read email headers and spot a phishing email

Written by Aldo · blue-team threat hunter
Last updated November 9, 2026 · 5 min read

An email says it's from your bank, your boss or your supplier. Its visible From line is just text the sender typed. The headers underneath record what the mail servers actually saw, and those are much harder to fake.

Open the full headers

Every mail app hides them by default. Here's where they are (menu names change between versions, but these have been stable for a while):

Gmail (web): open the email, click the three dots next to Reply, then Show original.
Outlook on the web and the new Outlook: open the email, select the three dots, then View → View message details.
Classic Outlook for Windows: open the email in its own window, then File → Properties; the headers are in Internet headers.
Apple Mail on a Mac: View → Message → All Headers.
Thunderbird: View → Message Source (Ctrl+U).
iPhone and Android mail apps generally can't show full headers. Forward yourself the question: open the same mailbox on a computer.

Copy everything from the top down to the first empty line. That block is the header.

A worked example: the overdue invoice

This is the sample in iplover's email header analyzer. The domains are documentation domains (example.com, .org, .net) and the sending address is a public Tor exit, so no real company or person is involved, but every line is the kind you'll meet in real phishing:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.org header.s=s1 header.b=Xy12;
       spf=pass (google.com: domain of bounce@mailer.example.org designates 198.51.100.25 as permitted sender) smtp.mailfrom=bounce@mailer.example.org;
       dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=example.com
Return-Path: <bounce@mailer.example.org>
Received: from relay.mailer.example.org (relay.mailer.example.org. [198.51.100.25])
        by mx.google.com with ESMTPS id 5a1b2c3d4e
        for <you@example.net>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 03 Nov 2026 10:14:04 -0800 (PST)
Received: from webmail.example.org (unknown [185.220.101.7])
        by relay.mailer.example.org (Postfix) with ESMTPSA id 7C1A2B3;
        Tue,  3 Nov 2026 16:11:58 +0000 (UTC)
Received: from [10.0.0.12] (localhost [127.0.0.1])
        by webmail.example.org with ESMTP;
        Tue,  3 Nov 2026 16:11:55 +0000 (UTC)
From: "Example Billing" <billing@example.com>
Reply-To: payments-desk@example.net
Subject: Invoice 4471 is overdue
Message-ID: <20261103161152.4471@mailer.example.org>
X-Originating-IP: [185.220.101.7]

(Shortened; the full sample also has ARC headers, which record checks made by servers along the way.) The analyzer's verdict:

Verdict	Suspicious Suspicious: be careful with this email.
Reasons	It failed DMARC: example.com did not authorize it, so the From address may be forged. · It was sent through the Tor network (185.220.101.7), which hides the real sender. · Replies would go to example.net, a different domain from the sender's. Scam emails often do this. · It was held up for more than an hour on the way.
SPF, DKIM, DMARC	SPF pass (for mailer.example.org) · DKIM pass (for example.org) · DMARC fail (for example.com, policy reject)

How to read it, line by line

1. Authentication-Results: the receiving server's verdict

The receiving server (here Google's) checked the message and wrote down the results. Read the topmost Authentication-Results line: it's the one your own mail provider added. Anything further down could have been written by anyone, including the sender.

The trick in this example is that SPF and DKIM both passed, just not for the right domain. SPF passed for mailer.example.org and DKIM for example.org, but the From address says example.com. DMARC is the check that ties the result to the From domain, and it failed. The owner of example.com even published a policy asking receivers to reject such mail. This pattern, passes everywhere except DMARC, is how most forged mail looks.

2. From, Reply-To and Return-Path: who it claims to be, and where answers go

The From line shows “Example Billing” at example.com. Reply-To, though, sends your answer to example.net. Help desks and mailing lists do this legitimately, but in an unexpected invoice it means: whoever wrote this wants your reply somewhere the real company doesn't control. Return-Path is where bounces go; a mail service's domain there is normal.

3. Received: the delivery path, read from the bottom up

Each server that handles a message adds a Received line at the top, so the oldest is at the bottom. Read upward: a device on a private network (10.0.0.12) handed the mail to webmail, which received it from 185.220.101.7, a Tor exit, before passing it to the relay and on to Google. That first public address is the closest you'll get to the sender, and here it's deliberately anonymous. X-Originating-IP, which some webmail services add, says the same.

The times tell a story too: two hours between the relay and Google. Delays happen for innocent reasons, but they're worth noticing.

If you see this, do this

In the headers	What it means	What to do
`dmarc=fail` for the From domain	The domain's owner didn't authorise this sender	Treat it as forged. Don't click, don't reply; report it as phishing in your mail app.
`dmarc=pass`, but the From domain is a lookalike (`examp1e.com`, `example-billing.com`)	A real domain, registered by the attacker	DMARC can't help here. Compare the domain letter by letter with the one you know.
Reply-To on a different domain, in an unexpected request	Answers go to someone else	Contact the company through a number or address you already have.
Display name of a known person, but an address you've never seen	Impersonation	Check with the person through another channel.
Everything passes, and the address is the one you know	Sent from that real account	Probably genuine, but accounts get hacked: an odd payment request still needs a phone call.
No Authentication-Results at all	Your provider recorded no checks	Judge it on content alone, and be careful.

What headers can't tell you

Headers prove where a message came from, not what it wants. A message from a hacked but genuine account passes every check. A lookalike domain passes DMARC for itself. And headers say nothing about the link or the attachment, which is where the harm usually is. So headers are one test among several: an unexpected request for money, passwords or a quick decision deserves suspicion whatever the headers say.

iplover's analyzer reads the results your provider recorded; it doesn't re-verify DKIM signatures or fetch SPF records for every hop itself. It tells you that at the end of each report, and it's worth keeping in mind with any tool.

Sources

Official documents we used to check the facts in this guide.