How to read email headers and spot a fake email

Email headers are the technical lines hidden at the top of every message: who it claims to be from, where replies go, which servers carried it, and whether it passed the SPF, DKIM and DMARC checks. To spot a fake, open the raw headers, find the Authentication-Results line your own email provider added, and compare the domain in the From line with the domains in Reply-To and in those checks. If DMARC failed and replies go somewhere else, treat the message as fake.

What the headers are, and who writes them

Some headers are written by the sender, so they can say anything. Others are added by the servers that carry the message, and the most useful ones by your own provider on arrival.

• From is the address you see. The sender types it, and the display name in front of it is plain text.
• Reply-To is where your answer goes. If it is at another organization, your reply goes to someone else.
• Return-Path is the hidden address for bounced mail. Mailing services often put their own domain here, so a different domain is not suspicious on its own.
• Received is one line per server that handled the message.
• Authentication-Results holds the SPF, DKIM and DMARC verdicts, written by the receiving server.
• Date, Message-ID and X-Mailer (the program used) are all written by the sender.

Step 1: find the raw headers

1. Don't click links or reply yet. Open the message on a computer: many phone apps hide the full headers.
2. In Gmail on the web, click the three-dot menu next to Reply and choose "Show original". A new tab opens with the full text.
3. In Outlook on the web, click the three-dot menu, then "View" and "View message source".
4. In Apple Mail on a Mac, choose View > Message > All Headers.
5. Copy everything from the first line down to the first blank line, where the headers end and the body starts.

The menu wording may change. If you can't find it, search your provider's help for "message source".

Step 2: read the Received lines from bottom to top

Each server that handles a message adds its Received line above the ones already there. The newest line is at the top and the oldest at the bottom, so you follow the trip from the bottom up.

The top lines were written by your provider's servers. The bottom ones were written earlier, and the sender can invent them. The first line you can rely on is where your provider received the message: "from" some server "by" your provider's server. That "from" server, with its IP address (a machine's numeric address on the internet), really handed the message over.

Each line ends with a time. A few seconds between servers is normal; long delays usually mean a mail queue and prove nothing.

Step 3: trust only your provider's Authentication-Results

When a message arrives, your provider checks it and writes three verdicts:

• SPF (Sender Policy Framework): is the sending server on the list the domain published? The domain checked appears as smtp.mailfrom, taken from the Return-Path.
• DKIM (DomainKeys Identified Mail): does the message carry a valid digital signature? The signing domain appears as header.d or header.i.
• DMARC: did SPF or DKIM pass for the domain in the visible From line, shown as header.from?

Use only the Authentication-Results line your own provider added, normally the one nearest the top. Lower ones may have been written by the sender, and a fake dmarc=pass is just text.

What alignment means

A scammer can pass SPF for their own domain and still put someone else's domain in From. DMARC catches this with alignment: SPF or DKIM only counts if the domain it checked matches the From domain. In the usual relaxed mode, a subdomain such as mail.tienda-ejemplo.co matches tienda-ejemplo.co. So compare smtp.mailfrom and header.d with header.from. To see how a domain sets this up, read DMARC in one day.

A worked example

Your business buys from a supplier at tienda-ejemplo.co. An email from "Tienda Ejemplo Cartera" says its bank account has changed and asks you to pay the next invoice into the new one. Below are its key headers, top to bottom, invented and shortened; mx.mailhost.example is your provider.

Header line	What it tells you
Return-Path: <bounce@example.net>	Bounces go to example.net. Alone, this is normal for mailing services.
Received: from mail.example.net [203.0.113.45] by mx.mailhost.example; 09:14:07	Written by your provider: the message came from mail.example.net.
Authentication-Results: mx.mailhost.example; spf=pass smtp.mailfrom=bounce@example.net; dkim=none; dmarc=fail (p=NONE) header.from=tienda-ejemplo.co	SPF passed, but for example.net. No DKIM signature. DMARC failed: nothing proves the supplier sent it.
Received: from [192.0.2.10] by mail.example.net; 09:13:58	The oldest line, from the sender's side. It could be invented.
From: "Tienda Ejemplo Cartera" <cartera@tienda-ejemplo.co>	What you see. Anyone can write it.
Reply-To: <pagos.cartera@example.org>	Your answer would go to a third domain.
X-Mailer: bulk-mailer 1.4	A bulk-mail program. A note, not proof.

SPF passed for the wrong domain, so it isn't aligned, and DMARC failed. The supplier's domain only monitors (p=none), so the fake was delivered anyway. Add the Reply-To, and this message is fake. Call the supplier on a number you already have.

Step 4: check it with the eThorns tools

1. Paste the headers into the Email header analyzer and click "Analyze headers". It only reads the text you paste: it looks nothing up and sends nothing anywhere.
2. Read the overview: From, Reply-To, Return-Path, Date, the mailer and the Message-ID, side by side.
3. Read the red flags: a display name that is an email address from another domain, a Reply-To at another organization, a Date in the future, and SPF, DKIM or DMARC failures. Softer notes cover a Return-Path at another organization, a script or bulk-mail X-Mailer, and an SPF softfail. The example gets two red flags and two notes.
4. Check the verdicts. The tool doesn't run SPF or DKIM itself; it reads the Authentication-Results lines, starting at the top. If there are several, make sure the one you rely on is your provider's.
5. Look at the Received chain: the hops from bottom to top, with the delay between each. Hop 1 is the least reliable.
6. If the message has links, paste its text into Is it a scam?. Only the links go to the eThorns server, which follows them and checks each domain's age; results are kept for up to an hour.
7. Check the real sender's domain with the Email security checker, which queries Cloudflare's public DNS from your browser. With no DMARC, or only p=none, anyone can put that domain in From, as in the example.

What headers can't prove

• A pass is not a guarantee. DMARC proves the message came from the domain in From, not that the domain belongs to who it claims. Whoever registers tubanco-seguro.co can pass all three checks for it.
• A hacked account sends real mail. If a supplier's mailbox is taken over, its messages pass everything.
• The first IP is not a person. It may be a rented server or a hacked computer.
• Headers say nothing about links or attachments. Check those separately.
• A forwarded message has new headers. You see the forward's headers, not the original's.

For fake tax notices, see Fake DIAN emails.

Checklist

• Headers copied on a computer, down to the first blank line.
• SPF, DKIM and DMARC read from your provider's Authentication-Results line.
• DMARC pass, with header.from showing the exact domain you expected.
• Reply-To absent, or at the same organization as From.
• Received read bottom to top, trusting only your provider's lines.
• Any money request confirmed by phone, on a number you already had.

Frequently asked questions

Can a scammer fake email headers?

Most of them, including fake Received and Authentication-Results lines lower down. They can't write the lines your provider adds at the top on arrival.

DMARC passed. Is the email safe?

Not necessarily. It means the message really comes from the domain in From. Check that the domain is the one you expected, not a lookalike; the lookalike domain checker helps.

Why does a real newsletter have a different Return-Path?

Mailing services use their own domain to process bounces. If DMARC passes, that is normal.

Is it safe to paste headers into the analyzer?

Yes. It runs in your browser and sends nothing. Headers do contain your address, so share them with other people as carefully as the email itself.

Try it

• 2.5Email header analyzerPaste an email's raw headers to see the servers it passed through, the SPF, DKIM and DMARC results your provider recorded, and signs of a forged sender.
• 1.1Is it a scam?Paste a message or link you received and see its warning signs: brand look-alikes, new domains, short links, scam wording.
• 2.2Email securityCheck a domain's SPF, DKIM, DMARC, MTA-STS, BIMI and DNSSEC, and get copy-ready DNS records for what's missing or wrong.