How to Detect a Spoofed Email From Its Headers

SMTP was designed with no built-in way to verify who actually sent a message — anyone can claim to be anyone in the visible From field. Nearly every practical defense against that lives in the headers, not the message body. The flags below are listed roughly in order of how strong a signal each one is on its own, and how the analyzer on this page (and the full Email Header Analyzer) detects each.

The Red Flags, Ranked

From vs Return-Path Mismatch

Return-Path is set by the final delivering server from the SMTP envelope's MAIL FROM — it's where bounces and delivery failures actually go, and it's what SPF checks. When its domain doesn't match the visible From domain, bounces go somewhere other than the apparent sender. Mailing lists and some forwarders produce this legitimately, but on a message that isn't going through either, it's one of the strongest available signals of a spoofed sender — the analyzer flags this as return-path-mismatch at danger severity.

Reply-To Tricks

A Reply-To header overrides where a reply goes, separately from where the message claims to be from. A phishing message with a perfectly matched, legitimate-looking From address can still route every reply straight to an attacker-controlled mailbox via Reply-To — the recipient never notices because most clients don't surface Reply-To prominently. This is the core mechanic behind a lot of business-email-compromise attacks: the visible sender is trustworthy, but hitting "Reply" hands the conversation to someone else entirely. Flagged as reply-to-mismatch at warning severity, since legitimate marketing and support systems also use Reply-To routinely.

Display-Name Spoofing

The From header format allows an arbitrary display name next to the actual address: "billing@yourcompany.com" <attacker@evil.example>. Most mail clients show only the display name by default, so a display name engineered to look like a domain or address — especially one that doesn't match the real sending domain — is designed specifically to exploit that truncated view. Flagged as display-name-spoofing at danger severity whenever the display name contains a domain-looking string that differs from the actual address domain.

Broken or Suspicious Received Chains

Because each hop's Received: header is prepended by the server that accepted the message next, the timestamps should increase monotonically as you read from the bottom (originating hop) to the top (final delivery). A hop whose timestamp is earlier than the one before it is either significant clock skew between two real servers, or a header that was forged or reordered by hand — attackers sometimes inject fake earlyReceived: lines to make a message look like it originated from a trusted internal server. Flagged as non-monotonic-timestamps at warning severity; converting a raw hop timestamp with the Epoch Converter can help when cross-checking a suspicious hop against other system logs.

Failed or Unaligned Authentication

A dmarc=fail verdict in Authentication-Results means the receiving server itself concluded the visible From domain wasn't authorized — flagged as dmarc-fail at danger severity. Just as important, and easier to miss: spf=pass or dkim=pass alone don't mean the message is legitimate if neither is aligned to the From domain (see SPF, DKIM & DMARC: Reading the Verdicts for the full mechanics). When no aligned DMARC pass is found — whether the header is missing entirely, absent for this domain, or present but not aligned — the analyzer flags dmarc-absent at informational severity: not proof of spoofing by itself, but a signal that sender authenticity simply couldn't be verified.

Check a Suspicious Message

Paste the raw headers of a message you're unsure about below. The analyzer runs every check described above and lists any flags alongside the Authentication-Results verdicts that back them up.

Privacy note: analysis runs entirely client-side. Header content is never sent to a server.

What to Do About It

No single flag is conclusive proof on its own — weigh them together, and treat a cluster of them (say, a Return-Path mismatch and a DMARC fail) as far more significant than any one in isolation. A few practical next steps:

• Don't click, reply, or reuse the sender's contact info from the message itself. If the message claims to be from a known organization, look up their contact information independently rather than using anything provided in the suspicious email.
• Check the real sending domain's authentication posture. If a message claiming to be from your own organization keeps failing DMARC, the Domain Intelligence Dashboard can confirm what policy your domain actually publishes — a p=none policy means DMARC failures are only ever reported, not blocked, which is often why obviously spoofed mail is still reaching inboxes.
• Report it. Most mail clients have a built-in "report phishing" action that forwards the full headers to the provider — more useful than deleting the message, since it feeds the provider's own filtering.
• If it impersonates your organization, monitor DMARC aggregate reports. The rua tag in a DMARC record routes XML reports back to the domain owner showing exactly who is sending mail as that domain and whether it's passing — see the SPF, DKIM, and DMARC guide for how to set that up.