Gmail’s Authentication-Results Header, Translated for SOC Analysts

You have the raw header from a suspected phishing attempt. The first few `Received` headers trace a messy path across the internet, but the real story—the cryptographic proof of identity—is packed into a single, dense line.

For anyone defending a Google Workspace environment, that line is the `Authentication-Results` header. It’s Google’s final judgment on a message's legitimacy, a condensed report card detailing every major email authentication check. It’s not a Google invention; the header is standardized in RFC 8601.

But Google’s implementation is what matters. It's the ground truth for delivery, spam filtering, and security policy inside the world's most dominant email platform. Understanding its syntax isn't just an academic exercise; it’s a core skill for incident triage.

The Core Verdicts: SPF, DKIM, and DMARC

At its heart, the header reports on the Big Three of email authentication. Every analyst should be able to parse this at a glance. It tells you what passed, what failed, and why.

Authentication-Results: mx.google.com;
spf=pass (google.com: domain of sender@example.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=sender@example.com;
dkim=pass header.i=@example.com header.s=20230601 header.b=somehash;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

SPF: The Brittle IP Check

Sender Policy Framework (RFC 7208) is the simplest check. It asks: is the connecting IP address authorized to send mail for the domain in the envelope-from (`MAIL FROM`) address? Google’s verdict is usually `pass`, `fail`, `softfail`, or `neutral`. A `pass` is good, but it's a weak signal on its own. Its notorious weakness is that it breaks the moment an email is forwarded. When a message is rerouted through an intermediary server—like a mailing list or a partner's helpdesk—the new server's IP won't be in the original sender's SPF record. The result is an instant `spf=fail`, even for a perfectly legitimate email.

DKIM: The Cryptographic Signature

DomainKeys Identified Mail (RFC 6376) is far more resilient. It adds a cryptographic signature to the email's headers, tying the message content to the sending domain. As long as the signed headers and body aren't modified in transit, DKIM will pass. A `dkim=pass` is a strong signal of integrity. A `dkim=fail` means one of two things: either the message was tampered with, or a clumsy intermediary mail transfer agent (MTA) modified the content, breaking the body hash. This often happens when corporate legal disclaimers or antivirus banners are appended to the bottom of an email after it was signed.

DMARC: The Policy Layer

Domain-based Message Authentication, Reporting, and Conformance (RFC 7489) doesn't introduce a new check. Instead, it tells receivers what to do if SPF or DKIM fail. DMARC requires *alignment*—the domain in the user-visible `From:` header must match the domain used for the passing SPF or DKIM check. A message can have `spf=pass` and `dkim=pass` but still result in `dmarc=fail` if the domains don't align. This is a primary defense against Business Email Compromise (BEC) where an attacker sends from a lookalike domain. The DMARC result (`pass` or `fail`) and the resulting disposition (`dis=NONE`, `QUARANTINE`, or `REJECT`) tell you if the sender's policy was enforced.

Beyond the Standards: Google's Own Signals

Google doesn't just stop with the standard RFCs. The `Authentication-Results` header often includes additional, proprietary checks that feed into its massive spam-filtering engine. These provide crucial context during an investigation.

The `iprev` Check

One of the most common additions you'll see is `iprev`. This stands for IP reverse validation. It performs a reverse DNS lookup (PTR) on the connecting mail server's IP address to get a hostname, then performs a forward DNS lookup (A or AAAA) on that hostname. If the resulting IP address matches the original, the check passes. An `iprev=pass` is a sign of a well-configured mail server. An `iprev=fail` suggests a misconfiguration or, more ominously, a server on a dynamic IP block or a compromised machine in a botnet. While many legitimate but poorly configured servers fail this check, it’s a strong negative signal when combined with other authentication failures.

BIMI and Brand Trust

You may also spot `bimi=pass` in the header. Brand Indicators for Message Identification (RFC 8461) allows domains to publish a logo via DNS, which clients like Gmail can display next to authenticated messages. For BIMI to pass, DMARC must be passing with a policy of quarantine or reject. It's not a security mechanism in itself, but a `bimi=pass` is a strong indicator of a mature, well-defended sending domain. It tells you the sender has invested enough in their email posture to deploy strict DMARC, which is a powerful signal of legitimacy.

ARC: The Fix for a Forwarded World

Remember how SPF breaks with forwarding? Authenticated Received Chain (ARC), defined in RFC 8617, was built to solve precisely that problem. It creates a chain of custody for authentication results, allowing a downstream mail server to validate the original sender's authentication, even after multiple hops.

Imagine a calendar invite from a vendor that gets forwarded through a customer's mail system before landing in your inbox. By the time it hits Google's MX servers, the connecting IP belongs to the customer, not the original vendor. SPF fails. If any MTA along the way added a footer, DKIM might fail, too. DMARC, therefore, fails.

ARC prevents this legitimate message from being junked. Each ARC-aware forwarder in the chain adds a set of headers: `ARC-Authentication-Results`, `ARC-Message-Signature`, and `ARC-Seal`. Each seal cryptographically signs the previous ARC headers. When the final server (Google) receives the message, it validates the entire chain. If the chain is intact, Google can trust the `ARC-Authentication-Results` from the very first hop (`i=1`) where SPF and DKIM originally passed.

In the main `Authentication-Results` header, you'll see a final verdict: `arc=pass (i=2 cv=pass)`. The `i` value indicates the number of ARC hops, and `cv=pass` means the chain validation passed. This tells you Google trusted the chain and used it to inform its delivery decision.

From Raw Text to Action: The Header Analyzer

Staring at a wall of raw header text is a classic SOC ritual, but it's not efficient. Google provides a powerful tool to short-circuit this process: the Message Header analyzer. You can find it in the Admin Console under `Security > Security center > Investigation tool`, or just by searching for it.

You paste the full raw header into the tool, and it renders a clean, digestible summary. It shows the sender and recipient, a timeline of the delivery path, and most importantly, a clear breakdown of the SPF, DKIM, and DMARC results. It's an excellent first-pass tool for quickly confirming if authentication passed or failed, saving you from manually parsing the `Authentication-Results` string.

But don't mistake visualization for analysis. The analyzer tells you *what* happened, but it doesn't tell you *why*. It will show you a `dmarc=fail` but it won't tell you if it's because of a benign forwarder or a malicious spoofing attempt. That's where your knowledge of these protocols becomes critical. The tool is your assistant, not your replacement.

Decoding False Positives and Legitimate Failures

Not every authentication failure is a red flag for a malicious attack. A huge portion of an analyst's time is spent separating the signal from the noise of misconfigured systems. These are the ghosts in the machine.

Third-Party Senders

The most common source of legitimate DMARC failures comes from third-party services sending email on your behalf—think marketing platforms, HR systems, or transactional email providers. If a new service is onboarded and their sending IPs aren't added to your domain's SPF record, or they fail to sign with DKIM for your domain, their messages will fail authentication. This often looks like someone is spoofing your own domain, but it's really a simple (and common) administrative oversight.

Mailing Lists and Forwarding Rules

Even with ARC, not all forwarding systems are created equal. Old, non-compliant mailing list software or personal forwarding rules set up by users can still strip or modify headers in a way that breaks all authentication. When you see a failure from a known mailing list source, you learn to treat it with less suspicion than a direct-to-inbox failure from an unknown IP.

Content Modification in Transit

A baffling `dkim=fail` on an otherwise legitimate-looking email can often be traced to a well-intentioned but disruptive security appliance. Many older on-premise email gateways or even cloud security services anachronistically add a footer to every message (e.g., "Scanned for threats by XYZ Security"). By modifying the message body, they invalidate the DKIM body hash. The signature was valid, but the content it signed has changed. It's a self-inflicted wound.

The takeaway

The `Authentication-Results` header is a log file, not a final verdict. It's a precise record of what Google's servers observed at the moment of delivery, but it lacks intent. It can't tell you if a `dmarc=fail` is from a forgotten marketing platform or a determined attacker attempting a CEO fraud.

Your job as an analyst is to be the interpreter. You combine the evidence in this header with other signals—the sender's reputation, the message content, the delivery path—to build a complete picture. For individual cases, Google's Header Analyzer is a great starting point, but for identifying systemic issues or hunting widespread campaigns, you need to analyze these signals at scale. Tools that can ingest and correlate thousands of headers, like MailSleuth.AI, are designed to bridge that gap between single data points and actionable intelligence.