Why 'Received: from' Lies—and How to Find the Truth in Email Headers

An alert fires for a potential CEO fraud attempt. You pull up the headers. The message claims to be from your CFO, asking for an urgent wire transfer. You start tracing the hops, working from the bottom up, and the first external `Received` header looks clean: `Received: from mail-relay.trusted-vendor.com`. Case closed, right? It passed through a known partner. Except the wire transfer is to a brand new beneficiary, and the CFO is on a plane.

This is the moment every analyst faces. The evidence says one thing, but your gut says another. Your gut is right. The single most important rule of email header analysis is that the `Received: from` clause is not a statement of fact. It's an unverified claim. And until you learn how to dismantle it, you're triaging with one hand tied behind your back.

Finding the One Line You Can Actually Trust

Email headers are a stack of entries, each prepended by a Mail Transfer Agent (MTA) that handled the message. A message from sender@example.com to recipient@mycorp.com might traverse three MTAs. The header chain would look like this, read from top (oldest) to bottom (newest):

Received: from mta3.mycorp.com ... (written by your local delivery agent)
Received: from mta2.partner.net ... (written by mta3.mycorp.com)
Received: from mta1.example.com ... (written by mta2.partner.net)

Here's the critical distinction: the server at `mta3.mycorp.com` wrote the line about `mta2.partner.net`. The server at `mta2.partner.net` wrote the line about `mta1.example.com`. Each server documents the connection it *received*. The only entry in this entire chain that you can fundamentally trust is the one written by a server you control.

This is your trust boundary. For most organizations, it's your secure email gateway (like a Proofpoint or Mimecast) or your cloud tenant's primary MX record (Microsoft 365, Google Workspace). When you're analyzing a suspicious email, your first job is to ignore everything else and find the *first* `Received` header stamped by your own infrastructure. This is ground zero. This header documents the last external hop before the message entered your environment. All headers above it are hearsay.

The SMTP Handshake: Where the Lie Begins

To understand why this hearsay is so unreliable, you have to look at the SMTP transaction itself. When a sending server connects to your MTA on port 25, one of the first things it does is introduce itself with a `HELO` (or `EHLO`) command.

The HELO Name Is Just a String

The client can say whatever it wants. A legitimate Google server will say `EHLO mail-sor-f41.google.com`. A malicious server hosted on a compromised machine in a residential IP block can also say `EHLO mail-sor-f41.google.com`. The receiving MTA has no initial reason to disbelieve this. It's just a string, part of the protocol.

When your MTA generates its `Received` header, the `from` clause is typically populated with this self-declared `HELO` name. The `by` clause is your own server's name. So a malicious connection can look like this: `Received: from mail-sor-f41.google.com (...) by mx.mycorp.com ...`. It looks legitimate, but the `from` part is pure fiction supplied by the attacker.

Cross-Validation with Reverse DNS (PTR)

This is why competent MTAs don't just blindly trust the HELO. They perform a series of checks. The most basic is a reverse DNS (PTR) lookup on the connecting IP address. This asks the network: 'Who owns IP address 198.51.100.123?'

A well-configured mail server will have a PTR record that resolves back to a hostname, and that hostname should have an A record that resolves back to the original IP address. This is called Forward-Confirmed Reverse DNS (FCrDNS). While not a foolproof security mechanism, its absence is a massive red flag. Spammers and phishing kits operating from compromised devices rarely have control over PTR records.

Most modern MTAs will record both the claimed `HELO` name and the verified PTR result in the `Received` header. You'll see something like this: `Received: from claimed-name.com (verified-ptr-name.com [198.51.100.123])`. If `claimed-name.com` is `google.com` but `verified-ptr-name.com` is `adsl-123.some-isp.net`, you've found the lie.

The Prepend Attack: Injecting a Fake History

Okay, so we know the `HELO` name in our trusted `Received` header can be a lie. But what about the headers *above* it? Those can be complete fabrications.

Remember, headers are just text. An attacker can construct a block of four, five, or ten perfectly formatted `Received` headers, making it look like the email originated from their target's own domain and bounced through a dozen legitimate internal relays. They simply add this text block to the top of the message body *before* initiating the `DATA` command in the SMTP session.

Your gateway receives this payload. It doesn't interpret these lines; it just sees them as part of the message content. Then, it does its job: it prepends its *own*, single, truthful `Received` header to the very top. The result is a beautiful, layered, and entirely fictional history sitting right above the one real entry. The analyst who isn't trained to find the trust boundary first will get lost in this fantasy trail, wasting precious time.

This is a common tactic in Business Email Compromise (BEC) and spear-phishing. The goal is to create just enough plausible header chatter to bypass a cursory human review. The attacker is betting you won't dig deep enough to find the one line that matters: the one where their server, with its shady IP and mismatched PTR record, actually connected to yours.

Finding Ground Truth with Authentication

So far, we've focused on network-level tells like IP addresses and PTR records. But the most powerful tools for cutting through the noise are the email authentication standards themselves: SPF, DKIM, and DMARC.

The Power of Authentication-Results

The `Authentication-Results` header, defined in RFC 8601, is your best friend. Your secure email gateway generates this header *after* it performs its checks. It's a definitive summary of what passed and what failed, recorded at your trust boundary.

A passing SPF result (RFC 7208) tells you that the connecting IP address is authorized to send mail for the domain in the `MAIL FROM` (or `Return-Path`) address. This gives you an authenticated link between an IP and a domain that completely bypasses the untrustworthy `HELO` name. If SPF passes, you know the source is legitimate for that envelope domain, even if other signals are weird.

A passing DKIM signature (RFC 6376) provides a different kind of truth: cryptographic assurance that the message body and certain headers haven't been tampered with since they were signed by the domain in the `d=` tag of the signature. DMARC (RFC 7489) then ties it all together, requiring alignment between these authenticated domains and the `From:` header the user sees. The `Authentication-Results` header is the report card for all of this.

How ARC Preserves Truth Across Hops

Complex mail flows, especially involving mailing lists or forwarders, are the bane of SPF and DKIM. A simple forward can break SPF because the forwarder's IP isn't in the original sender's SPF record. Some forwarders add footers, breaking the DKIM body hash.

This is where the Authenticated Received Chain (ARC), defined in RFC 8617, comes in. An ARC-aware forwarder will perform its own auth checks, record the results (e.g., 'SPF passed, DKIM passed from the original source'), and then cryptographically sign those results in a new set of `ARC-` headers (`ARC-Authentication-Results`, `ARC-Seal`). When the message arrives at its final destination, the receiver can validate this chain. It allows the final MTA to say, 'Okay, SPF is failing *now*, but I can see a valid signature from Google attesting that it was passing before it hit this forwarder.' It's a chain of custody for authentication verdicts, helping you distinguish a broken-but-legitimate forward from a malicious attack.

A Simple Methodology: Think Like Traceroute

You don't need to be an SMTP guru to apply these rules. Just adopt a simple, repeatable methodology. Think of it like running `traceroute` on an email.

First, find the absolute bottom. Scroll past the message body, past all the `Received` headers, until you find the headers added by the user's mail client (MUA) itself, like Microsoft Outlook or Apple Mail. This is your destination.

Now, work your way up. Each `Received` header is a hop. You'll likely see a few internal hops as the message moves from your gateway to your mail-store to the user's inbox. Keep going until you find the first header stamped by a server you recognize as your external-facing gateway. This is the hop that matters.

Stop here. Scrutinize this single header. What is the connecting IP address? What does the PTR record say? Now, look for the `Authentication-Results` header generated by that same gateway. What does it say about SPF and DKIM for the `From:` domain? This is your ground truth.

Everything above this point is suspect. Any `Received` header higher up the chain could be, and often is, a complete fabrication. By anchoring your analysis to your own trust boundary, you can confidently call out `Received: from` spoofing and get to the real source of the threat.

The takeaway

The `Received` header is a story of an email's journey, but it's a story told by many different narrators, some of whom are liars. The only narrator you can trust is yourself—or rather, your infrastructure. The logs, headers, and authentication results generated at your own border are the only forensic evidence that matters. Everything else is just noise designed to distract you.

Hunting for that trust boundary and validating the connecting IP against authentication results is the core discipline of header analysis. It's a skill that separates a junior analyst from a seasoned investigator. For complex cases, especially those involving multiple forwarders or convoluted ARC chains, tools built for this purpose, like MailSleuth.AI, can automate this 'traceroute' logic, instantly highlighting the true origin and saving critical time during an incident.