Anatomy of an Email Header

Almost every phishing investigation begins with the same artefact: a block of headers the recipient pasted into a ticket. Read them in the wrong order and you will believe a forged From: line.

Read from the bottom up

Headers are appended by each server that handles the message. The oldest hop is at the bottom, the newest at the top. Start at the lowest Received: line and work upward to reconstruct the actual path the message took.

Each hop looks like this:

Received: from mail.example.com (mail.example.com [203.0.113.10]) by mx.recipient.net with ESMTPS id abc123 for <user@recipient.net>; Tue, 13 Oct 2026 09:14:22 +0000

That gives you the sending host name, the IP it connected from, the receiving server, and a timestamp. Discrepancies between the hostname and the IP are a strong signal.

The fields that matter

• From vs Return-Path vs Reply-To. These do not have to agree. Attackers routinely set From: to a trusted brand while Reply-To: points somewhere else entirely.
• Authentication-Results. The receiving server's verdict on SPF, DKIM and DMARC. spf=pass only means the sending IP was authorised for the envelope domain — not that the message is trustworthy.
• Message-ID. Usually generated by the originating client or gateway. An internal-looking Message-ID on a message that arrived from the internet is suspicious.
• X-Mailer / User-Agent. Bulk mailers and phishing kits leave distinctive strings. Not proof of anything, but a useful pivot.
• Received-SPF. The raw SPF evaluation, useful when Authentication-Results has been stripped.

What you can and cannot conclude

Can. The chain of servers that handled the message, within the limits of what they chose to log. Whether the envelope domain authorised the sending IP. Whether the DKIM signature covers the body — and whether the body changed in transit.

Cannot. That the From: address is genuine (it is a header, and headers can be forged). That the sender is a particular person — you have an IP and possibly a compromised account, not an identity. Anything at all about hops whose logs you do not have.

A quick triage order

1. Extract the full header block, not a screenshot.
2. Walk the Received: chain bottom-up and note each IP.
3. Check Authentication-Results for SPF, DKIM and DMARC.
4. Compare From, Return-Path and Reply-To.
5. Extract every URL and hash the attachments — never open them on a workstation.
6. Record what the headers do show, and explicitly state what they do not.

That last step is the difference between a report and a guess.