Email Anatomy & Header Analysis

Why Email Headers Matter

When a phishing email lands in a user's inbox, the body is what the attacker wants you to see. The headers are what the attacker hopes you will never look at.

Every email carries metadata that records the full journey from the sender's mail server to the recipient's inbox. This metadata — the headers — is the forensic evidence of the email's true origin. A convincing phishing email can fake the display name, the From address, and the entire body. But the headers contain infrastructure fingerprints that are significantly harder to forge convincingly.

As a SOC analyst, email header analysis is one of your most frequently used skills. Phishing is the initial access vector in over 80% of breaches, and your ability to quickly dissect headers separates a 30-second triage from a 30-minute rabbit hole.

The Three Layers of an Email

An email is not a single blob of text. It has three distinct layers, and understanding them is essential for analysis.

Click to enlarge

Layer 1: The Envelope

The envelope is the SMTP-level routing information. It is never displayed to the end user, but it controls where the email actually goes and where bounces return. The two critical envelope fields are:

• MAIL FROM (envelope sender): The address that receives bounce notifications. This becomes the Return-Path header in the delivered message.
• RCPT TO (envelope recipient): The actual delivery destination.

Think of it like a physical letter: the envelope has a return address and a destination address. The letter inside can say anything — the postal service only reads the envelope.

Layer 2: The Headers

Headers are key-value pairs that record metadata about the email. They include both sender-provided fields (which can be forged) and server-added fields (which are harder to forge). Critical headers for analysis:

Layer 3: The Body

The body is the visible content — text, HTML, attachments. Phishing analysis of the body focuses on URL inspection, attachment type, and social engineering language. We will cover body analysis in later lessons. For now, the headers are your primary target.

The SMTP Delivery Chain

To understand Received headers, you need to understand how email actually travels. SMTP delivery works as a relay chain:

Sender's MUA (Mail User Agent)
    → Sender's MSA (Mail Submission Agent)
    → Sender's MTA (Mail Transfer Agent)
    → [Intermediate relays if any]
    → Recipient's MTA (inbound MX server)
    → Recipient's MDA (Mail Delivery Agent)
    → Recipient's mailbox

Each server in this chain adds a Received header to the top of the email. This means the bottom Received header was added first (by the first server in the chain) and the top Received header was added last (by the server that delivered to the mailbox).

Reading Received Headers

Here is a real-world Received header chain from a legitimate email:

Received: from mail-gateway.company.com (10.0.1.5) by mailbox.company.com
  (10.0.1.10) with LMTP; Mon, 23 Feb 2026 14:32:18 +0000
Received: from mx1.company.com (mx1.company.com [203.0.113.50]) by
  mail-gateway.company.com (Postfix) with ESMTPS id A1B2C3;
  Mon, 23 Feb 2026 14:32:17 +0000
Received: from sender-smtp.example.com (sender-smtp.example.com [198.51.100.25])
  by mx1.company.com (Postfix) with ESMTPS id D4E5F6;
  Mon, 23 Feb 2026 14:32:16 +0000

Reading bottom to top:

1. Origin: sender-smtp.example.com (198.51.100.25) sent the email to mx1.company.com at 14:32:16
2. Inbound gateway: mx1.company.com passed it to mail-gateway.company.com at 14:32:17
3. Final delivery: mail-gateway.company.com delivered it to mailbox.company.com at 14:32:18

Click to enlarge

The timestamps increment by about one second per hop — this is consistent with normal delivery. If you see a 6-hour gap between hops, or timestamps that go backwards, something is wrong.

Anatomy of a Single Received Header

Each Received header follows this pattern:

Received: from <sending-server> (<reverse-DNS> [<IP>])
    by <receiving-server> (<software>) with <protocol> id <queue-id>;
    <timestamp>

Return-Path vs From: The Phishing Red Flag

The single most common phishing indicator visible in headers is a mismatch between Return-Path and From.

Return-Path: <random38271@cheap-bulk-mailer.ru>
From: "IT Support" <support@yourcompany.com>
Reply-To: helpdesk-urgent@gmail.com

Three different addresses, three different domains. The user sees "IT Support support@yourcompany.com" in their inbox and trusts it. But the actual envelope sender is a Russian bulk mailer, and replies go to a Gmail account.

X-Headers: Hidden Intelligence

X-headers are non-standard headers added by mail servers, security gateways, or sending applications. They are prefixed with X- and often contain forensic gold:

X-Originating-IP

Added by webmail services (Outlook.com, Yahoo) to record the sender's actual IP address:

X-Originating-IP: [185.220.101.42]

This lets you geolocate the sender. If the email claims to be from your CEO in Chicago but X-Originating-IP resolves to a Tor exit node in Romania, you have a strong indicator.

X-Mailer

Identifies the software used to compose the email:

X-Mailer: Microsoft Outlook 16.0
X-Mailer: PHPMailer 6.5.0
X-Mailer: sendmail/8.15.2

Legitimate corporate email typically shows Outlook, Apple Mail, or Thunderbird. Phishing campaigns often reveal bulk-sending tools: PHPMailer, King Phisher, GoPhish, or custom Python scripts. Seeing X-Mailer: PHPMailer on an email claiming to be from your CFO is a red flag.

X-Spam-Status and X-Spam-Score

Added by spam filters (SpamAssassin, Barracuda, Proofpoint):

X-Spam-Status: Yes, score=8.7 required=5.0
X-Spam-Flag: YES

If the email reached the inbox despite a high spam score, check whether the user whitelisted the sender or if a mail rule bypassed filtering.

Message-ID Analysis

Every email should have a unique Message-ID generated by the originating server:

Message-ID: <5f2b3c4d.1c69fb81.a3f52.8721@mx.google.com>

The domain after @ in the Message-ID should match the sending infrastructure. Key checks:

Message-ID: <20260223.abc123@legitimate-corp.com>   ← consistent
Message-ID: <x8dj2k@vps-cheap-hosting.xyz>          ← suspicious origin
Message-ID: <>                                       ← broken/missing — red flag

Practical Header Analysis: Spotting the Phish

Let us walk through a complete set of suspicious headers:

Return-Path: <info-29481@mass-mailer.info>
Received: from gateway.company.com (gateway.company.com [10.0.1.1])
    by mailbox.company.com with LMTP; Mon, 23 Feb 2026 09:14:22 +0000
Received: from mx.company.com (mx.company.com [203.0.113.10])
    by gateway.company.com (Postfix) with ESMTPS id 7A8B9C;
    Mon, 23 Feb 2026 09:14:21 +0000
Received: from mail-out.mass-mailer.info (unknown [45.33.18.201])
    by mx.company.com (Postfix) with ESMTP id 3D4E5F;
    Mon, 23 Feb 2026 09:14:20 +0000
Received: from localhost (unknown [192.168.1.100])
    by mail-out.mass-mailer.info (Postfix) with ESMTP id 1A2B3C;
    Mon, 23 Feb 2026 09:14:18 +0000
From: "Microsoft 365 Team" <no-reply@microsoft.com>
Reply-To: account-verify@outlook-security-check.com
Message-ID: <928371.a8c9d2@mass-mailer.info>
X-Mailer: PHPMailer 6.5.0
Subject: Urgent: Your Account Will Be Suspended

Red flags identified (bottom to top):

1. Return-Path domain (mass-mailer.info) does not match From domain (microsoft.com)
2. Bottom Received header: Originated from localhost on a private IP via mass-mailer.info — not Microsoft infrastructure
3. Received from vs parenthetical: from mail-out.mass-mailer.info (unknown [45.33.18.201]) — the IP has no reverse DNS, flagged as "unknown"
4. Protocol: ESMTP (no S) — the connection from the attacker to the company MX was unencrypted
5. Reply-To: outlook-security-check.com — a look-alike domain, not microsoft.com or outlook.com
6. Message-ID domain: mass-mailer.info — matches the actual sending infrastructure, not Microsoft
7. X-Mailer: PHPMailer 6.5.0 — a bulk-sending library, not Outlook/Exchange

That is seven independent indicators in a single header set. Any one of them warrants suspicion. Together, they confirm this is a phishing email with near certainty.

How to View Raw Headers

Every mail client lets you access raw headers. Here are the common methods:

Building Your Header Analysis Checklist

When you receive a suspicious email for analysis, work through these checks in order:

1. Return-Path vs From: Do the domains match? If not, why?
2. Received chain (bottom to top): Does the origin server match the claimed sender? Are there suspicious hops?
3. Reply-To: Does it differ from From? Is it a look-alike domain?
4. Message-ID domain: Does it match the sending infrastructure?
5. X-Originating-IP: If present, does the geolocation make sense?
6. X-Mailer: Is it a legitimate mail client or a bulk-sending tool?
7. Timestamps: Are they sequential? Any large gaps or anachronisms?
8. Authentication-Results: SPF, DKIM, DMARC pass/fail (covered in depth next lesson)

Key Takeaways

• An email has three layers: envelope (SMTP routing), headers (metadata), and body (content) — headers are the primary forensic target
• Read Received headers from bottom to top to trace the delivery path chronologically
• The Return-Path (envelope sender) and From (display sender) are independent — a mismatch is the single most common phishing indicator
• The parenthetical in Received headers (reverse-DNS and IP) is added by the receiving server and is much harder to forge than the from claim
• X-headers like X-Originating-IP and X-Mailer provide attacker infrastructure fingerprints
• Message-ID domain should match the actual sending infrastructure — mismatches reveal spoofing
• Always request the original .eml file from reporters — inline forwarding destroys header evidence

What's Next

You now know how to read the forensic evidence in email headers. But how do you know if the sending server was authorized to send that email? In the next lesson, we will cover the three email authentication protocols — SPF, DKIM, and DMARC — that give you a definitive answer. These protocols are the automated gatekeepers that validate (or reject) every email before it reaches the inbox, and understanding their headers is essential for phishing triage in Lab 4.1.