SPF records have a hard limit: an evaluation permits at most ten DNS-query-causing mechanisms and modifiers, including terms reached recursively through include or redirect. This counts lookup-causing terms, not the raw DNS transactions they produce. Exceed that limit and the SPF result is treated as a permanent error - the receiving mailbox provider may reject or quarantine the message.
Most teams hit this limit through nested include statements. Each include:spf.provider.com triggers a DNS lookup. Four top-level provider includes with three nested includes each consume sixteen lookup-causing terms before your own mechanisms even resolve.
Start by auditing which services still send for the domain and remove includes for services that no longer do. If you replace an include with ip4: or ip6: mechanisms, you also accept responsibility for tracking that provider's address changes, so do not copy a one-time flattening result and forget it.
When flattening is not possible, consider a sub-domain strategy: split sending across mail.example.com and transactional.example.com so each subdomain has its own SPF record under the 10-lookup ceiling. The receiving mailbox provider evaluates the SPF record of the envelope-from domain, not the organizational domain.
Collect the envelope-from domain from a test message, then query that domain's TXT record. Trace each include target and redirect recursively on the evaluation path. A top-level record alone cannot establish the lookup count. RFC 7208, section 4.6.4 defines the processing limit; separate MX/address and void-lookup limits can also apply.
Use the DNS checker for a first pass, and read its limitations alongside the result. The checker counts top-level lookup-causing terms; it does not expand nested includes, so a low displayed count does not prove that a receiver's SPF evaluation will stay within the limit.
Before/after example: in a fictional policy with four includes and three nested lookup-causing terms under each, the illustrated non-matching evaluation path reaches sixteen terms. Removing two genuinely retired senders would reduce that path to eight. This is arithmetic for the example, not a measured result or a record to publish. An earlier matching mechanism may stop evaluation before the later terms.
After publishing a reviewed change, query the authoritative server and a recursive resolver, then send from every remaining legitimate service and inspect Authentication-Results. Keep exactly one SPF TXT policy at each owner name. A TXT lookup proves publication, not a successful SPF check for every source.
To compare the published record with the identities in a real received message, follow the authentication and alignment checklist.
PulsePigeon's delegated model gives customers one include target, include:spf.auth.pulsepigeon.com. PulsePigeon owns the shared record behind that target, so transport changes can be made in the delegated zone without asking every customer to republish SPF. Follow the domain API reference for your assigned records and verify the result before changing production mail. For the application request format, see the developer API reference.