How to Read Email Headers & Spot a Spoofed Email
Every email carries an invisible audit trail: which servers handled it, when, and whether the sender's domain vouched for it. Learning to read that trail turns "this looks official" into "this is fake" — in about a minute.
What's Actually in an Email Header
Email headers are the metadata prepended to every message. The key players:
| Header | What it tells you |
|---|---|
From | The visible sender — easily spoofed, never trust it alone |
Return-Path | The envelope sender used during SMTP delivery — the "real" return address |
Reply-To | Where replies go — attackers set it to their own inbox |
Received (chain) | Every server hop, in reverse order (top = last, bottom = first) |
Authentication-Results | SPF, DKIM, and DMARC verdicts recorded by the receiving server |
Message-ID | Unique identifier — the sending domain usually appears in it |
X-Originating-IP | Some ISPs expose the original sender's IP address here |
The critical insight: From is the only field the sender fully controls. The Received chain and authentication results are written by servers along the way — that's what makes them trustworthy evidence.
Reading the Received Chain
Received headers are prepended: each server adds its line at the top. So the chain reads bottom-up for chronological order:
Received: from mail.attacker-evil.com (mail.attacker-evil.com [203.0.113.77])
by mx.google.com with ESMTPS id abc123; Tue, 2 Aug 2026 09:14:22 -0700
Received: from smtp.gmail.com (smtp.gmail.com [142.250.1.25])
by mx.google.com with ESMTPS id xyz789; Tue, 2 Aug 2026 09:14:20 -0700
Received: from localhost (localhost [127.0.0.1])
by smtp.attacker-evil.com with SMTP id SEND-9911; Tue, 2 Aug 2026 09:14:18 -0700
- Bottom line = origin. The first server that touched the message (here, attacker-evil.com).
- Top line = delivery. The last server before your inbox (here, Google's MX).
- Delays matter. Real people take seconds to minutes between hops; several hops in 2 seconds is bulk-sending behavior.
- The parenthetical IP is the truth.
(mail.attacker-evil.com [203.0.113.77])— the hostname can be claimed, the IP is what connected.
SPF, DKIM & DMARC — the Authentication Trio
| Check | What it verifies | Pass looks like | Fail means |
|---|---|---|---|
| SPF | The sending server is allowed to send for the domain | spf=pass | spf=fail / softfail — unauthorized sender |
| DKIM | The message is signed by the domain & unmodified | dkim=pass | dkim=fail — signature broken or absent |
| DMARC | SPF or DKIM passed and the domain aligns with From | dmarc=pass | dmarc=fail — nothing vouches for the From domain |
dmarc=pass is the strongest signal of all: it means the visible From domain is backed by a passing authentication check with domain alignment. When SPF and DMARC both fail while the display name says "PayPal," the message is almost certainly spoofed.
One nuance: forwarding breaks SPF. If you forward mail between accounts, the forwarder's server isn't in the original domain's SPF list, so spf=fail is expected — DKIM usually survives and DMARC handles it. Read failures in context, not in isolation.
The Red Flags That Reveal Spoofing
- Display name vs. real address. "PayPal" <paypal@attacker-evil.com> — the name is free text; the address is the truth.
- Return-Path mismatch. From says paypal.com but Return-Path is bounce@attacker-evil.com — the envelope doesn't match the display.
- Reply-To hijack. Replies quietly routed to an address you've never heard of.
- Failed authentication. spf=fail or dmarc=fail on mail claiming to be from a brand that enforces both.
- Odd Message-ID domain. A "Microsoft" mail with <xyz@random-server.ru> is a confession.
- Urgency + one link. "Verify within 24 hours" with a single login link — the phishing signature.
How to View Full Headers
- Gmail (web): open the message → ⋮ → Show original → copy from the new tab, or Download original.
- Outlook (web): open the message → ⋯ → View → View message source.
- Outlook (desktop): double-click the message → File → Properties → Internet headers.
- Apple Mail: open the message → View → Message → Raw Source.
Paste everything into the Prescosoft Email Header Analyzer — it decodes the chain, extracts the verdicts, and lists the red flags in plain English, entirely on your device.
Frequently Asked Questions
What exactly is in an email header?
An email header is the metadata attached to every message before the body: the From and To addresses, Subject, Date, Message-ID, the complete Received chain showing every server the message passed through, and — when the receiving server publishes them — Authentication-Results lines with SPF, DKIM, and DMARC verdicts. Together they form the message's audit trail.
Can I really tell if an email is fake from its headers?
Often, yes. The display name can claim to be PayPal while the actual address is attacker@fake-domain.com; the Return-Path can point to a different domain than the From; and SPF or DMARC can outright fail. No single clue proves fraud, but several together are a strong signal. Headers are the only evidence that survives after the sender disappears.
Why does my forwarded email fail SPF?
Forwarding breaks SPF by design: the forwarder's server sends the message to the next hop, and that server isn't in the original domain's SPF allowlist. DKIM usually survives forwarding (the signature stays intact), and DMARC with relaxed alignment handles it. So a lone SPF fail on forwarded mail is common — treat it as a warning, not proof of phishing.
What does DMARC=pass actually prove?
DMARC pass means the message passed SPF or DKIM with domain alignment — the visible From domain matches an authenticated domain. It's the strongest single signal that the message genuinely came from that domain. Note that dmarc=none (no policy) is not a pass; it means the domain publishes no enforcement, which is common but weaker.
Is it safe to paste headers into an online analyzer?
Only if the analysis runs locally. Upload-based analyzers receive your headers — and headers of suspicious mail often contain IP addresses, routing data, and other forensic clues you may not want to hand to a third party. A browser-local analyzer parses everything on your device and never transmits it. That's the entire point of the Prescosoft Email Header Analyzer.
What should I do if headers show an email is spoofed?
Don't reply, don't click links, and don't download attachments. Report it as phishing in your mail client (Gmail, Outlook, and Apple Mail all have a report option), forward the full headers to your IT team if it's a work account, and if it impersonates a bank or government agency, report it to that organization's abuse channel. Legitimate organizations will never ask you to 'verify' credentials via a link in an email.
Analyze a suspicious header — privately
SPF/DKIM/DMARC verdicts, hop timeline, and red flags — all decoded on your device. Nothing uploaded.