Spotting phishing from the headers

The fastest reliable check is the Authentication-Results header your own mail provider added: if dmarc=pass and the From domain is one you genuinely deal with, the message really came from that domain. If DMARC failed, or passed for a domain that only resembles the real one, treat the message as hostile. After that, compare the From address with the Reply-To and Return-Path, and look at where the first external Received hop came from. Headers cannot catch everything, though: a phishing email sent from a real, compromised account passes every check.

First you need the full headers. Our guide to viewing headers covers every common mail app. Then work through the list below, or paste them into the analyser, which runs these checks in your browser without uploading anything.

The checklist, most useful first

1. Your provider's authentication results

Find the topmost Authentication-Results header whose first word is your provider's server name (for example mx.google.com for Gmail). Ignore any lower down or any naming a server you don't recognize: anyone can put a fake one in a message before sending it. RFC 8601 §5 tells receivers to remove look-alike results claiming to be from themselves, but you cannot see whether yours did.

What to look for:

• dmarc=pass with header.from= the real domain is the strongest header evidence you get. See DMARC explained.
• dmarc=fail for a domain that normally sends you mail (your bank, your employer) is a serious red flag, especially if the domain's policy is reject or quarantine and the message still reached you.
• No DMARC result at all, or dmarc=none, means the domain has no policy. Common for small businesses, so not damning by itself, but it means nothing protects that From address from being forged.

2. The From domain itself

Read the domain after the @ character by character. A passing DMARC result for a typo (examp1e for example), an extra word or a different ending is a pass for the attacker's domain. Our look-alike domains guide covers swapped letters, added words and Unicode tricks such as Cyrillic letters that look Latin.

3. The display name

The name shown in your inbox is free text chosen by the sender. "Payroll Department", "IT Helpdesk" and even a full email address can be put there. Phones often show only the name. See display name spoofing.

4. Reply-To

If a Reply-To is present, your reply goes there instead of to the From address (RFC 5322 §3.6.2). Newsletters and ticket systems use this legitimately. A message that appears to come from a colleague but replies to a free webmail account is the classic set-up for invoice and gift-card fraud.

5. Return-Path

The Return-Path is the envelope sender, where bounces go and what SPF checked. It often differs from From for legitimate bulk mail (the email service's bounce domain). It is worth a look when it is a domain with no connection to either the sender or a known email service.

6. The first external Received hop

Received headers are added top-down, newest first, and must not be altered once added (RFC 5321 §4.4). Read from the bottom up and find the first one written by a server you recognize as yours or as the claimed sender's provider; the from part of that line is the machine that handed the message in. Anything below it was written by the sender's side and can be invented. A message "from your bank" that entered via a residential connection or an unrelated hosting company is suspicious.

7. Date oddities

The Date: header is set by the sender's software when the message was finished (RFC 5322 §3.6.1). A Date far in the past or future, or in a time zone that makes no sense for the sender, can indicate a bulk mailer or a recycled template. On its own this is weak evidence; delays and drafts explain many odd dates.

8. Encoded-word subjects and names

Headers can carry non-ASCII text as encoded-words like =?UTF-8?B?...?= (RFC 2047 §2). That is normal for any language with accents. It becomes suspicious when used to hide something: a display name encoded so that simple filters do not see a brand name, or a subject full of invisible or look-alike characters. Decode it and read what it really says.

An annotated spoof

A synthetic example of an account-alert phish. The real bank uses examplebank.example.

Authentication-Results: mx.example.net;               ← your provider: trust this one
 spf=pass smtp.mailfrom=examplebank-alerts.example;     ← SPF passed… for a look-alike
 dkim=pass header.d=examplebank-alerts.example;         ← DKIM passed for the same look-alike
 dmarc=pass header.from=examplebank-alerts.example      ← DMARC passed for the look-alike, not the bank
Received: from mailer.test (unknown [203.0.113.45])   ← first external hop: generic host, no rDNS
 by mx.example.net with ESMTPS id 4Xk2; Mon, 26 Oct 2026 09:14:03 +0000
From: "Example Bank Security" <alerts@examplebank-alerts.example>   ← extra word in the domain
Reply-To: examplebank.help@freemail.example            ← replies go to an unrelated mailbox
Subject: =?UTF-8?B?QWN0aW9uIHJlcXVpcmVkOiDQsNGBY291bnQgbG9ja2Vk?=
Date: Mon, 26 Oct 2026 09:13:58 +0000

Everything "passes", which is exactly the point: authentication tells you which domain sent the message, not whether that domain is trustworthy. The tell-tales are the look-alike domain, the unrelated Reply-To and the anonymous sending host. The subject decodes to "Action required: асcount locked", where the first two letters of "account" are Cyrillic а and с, a trick to slip past keyword filters.

What headers cannot tell you

• Compromised real accounts. If an attacker has the password of a genuine mailbox at a supplier or colleague's company, their mail passes SPF, DKIM and DMARC for the real domain. The BEC pattern relies on this. Watch the content: unusual payment changes, urgency, secrecy.
• Malicious links and attachments. Headers say nothing about where a link goes.
• Display-name attacks in general. The DMARC specification itself lists them as outside what DMARC can solve (RFC 9989 §11.4).
• Forged lower headers. Anything below the first hop you trust could be invented.

What to do with a suspicious message

1. Don't click links, open attachments or reply. Don't use the "unsubscribe" link in it either; see List-Unsubscribe for the safe way.
2. Verify out of band. Contact the company or person using a phone number or website you already know, not anything in the email.
3. Report it using your mail app's report-phishing or report-junk option, and at work, to your IT or security team, who may want the full headers.
4. Delete it once reported.

If you already clicked or entered a password, change that password from a device you trust, turn on two-step verification, and tell your bank or IT team straight away.