SPF flattening guide.
The 10-lookup limit, safe flattening approaches, and the pitfalls that break email delivery when you flatten incorrectly.
The problem: too many DNS lookups
Every include:, a:, mx:, ptr:, exists:, and
redirect=
in your SPF record costs a DNS lookup. RFC 7208 limits SPF evaluation to 10 lookups total — including nested lookups inside included records.
Modern organizations often use 5-10 sending services (Google Workspace, SendGrid, Mailchimp, HubSpot, Salesforce, etc.), each requiring their own include:. It's easy to exceed the limit.
What is SPF flattening?
SPF flattening replaces include:
mechanisms with the underlying ip4:
and ip6:
addresses. Since IP mechanisms don't require DNS lookups, this reduces your lookup count without changing which servers are authorized.
v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all
v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:167.89.0.0/17 ip4:159.135.0.0/17 ip4:69.72.0.0/16 ~all
The risks of flattening
include:, it's clear which provider is authorized. Flattened IP blocks are opaque — you can't tell who owns
ip4:167.89.0.0/17
at a glance. This makes debugging harder.
Safer alternatives
mail.example.com
instead of example.com. Each subdomain gets its own 10-lookup budget.