I just found something very interesting, when poking around in DNS: Google seems to have recently updated what goes into their "_spf.google.com" SPF record. Keep in mind that this change doesn't affect many; folks already doing things right are fine. But some people with a customized SPF configuration should consider making a change; read on to understand why and what needs to happen.
Google Workspace Users
If you use Google Workspace to host your domain's email inboxes, you're probably already long aware of Google's guidance that instructs that you add "include:_spf.google.com" to your SPF email authentication DNS record. If the domain only sends mail via Google Workspace, then your whole SPF record for that email domain would be "v=spf1 include:_spf.google.com ~all", nice and easy.
That doesn't change -- that guidance remains the same.
On the inside? Things have changed
When we peek inside of _spf.google.com to see what's in there, we see the following: "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com ~all"
It also used to contain "include:_netblocks3.google.com" linking to even more IP ranges. It no longer does. Meaning that the "_netblocks3.google.com" include is no longer necessary or active. If you look it up today, you'll see that it's empty.
If you're only using "_spf.google.com" in your SPF DNS record, you'll all set. the "netblocks3" reference is long gone.
However, there seem to be quite a few folks out there who have customized the SPF record for their email domains, meaning that they've manually picked apart the "_spf.google.com" SPF record and included a now-outdated snapshot of its contents in their own SPF records.
When I check the top ten million domains, meaning the most popularly used domains, nearly a thousand of them manually reference the various "netblocks" records: listing include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com. (Even more annoying, more than a couple hundred of them contain both the "netblocks" entries AND _spf.google.com.)
What should you do?
Check your email domain's SPF record and look for these things to fix:
If the only reference to Google in your SPF record is "include:_spf.google.com", do nothing -- you're good.
If you're explicitly referencing any of the "_netblocks" Google SPF subdomains, remove them and replace them with a single include pointing to _spf.google.com instead.
If you really, really are absolutely sure that you need to specifically and explicitly reference the netblocks subdomains, remove _netblocks3, as it is no longer used. (But really, it is better to yank them all and use _spf.google.com, instead.)
And if your SPF record contains includes for the netblocks subdomains as well as one for "_spf.google.com," note that you're duplicating effort. Remove the netblocks entries; they're covered in the _spf.google.com SPF record already.
The net here is that it's better to trust Google to manage their overall SPF record, and not to try to hard code things at a lower level to avoid some perceived potential for issues. If you do hard code things, you're making SPF brittle, in that it can get out of date.
And while Google is undoubtably careful enough to not leave dangling subdomains or expired domain references behind, we can't say for sure that everyone will be as careful and fastidious. Dangling SPF references can lead to bad things happening, like subdomain hijacking. Best to avoid going down the path toward this potential future risk.
I just found something very interesting, when poking around in DNS: Google seems to have recently updated what goes into their "_spf.google.com" SPF record. Keep in mind that this change doesn't affect many; folks already doing things right are fine. But some people with a customized SPF configuration should consider making a change; read on to understand why and what needs to happen.
Google Workspace Users
If you use Google Workspace to host your domain's email inboxes, you're probably already long aware of Google's guidance that instructs that you add "include:_spf.google.com" to your SPF email authentication DNS record. If the domain only sends mail via Google Workspace, then your whole SPF record for that email domain would be "v=spf1 include:_spf.google.com ~all", nice and easy.
That doesn't change -- that guidance remains the same.
On the inside? Things have changed
When we peek inside of _spf.google.com to see what's in there, we see the following: "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com ~all"
It also used to contain "include:_netblocks3.google.com" linking to even more IP ranges. It no longer does. Meaning that the "_netblocks3.google.com" include is no longer necessary or active. If you look it up today, you'll see that it's empty.
If you're only using "_spf.google.com" in your SPF DNS record, you'll all set. the "netblocks3" reference is long gone.
However, there seem to be quite a few folks out there who have customized the SPF record for their email domains, meaning that they've manually picked apart the "_spf.google.com" SPF record and included a now-outdated snapshot of its contents in their own SPF records.
When I check the top ten million domains, meaning the most popularly used domains, nearly a thousand of them manually reference the various "netblocks" records: listing include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com. (Even more annoying, more than a couple hundred of them contain both the "netblocks" entries AND _spf.google.com.)
What should you do?
Check your email domain's SPF record and look for these things to fix:
The net here is that it's better to trust Google to manage their overall SPF record, and not to try to hard code things at a lower level to avoid some perceived potential for issues. If you do hard code things, you're making SPF brittle, in that it can get out of date.
And while Google is undoubtably careful enough to not leave dangling subdomains or expired domain references behind, we can't say for sure that everyone will be as careful and fastidious. Dangling SPF references can lead to bad things happening, like subdomain hijacking. Best to avoid going down the path toward this potential future risk.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.