Anatomy of a Phish: Five Real Email Headers, Deconstructed

The alert fires at 7 AM. Someone in finance reported a weird email from the CEO. You pour coffee, pull the raw message source, and the day begins. This isn't about fancy dashboards or blinking threat maps. This is about getting your hands dirty in the raw text of an email header, the digital crime scene of every phishing attempt.

Reading headers is a core skill. It's the difference between blindly blocking a sender and understanding an attacker's entire delivery infrastructure. You learn to spot the lies a message tells by reading the truths it can't hide in the `Received` and `Authentication-Results` fields. Forget the email's body for a second. The real story is written in the metadata.

We've pulled five real-world examples from our incident archives. No hypotheticals. We're going to tear them down, line by line, and show you what to look for.

Example 1: The Classic Payroll Redirect BEC

This is the bread-and-butter business email compromise (BEC). No malware, no fancy exploits. Just a simple, urgent request from a spoofed executive, sent to someone in HR or finance with the power to change direct deposit information. The goal is to hijack a paycheck. The entire attack hinges on the recipient being too busy or intimidated to verify the request out-of-band.

Display Name Deception vs. Header From

Right away, you see the core of the deception. The email client shows the CEO's name, creating immediate, unearned authority. But the header tells a different story. The display name is arbitrary; I can make it say anything. The actual sending address, the `smtp.mailfrom` or `header.from`, is what matters.

From: "Jane CEO" <info@random-marketing-service.biz>

This immediately screams. Why is the CEO using a bizarre external domain? This is where email authentication standards are supposed to save us. SPF (RFC 7208) checks if the sending IP is authorized for `random-marketing-service.biz`. DKIM (RFC 6376) checks if the message is signed with a key from that domain. The problem? Both might actually pass for the attacker's domain.

DMARC Alignment is The Real Test

This is where DMARC (RFC 7489) comes in. DMARC doesn't just ask if SPF and DKIM passed; it asks if they *aligned*. Did the domain in the `From:` header (`random-marketing-service.biz`) match the domain that passed SPF or DKIM? In this case, no. The attacker is hoping your company's DMARC policy is set to `p=none` (monitor mode) or that your mail gateway isn't configured to honor `p=quarantine` or `p=reject`. A failing DMARC alignment check on an inbound email from your own domain is the reddest of red flags.

Example 2: The M365 Phish Where Auth Checks Pass

This one is more insidious. An employee gets a notification: 'Your Mailbox Storage is Almost Full'. The email looks perfect—Microsoft logos, correct fonts. The link points to what seems to be a legitimate login portal. And the scariest part? When you check the headers, everything might look clean.

Attackers aren't running these campaigns from sketchy basement servers anymore. They use legitimate, high-reputation email service providers (ESPs) like Amazon SES or SendGrid. They register a new domain, properly configure SPF and DKIM for it, and then build their campaign. The ESP's IPs are authorized, and the DKIM signature is valid for the attacker's own domain.

Authentication-Results: mx.google.com;
dkim=pass header.i=@phishy-but-valid.com;
spf=pass (google.com: domain of messages@phishy-but-valid.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=messages@phishy-but-valid.com;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=phishy-but-valid.com

Look at that. Pass, pass, pass. The email is technically authentic... for the domain `phishy-but-valid.com`. DMARC passes because the `header.from` domain aligns with the DKIM and SPF domains. The receiving mail server sees a perfectly authenticated email. This proves that email authentication is not a silver bullet for phishing. It validates a domain's identity, but it can't validate its intent.

Here, the header analysis tells you something important: the delivery vehicle is clean. Your investigation must pivot immediately from the email's path to its payload—the URL. That's where the real attack is.

Example 3: Malice from a Compromised Vendor

This is a nightmare scenario for Accounts Payable. An invoice arrives from a regular vendor. It's a reply to an existing email thread. The invoice number looks right, the amount is plausible. But the bank account details at the bottom have been changed. The attacker isn't spoofing the vendor; they are the vendor, for all intents and purposes. They've compromised a real account.

The headers here will be deceptively clean. The email originates from the vendor's actual mail server (e.g., Office 365). SPF, DKIM, and DMARC will all pass and align perfectly with the vendor's domain. So how can headers help?

Hunting for Anomalies in Received Headers

You have to become a historian. The chain of `Received:` headers tells the story of the email's journey from client to server to server to you. In a compromised account scenario, you're looking for signs of unusual access. Does the first `Received:` header, which records the client connection, show an IP from a country where the vendor has no employees? Does the `Mimecast-Client-IP` or `X-Originating-IP` point to a residential ISP or a TOR exit node? Is the `User-Agent` string in a non-standard header something weird, like a Python script instead of 'Outlook 16.0'?

This is subtle work. It requires having a baseline of what 'normal' looks like for that vendor, which is often impossible. But if you see an IP from Lagos in the authentication headers for an email from your Omaha-based printing partner, it's time to pick up the phone and verify.

Example 4: The Callback Scam and Freemail Vectors

The callback phish is a social engineering play that uses the phone as the attack vector. An email lands claiming you've been charged $499 for a security software renewal. It's intentionally shocking. To cancel, you have to call a number. On the other end, a scammer waits to talk you into installing remote access software. The email is just bait.

Because the email itself contains no malicious code, just text and images, attackers often use throwaway freemail accounts (Gmail, Outlook.com, etc.) to send them. The headers on these are often a mess, and that's your clue.

Received: from mail-sorter-f41.google.com (mail-sorter-f41.google.com. [209.85.220.41])
by mx.google.com with SMTPS id h19sor12345678pjb.17.2023.01.01.10.00.00
for <victim@example.com>
(Google Transport Security);
Received-SPF: softfail (google.com: domain of transitioning norton.billing@gmail.com does not designate 209.85.220.41 as permitted sender) client-ip=209.85.220.41;

You'll frequently see `softfail` verdicts on SPF. While Google uses its own internal routing that can sometimes cause this, it's still a signal. The `From` header will be something like `norton.billing@gmail.com`. The key is that `gmail.com` has a `p=none` DMARC policy. This means they are telling receivers, 'We know people spoof us, we can't enforce a block, so you decide.' Attackers know this and abuse it. They're counting on the receiver's mail gateway to be permissive and let the email through because there's no strong `p=reject` instruction.

Example 5: The AiTM Proxy and Stolen Session Tokens

Attacker-in-the-Middle (AiTM) phishing is the current top-tier threat against accounts protected by MFA. Instead of just cloning a login page to steal a password, the attacker's server acts as a proxy, sitting between the user and the real service (e.g., Microsoft 365). The user enters their credentials, the proxy passes them to Microsoft. Microsoft challenges for MFA, the proxy passes that to the user. The user approves the MFA push, the proxy passes that back. Microsoft issues a session cookie, and the attacker steals it. They now have an authenticated session and can bypass MFA entirely.

The initial email that delivers the AiTM link often looks identical to the M365 phish in our second example. It might come from a carefully prepared, well-authenticated domain. The headers, once again, may show `dmarc=pass`. This is a critical lesson: header analysis can only tell you about the delivery of the message itself.

The Headers Tell You *What* to Investigate Next

When you encounter a sophisticated phish where the headers look legitimate, that's not a dead end. It's a finding. It tells you the attacker is not a script kiddie using an open relay. They have resources. Your investigation must then shift entirely to the URL in the email body. You need to analyze the link for redirection chains, inspect the landing page's domain registration records (Whois), and check its SSL certificate details. Does a link for a Microsoft login portal have a certificate issued by Let's Encrypt for a domain like `office365-secure-login-portal.xyz`? That's your tell.

Header analysis in an AiTM case confirms the legitimacy of the delivery channel, which forces you to conclude the payload itself is the entire attack. It narrows your focus and helps classify the sophistication of the actor you're dealing with.

The takeaway

Email headers don't lie, but they do tell complicated stories. They are the transaction logs of a message's journey. A `pass` verdict isn't a guarantee of safety, and a `fail` isn't always malice (thanks, misconfigured calendar forwarders). The skill is in synthesis—combining the story told by the `Received:` chain with the verdicts in the `Authentication-Results` and the context of the `From:` header.

Think of this as digital forensics. You gather the evidence, establish a timeline, and look for inconsistencies that reveal the attacker's methods. The more headers you read, the faster you'll spot the patterns, and the more effective you'll be at moving from reactive blocking to proactive threat hunting. This is the ground truth, and tools that help automate and visualize this data, like MailSleuth.AI, build upon this fundamental analyst skill.