Learning Objectives

By the end of this module, you will be able to:

1. Read a Received: header chain in the correct order and reconstruct the message's actual path.
2. Identify the likely originating infrastructure and, where possible, the originating IP, while recognizing the limits of that determination.
3. Normalize and interpret timestamps and inter-hop delay correctly.
4. Locate and interpret authentication results (Authentication-Results:, Received-SPF:, DKIM-Signature:) in a real header block.
5. Compare envelope and header identities systematically, not impressionistically.
6. Identify headers added by Microsoft 365, Google Workspace, common gateways, and — once documented — the product itself.
7. Recognize signs of altered, incomplete, or copy-pasted headers, and know when a conclusion cannot be reached from the evidence available.
8. Apply a repeatable checklist and produce a structured findings write-up for any header set.

Key Terminology

Received chain

The ordered set of Received: headers, each prepended by the receiving system at that hop — read bottom-to-top for chronological (oldest-first) order.

Authentication-Results header

A header (RFC 8601) added by a receiving system summarizing the SPF, DKIM, and DMARC verdicts it computed at that hop — this is hop-specific, not a universal fact about the message.

X-Originating-IP

A non-standard, vendor-specific header some webmail/submission systems add, recording the client IP that originally submitted the message. Useful when present, but not guaranteed and not authenticated.

Hop

One MTA-to-MTA transfer, represented by one Received: header.

Header injection

Any header added, by design, by an intermediate system (gateway, filter, mailbox platform) as the message transits it — distinct from a header present in the original message as composed by the sender.

Lesson

Module 1 established the envelope/header split and the idea that a message crosses several independently owned systems. Module 5 turns that theory into a repeatable, defensible skill: given nothing but a raw header block, reconstruct exactly what happened to a message, in what order, and with what confidence. This is the single most-used technical skill in the entire support role — you will run some version of this checklist on a large fraction of every ticket you ever touch, whether the question is "did this get delivered," "was this spoofed," or "why did authentication fail." Because it's used so often and under time pressure, the goal of this module isn't just to teach you the individual facts — it's to make the correct order of operations automatic, so you reach for the checklist instead of eyeballing the header block and guessing.

5.1 Reading the Received Chain in the Correct Order

The single most common analysis error at the L1 level is reading Received: headers top-to-bottom as if that were chronological order. It is exactly the opposite. Each hop prepends its own Received: header above all the previous ones — so the header block's top-most Received: line is the most recent hop, the one closest to final delivery, and the bottom-most line is the oldest hop, the one closest to the original sender. A useful way to fix this in memory: think of each new hop as a sheet of paper dropped on top of a stack, newest sheet always on top. If you want the story in the order it actually happened, you read the stack from the bottom up.

Always read bottom-to-top for a chronological narrative, and say so explicitly in your findings notes every time — not because the rule is complicated, but because it is the single detail most likely to get silently reversed under time pressure, and a reversed reading order silently inverts every conclusion built on top of it. If you ever catch yourself describing the top Received: line as "the first thing that happened," stop and re-check.

Each Received: line generally follows the same pattern:

Received: from <claimed sending hostname> (<observed rDNS hostname> [<observed IP>])
    by <receiving hostname> (<software/version>)
    with <protocol, e.g. ESMTPS>
    id <local queue ID>;
    <RFC 2822 date/time with offset>

Two different hostnames are doing two very different jobs in that line, and confusing them is a recurring source of bad conclusions. The claimed hostname comes from the sending system's own EHLO/HELO announcement at the start of the SMTP conversation (see Module 1.3) — it is simply asserted by the sending system, and an attacker's own MTA can claim whatever hostname it wants. The observed rDNS hostname and IP, by contrast, are recorded by the receiving system based on the actual TCP connection it saw — information the sender does not get to fabricate in the same way. A mismatch between the claimed and observed identity at a given hop is meaningful and worth flagging; a match is expected and unremarkable, and you shouldn't over-read it as reassuring on its own — it's simply the normal case.

5.2 Identifying Sending Infrastructure and Originating IP

Once you can read the chain in order, the next question is usually: where did this message actually come from? Work outward from the oldest Received: header that your organization does not control — that is, the first hop that your trusted infrastructure itself recorded receiving the message from. This is generally the most reliable point to treat as "the originating conversation," because every Received: header written before that point was authored by systems outside anyone's ability to independently verify — including, in principle, an attacker who controls their own outbound MTA and could theoretically forge earlier hops. In practice this is uncommon, but it is a real limitation worth naming explicitly rather than quietly ignoring.

The practical method:

1. Start at the top of the header block (the most recent hop) and walk downward.
2. Identify the point where the hops transition from "systems we trust or recognize" — the mailbox platform, the security product, internal relays — to "the first external, untrusted system."
3. That first untrusted hop's observed IP (not its claimed hostname) is generally the best available "originating IP" for investigative purposes. Cross-reference it against reputation and threat-intelligence sources (Module 11) and against the domain's own published sending infrastructure (Module 3, SPF/DNS records) for consistency.
4. State the confidence level explicitly in your findings. "Observed originating IP, consistent with the sender's published SPF range" is a materially stronger, more defensible statement than "originating IP" stated as bare fact — train yourself to always qualify this determination rather than presenting it as absolute.

5.3 Timestamps and Delay — Applying Module 1.8 in Practice

This is Module 1.8's timezone-normalization discipline, now applied hop by hop across a full chain instead of just two points. For every Received: header, extract the timestamp and its UTC offset, convert it to a single reference timezone — UTC is recommended — and calculate the delta between each pair of consecutive hops. Flag any single-hop delta greater than a few minutes as worth explaining, rather than dismissing all delay as automatically normal: a few minutes can reflect ordinary queueing delay, greylisting, or scanning time, but it can also reflect an actual problem, and the header block alone won't tell you which without you asking the question.

Watch in particular for a pattern rather than a single data point: if one specific hop consistently shows the longest delay across multiple, unrelated messages — not just one isolated slow message — that is a strong analytical signal that a specific system is a genuine bottleneck, and it's worth surfacing in your findings even if it wasn't what the customer originally asked about.

5.4 Locating and Interpreting Authentication Results

The Authentication-Results: header (RFC 8601) is added by whichever system performed the check, and its verdict is scoped to that system's own hostname — given as the leading token in the header, for example Authentication-Results: mx.example.com; spf=pass .... A single message can legitimately carry multiple Authentication-Results: headers, one per hop that performed a check, and — this is the part that trips people up — they can legitimately show different verdicts at different hops. A hop that occurs after a forwarding step, for instance, may show a different SPF verdict than the original receiving hop did, because the envelope itself changed in between (Sample B, below, is a worked example of exactly this).

Always identify which hop's result you are citing before you state a conclusion — never just "the Authentication-Results said." As a general rule, prefer the result computed closest to the point of final delivery for operational decisions, because that is the verdict the mailbox platform actually acted on; use the earlier hops' results to understand the message's fuller journey, not to override the operational verdict.

Two related headers are also worth checking directly. Some systems still emit the older, separate Received-SPF: header alongside or instead of the unified Authentication-Results: field — don't overlook it if Authentication-Results: is absent. And the DKIM-Signature: header itself (Module 4.2) is worth inspecting directly whenever your tooling allows you to independently re-verify a signature, rather than simply trusting a hop's stated verdict at face value.

5.5 Comparing Envelope and Header Identities — Systematically

Don't eyeball this comparison — it's exactly the kind of judgment call that goes wrong under time pressure. Use a fixed comparison table for every investigation, every time, populating every row that has data and explicitly marking any row that doesn't as "absent" rather than leaving it blank. A blank cell is ambiguous — it could mean "not present in this message" or it could mean "I forgot to check" — and a reviewer (including a future version of you, re-reading your own ticket notes) can't tell those apart. "Absent" removes the ambiguity.

Once populated, apply Module 4's alignment logic to reach a conclusion about SPF/DKIM/DMARC alignment. This table isn't just a teaching aid — it is the findings template you'll use in 5.9. Training yourself to always produce it, rather than informally scanning a header block and forming an impression, is the core skill this module is built around. Every one of the three annotated samples later in this module was worked using exactly this table.

5.6 Forwarding, Relaying, and Gateway Processing Fingerprints

Each type of intermediary system tends to leave a recognizable fingerprint in the header block, and learning to recognize these on sight will save you a great deal of time:

• Corporate/on-prem relay: typically shows up as an internal-hostname Received: hop with a private IP range, positioned between the internet-facing hop and final delivery.
• Mailbox-platform ingestion (Microsoft 365 / Google Workspace): adds its own distinctive Received: hostname pattern and typically its own X-MS-Exchange-* or X-Google-*-prefixed headers, and/or its own Authentication-Results: entry.
• Security gateway/product processing: adds its own Received: hop plus — once documented — product-specific headers, commonly including a verdict/classification header, a message-tracking ID header, and potentially a rewritten-URL indicator.
• Mailing list software: typically rewrites the envelope sender to the list's own bounce-handling address, adds List-Unsubscribe:/List-Id: headers, and often modifies the body itself (a footer, most commonly) — which is exactly why DKIM breakage is an expected, benign pattern here, per Module 4.5.

5.7 Recognizing Suspicious or Spoofed Fields

The following indicators are worth flagging when you see them — but treat each one as a soft signal to be weighed alongside the others, not as proof by itself. Evaluate them as a set, and phrase your findings with that same caution:

• A claimed EHLO/HELO hostname that does not match the observed rDNS at the same hop.
• A Received: chain with a gap — a hop whose "by" hostname doesn't match the next hop's "from" hostname, suggesting a missing or altered link in the chain.
• Header capitalization or formatting inconsistent with the claimed originating platform — for example, headers claiming to originate from a well-known provider but not matching that provider's known header conventions. This is a soft signal, not proof, and your findings notes should say so explicitly rather than stating it as a conclusion.
• A Date: header that is wildly inconsistent with the Received: timestamps.
• Duplicate or out-of-sequence Received: headers that are inconsistent with any plausible real routing path.

5.8 Limitations — Altered, Incomplete, or Copied Headers

Part of doing this analysis well is being honest, in your own findings, about what header analysis cannot do. Three limits matter enough to state explicitly every time they apply:

• A customer who pastes headers into a ticket as a screenshot, or as a partial copy-paste, routinely loses line-wrapping, header ordering, or entire headers in the process. Always request the original, complete message source — an .eml export, or "view source"/"show original" from the customer's mail client — rather than working from a pasted excerpt whenever the finding actually matters.
• Headers written before the first hop your organization's trusted infrastructure recorded cannot be independently verified. They were authored by systems outside anyone's control — including, in principle, an attacker's own infrastructure — and no amount of careful reading changes that fact.
• Header analysis alone cannot prove or disprove account compromise (Module 9). A compromised account's outbound mail will show entirely legitimate authentication and infrastructure, because it genuinely did originate from the legitimate, authenticated account — the compromise happened somewhere headers can't see.

5.9 The Header-Analysis Checklist and Findings Template

Everything above compiles into one repeatable checklist. Work it in this order, every time — the order matters, because later steps depend on information gathered in earlier ones:

1. Confirm you have the complete, original message source — not a screenshot or partial paste (5.8).
2. Extract the Message-ID.
3. Walk the Received: chain bottom-to-top; list every hop with its claimed hostname, observed hostname/IP, and normalized (UTC) timestamp (5.1).
4. Calculate inter-hop delays; flag any outliers (5.3).
5. Identify the first untrusted/external hop; note its observed IP (5.2).
6. Populate the envelope/header identity comparison table (5.5).
7. Extract every Authentication-Results: header present; note which hop each belongs to (5.4).
8. Apply Module 4's alignment logic; state the SPF/DKIM/DMARC conclusion and explain why, not just what.
9. Note any fingerprints of forwarding, relaying, mailing-list, or gateway processing (5.6).
10. Note any suspicious or inconsistent indicators (5.7), explicitly framed as soft signals unless genuinely conclusive.
11. State explicitly what could not be determined from the evidence available, if anything.
12. Write the conclusion as a plain-language summary suitable for both the ticket record and, if needed, a customer-facing explanation.

Step 12's output should always follow the same structure, so that any teammate — or you, reading your own notes weeks later — can find the same information in the same place every time:

MESSAGE-ID: <...>
SUMMARY: [one sentence — what is this message and what was found]
ENVELOPE/HEADER IDENTITY: [table from 5.5]
AUTHENTICATION: SPF=<result, domain evaluated> | DKIM=<result, d= domain> | DMARC=<result, alignment basis>
ROUTING PATH: [ordered hop list, oldest to newest, with any outlier flagged]
FINDINGS: [bulleted, evidence-based]
CONCLUSION: [plain-language, appropriately hedged where evidence is incomplete]
UNRESOLVED / NOT DETERMINABLE: [explicit — do not omit if applicable]

Annotated Sample Headers

(All examples below are constructed and sanitized for training use — no real customer or personal data appears in them.)

Before reading each annotation, it's worth trying the checklist yourself first: read the raw header block, work through 5.9's twelve steps, and decide — legitimate, benign-but-alarming-looking, or malicious — before you read what the annotation says. The point of this module isn't to memorize three answers; it's that the process, run correctly, produces the right answer without you needing to be told in advance which category a given message falls into. That's the actual test you'll face on a real ticket.

Sample A — Legitimate Mail, Clean Authentication

Received: by mail.customer.example.com with ESMTP id 4XyZ12 for <ap@customer.example.com>;
    Tue, 25 Aug 2026 14:02:11 -0400
Received: from mx1.vendor-example.com (mx1.vendor-example.com [198.51.100.22])
    by mail.customer.example.com with ESMTPS id 9AbC34;
    Tue, 25 Aug 2026 14:02:05 -0400
Authentication-Results: mail.customer.example.com;
    spf=pass smtp.mailfrom=billing@vendor-example.com;
    dkim=pass header.d=vendor-example.com;
    dmarc=pass header.from=vendor-example.com
Message-ID: <a1b2c3@vendor-example.com>
From: "Vendor Billing" <billing@vendor-example.com>
To: ap@customer.example.com
Date: Tue, 25 Aug 2026 14:02:00 -0400

Walking through it: two Received: hops in total. Reading bottom-to-top (5.1), the oldest hop is mx1.vendor-example.com handing the message to mail.customer.example.com at 14:02:05, and the newest hop is that same customer server completing local delivery six seconds later at 14:02:11 — a normal, unremarkable delay (5.3). There's only one external hop here, so mx1.vendor-example.com's observed IP, 198.51.100.22, is both the first untrusted hop and the best available originating IP (5.2).

The Authentication-Results: header shows SPF, DKIM, and DMARC all passing, and — this is the part worth checking deliberately, not just noting that three checks say "pass" — all three are evaluated against and aligned to the same domain, vendor-example.com. That domain matches both the envelope sender (smtp.mailfrom=billing@vendor-example.com) and the visible Header From (billing@vendor-example.com). Populating the 5.5 comparison table confirms full alignment across every field that has data. Conclusion: legitimate, clean authentication with full identity alignment — no further investigation warranted.

Sample B — Legitimate but Suspicious-Looking (Benign Forwarding Failure)

Received: by mailbox.customer.example.com; Tue, 25 Aug 2026 09:15:40 -0400
Received: from relay.customer.example.com (relay.customer.example.com [10.10.4.12])
    by mailbox.customer.example.com; Tue, 25 Aug 2026 09:15:38 -0400
Received: from mx1.vendor-example.com (mx1.vendor-example.com [198.51.100.22])
    by relay.customer.example.com; Tue, 25 Aug 2026 09:15:20 -0400
Authentication-Results: relay.customer.example.com;
    spf=fail smtp.mailfrom=bounce@relay.customer.example.com;
    dkim=fail header.d=vendor-example.com (body hash did not verify);
    dmarc=fail header.from=vendor-example.com
Message-ID: <d4e5f6@vendor-example.com>
From: "Vendor Billing" <billing@vendor-example.com>
To: ap@customer.example.com

Walking through it: at first glance this looks alarming — SPF fail, DKIM fail, DMARC fail, all three. If you stopped there, you'd misdiagnose this as a spoofing attempt. Work the checklist instead. Reading bottom-to-top, there are three hops: mx1.vendor-example.com (external, oldest) hands off to relay.customer.example.com, which hands off to mailbox.customer.example.com for final delivery. Notice that middle hop's IP: 10.10.4.12 is a private, internal address range — that's the fingerprint of a corporate/on-prem relay described in 5.6, not an external or untrusted system.

That relay hop is exactly what explains the failing authentication. The Authentication-Results: header was generated by relay.customer.example.com, and its SPF check evaluated smtp.mailfrom=bounce@relay.customer.example.com — the customer's own relay rewrote the envelope sender to its own bounce-handling address as part of its own relay/forwarding behavior, which is a normal, expected pattern, not evidence of an external actor. That rewritten envelope domain naturally fails SPF against records that were never meant to authorize it.

The DKIM failure has its own explicit, helpful reason attached: (body hash did not verify). That's consistent with the relay having modified the message body in transit — appending a disclaimer footer is the most common cause — which is precisely the benign DKIM-breakage pattern Module 4.5 describes for intermediary processing. Populating the 5.5 table shows the Header From is still vendor-example.com, matching Sample A's known-good sender — it's only the envelope identity that changed, and only because of an internal hop, not an external one. Conclusion: the DMARC fail is fully explainable by internal relay/forwarding behavior, not by external spoofing. Confirm with the customer that this relay hop is expected before treating the result as suspicious — but the header evidence itself does not support a spoofing conclusion here.

Sample C — Malicious: Display-Name Spoofing with Passing Authentication

Received: by mailbox.customer.example.com; Tue, 25 Aug 2026 16:40:02 -0400
Received: from mail.freemailhost-example.net (mail.freemailhost-example.net [203.0.113.77])
    by mailbox.customer.example.com; Tue, 25 Aug 2026 16:39:55 -0400
Authentication-Results: mailbox.customer.example.com;
    spf=pass smtp.mailfrom=n.finance8842@freemailhost-example.net;
    dkim=pass header.d=freemailhost-example.net;
    dmarc=pass header.from=freemailhost-example.net
Message-ID: <9f8e7d@freemailhost-example.net>
From: "Nicholas — CFO" <n.finance8842@freemailhost-example.net>
Reply-To: n.finance8842@freemailhost-example.net
To: ap@customer.example.com
Subject: Urgent wire update needed today

Walking through it: this is the sample most likely to be cleared incorrectly by an engineer who checks authentication and stops. All three mechanisms pass — and they are passing correctly, in the narrow technical sense: SPF, DKIM, and DMARC all correctly confirm that this message really was sent by, and really does align to, freemailhost-example.net. There's no forgery in the authentication layer at all, because the attacker doesn't need any — they legitimately control that free-mail domain and its mailbox.

The deception is sitting in a field none of those three mechanisms ever examine: the display name, "Nicholas — CFO", paired with an unrelated, throwaway-looking address (n.finance8842@freemailhost-example.net) and urgency language in the subject line ("Urgent wire update needed today"). Populating the 5.5 table makes the mismatch obvious once you look for it in the right place — Envelope From, Header From, and DKIM d= all agree with each other (all freemailhost-example.net), but none of them is the domain the display name is impersonating, because the display name isn't an authenticated field at all. Conclusion: this is display-name-based impersonation — the pattern covered fully in Module 9 as BEC/executive impersonation — despite entirely clean authentication. Authentication results must never be the sole basis for clearing a message like this one; they answer "is this domain who it claims to be," not "is the person this message claims to be from real."

Hands-On Lab

Scenario-Based Exercise

Knowledge Check

Answer each question yourself before expanding it.