What?

SPF records can chain to each other using include: directives. No matter how long they grow (including chaining) only 10 DNS lookups are permitted as an SPF record is processed. This is to prevent someone from using DNS to do a DDOS attack on other sites. For example, you could set up an SPF record that requires millions of DNS lookups that land on the same DNS server, send email to companies around the world, and soon those companies will all be (unknowingly) participating in an attack on the target DNS server. That's the theory, at least.

If you include: some other SPF record, that's one DNS lookup. If it performs 3 DNS lookups, that's 4 DNS lookups total. That leaves you with 6 lookups remaining. The Google SPF record consumes 4 lookups.

If it unclear what happens if you exceed 10 DNS lookups. In theory if an SPF record contains any errors it is supposed to be ignored, however the spec is unclear if exceeding the 10 lookup budget counts as that kind of error. Do sites ignore the SPF record? Do more than 10 lookups? Ignore the 11th and remaining lookups? Who knows! You can read the source code to various open source packages but it is a mystery what Google and other major email services do. I know. I've asked them.

What Google Changed

Here's an example:

The Google SPF record looks like this:

$ dig +short _spf.google.com. txt
"v=spf1 include:_netblocks.google.com
          include:_netblocks2.google.com
          include:_netblocks3.google.com ~all"

(Newlines added to enhance readability)

See the change?

No, you won't because the change is in include:_netblocks3.google.com. That record is now:

$ dig +short _netblocks3.google.com. txt
"v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19
          ip4:172.217.160.0/20 ip4:172.217.192.0/19
          ip4:108.177.96.0/19
          ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

The change? Google recently added these two CIDR blocks: ip4:35.191.0.0/16 ip4:130.211.0.0/22

To be 100% clear: GSuite users don't have to make any changes. GSuite administrators simply use "include:_spf.google.com" and any changes that Google makes happen automatically. What I'm talking about is a very special case required by sites that are up against the 10 lookup limit.

Tip for SPF unrollers

If you have manually unrolled Google's SPF record, you'll want to add those two CIDR blocks. Then you should go back and make sure your TXT records aren't longer than the limit (which... umm... I think is 254 bytes... I mean octets..... but there's multiple TXT records and... oh bother.)

The simple thing is to use any of the various SPF checking websites out there. There are many.

Part of the DNSControl project includes an SPF flattener that you can use manually at this website:

https://stackexchange.github.io/dnscontrol/flattener/index.html

Checkbox the parts of your SPF record that you want to unroll. I recommend unrolling just enough to get below the 10-lookup limit.

However, you're still stuck doing it manually.

Automate it!

DNSControl lets you specify your DNS records like this:

D("example.tld", REG, DSP, ...
  A("@", "10.2.2.2"),
  MX("@", "example.tld."),
  SPF_BUILDER({
    label: "@",
    overflow: "_spf%d",
    raw: "_rawspf",
    parts: [
      "v=spf1",
      "ip4:198.252.206.0/24", // ny-mail*
      "ip4:192.111.0.0/24", // co-mail*
      "include:_spf.google.com", // GSuite
      "include:mailgun.org", // Greenhouse.io
      "include:spf-basic.fogcreek.com", // Fogbugz
      "include:mail.zendesk.com", // Zenddesk
      "include:servers.mcsv.net", // MailChimp
      "include:sendgrid.net", // SendGrid
      // Hubspot (Ticket# SREREQ-107)
      "include:450622.spf05.hubspotemail.net",
      "~all"
    ],
    flatten: [
      // Rational: Being deprecated. Low risk if it breaks.
      "spf-basic.fogcreek.com",
      // Rational: Unlikely to change without warning.
      "450622.spf05.hubspotemail.net"
    ]
  }),
);

Notice the "flatten:" section. That indicates which items should be unrolled.

If you use DNSControl in a CI/CD pipeline, any changes to a downstream SPF record will be handled automatically.

While I'm at it... my other favorite feature of SPF_BUILDER is that each segment of the SPF record is listed separately. You can include comments and stuff. For example look at the last one (include:450622.spf05.hubspotemail.net). Notice that there is a ticket #. If you can't remember why that item was added, you can refer to the ticket. That's really cool.

DNSControl is one way to adopt Infrastructure as Code. It is also the only IaC system I've seen so far that has an optimization step.

For more info about DNSControl's SPF_BUILDER feature, visit:

https://github.com/StackExchange/dnscontrol/blob/master/docs/spf-optimizer.md