Google Silently Cuts SPF Reference, Audit Required
Google removed _netblocks3.google.com from its SPF chain. Most Google Workspace users unaffected, but domain owners using custom SPF configs need to audit records now.
Sarah Mitchell
April 9, 2026
Google quietly removed _netblocks3.google.com from its SPF record chain in early 2026, with no official announcement. For most Google Workspace users, nothing changes. But for domain owners or IT teams who manually hard-coded Google's internal SPF structure, this update is a signal to audit their records now, before a messy configuration causes a deliverability problem.
What Google Actually Changed
When you look inside Google's _spf.google.com reference, it points to internal sub-records that contain Google's IP ranges for sending email. Previously, the chain included three of these sub-records. Google has now silently removed _netblocks3.google.com from that chain, which simply means the sub-record no longer holds active sending addresses. In plain terms, Google cleaned up its SPF structure.
Google made no loud announcements about this because, for most domains, nothing breaks. The problem only surfaces if you manually copied Google's internal structure, which could leave your SPF record invalid or pointing to an unnecessary reference. It may not break email delivery immediately, but it makes your SPF setup harder to maintain.
Who Is Actually at Risk
Most Google Workspace users do not need to worry about this change. They rely on the standard include:_spf.google.com entry, and Google manages everything behind the scenes. Records in this format continue to work exactly as expected.
Those using Google's recommended include will face no issues. However, domain owners who manually copied Google's internal structure may encounter problems. This typically happens when a technical team hit the 10 DNS lookup limit and tried to resolve it by hard-coding individual netblock references instead of using an SPF flattening tool.
That lookup limit is not a minor concern. Per RFC 7208, SPF evaluation is capped at 10 DNS mechanism lookups and 2 void lookups per check. Exceeding either limit produces a PermError that fails authentication for every message from the domain. And that failure is silent: your emails do not bounce, they simply land in spam or get rejected without any clear error the sender can see.
The DNS Lookup Budget Problem
This update also highlights a wider issue for businesses using multiple sending tools. Google's include:_spf.google.com alone uses 4 of your 10 available lookups, leaving only 6 for all other senders. If you also use SendGrid, which consumes 5 lookups, the combined total reaches 9, and adding just one more sender hits the wall.
A domain that includes Google, Microsoft, SendGrid, and Mailchimp together reaches 12 lookups. RFC 7208 caps evaluation at 10. The receiving mail server returns a PermError and every message from the domain fails SPF authentication, regardless of which sender it actually came from.
