SPF flattening solves the lookup limit and creates a worse one

SPF evaluation is capped at ten DNS lookups. Exceed it and the result is a PermError, which receivers treat as no SPF record at all — so a record that was working yesterday can stop counting the day a provider adds an include of their own.

Flattening is the obvious fix: resolve every include yourself, collect the IP addresses, and publish those directly. Zero lookups, problem solved.

It is not solved. It is deferred, and the deferred version fails silently.

What you actually published

When a provider publishes include:_spf.example.com, they are telling you to ask them, every time, which addresses they are currently sending from. That is the contract. They change infrastructure, the include changes, your record keeps working.

Flattening replaces that question with a snapshot of the answer. The moment the provider adds a sending range, your record is wrong — and it is wrong in the direction that fails: their new servers are not in your SPF, so mail from them fails SPF, and if DKIM does not cover it the message fails DMARC.

Nothing alerts you. The record is syntactically valid, under the limit, and stale.

Why it is worse than the PermError

A PermError is loud. Every checker reports it, DMARC aggregate reports show it, and someone notices within a week.

A stale flattened record produces intermittent failures for a subset of mail from one provider. The mail that fails is the mail routed through whichever servers are new. Delivery drops a few percent. No tool reports a problem, because there is no problem with the record itself.

What to do instead

Remove senders you are not using. Most records over the limit are carrying includes for services nobody has used in two years. This is free and usually sufficient.

Use subdomains per sender. SPF is evaluated against the return-path domain. Send marketing from mail.example.com and transactional from send.example.com, each with its own record and its own lookup budget. This also isolates reputation, which is worth doing on its own merits.

Lean on DKIM for alignment. DMARC passes when SPF or DKIM aligns. A correct DKIM signature with your domain in d= means SPF is not load-bearing for alignment, and the pressure on the record drops.

If you must flatten, automate and monitor. Re-resolve the includes on a schedule, diff against what is published, and alert on change. A flattened record regenerated nightly from the real includes is defensible. One pasted in by hand two years ago is a time bomb with an unknown fuse.

Checking where you stand

Count your current lookups with the SPF checker — it resolves every include and shows the total, including the nested ones your provider added without telling you.

If you are at eight or nine, you are not safe. You are one provider change away from a PermError, and the change will not be yours.