SPF Flattener

Why Flatten SPF Records?

RFC 7208 Section 4.6.4 imposes a hard limit of 10 DNS lookups during SPF evaluation. Mechanisms like include, a, mx, redirect, and exists each consume one lookup. When your SPF record includes third-party services (Google Workspace, Microsoft 365, SendGrid, etc.), it is common to exceed this limit, causing a permerror that many receivers treat as a complete SPF failure.

Flattening resolves all include chains down to their underlying ip4 and ip6 addresses, replacing many DNS lookups with zero-lookup IP mechanisms. This brings your total lookup count back under the limit.

The 10-Lookup DNS Limit

The limit counts every mechanism that triggers a DNS query during evaluation. Each include costs one lookup at the current level, and the included record's own lookups also count. Nested includes create a multiplicative effect: three includes that each have three includes already uses 12 lookups (3 + 9), exceeding the limit.

Risks of Flattening

Flattened records use static IP addresses. When a provider (like Google or Microsoft) adds, removes, or rotates IPs, your flattened record becomes stale and may block legitimate mail. You must re-flatten periodically to pick up changes. For dynamic environments, consider alternatives like SPF macros or splitting the record across subdomains.

Alternative Approaches

Instead of flattening, you can reduce lookups by: (1) removing unused include mechanisms, (2) using ip4/ip6 for services with stable IPs, (3) using SPF macros for per-sender evaluation, or (4) delegating subdomains (e.g., bounce.example.com) with their own SPF records to spread the lookup budget across multiple domains.

Our SPF Supply Chain 2026 study found that 148,655 domains risk PermError from exceeding the 10-lookup limit — see the full analysis for provider-level breakdowns.

Read the complete SPF guide to learn more.