The message looks exactly like your bank wrote it. Logo, tone, a link to confirm a payment you never made, and a From line that reads like the real thing. None of that proves anything. The From line is typed text, and anyone can type anything there. The header underneath it is the record of where the message actually travelled, and it takes about a minute to read once you know which two parts matter. I run AliasFleet, an email-alias service, and this is the check I use on any message that asks me to act.
Most inboxes hide the header entirely. You get a name, a subject, a body. The name is the easiest part of the whole message to write, and nothing on its own verifies it. This guide shows how to open the header in Gmail and Outlook, which two parts carry the evidence, and how to reach a verdict on one suspicious email fast.
The From line is a claim, the header is the record
A message carries two sender addresses, and your inbox shows you one of them. The envelope sender is the address bounces return to. The From header is the address on screen. Nothing in the mail system forces the two to agree, so a server can announce one domain on the envelope and print another in the From line, and the message still gets delivered.
The From header is defined by RFC 5322 as a text field, not a verified identity. A display name of "Your Bank" on a domain the bank never owned is not a bug in the system; it is how the system works.
Three lines deserve your attention before anything else. From states the claim. Return-Path carries the envelope sender, the address that receives bounces, while Reply-To decides where your answer goes and can differ from both. When the three disagree, treat the message as suspect. The Received lines and Authentication-Results are the evidence. The rest of the header can wait.
The spoofing guide explains what each check proves in more depth. This guide is the hands-on half.
Open the full header in Gmail and Outlook
Use a computer for this. Phones bury the header, and the guides below describe the desktop flow.
In Gmail, open the message, click the three dots beside Reply, then pick Show original. A new window opens, full header at the top. Google's header guide lists the same steps and covers other providers too, if you use something other than Gmail or Outlook.
In Outlook, the path depends on your version. In new Outlook and Outlook on the web, go to More actions, then View, then View message details. In classic Outlook for Windows, double-click the message to open it, then File, then Properties, and look in the Internet headers box. Microsoft's header guide covers the new Outlook path.
Always work from the original message. Forwarding rewrites the header, so a forwarded copy tells you about the forwarder, not the sender. And while you check, click nothing inside the message.
Read the Received chain from the bottom up
Every server that touches a message stamps a Received line on top of the header. The newest stamp sits highest, so the chain reads in reverse: the bottom line is where the journey started, the top line is the final handoff into your inbox. RFC 5321 defines this trace model.
A short fictional example, using test domains and test addresses, makes the shape clear:
From: "Your Bank" <security@bank.example>
Return-Path: <bounces@sender.example>
Reply-To: <help@sender.example>
Authentication-Results: mx.example-provider.com;
spf=pass smtp.mailfrom=sender.example;
dkim=pass header.d=sender.example;
dmarc=pass header.from=sender.example
Received: from mail.sender.example (192.0.2.1)
by mx.example-provider.com;
Mon, 19 Oct 2026 09:12:00 +0000
Received: from laptop.internal (198.51.100.7)
by mail.sender.example;
Mon, 19 Oct 2026 09:11:40 +0000
Start at the bottom. A machine calling itself laptop.internal handed the message to mail.sender.example. Then mail.sender.example passed it to your provider. The From line claims "Your Bank", yet the routing never mentions a bank, and that gap is the tell.
One limit governs the whole exercise. A sender can invent any Received lines they like before the message reaches your provider. The lines worth trusting are the ones your own provider added after receipt: the top Received line, and the Authentication-Results line. Everything beneath them is a claim waiting for support.
A sender can forge every Received line below the handoff. Your provider writes the top Received line and the Authentication-Results line on arrival. Treat the rest as unproven.
Timestamps can place a long delay, though a small oddity usually means one server clock runs fast or slow. Treat that as weak evidence, not proof of forgery.
The alias test names the source
Give each site its own email alias, one forwarding address per site, and the To line starts talking. A message that claims to come from your bank, yet arrives on the alias you handed only to a bookshop, is forged on arrival. The bookshop is the only holder of that address. The leak-tracing method runs on the same idea.
Two limits keep this in proportion. An alias cannot vouch for a sender: a forgery can still land on the correct alias if the attacker already knows it. And aliases do nothing to stop someone spoofing your own address. Think tripwire, not verdict. When a phish lands on the wrong alias, pause that alias. The set-up guide takes about two minutes.
SPF, DKIM and DMARC in one verdict line
The Authentication-Results header carries the verdicts, in the format RFC 8601 defines, and a typical line looks like this:
Authentication-Results: mx.example-provider.com;
spf=pass smtp.mailfrom=sender.example;
dkim=pass header.d=sender.example;
dmarc=pass header.from=sender.example
Each check answers one question:
| Check | What it proves | What it does not prove | If it fails |
|---|---|---|---|
| SPF | The sending server is allowed to send for the envelope domain | Anything about the From header | Server had no authorisation for the envelope domain |
| DKIM | The signed parts arrived unaltered, and the signer is named | That the signer matches the From domain | Signature absent, broken, or the message changed |
| DMARC | An SPF or DKIM pass matches the From domain | Safety, or anything about lookalike domains | No aligned pass supported the From domain |
SPF checks the envelope domain, not the From header. Seven outcomes exist: pass, fail, softfail, neutral, none, temperror, permerror. Fail means not authorised. Softfail means probably not authorised. None means the domain published no SPF record at all.
DKIM checks the seal, not the sender. The sending domain signs chosen headers and the body, and the receiver checks that signature against the public key in DNS. A pass confirms the signed parts arrived unchanged and names the signing domain in the d= tag. That domain can differ from the From domain.
DMARC ties the two checks to the From line. A pass needs an SPF or DKIM pass aligned with the From domain: the same organisational domain in relaxed mode, identical in strict mode. It does not cover lookalike domains or display-name tricks, and no receiver has to follow the published policy.
Forwarding breaks SPF, since the forwarder sits outside the original domain's SPF record. Mailing lists that rewrite a subject or append a footer can break DKIM. ARC, the Authenticated Received Chain, exists for this case: each intermediary records the verdict it saw, so the final receiver can weigh the original result rather than only the broken one.
The 60-second verdict on one suspicious email
The To line first. A message claiming to be from Company X, arriving on an alias you gave to another site, is forged. Pause the alias, delete the message, done.
The verdict line next. Open the full header and find Authentication-Results. A dmarc=fail on a message claiming to be from your bank is strong evidence of forgery. A dmarc=pass carries less weight than it seems: read the From domain character by character against the organisation's real domain, because a lookalike passes for its own domain.
The routing after that. Read the Received chain bottom up and confirm the top line names your provider as the receiving server. Compare Return-Path with the From domain. A Return-Path on an unrelated domain, beside a From line naming your bank, is a mismatch worth treating as forgery.
Then decide. Clean passes on every check, plus the right alias, mean read the message normally. A hard fail on the alias test, or a dmarc=fail on a sensitive message, means delete it and reach the organisation through its own app or a fresh tab, typing the address yourself. If you already clicked, follow the breach-response guide: change the password on the real site and everywhere you reused it, switch on two-factor authentication, and check Have I Been Pwned.
Long headers get easier with a parser. Google's Messageheader tool turns the hop list into a timeline. Microsoft's Message Header Analyzer does the same job. Neither judges the message for you, but both spare you squinting at folded lines.
Report the message once you have decided. In Gmail, open the message, click More beside Reply, then Report phishing, which sends Google a copy for analysis. Google's phishing guide covers the steps. For ordinary spam rather than phishing, the spam guide explains why the report button manages senders, not addresses.
What headers cannot prove
Headers hand you a routing record and three verdicts. They do not hand you safety. Four gaps stay open.
Lookalike domains pass everything for their own domain. A domain that differs from the real one by a single letter passes SPF, DKIM and DMARC for the lookalike. Only a character-by-character read of the From domain against the real one catches it.
Display-name tricks skip the checks. DMARC authenticates domains, not the human-readable name, so a message with the display name "Your Bank" from an unrelated domain can pass every check for that domain.
A pass says nothing about intent. A valid DKIM signature on a phishing message proves it arrived unaltered, not that it is safe. A DMARC pass from a brand-new domain means the domain authorised the mail. It says nothing about who stands behind it.
Post-breach phishing beats content checks by copying the real template. The forged breach notice quotes the genuine apology and lands in the same window as the real one. The post-breach phishing guide covers that case: when the content is identical, the header plus the alias are the test.
The header check still earns its place in your routine. It catches the common case: a From line claiming one domain while the routing and the verdicts point somewhere else. Open the header, read the verdict line, check the alias, and you are done in about a minute once the three checks are familiar. The message either earns a read or gets deleted.
Top comments (0)