SPF DNS Lookup Budget Guide
SPF evaluation has a DNS-lookup limit, so repeatedly adding provider includes can make a seemingly valid policy fail.
Begin with senders
Authorise only services that genuinely send using the domain's envelope identity. Do not add an include merely because a vendor account exists.
Count lookup-causing mechanisms
Includes, redirects and mechanisms such as a, mx, ptr and exists can trigger DNS work during evaluation. Nested includes contribute to the total path.
Distinguish text length
A short SPF string can exceed the lookup limit through nested policies, while a longer record containing IP mechanisms may not. Character count is not a lookup-budget calculation.
Avoid multiple policies
Publish one SPF policy for a name. Splitting providers across several v=spf1 records does not increase capacity and produces an invalid evaluation condition.
Reduce deliberately
Retire unused senders, use the provider's supported design and consider separate subdomains for distinct mail streams. Do not flatten provider IPs unless the provider explicitly supports that operational model.
Verify after change
Inspect real received headers and the current public record. Keep the prior value and TTL so a harmful change can be reversed.
Authoritative references
Read the underlying standards and provider instructions before changing production DNS: RFC 7208 (SPF), RFC 9989 (DMARC), Google Workspace SPF guidance and your sending provider's current DKIM documentation.
Editorial responsibility
Published by Acerville Sparks Limited. Software assists research, drafting and automated record testing. Internet standards, provider documentation, reproducible checks and limitations are shown so readers can inspect the work. No independent deliverability consultant review is claimed. Reviewed 4 September 2026.
What this site does not do
No inbox guarantee. No live DNS checks. No storage of entered data. No passwords or private keys requested.