SPF Flattening Explained — How to Solve the 10 DNS Lookup Limit
· DMARC Analyzer Pro
Hitting the SPF 10 DNS lookup limit? Learn what SPF flattening is, why the limit exists, and how to fix it without breaking your email authentication.
If you manage email for a mid-size or large organisation, you've almost certainly run into the SPF 10 DNS lookup limit. Your SPF record grows with every third-party service you authorise to send email — your CRM, marketing platform, helpdesk, HR system — and before you know it, authentication starts failing silently. SPF flattening is the solution, but it needs to be done carefully.
Why the 10 lookup limit exists
The SPF specification (RFC 7208) imposes a hard limit of 10 DNS lookups per SPF evaluation. This was a deliberate design decision to prevent SPF checks from becoming a denial-of-service vector. Every `include:`, `a:`, `mx:`, and `redirect=` mechanism in your SPF record triggers a DNS lookup. Nested includes count too — if your marketing platform's SPF record includes three other domains, those three lookups come out of your budget.
Once you exceed 10, the SPF check returns a `permerror` result, which most receiving servers treat as a fail. The worst part? This failure is silent. You won't get a bounce message, and your emails will quietly land in spam or get rejected.
What SPF flattening does
SPF flattening replaces DNS-lookup-heavy mechanisms (like `include:`) with the resolved IP addresses or CIDR ranges they point to. Instead of `include:spf.protection.outlook.com`, your flattened record might contain `ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14` — and similar for each service.
Since `ip4:` and `ip6:` mechanisms don't require DNS lookups, your flattened record can authorise dozens of services while staying well under the 10-lookup cap.
The catch: IP addresses change
Here's where many organisations get into trouble. Cloud providers and SaaS platforms rotate their sending IP addresses regularly. Microsoft, Google, and others update their SPF ranges without notice. If you flatten your record once and forget about it, you'll eventually be missing IP ranges that your services are actively using — leading to SPF failures for legitimate mail.
This is why SPF flattening must be automated. A proper flattening solution continuously monitors the source SPF records, detects changes, and updates your flattened record accordingly. Manual flattening is a ticking time bomb.
Best practices for SPF flattening
First, audit your current SPF record. Identify every `include:` and determine whether each service is still in use. It's common to find includes for platforms you stopped using years ago. Remove those first — you might not even need flattening.
Second, use an automated flattening tool that monitors upstream changes and alerts you when updates are needed. Ideally, it should update your DNS records automatically or provide you with ready-to-publish records.
Third, always keep a `~all` or `-all` at the end of your flattened record. The softfail (`~all`) is a safer choice during transition, but once you're confident in your configuration, move to a hardfail (`-all`) for stronger protection.
Finally, monitor your DMARC reports closely after making changes. Your DMARC aggregate reports will show you exactly which messages are passing or failing SPF — giving you a safety net that catches problems before they impact your users.