SPF Flattening and the 10-Lookup Limit

An SPF evaluation is limited to 10 DNS-querying terms. When a record and its dependencies exceed that limit during evaluation, the result can be a permanent error rather than the intended SPF pass or fail.

SPF flattening can reduce lookup pressure by replacing some provider references with their current IP address ranges. That can be useful in a carefully managed case, but it exchanges a live provider dependency for a copy that must stay current.

The SPF lookup limit

The SPF specification limits the combined number of terms that cause DNS queries during a check. The relevant mechanisms are include, a, mx, ptr, and exists, together with the redirect modifier. ptr is deprecated and should not be introduced into new records.

The count includes recursive evaluation. If an include points to another SPF record containing further includes or other DNS-querying mechanisms, those terms can also consume the budget.

The authoritative rules are in RFC 7208, section 4.6.4.

Why records grow

Lookup pressure commonly grows when a domain authorises several third-party sending services. A record may appear short at the top level but expand into a deep dependency tree.

Example shape:

example.co.za. IN TXT "v=spf1 include:provider-a.invalid include:provider-b.invalid include:provider-c.invalid -all"

Each provider can publish its own includes, a records, or mx references. The result depends on the path evaluated for the connecting IP, so a simple count of top-level includes is not always enough.

What SPF flattening does

Flattening resolves selected provider dependencies and publishes their current IP networks directly in the customer record.

Before:

include:provider.invalid

Illustrative flattened shape:

ip4:192.0.2.0/24 ip6:2001:db8::/48

The example ranges above are documentation-only addresses and must not be published as a real authorisation.

Direct ip4 and ip6 mechanisms do not themselves require DNS lookups during SPF evaluation. That is why flattening can reduce the query count.

The main trade-off: freshness

With a normal include, the provider can change its authorised networks in its own SPF record. A receiving system evaluates the provider’s current publication.

With a flattened copy, the domain owner or its service must detect that change and update the copied networks. If the copy is stale:

• a new legitimate provider range may not pass SPF; or
• an old provider range may remain authorised longer than intended.

Automated refresh can reduce that risk, but it does not eliminate the need for monitoring, validation, safe publishing, and rollback.

Other constraints still apply

Flattening does not remove every SPF risk. The resulting TXT record must still be valid and practical to publish. Consider:

• DNS response and record-size behaviour;
• provider ranges that change frequently;
• nested or conditional provider logic;
• IPv4 and IPv6 coverage;
• record ownership and change approval;
• the effect of a failed update; and
• whether the service allows or supports flattening.

It also does not fix DMARC alignment. SPF can pass for a return-path domain that does not align with the visible From domain.

Options to consider before flattening

Remove obsolete senders

Confirm whether every authorised service still sends mail for the domain. Removing an abandoned include is usually simpler than copying its IP ranges.

Correct duplicate or invalid records

A domain must not publish multiple SPF records. Consolidate authorised senders into one syntactically valid record rather than adding another record beside the first.

Use provider-specific subdomains

Some organisations can assign a dedicated return-path or sending subdomain to a service. This can separate authorisation and ownership, but it must be supported by the provider and designed with DMARC alignment in mind.

Prefer aligned DKIM where appropriate

DMARC needs either aligned SPF or aligned DKIM to pass. Reliable DKIM signing can make a message less dependent on SPF surviving forwarding, although it does not make an invalid SPF record acceptable or remove the need to manage it.

Ask the provider for its supported design

Do not invent IP ranges from observed traffic. Use the provider’s current supported authentication and custom return-path options.

A controlled flattening workflow

If flattening is selected after review:

1. Inventory the source. Record the original include, its owner, and why it is authorised.
2. Resolve the complete dependency safely. Detect loops, errors, unsupported terms, and both address families.
3. Build a candidate record. Preserve other authorised mechanisms and the intended final qualifier.
4. Validate before publishing. Check syntax, lookup behaviour, DNS response characteristics, and the change plan.
5. Publish through normal change control. Keep the previous value and a tested rollback path.
6. Monitor the upstream source. Detect provider changes and review them before updating the copy.
7. Verify after every change. Confirm public DNS and relevant message authentication results.
8. Reassess periodically. Remove senders or flattening dependencies that are no longer needed.

The refresh schedule should follow provider change behaviour and operational risk. A fixed interval is not a universal guarantee of freshness.

Where Vigil can help

Vigil can support SPF review, dependency analysis, optimisation planning, and managed flattening where that scope is explicitly agreed. Any production change still requires the customer’s authorised DNS process and a clear record of responsibility.

The aim is a maintainable, evidence-backed SPF design. No SPF optimisation can guarantee inbox placement or stop every form of impersonation.

Frequently asked questions

Does every include count as one lookup?

The top-level include causes a lookup, but evaluating the referenced SPF record can trigger additional DNS-querying terms. Review the recursive path, not only the visible record.

Does an ip4 or ip6 mechanism consume the 10-term budget?

Those mechanisms do not require a DNS query during evaluation. They can still make a record larger and harder to maintain.

Is flattening required when a record approaches the limit?

No. Removing obsolete authorisations, changing the provider design, or separating sending use may be more maintainable. The right option depends on the domain and services involved.

Can flattening improve delivery?

It can help avoid an SPF permanent error caused by the lookup limit. Delivery remains subject to DMARC alignment, DKIM, message and sender reputation, content, receiver policy, and other factors.

Next step

Use the Vigil DMARC checker to inspect the public SPF result and observable dependency chain. Before changing DNS, confirm every authorised sender and obtain a domain-specific review if the record is near or beyond the lookup limit.