What You're REALLY Authorizing With Google's SPF Record

You see the DMARC failure report. The sending IP belongs to Google, the `Authentication-Results` header shows an SPF `pass`, yet the message still fails DMARC alignment. The source isn't a user's mailbox—it's a notification from a Google Sheet. What happened?

For most IT admins, setting up SPF for Google Workspace is a one-and-done task. You add `v=spf1 include:_spf.google.com ~all` to your domain's DNS, test it, and move on. The common assumption is that this record simply greenlights Gmail's outbound mail servers. That assumption is dangerously incomplete.

That single `include` statement is a trust delegate. You are not just authorizing mail servers; you are authorizing a vast, dynamic, and partially opaque ecosystem of Google services to send mail on behalf of your domain. Understanding what's inside that `include` is critical to diagnosing bizarre delivery failures and securing your domain against abuse.

More Than Just Gmail's Outbound IPs

First, let's be precise about what `include:` does. As defined in RFC 7208, the `include` mechanism doesn't authorize anything directly. It's a directive for the receiving mail server to perform another DNS lookup, fetching the SPF record of the specified domain (`_spf.google.com`) and evaluating its contents as if they were part of your own record.

The First Layer of Abstraction

If you perform a TXT record lookup on `_spf.google.com`, you won't find a single IP address. Instead, you'll find more abstraction. The record typically looks like this:

v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

This is smart architecture on Google's part. By nesting `include` statements, their infrastructure teams can add, remove, or modify huge IP blocks by only updating one of the downstream `_netblocks` records. This prevents millions of Google Workspace customers from having to update their primary SPF record every time Google reconfigures a datacenter. It's abstraction for operational scale. But for a security analyst, it's a rabbit hole we have to go down.

Tracing the `_netblocks` Chain to Concrete IPs

The real meat is inside those `_netblocks` records. Resolving them recursively is the only way to see the actual IP ranges you’re authorizing. This process is exactly what a receiving mail server does when it validates an incoming email from your domain.

Heeding the 10-Lookup Limit

Before we go further, we have to acknowledge the hard limit imposed by RFC 7208: an SPF check cannot generate more than 10 DNS lookups involving `include`, `a`, `mx`, `ptr`, or `exists` mechanisms. Google’s multi-layered `include` structure is efficient; resolving `_spf.google.com` and its three subsequent `_netblocks` records consumes four lookups. This is good design, leaving you with six for your other sending services (Salesforce, Zendesk, etc.). But it underscores why you can't just keep adding `include` statements without a strategy.

When you finally resolve one of the `_netblocks` records, you hit paydirt: a long list of `ip4` and `ip6` CIDR ranges. These lists are extensive, frequently updated, and cover a massive surface area of Google's global infrastructure. And this is where the non-Gmail senders hide.

The Ghosts in the Machine: Groups, Apps Script, and Calendar

The IP ranges published in Google's SPF records do not just belong to the MTAs that handle user mail from the Gmail web client or a mobile app. They also cover the infrastructure powering a whole host of other Google services that can send email, often with surprising and problematic header configurations.

Google Groups and Forum Notifications

When a user posts a message to a Google Group (`support@yourdomain.com`), the resulting notification emails sent to group members originate from Google Groups servers, not the user's personal mailbox. The IP address of that server will be covered by the `_spf.google.com` record, so basic SPF authentication will pass. However, the `From` header of that email can be complex—it might be the group's address or the poster's address, while the envelope sender (`Return-Path`) is often a Google-specific address for bounce handling. This immediate mismatch is a common cause of DMARC SPF alignment failure.

Automated Emails from Apps Script & App Engine

Here's a perennial source of misery for security analysts. A developer or power user creates a simple Apps Script attached to a Google Sheet to send a daily report. The `MailApp.sendEmail()` function dispatches the mail from a generic Google Cloud server. That server's IP is, once again, authorized by your SPF record. The script might set the `From` address to `reports@yourdomain.com`. But the envelope sender used for the SPF check will almost certainly be a generic Google domain. Instant DMARC alignment failure, unless DKIM is also correctly configured and aligned.

Calendar Invites and Third-Party Integrations

Calendar invites are notoriously fragile. The `.ics` files inside them are frequently modified in transit by gateways and servers, which breaks DKIM signatures. For SPF, a calendar invite sent from Google Calendar will originate from a valid Google IP. But imagine a user syncs their Google Calendar with a third-party service. That service may issue updates or notifications on behalf of the user. If that service's IPs aren't in your SPF record, it's an instant `fail`. Even when everything originates from Google, forwarded invites can create complex authentication chains that rely on the Authenticated Received Chain (ARC) protocol (RFC 8617) for validation, which is not universally honored.

Scenario: How a Google Service Breaks DMARC Alignment

Let's make this concrete. Your finance team uses an add-on in Google Sheets to automatically email invoices. The add-on uses an underlying Apps Script to send mail. The recipient's mail server receives the message and begins the DMARC validation process.

The Misaligned `From` Header

The server inspects two key pieces of information: the `Header.From` address (`invoices@yourdomain.com`) and the envelope sender address, found in the `Return-Path` or used in the SMTP `MAIL FROM` command. Because this is an automated send from a Google service, the envelope sender is often set to a complex address for tracking bounces.

Authentication-Results: mx.example.org;
spf=pass (google.com: domain of 3flh-54b.bounces.google.com designates 209.85.220.69 as permitted sender) smtp.mailfrom=3flh-54b.bounces.google.com;
dmarc=fail (p=REJECT sp=REJECT) header.from=yourdomain.com

Look closely at that header. The SPF check itself gets a `pass` verdict. Why? Because the sending IP `209.85.220.69` is a valid sender for the domain `bounces.google.com`, which was used as the envelope sender. Your own SPF record was used to validate that IP against Google's domain.

However, DMARC (RFC 7489) doesn't just need an SPF pass. It requires *alignment*. The domain in the `Header.From` (`yourdomain.com`) must match the domain used for the SPF check (`bounces.google.com`). They don't match. Therefore, from DMARC's perspective, the SPF check fails. Unless a valid, aligned DKIM signature is present, the message will fail DMARC and be rejected. This is the crux of many Google-related delivery problems: SPF passes, but DMARC fails.

The takeaway

Treating `include:_spf.google.com` as a black box is a mistake. It is a sweeping authorization of Google's entire sending infrastructure, not just the MTAs for user-sent mail. This means a solid DMARC strategy for any organization using Google Workspace cannot depend on SPF alignment alone. You are virtually guaranteed to have legitimate mail flows from services like Groups, Calendar, and Apps Script that will fail SPF alignment. Your DMARC policy's resilience hinges on correctly configured DKIM.

This complexity is why recursive SPF validation is a non-negotiable diagnostic step for security teams. Don't just check if your record is syntactically valid; you must resolve the entire `include` chain to understand your true sending footprint. Using a tool that can perform this recursive lookup, like the SPF checker in MailSleuth.AI, shows you every CIDR range you are implicitly trusting. Understand your full authorization scope before an attacker finds a way to abuse it.