How to Read Email Headers in 2026: A Phishing Forensics Guide

The email body lies. The header doesn't — at least not without leaving footprints. Every modern phishing investigation begins and ends with what the message metadata reveals: who actually sent it, from where, through which infrastructure, and whether anything along the route was strong enough to call the message authentic.

This guide is for SOC analysts, M365 and Exchange admins, MSP technicians, and anyone who has ever stared at an "Original Message" pane and wondered which line actually matters. It is also a working template for using mailsleuth.ai to compress what used to be a thirty-minute manual read into a five-minute, evidence-backed verdict.

Why Headers Still Matter in 2026

It is fashionable to argue that AI gateways and behavioural analytics have made manual header analysis obsolete. They have not. Modern gateways are excellent at scoring averages — they are far less excellent at edge cases, novel infrastructure, lookalike sender domains, ARC-resigned forwards, or messages that drift just under a quarantine threshold.

A header tells you four things no AI score will:

The exact path the message travelled, and where it joined "your" infrastructure
Which sending identity claimed authorship, and whether the cryptographic and DNS evidence supports the claim
Whether the gateway you trust agreed with that evidence, and at what level of confidence
Operational fingerprints — the X-headers — that betray sender platform, IP, and sometimes the originating user

Treat the header as a chain of custody. Treat the IP as a real-world address. Treat reputation as a credit score. Together, they turn every phishing message into a solvable case.

The Five Sections That Actually Matter

A raw header is daunting. Strip it down to five regions and the noise disappears.

1. The Received Chain

Each gateway that handles the message stamps a Received: line on top. The chain reads bottom-up: the lowest Received: line is the original handoff, the topmost is the final delivery to the recipient mailbox.

The pattern to look for:

Received: from <claimed-sending-host> ([<actual-IP>])
        by <receiving-host>
        with <protocol>; <date>

The IP in square brackets is what the next hop observed, not what the sender claimed. That is the single most forensically useful field in the entire message — and it is the one mailsleuth.ai feeds into APIVoid for reputation, ASN, country, and historic abuse signals before plotting the message's full geographic route.

The bottom-most external Received: header is the message's true origin. Hops above that point are subject to your own organisation's trust boundary; hops below are sender infrastructure you neither own nor control.

2. Authentication-Results

This is the gateway's verdict, in one line, on whether the From: domain has any right to claim authorship:

Authentication-Results: mx.contoso.com;
    spf=pass smtp.mailfrom=marketing.example.com;
    dkim=pass header.d=example.com header.s=selector1;
    dmarc=pass action=none header.from=example.com;
    arc=none

Three checks, three independent signals:

SPF asks: is the sending IP allowed by the envelope (Mail From) domain's published SPF record?
DKIM asks: was the body cryptographically signed by a key the From-domain published in DNS, and does the signature still verify?
DMARC asks: do SPF or DKIM not just pass, but align with the visible From: domain?

DMARC pass is the only one that matters for impersonation defence. SPF pass on an envelope domain that is not the visible From: tells you nothing about the From: claim. A message can be SPF-aligned, DKIM-aligned, both, or neither — and only DMARC alignment protects the brand the user actually sees.

3. From, Return-Path, and Reply-To

These three fields are the most popular hiding place for casual phishers.

From: is what the user sees.
Return-Path: (also called the envelope sender or Mail From) is where bounces go.
Reply-To: is where replies go when the user clicks Reply.

A legitimate corporate message generally has all three pointing at the same domain, or at well-known bounce subdomains of it. A message where From: shows ceo@yourcompany.com and Reply-To: shows ceo.yourcompany@gmail.com is a textbook display-name spoof. A Return-Path on a domain you have never heard of, with a From: on a domain you trust, is a near-certain SPF-but-not-DMARC pass — exactly the kind of message that slips past gateways still running on SPF-only policies.

4. Message-ID and Date

The Message-ID is supposed to be globally unique and follows the pattern <random@sending-host>. Disposable phishing infrastructure tends to leak in two ways:

The host portion does not match any of the Received hosts above
The randomness pattern is suspiciously short, suspiciously sequential, or matches a known kit

The Date header should align — within a few minutes — with the timestamp on the bottom-most Received hop. Multi-hour skews and unexpected time zones often indicate either a misconfigured sender or an automated relay running on a server set to a different region than its claimed origin.

5. The X-Headers

Anything beginning with X- is non-standard, gateway-defined, and full of operational truth. The names you will see most:

X-Originating-IP — the originator IP recorded by the first MTA, where supported
X-Mailer — the user agent or sending platform (Microsoft Outlook 16.0, Mailgun, python-smtplib)
X-Spam-Status and X-Spam-Score — the receiving gateway's verdict
X-Authenticated-Sender — when the message was sent through an authenticated SMTP submission
X-Forefront-Antispam-Report (Microsoft 365) — encoded verdicts on country, language, sender reputation, bulk score
X-Microsoft-Antispam (Microsoft 365) — bulk confidence level, phishing confidence level, spam filtering verdict
X-MS-Exchange-Organization-AuthAs — whether the message was treated as Internal or External by Exchange Online

In a Microsoft 365 environment, these fields are where most of the actual decision-making happens — far more than the visible Authentication-Results line, which is essentially a summary of what is encoded inside the Forefront and Antispam headers.

Walking a Real Header

Consider an anonymised header from a recent BEC investigation:

Received: from BL0PR05MB7193.namprd05.prod.outlook.com (...)
        by SN6PR05MB4291.namprd05.prod.outlook.com with HTTPS; ...
Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181])
        by BL0PR05MB7193.outlook.office365.com with TLS;
        Thu, 17 Apr 2026 14:22:09 +0000
Authentication-Results: spf=pass (sender IP is 209.85.166.181)
        smtp.mailfrom=gmail.com;
        dkim=pass (signature was verified) header.d=gmail.com;
        dmarc=fail action=none header.from=contoso-finance.com;
From: "Jane Smith, CFO" <ceo@contoso-finance.com>
Return-Path: <attacker9182@gmail.com>
Reply-To: <ceo.contoso.finance@protonmail.com>
Message-ID: <CAB+xx7-randomstring@mail.gmail.com>
X-Originating-IP: [209.85.166.181]
X-Mailer: Gmail

Reading bottom-up:

The message originated from a Gmail outbound IP (209.85.166.181). Gmail's SPF passed for the envelope domain gmail.com — accurate, but irrelevant to authorship. DKIM passed for gmail.com. DMARC failed, because the visible From: is contoso-finance.com, not gmail.com, and there is neither SPF nor DKIM alignment with that domain.

The Return-Path on attacker9182@gmail.com, the Reply-To on a ProtonMail address, and the X-Mailer of Gmail make the operational pattern unmistakable: a free-mail account spoofing a CFO display name, relying on the recipient gateway's tolerance of DMARC none policies to let the message through.

What the header alone cannot tell you is whether 209.85.166.181 has shown up in other recent attacks against your tenant, what its ASN reputation looks like over the past 30 days, and whether the path the message took deviates from your organisation's normal Gmail-to-O365 traffic patterns. That is the layer mailsleuth.ai adds.

Where IP Intelligence Picks Up

A header is "what the sender claimed and what the gateway accepted." It is not a reputation score, an ASN profile, or a geographic plot. mailsleuth.ai layers APIVoid data on top of every IP it pulls from the Received chain and the X-Originating-IP fields, surfacing:

Reputation hits — appearance on commercial blocklists, known-abusive ASNs, residential proxy networks
Geolocation — country, city, organisation, ISP
ASN context — hosting provider, transit provider, anycast or static
Routing graph — every hop in the Received chain plotted by geography, with country boundaries crossed and unexpected detours flagged
Historical signals — when this IP first appeared in the corpus, and whether it has been seen in prior phishing or BEC samples

For a SOC tier-1 analyst, this is the difference between "the gateway said pass" and "the gateway said pass, but this IP was rotated into a residential proxy network three days ago and is now sending Gmail outbound for the first time in its history." The header gave the verdict; the intelligence gave the context.

Microsoft 365 Admins: A Few Specifics

If you operate in Exchange Online, do not stop at the user-facing message source. The full forensic picture combines three views:

The client header (what the user can dump from "View original")
The gateway-side trace (Get-MessageTraceDetailV2, replacing the legacy Get-MessageTraceDetail cmdlet)
The threat explorer entry in Microsoft Defender for Office 365, which contains the URL detonation verdict and any post-delivery actions

The header alone tells you what happened up to the point of delivery. The trace tells you what happened inside the tenant — including any zero-hour auto-purge actions Defender took after delivery. mailsleuth.ai is built to consume the client-side header export, but for any high-confidence verdict in an M365 environment you want all three views side-by-side.

A representative PowerShell snippet for pulling the gateway view:

Connect-ExchangeOnline

Get-MessageTraceV2 -RecipientAddress 'jane@contoso.com' `
                  -StartDate (Get-Date).AddDays(-7) `
                  -EndDate   (Get-Date) |
    Where-Object { $_.SenderAddress -like '*@gmail.com' } |
    Get-MessageTraceDetailV2 |
    Format-List Date, Event, Detail, Action

For Graph-driven workflows where the same header artefact needs to drive a SOC ticket, the pattern is similar — pull the message via /security/alerts_v2 or /users/{id}/messages/{id} and pass the internet-message-headers collection straight into mailsleuth.ai's analyser endpoint:

$headers = @{ Authorization = "Bearer $accessToken" }

$msg = Invoke-RestMethod `
    -Uri "https://graph.microsoft.com/v1.0/users/jane@contoso.com/messages/$messageId`?`$select=internetMessageHeaders" `
    -Headers $headers

$msg.internetMessageHeaders |
    ForEach-Object { "{0}: {1}" -f $_.name, $_.value } |
    Out-File ./headers.txt

Pair the trace output with the parsed header in mailsleuth.ai, and the routing graph plus the gateway events render a single timeline you can hand to leadership without further translation.

A Five-Minute Triage Workflow

The aim of header forensics is not to be exhaustive. It is to reach a defensible verdict in the time before the next phishing report lands.

Paste the full header into mailsleuth.ai
Read the Authentication-Results panel — DMARC alignment is the only signal that matters for impersonation
Open the routing graph — look for unexpected countries, ASN changes, residential IP space
Read the IP reputation panel for the bottom-most external Received IP
Compare From: against Return-Path and Reply-To for divergence
Decide: deliver, quarantine, or weaponise into a tenant-wide rule

A clean message will be quiet on every panel. A phish will speak up on at least three.

Closing

The header is the receipt. The IP is the address. Reputation is the credit score. Read in that order, and most phishing investigations stop being investigations and start being decisions. Modern attackers are sophisticated about content, but they remain constrained by the infrastructure they can rent — and infrastructure leaves traces.

mailsleuth.ai is, at heart, a microscope for those traces: a reader that flattens the header into something a tier-1 analyst can act on, and a graph that turns every hop into evidence the rest of your security stack can ingest.

Drop your next suspicious message in. Read bottom-up. Trust the headers — they are not lying.

How to Read an Email Header in 2026: A Phishing Investigator's Guide