Reading email headers to spot spoofing

Every email carries a full audit trail in its headers — the servers it passed through, the authentication results, and the true envelope sender. Reading them fluently is the fastest way to confirm or debunk a suspected spoof, and it's a core skill for triaging reported phishing.

Where to find the raw headers

The rendered message hides everything useful. Get the raw source:

• Gmail — Show original.
• Outlook — File → Properties → Internet headers (or View message source).
• Apple Mail — View → Message → Raw Source.
• Command line — inspect the .eml directly.

Headers read bottom-to-top for the delivery path: the oldest hop is at the bottom, the receiving server's Received: is at the top.

The identities that matter

There are two "from" values, and phishing exploits the gap between them:

• Envelope sender (Return-Path / MAIL FROM) — used for routing and bounces; checked by SPF.
• Header From (From:) — what the user sees in their client.

A spoof typically shows a trustworthy From: while the Return-Path points somewhere unrelated.

Return-Path: <bounce@sketchy-host.ru>
From: "IT Helpdesk" <helpdesk@yourbank.example>

The display name (IT Helpdesk) is fully attacker-controlled and proves nothing.

Reading Authentication-Results

The single most important header is Authentication-Results, added by your receiving server (trust only the one from your own domain, at the top):

Authentication-Results: mx.yourcompany.example;
  spf=pass (sender IP is 198.51.100.10) smtp.mailfrom=bounce@sketchy-host.ru;
  dkim=fail header.d=yourbank.example;
  dmarc=fail (p=reject) header.from=yourbank.example

Interpret it carefully:

• spf=pass here is a trap — it passed for sketchy-host.ru, not for the visible yourbank.example. SPF checks the envelope, not the From:.
• dkim=fail — no valid signature aligning with the From: domain.
• dmarc=fail (p=reject) — this is the verdict that matters: the visible domain's authentication does not align. A message that reaches an inbox despite dmarc=fail warrants scrutiny.

Always compare the domain each mechanism authenticated (smtp.mailfrom, header.d) against the From: domain. Authentication without alignment means nothing.

Tracing the path with Received

Each hop prepends a Received: line. Read from the bottom up:

Received: from mail.evilrelay.ru (mail.evilrelay.ru [203.0.113.7])
    by mx.yourcompany.example ...; Tue, 08 Jul 2026 09:14:22 +0000
Received: from unknown (HELO localhost) (185.220.101.5)
    by mail.evilrelay.ru ...

Red flags:

• The originating hop's IP geolocates far from where the sender claims to be.
• A forged HELO (localhost, or a hostname mismatching reverse DNS).
• Suspicious gaps or timezone jumps in the timestamps.
• The first trusted hop is your own MX — anything below it is attacker-supplied and forgeable, so weight it accordingly.

Other tells in the headers

• Reply-To divergence — From: looks like a colleague, but Reply-To redirects answers to an external address. Classic in BEC/CEO fraud.
• Message-ID domain that doesn't match the sending domain.
• X-Mailer / X-PHP-Script headers revealing a bulk tool or a PHP script on a compromised host.
• Unicode/punycode in the From: domain (xn--), a homograph attack.

A quick triage checklist

1. Does From: domain == Return-Path domain?          (mismatch = suspect)
2. Authentication-Results: dmarc=pass and aligned?    (fail = suspect)
3. Which domain did SPF/DKIM actually authenticate?   (must match From:)
4. Does Reply-To differ from From:?                   (yes = suspect)
5. Where does the bottom Received hop originate?      (unexpected geo = suspect)
6. Any punycode / homoglyphs in the From: domain?     (yes = suspect)

A single header rarely proves a spoof on its own. The verdict comes from alignment: does the domain that authenticated match the domain the human sees? DMARC exists precisely to automate that comparison — but on inbound mail from other domains, you still need to read it by hand.

How GottaPhish helps

Reading headers is a reactive, expert-only skill, and most users never see them at all. GottaPhish and its expert support team help you bridge that gap: realistic simulated phishing — alignment gaps, Reply-To swaps, look-alike domains — plus dashboards reporting exactly who reported, clicked or submitted credentials. Our experts assist with setup, design scenarios that exercise the header tricks attackers really use, and help you interpret the results — sharpening triage playbooks for technical teams while awareness training teaches everyone else the visible warning signs behind those headers.