What is SPF?

The record is a TXT entry starting v=spf1, followed by mechanisms naming who may send: include:_spf.google.com hands the decision to Google, ip4: names an address directly, and a or mx point at your existing records.

It ends with an all mechanism that decides the default. -all tells receivers to reject anything not listed; ~all asks them to accept it with suspicion. Start at ~all while you are still finding forgotten senders.

The check happens at the envelope level, against the MAIL FROM address, not the From header your recipient reads. That gap is exactly why DMARC was invented.

Ten DNS lookups is the hard ceiling for evaluating a record, and each include: can pull in more. Marketing platforms and helpdesks stack up quickly, and the eleventh lookup breaks the whole thing.

Suppose your record reads: v=spf1 include:_spf.google.com include:helpdesk.example include:newsletter.example include:billing.example ip4:198.51.100.7 ~all. It looks like four services and one address. Only the lookups count toward the limit, and they add up faster than the record suggests.

Google's include costs four, because that record itself includes three more. Say the helpdesk include nests two others, which makes three, the newsletter platform costs two and the billing tool costs two. That's eleven. The ip4 entry and the all at the end cost nothing, since neither needs a DNS query.

At eleven, a receiver following the standard stops and returns a permanent error, and your DMARC evaluation treats SPF as failed for every message, including the ones from Google that were listed first. Removing the billing include, and having that tool sign with DKIM instead, brings you back to nine.

Run dig +short TXT yourdomain.com and look for the line starting v=spf1. You should find exactly one. Then run the same command against each include you see, and keep going until no new includes appear, tallying one for every include, a, mx, exists and redirect along the way.

There's a second, less known limit. The standard also caps lookups that return nothing at two, so an include pointing at a service you cancelled years ago, whose record has since been deleted, can break evaluation all by itself.

Be wary of flattening, which replaces includes with the raw IP ranges they resolve to. It fixes the count today. When the provider adds a range next month, your flattened record won't know, and some of your legitimate mail starts failing with nobody having touched DNS. If you flatten, you need something re-checking those ranges on a schedule.