Last updated: August 2026 · 11 min read

What an email header actually is

An email has two layers. The part you normally see — sender name, subject, body — is written entirely by the sender, which means a phisher controls every pixel of it. Underneath sits the raw header: a block of technical lines added partly by the sender's software and partly by every mail server that handled the message on its way to you. Each server stamps its own Received line on top, records the IP address it accepted the message from, and your own provider adds the results of its authentication checks before the email lands in your inbox.

That layering is what makes headers useful. A scammer can forge the lines they write themselves, but they can't rewrite the stamps your provider adds on arrival. The trustworthy evidence — the sending server's IP, the SPF and DKIM verdicts, the domain that actually handed the message over — sits in the parts they don't control. Reading a header is simply knowing where to look.

How to open the full header in your mail app

Every major mail client can show you the raw header, though they all hide it in a slightly different place.

Gmail

Open the message, click the three-dot menu at the top right of the email (not the page), and choose Show original. Gmail opens a new tab with the raw message and, helpfully, a summary table at the top showing the SPF, DKIM and DMARC results at a glance. The Copy to clipboard button grabs the whole header for pasting into an analyser.

Outlook

In Outlook on the web, open the message, click the three-dot menu and choose View > View message source. In the desktop app, open the message in its own window, then go to File > Properties — the raw header appears in the Internet headers box at the bottom.

Apple Mail

Open the message and choose View > Message > All Headers to see the extended fields inline, or View > Message > Raw Source for the complete original, ready to copy.

Once you have the raw text, you can read it by hand using the sections below, or paste it into our email header analyser, which traces the delivery route, extracts the sending IPs and checks the authentication results for you — entirely in your browser, so the header never leaves your device.

The fields that matter most

A raw header can run to dozens of lines, but a handful of fields do nearly all the work when you're judging whether a message is legitimate.

From, Return-Path and Reply-To

The From line is what your inbox displays — and it's freely chosen by the sender, display name and all. The Return-Path (sometimes shown as the envelope sender) is the address the sending system used at the mail-protocol level, and it's where the authentication checks actually look. On legitimate mail from a company, the two usually belong to the same organisation, even if they're not identical. On phishing mail they often diverge sharply: a From that says your bank and a Return-Path pointing at a random domain you've never heard of is a classic tell.

The Reply-To field deserves its own glance. It controls where your reply actually goes, and scammers use it to quietly redirect conversations: the message appears to come from a colleague or supplier, but replies flow to an outside mailbox — very often a free webmail address. A Reply-To that doesn't match the From domain on a business email is a strong warning sign.

The Received chain

Each server that handles the message adds a Received line above the previous one, so the chain reads bottom-up: the bottom-most line is closest to the true origin, and the top line is your own provider accepting delivery. The lines added by your provider and other reputable servers are reliable; the bottom of the chain can contain forged entries the sender inserted before handing the message off. The most useful detail is the IP address in the earliest trustworthy hop — the point where a server you have reason to trust says who it accepted the message from.

That IP tells you what kind of network the email really came from. Marketing mail from a major brand arrives from that brand's mail infrastructure or a known sending service — not from a residential broadband line or an anonymous rented server. If you pull the sending IP out of the chain, our IP reputation check will show whether it's flagged as a proxy, Tor exit or hosting provider, and our guide to IP blacklists explains how sending addresses end up on block lists in the first place.

Authentication-Results

Near the top of the header, your provider records a line like Authentication-Results: spf=pass dkim=pass dmarc=pass. This single line is the closest thing a header has to a verdict, and it's worth understanding what each check actually proves — and what it doesn't.

SPF, DKIM and DMARC in plain English

These three acronyms do related but distinct jobs. SPF (Sender Policy Framework) lets a domain publish the list of servers allowed to send mail on its behalf; a receiving server checks whether the connecting IP is on that list. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the message, proving it was sent by the signing domain and hasn't been altered in transit. DMARC ties the two together: it checks that the domain which passed SPF or DKIM actually matches the domain in the visible From line — the one you see — and tells receivers what to do with mail that fails, from “deliver it anyway” to “reject it outright.”

That last part matters more than it sounds. Industry surveys in the past year put DMARC adoption at roughly half of active sending domains, but only a minority of those — figures around one in five are commonly cited — enforce a strict reject policy; the rest merely monitor. A domain that publishes DMARC without enforcement can still be spoofed into many inboxes, which is why spoofed mail from real brands continues to arrive despite all three technologies existing for years. The gap is closing, though: domains that do enforce see dramatically fewer spoofing incidents, and major mailbox providers now require authentication from bulk senders.

For you as a reader of headers, the practical rules are these. A fail on SPF or DKIM for a message claiming to be from a brand is a serious red flag. A pass is necessary but not sufficient — it proves the mail genuinely came from the domain that signed it, not that the domain is honest. Phishers increasingly register their own lookalike domains, set up SPF, DKIM and DMARC correctly, and pass every check while impersonating a brand in the display name and message body. Authentication answers “did this domain really send it?”, never “should I trust this domain?”

Red flags: a header-reading checklist

Pulling it together, these are the patterns that should make you stop before clicking anything. The From and Return-Path domains belong to different organisations on a message claiming to be from a company. The Reply-To points somewhere else entirely, especially a free webmail address on supposed business mail. The Authentication-Results line shows spf=fail, spf=softfail, dkim=fail or dmarc=fail on mail that claims to come from a major brand — real banks and platforms essentially never fail their own authentication. The sending domain is a lookalike: an extra word, a swapped letter, a different ending, like secure-yourbank-login.com instead of yourbank.com. The earliest trustworthy Received hop shows the message originating from a residential connection, an anonymous hosting box or an IP with a poor reputation. And the mundane details disagree with each other — a “sent from our London office” message whose sending infrastructure and time-zone offsets sit on the other side of the world.

No single flag is absolute proof, and one or two have innocent explanations — forwarding, mailing lists and newsletter platforms produce odd-looking headers routinely. But phishing mail rarely trips just one wire. When three or four of these show up together, treat the message as hostile: don't click its links, don't open its attachments, and verify through a channel you already trust. Our guide to staying safe online covers what to do next.

What headers can't tell you

Headers are powerful, but honest limits matter. They won't give you the sender's identity or precise location — the IP in the Received chain locates a mail server, which for consumer email usually means the provider's infrastructure rather than anyone's house, and for criminals is typically a rented or compromised machine. They can't flag a message sent from a genuinely compromised account, which passes every authentication check because it really was sent from the real mailbox — a favourite technique in business email compromise, a category of fraud the FBI's complaint centre has recently attributed billions of dollars in annual reported losses to. And they can't read intent: a perfectly authenticated email from a freshly registered lookalike domain is still a trap.

Treat header reading as one strong layer in a stack: authentication results and sending IPs from the header, scepticism about urgency and payment requests from you, and independent verification — a phone call, a fresh browser tab typed by hand — before any money moves or credentials get entered. That combination defeats the overwhelming majority of phishing attempts, however polished the message looks.

Frequently Asked Questions

Can email headers be faked?

Partly. The sender controls the lines they write themselves — From, Subject, Reply-To and any Received lines they insert before sending. But the stamps added after the message leaves them — your provider's Received line, the connecting IP it recorded, and the Authentication-Results — are written by servers the sender doesn't control. That's why analysis focuses on the top of the Received chain and the authentication verdicts rather than the sender-supplied fields.

Does an SPF or DKIM fail always mean phishing?

No. Forwarding commonly breaks SPF, because the forwarding server isn't on the original domain's approved list, and mailing lists can break DKIM by modifying messages in transit. That's exactly why DMARC exists — it passes if either check survives and aligns with the visible From domain. A fail on ordinary forwarded mail can be innocent; a fail on a message that claims to come directly from your bank is another matter entirely.

Can I find someone's exact location from an email header?

No. The IPs in a header belong to mail servers, not to the sender's device — consumer email from Gmail or Outlook shows the provider's infrastructure, not the writer's home. Even when a header does expose an originating IP, IP-based location is approximate at best, typically resolving to a provider's regional hub rather than a street address. Headers reveal the network path of a message, not a person's whereabouts.

What's the difference between From and Return-Path?

The From address is the human-facing one your inbox displays, chosen freely by the sender. The Return-Path is the envelope address used at the mail-protocol level for delivery and bounces, and it's what SPF is checked against. Legitimate senders usually keep both within the same organisation; phishers often show you a trusted name in From while the Return-Path exposes the unrelated domain that really sent the message.

Is it safe to paste an email header into an online tool?

Headers contain metadata — addresses, server names, IPs and subject line — but not the message body. Even so, it's fair to be cautious about uploading them to unknown sites. Our email header analyser processes everything locally in your browser, so the header is parsed on your own device and never uploaded to a server.

What should I do if a header confirms the email is fake?

Don't click any links, download attachments or reply. Use your mail app's report-phishing button, which helps your provider filter the campaign for everyone, and delete the message. If it impersonates a company you use, tell that company through its official site. And if you clicked before checking, change the affected password immediately from a device you trust and turn on two-factor authentication — our online safety guide walks through the recovery steps.