Definition
SPF flattening is the process of resolving an SPF (Sender Policy Framework) record that contains includes, redirects, and mechanisms into a minimal record that lists only explicit IP ranges. The purpose is to avoid the SPF 10-DNS-lookup limit, which is the maximum number of DNS queries a receiving server will perform when evaluating an SPF record. If an SPF record requires more than 10 DNS lookups, receiving servers return a "permerror" (permanent error), which typically causes SPF to fail, potentially resulting in messages being rejected or marked as spam.
The 10-lookup limit is reached quickly when SPF records include third-party services. Each include: mechanism counts as one lookup. An organisation using an ESP (one include), a marketing platform (one include), a transactional email service (one include), and a CRM platform (one include) has already used 4 lookups. Adding a, mx, and ptr mechanisms each consume additional lookups. Including redirect mechanisms or nested includes further consumes the limit. A typical mid-sized organisation with 4-6 email service providers can easily exceed the 10-lookup limit.
Flattening resolves the limit by converting each include into its explicit IP address ranges. For example, include:_spf.google.com expands to all of Google's published sending IP ranges. These ranges are combined into a single SPF record that uses only ip4: and ip6: mechanisms, which do not count against the lookup limit. The result is a longer SPF record (in terms of string length) but one that uses only 1-2 lookups (the initial query and any remaining includes). The trade-off is that the flattened record must be updated when the included services change their IP ranges, which happens periodically.
Best Practices
Monitor SPF record lookup count and flatten when approaching 8 or more lookups. A record using 8-9 lookups is dangerously close to the 10-limit. DNS changes or new service additions could push it over. Run an SPF lookup count check monthly or whenever you add or change an email service provider. Many SPF validation tools report the current lookup count.
Automate SPF flattening with tools or scripts that monitor for changes. Manual SPF flattening is tedious and error-prone. Use automated tools that: pull the current includes from your SPF record, resolve each include to its current IP ranges, generate a flattened record with only ip4 and ip6 mechanisms, and compare the flattened version against your current record. Some DNS hosting providers offer built-in SPF flattening. Re-run the flattening monthly to capture IP range changes from included services.
Use the exists: mechanism sparingly as it counts as a lookup. The exists: mechanism performs a DNS lookup to check if a specific domain exists, which counts toward the 10-lookup limit. It does not avoid lookup limits and should typically be avoided in favour of explicit IP ranges or flattened records.
Prioritise the most important services to include if flattening cannot accommodate all senders. In rare cases where the combined IP ranges from all services exceed DNS record size limits (255 characters per string, multi-string records up to a practical limit of 2048 bytes), you may need to prioritise which services are included. Always include transactional email services at minimum. Marketing services can be deprioritised if there is insufficient record space.
Document your SPF flattening process and regeneration schedule. Your SPF record is a critical piece of email authentication infrastructure. Document: how the flattened record is generated, which services are included, the regeneration schedule (monthly recommended), the review and approval process for changes, and the fallback procedure if the flattened record causes delivery issues.
Related Glossary Terms
DMARC Alignment
DMARC identifier alignment determines whether the domain in the From header matches the domains used in SPF and DKIM authentication. Strict or relaxed.
DMARC Policy Tags
DMARC DNS record tags including v, p, sp, rua, ruf, pct, adkim, aspf, fo, rf, and ri control authentication policy, reporting, and alignment enforcement.
Email Bandwidth
Email sending bandwidth and throughput refer to the rate at which emails can be delivered, typically 100-500 emails/second per IP. Bandwidth planning ensures campaigns complete within desired delivery windows.
Email BIMI VMC
BIMI Verified Mark Certificate (VMC) certifies brand logo ownership for display in supporting email clients. VMCs cost £1,500-2,000+ per year per logo and require DMARC reject or quarantine policy plus SVG logo format.
Email Blacklist
An email blacklist (DNSBL) is a real-time database of IP addresses or domains known for sending spam or unwanted email.
Email Bulk
Bulk email classification distinguishes mass commercial messages from transactional emails, with specific authentication requirements for senders over 5,000 daily.
Frequently Asked Questions
The SPF specification (RFC 7208) limits the number of DNS lookups that a receiving server will perform while evaluating an SPF record to 10. Each `include:`, `a`, `mx`, `ptr`, `exists:`, and `redirect=` mechanism counts as one lookup. If the limit is exceeded, the receiving server returns a permerror and SPF validation fails, which can result in mail rejection or spam placement.
Without flattening, complex SPF records that include multiple third-party services quickly exceed the 10-lookup limit. Flattening converts includes to explicit IP ranges, which do not count toward the lookup limit. This ensures SPF validation succeeds for all messages while still authorising all legitimate senders.
SPF records should be reviewed and flattened if necessary at least monthly. Third-party services change their sending IP ranges periodically. An SPF record flattened 6 months ago may be missing IP ranges for services that have since updated their infrastructure, resulting in SPF failures for legitimate messages.
The main downsides are: the SPF record becomes longer and harder to read manually, it must be updated when any included service changes its IP ranges (whereas an include would automatically reflect the change), and very large flattened records may approach DNS packet size limits. Automated flattening tools mitigate these downsides.
When the lookup limit is exceeded, the receiving server returns a permerror. Combined with DMARC policy, this typically results in the message failing authentication. With a DMARC policy of `p=reject`, the message will be rejected. With `p=quarantine`, it will be sent to spam. With `p=none`, it will be delivered but reported in DMARC aggregate reports.