The X-Headers Cheat Sheet: 25+ Headers That Expose Phishing Attempts

You’re looking at a phish. The display name is your CEO, the request is urgent, and the link looks suspicious. But the `Authentication-Results` header is a sea of green: `spf=pass`, `dkim=pass`, `dmarc=pass`. How? The attacker registered a convincing lookalike domain, set up perfect DNS records, and sailed right through your basic checks. Now what? The answer is buried deeper in the email source, in the chaotic, non-standard, and utterly essential world of X-headers.

Forget the idea that any header starting with `X-` is just informational junk. These proprietary headers, added by every major mail provider from Microsoft to Google to SendGrid, are the telemetry of modern email delivery. They are the scribbled notes in the margin of the official RFCs—and they often tell the real story of an email's journey and intent.

This isn't a theoretical exercise. This is a practical, operational cheat sheet. Knowing which X-headers to trust, which to question, and which to use as a pivot point can be the difference between closing an incident in ten minutes versus ten hours.

The Ancestors: X-Originating-IP & X-Mailer

Before we get to the vendor-specific good stuff, let's cover two of the oldest and most common X-headers. They are often the first place a junior analyst looks and the first thing a seasoned analyst questions. They offer clues, but they come with major caveats.

X-Originating-IP: The First Hop (Maybe)

This header is typically inserted by the first major mail server that handles a message from a web client, most famously by Microsoft's Hotmail and Outlook.com. It records the public IP address of the user who submitted the email. In a perfect world, if your CFO based in Chicago suddenly sends an invoice request with an `X-Originating-IP` in Lagos, you've found your smoking gun.

The problem is, this world isn't perfect. The `X-Originating-IP` is trivial for an attacker to forge in a custom script. Even when legitimate, it might point to a generic VPN exit node or a massive cloud provider's NAT gateway, rendering it useless for precise attribution. Treat this header as a directional hint, a data point for correlation, but never as definitive proof. It's evidence, not a verdict.

X-Mailer: The Sending Application's Fingerprint

The `X-Mailer` header identifies the software used to compose the message. You'll see values like "Microsoft Outlook 16.0", "Apple Mail (2.3608.80.23.2.2)", or the ever-popular "PHPMailer 6.5.1" from countless web forms and scripts. This is a fingerprint, and its power lies in anomaly detection.

Imagine a long-running correspondence with a vendor who has always used Outlook. Suddenly, a payment request arrives from them with an `X-Mailer` of "PHPMailer". This is a massive red flag. It suggests the message didn't come from your contact's desktop but from a (likely compromised) web server. The attacker isn't your vendor; they've just compromised a system that is authorized to send email for their domain. Like its IP-based cousin, `X-Mailer` can be forged, but attackers often forget to, leaving behind a valuable clue about their tooling.

Inside the Microsoft Security Graph

If your organization uses Microsoft 365, these headers are your native language. Exchange Online Protection (EOP) injects a wealth of information into every inbound and outbound email, detailing every decision its filtering stack makes. Learning to read them is non-negotiable.

The Rosetta Stone: X-Forefront-Antispam-Report

This is arguably the single most valuable header in a Microsoft environment. It's a dense, semicolon-delimited string that provides a complete diagnostic report from EOP's perspective.

X-Forefront-Antispam-Report: CIP:209.85.220.69;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mail-sor-f69.google.com;PTR:mail-sor-f69.google.com;CAT:NONE;SFS:(4638002)(3945004);DIR:INB;

Let's break down the critical fields. `CIP` is the connecting IP that handed the message to EOP. `CTRY` is its country of origin. `LANG` is the detected language. `SFV` is the Spam Filtering Verdict; `NSPM` means Not Spam, while `SPM` indicates it was flagged as spam. Most importantly, `SCL` is the Spam Confidence Level. This number dictates delivery: -1 is a trusted internal bypass, 1 is clean, 5 or 6 sends the mail to Junk, and 9 means it's high-confidence spam and likely quarantined. Understanding this scale is key to diagnosing why a message was delivered or blocked.

The Organization's Authentication Context

The `X-MS-Exchange-Organization-*` family of headers tells you how the message was treated *inside* your tenant. The most important of these is `X-MS-Exchange-Organization-AuthAs`. If this value is `Internal`, Exchange authenticated the sender as a genuine user inside your tenant. If it's `Anonymous`, the message came from the outside world, regardless of what the `From` address says.

Spotting an email from your CEO's address with `AuthAs: Anonymous` is the definitive signal of a direct spoof attempt. It means an external sender simply put your CEO's address in the `From` field. This header, combined with the final verdict in `X-MS-Exchange-Organization-SCL` (which reflects any mail flow rules you've applied), provides the ultimate disposition of a message within Exchange.

Peering Into Google's Infrastructure

Google Workspace tenants have their own set of proprietary headers that provide similar context, though they are often less verbose than Microsoft's. They reveal how a message entered and was processed by Google's massive global mail infrastructure.

A key header is `X-Google-Smtp-Source`. This gives you a trace of how the message was submitted to Google's SMTP servers. You'll see codes that correspond to different ingress points, which can help differentiate a message sent from a third-party app integrated via API versus one sent from the Gmail web client.

Google also adds its own `Authentication-Results` header, which is critical in complex mail flows. Imagine an email passes through a third-party secure email gateway before reaching your Google Workspace tenant. That gateway might add one `Authentication-Results` header. When Google receives it, it performs its own validation and prepends a second, authoritative `Authentication-Results` header. The one at the top is the one that matters most for final delivery decisions within Gmail. This is especially true when dealing with forwarded messages, where ARC (Authenticated Received Chain, RFC 8617) might be in play to preserve authentication signals across hops.

Following the Trail Through Third-Party Senders

Some of the most convincing phish don't come from sketchy IP addresses. They come from legitimate, high-reputation Email Service Providers (ESPs) like SendGrid, Mailgun, Postmark, or Amazon SES. Attackers compromise an account on these platforms and use their pristine infrastructure to blast out campaigns. SPF (RFC 7208) and DKIM (RFC 6376) will pass, because the ESP is an authorized sender.

This is where ESP-specific X-headers become your best tool for remediation. These platforms embed unique identifiers in every single email they send.

Look for headers like `X-SG-EID` or `X-SG-MESSAGE-ID` from SendGrid, `X-Mailgun-Sid` from Mailgun, or `X-SES-Message-ID` from AWS SES. These aren't just random strings; they are high-precision tracking IDs. When you report a malicious email to `abuse@sendgrid.com`, providing this ID is the difference between a generic complaint and a surgical strike. Their support team can use that ID to pinpoint the exact sending account, API key, and campaign, shutting down the attacker at the source.

This is a crucial workflow. In these cases, blocking the sending IP is useless—it belongs to the ESP. Blocking the domain punishes the legitimate brand whose account was compromised. Reporting the specific message ID to the ESP is the only response that addresses the root cause.

Headers from Your Own Security Stack

Don't forget that your own Secure Email Gateway (SEG) or other mail filtering tools add their own headers. Whether it's from Proofpoint, Mimecast, or another vendor, you will almost always find custom `X-` headers that contain the vendor's own scoring, threat classification, and verdicts.

Common examples include headers like `X-Proofpoint-Spam-Details` or `X-Mimecast-Spam-Score`. These are just as important as the Microsoft or Google headers, because they represent the decisions made by the first line of defense. Understanding what these proprietary headers mean is essential for tuning your gateway's policies, troubleshooting false positives, and understanding why a malicious email might have been passed downstream to EOP or Google for a second opinion.

Often, these headers will contain valuable metadata about sandboxing results (Did the attachment detonate? Did the URL lead to a malicious payload?) that you won't find anywhere else. When triaging an alert, always check for your own gateway's headers first—they contain the context closest to your own configuration.

The takeaway

Standard authentication protocols defined by RFCs like DMARC (RFC 7489) are the foundation of email security. They establish identity. But X-headers provide the environmental context—the 'who, what, where' of mail processing that isn't covered by a simple `pass` or `fail`. They are the ground-truth telemetry from the systems that routed, scanned, and delivered the message.

A good analyst knows the standards. A great analyst knows how to read the vendor-specific tea leaves scattered throughout the email source to find the story behind the story. This is the skill that uncovers the sophisticated attacks that are built to look clean on the surface. Parsing these headers manually, however, is a tedious and error-prone chore. Platforms like MailSleuth.AI automatically extract and decipher these disparate vendor headers, correlating them into a single, understandable narrative so you can focus on the verdict, not the regex.