SPF DNS Lookup Budget

SPF (RFC 7208 section 4.6.4) caps the total DNS lookups required to evaluate a record at 10. Each include:, redirect=, a, mx, ptr, and exists: counts as one lookup. include: chains nest, so one include can pull in many more. Once the count exceeds 10, receivers return permerror, and DMARC treats permerror as a hard fail. RedScore counts your SPF tree recursively (up to a 5-deep depth and a 20-second wall-clock budget) and verdicts based on the result.

This check only runs when your domain has a non-null MX. If you have only a null MX or no MX, it shows as not applicable rather than failing.

How the verdict maps to evidence

• Pass: under 8 lookups. Comfortable margin to add a new sender without breaking SPF.
• Warn: 8 to 10 lookups, or the recursion guard tripped (depth > 5, or 20-second budget exceeded). At-or-near the limit; one new include could push you over.
• Fail: more than 10 lookups. SPF returns permerror at every receiver. DMARC treats this as a hard fail.

Fail or warn: bring the count back under 8

Three approaches. Combine them as needed.

1. Audit and prune unused senders

The fastest win. After every mailing platform migration there are stale include: entries nobody removed. Each one consumes a lookup needlessly.

• Pull your current SPF: dig +short TXT yourdomain @1.1.1.1.
• List every include: alongside the service it represents (Google Workspace, Microsoft 365, SendGrid, Mailchimp, etc.).
• Cross-reference against your actual mail-sending services. Prune anything you no longer use.
• Cross-reference against DMARC aggregate reports if you have them. Reports show every IP that sent mail "from" you; anything that does not match a known sender is either an unauthorized service to remove from SPF, or a forgotten authorized one that needs to stay.

2. Replace include: with ip4: / ip6: where stable

ip4: and ip6: are the only mechanisms that cost zero DNS lookups. If a sender publishes a stable IP range that does not change, hard-coding it eliminates the lookup. Risky for providers that rotate IPs (Google, Microsoft); reasonable for self-hosted MTAs and small transactional senders with documented static ranges.

# Before
"v=spf1 include:_spf.google.com include:mail.example-mta.com -all"

# After (only if mail.example-mta.com publishes a stable ip4 198.51.100.0/24)
"v=spf1 include:_spf.google.com ip4:198.51.100.0/24 -all"

Never hard-code IPs for providers that rotate them; you will silently break sending when they renumber. Verify with the provider's own documentation before flattening.

3. Use a managed SPF flattening service

Services like PowerDMARC, EasyDMARC, Valimail, and Red Sift OnDMARC offer macro-based or subdomain-redirect SPF flatteners. They monitor upstream provider IPs and rewrite a single hosted SPF record on your behalf so the apex stays under 10. Pick a service that watches your providers' IP changes and updates the flattened record automatically; otherwise you will have outages every time a provider renumbers.

4. Move transactional senders off the apex

If a transactional sender lets you configure a custom envelope domain (most do), point it at a subdomain like mailer.yourdomain.tld with its own SPF record. The apex SPF no longer needs to include: that sender, freeing up lookups. Your DMARC alignment still works because subdomain-aligned authentication satisfies relaxed alignment by default.

Verify the fix

• Run a third-party SPF lookup counter (mxtoolbox.com SPF Record Lookup, dmarcian SPF Surveyor, or kitterman.com's SPF tools) to confirm the count.
• Send a test message from each sender and check the receiving server's headers (Gmail "Show original" shows spf=pass with the matching mechanism).
• If you flattened to ip4:, set a recurring reminder to verify the upstream provider has not changed their range.
• Re-run the RedScore lookup.

Common pitfalls

• Hard-coding Google or Microsoft IPs. They rotate frequently and silently. Never flatten _spf.google.com or spf.protection.outlook.com manually.
• Forgetting nested includes. include:_spf.google.com pulls in include:_netblocks.google.com, _netblocks2.google.com, and _netblocks3.google.com. That is four lookups from one include.
• Counting ptr but assuming it is free. ptr is deprecated and many receivers ignore the result, but it still consumes a lookup against the 10 limit. Remove ptr entirely.
• Adding void lookups. Each include: that returns no SPF record (because the target stopped publishing one) counts as a void lookup. RFC 7208 caps these at 2 before SPF returns permerror; a single missing include can break your record.
• Trusting flattening services that go stale. If your provider changes IPs and the flattening service does not update, your record claims to authorize old IPs and rejects mail from new ones. Pick services that monitor upstream changes and verify periodically.
• Truncated counts in the scan. If RedScore's count is marked truncated (the recursion guard tripped), the real count may be higher than reported. Treat any truncated result as the warn case at minimum, and audit the chain manually.