SPF Flattening on Cloudflare: Macros, Limits & Safer Patterns

Every SPF evaluation is capped at ten DNS lookups. The cap is invisible until you add one more include and the whole record starts returning permerror — which receivers treat as no SPF at all. Domains using several SaaS senders hit it constantly.

Many articles imply Cloudflare can fix this with a toggle. It cannot. This guide explains the limit, what Cloudflare does and does not do, and the patterns that work.

What the limit actually is

RFC 7208 section 4.6.4 allows ten DNS lookups of these mechanisms: include, a, mx, ptr, exists and redirect. The details that bite:

• Nested includes count every step — include:_spf.google.com alone costs about four lookups because it pulls in three more includes.
• ip4 and ip6 cost zero lookups; they are literals.
• Exceeding the limit does not skip the extra include — the entire record fails with permerror.
• Void lookups count double, so stale includes punish you faster than live ones.

Check your count with the SPF Checker — it walks the include chain exactly as a receiver does.

What Cloudflare does not do

Cloudflare is a standards-compliant authoritative DNS. It stores your TXT record and serves it verbatim. There is no setting anywhere in the dashboard that rewrites includes into IP addresses. Tutorials claiming otherwise describe a different product.

Two related myths:

• SPF macros are not flattening. RFC 7208 macros (such as %{i} inside exists:) are expanded by the receiving server during evaluation. They are a wildcard lookup mechanism, not a way to reduce lookup counts, and using them to dodge the limit is fragile and receiver-dependent.
• PowerDNS-style tricks do not transfer. Self-hosted authoritative servers can use custom logic to serve expanded records per query. That is a capability of software you run yourself; Cloudflare DNS has no equivalent, so guides built around it do not apply.

Option 1: Manual flattening, with eyes open

Flattening replaces include: mechanisms with the literal addresses they currently resolve to:

v=spf1 ip4:203.0.113.10 ip4:198.51.100.0/24 ip6:2001:db8::/32 ~all

Zero lookups, immune to the limit. The trade-off is why flattening is dangerous: when a provider adds or changes sending IPs, your record silently goes stale, legitimate mail starts failing SPF, and nothing alerts you. The only symptoms are deliverability decay and DMARC reports.

If you flatten manually, you accept a standing duty: re-resolve every source on a schedule (monthly at minimum) with the SPF Checker, watch DMARC reports for SPF failures from the flattened provider (DMARC Report Analyzer), and record in your runbook which includes were flattened and when they were last checked.

Option 2: Use a service that flattens for you

Several DMARC vendors offer SPF flattening: you include their record, they publish an auto-updated list of IPs on their side, and your record consumes one lookup. They watch the sources for you. Evaluate on two questions — how quickly source changes are picked up, and whether the update cadence is contractual or best-effort.

Option 3: Subdomain splitting

Often the cleanest answer is not flattening but partitioning — stop piling every sender onto the apex record:

@ (root)      v=spf1 include:_spf.google.com ~all
news          v=spf1 include:mailgun.org ~all
billing       v=spf1 include:sendgrid.net ~all

Each subdomain gets its own SPF budget, its own DKIM selector and its own DMARC record, because DMARC evaluates per From domain. The root stays clean and hard to spoof, and a compromised marketing tool cannot damage transactional mail from the apex. This is why ESPs recommend a subdomain for bulk sending. It fails only if your From addresses must literally be name@yourdomain.com.

Verify your work

• Count lookups after every change with the SPF Checker.
• For flattened records, run a TXT lookup periodically to confirm what is actually published.
• After any change, run the Email Health Check and confirm SPF still passes end to end with the header analyzer.

Common mistakes

• Assuming Cloudflare flattens includes. It does not; the setting does not exist.
• Flattening once and forgetting. The record is a snapshot of provider IP lists. Without re-verification it becomes a time bomb.
• Flattening a provider with rotating IPs. If a source publishes a large or dynamic range, keep the include or move that sender to a subdomain.
• Losing ~all or -all during edits. A record ending in a bare all silently weakens policy; the SPF Checker flags it.

Frequently asked questions

How many lookups do I have left?

Run the domain through the SPF Checker. It reports the count a receiver would see. Over ten means SPF is already failing.

Is flattening against the RFC?

No — a record of pure ip4/ip6 mechanisms is valid. The RFC limits what receivers may fetch; it cannot warn you when a provider changes IPs under your flattened record.

Which option should I pick?

Subdomain splitting first, if From addresses allow it — it is the only structurally safe option. Otherwise use a flattening service with an update guarantee; manual flattening only if you will genuinely keep re-verifying.