Google Workspace SPF: Audit Includes Before Adding Senders

The Google include is rarely what breaks a Google Workspace SPF record. The damage usually comes from the fourth vendor somebody added without counting what the first three already cost. SPF gives you a budget of ten DNS lookups, that budget is spent recursively by every include you add, and exceeding it invalidates the whole record rather than just the last entry. Treat the record as a capacity-managed asset with a named owner and a change log.

The budget is ten, and it is spent recursively

RFC 7208 is direct about the cap: "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS."

The terms that count are include, a, mx, ptr, exists, and the redirect modifier. The terms that cost nothing are all, ip4, ip6, and the exp modifier. That asymmetry gives you a lever on a crowded record: listing a vendor by published IP address costs nothing against the budget, while listing the same vendor by include costs at least one lookup and often more. Where a vendor publishes a stable address range, converting an include to ip4 entries buys back capacity without dropping the sender.

What people miss is the recursion. The spec describes include as something that "triggers a recursive evaluation of check_host()" using the referenced domain. Your record shows one include. The vendor's record behind it may contain three more. All of those count against your ten.

Google's Workspace SPF documentation gives the standard record for Workspace-only mail as v=spf1 include:_spf.google.com ~all, and notes that a record can hold "up to 10 include: tags". It also instructs administrators that the record "should include the domains (or IP addresses) of all servers that send email for your organization", covering web servers, on-premise systems, outbound gateways and third-party services.

Those two instructions are in tension for any organisation with a real vendor stack. Follow the second one without measuring against the first and you produce a record that lists every sender and authorises none of them.

What exceeding the budget actually does

The failure mode is worse than most people expect. RFC 7208 states that when the limit is exceeded, "the implementation MUST return permerror", which the spec defines as a state where "the domain's published records could not be correctly interpreted. This signals an error condition that definitely requires DNS operator intervention to be resolved."

Permerror does not behave as a partial pass, so the record does not evaluate up to the tenth lookup and authorise everything it found along the way. Your Workspace mail, which was authorised by the first include, now sits behind a record that cannot be interpreted at all.

This is why the symptom usually appears somewhere other than the change. A marketing team adds a new email vendor on Tuesday. On Thursday the finance team reports invoices failing. Nobody connects the two, because the system that broke is not the system that changed.

One record, and only one

RFC 7208 is unambiguous: "A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record."

Two SPF TXT records on the same name is a common state in organisations where two teams both had DNS access. It is not additive. It is a defect, and the result is not predictable from reading either record.

The version prefix matters for the same reason. Implementations "discard records that do not begin with a version section of exactly v=spf1". A record starting with a space, a quote mark in the wrong place, or a stray prefix is not a weak SPF record. It is not an SPF record.

Before any other work, confirm your domain publishes exactly one TXT record beginning v=spf1, and that your dedicated cold-sending subdomains publish their own rather than relying on the parent. SPF is evaluated against the envelope sender domain, so a sending subdomain needs its own record.

Build the sender inventory first

The record is the output. The inventory is the artifact worth maintaining. Every row should name a system, the business owner, the authorisation method, and the lookup cost.

Measure the cost rather than assuming it. Resolve each vendor include and count the querying terms inside it, then count anything nested below that. Vendors change their own records without telling you, so a count taken last year is not a count.

LeadHaste practice: we keep cold outbound on dedicated sending subdomains with their own SPF records, which keeps campaign infrastructure entirely out of the corporate domain's lookup budget. That is our operating preference for blast-radius reasons, not a requirement written into the spec.

The change-control worksheet

Adding a sender is a change to a shared, capacity-limited resource. Treat it like one.

Before the change, record the current record text verbatim and the current lookup count. Resolve the proposed vendor's own SPF record and add its querying terms to your total. If the new total reaches ten, the change does not proceed as an include. Either move that sender to its own subdomain, replace an include with published IP addresses where the vendor supplies a stable range, or remove a retired source to make room.

Retired sources are worth auditing before you conclude the budget is full, because an include for a marketing platform cancelled eighteen months ago costs exactly as much as an active one. Removing a dead include is the only way to add capacity without restructuring.

After the change, verify from outside your network that exactly one record resolves, that the total querying terms are at or under ten, and that a real message from the new sender passes SPF with the envelope domain you expect. Checking the record syntax is not the same as checking that a message passes.

Keep the previous record text. A rollback that requires reconstructing the old record from memory during a delivery incident is not a rollback.

Passing SPF is an eligibility check

One boundary worth stating plainly, because it changes how much effort this deserves. A passing SPF result authorises a sending host for an envelope domain. It does not assert that your mail is wanted, and it does not guarantee inbox placement.

It also does not, by itself, satisfy DMARC. DMARC requires that the authenticated identifier align with the visible From domain, so a vendor sending with its own envelope domain can pass SPF cleanly and still fail your DMARC policy. Our DMARC policy audit guide covers that alignment question, and how to fix SPF failure covers repair once a specific message is failing.

The reason to hold the lookup budget is narrower than deliverability in general. It is that a permerror silently unauthorises every legitimate sender you have, including the ones that were working before anyone touched the record.

Ready to audit your sending sources before the next campaign?

We can walk your sender inventory, lookup budget and subdomain structure as part of an ICP and campaign-fit discovery call. Book your free discovery call →