SPF flattening: what it is, and why it is a last resort

When an SPF record exceeds ten DNS lookups it stops working. Flattening is the practice of resolving every include: down to the IP ranges behind it and publishing those directly, so the record costs zero lookups.

What it looks like

Before, at three lookups:

After, at zero:

The problem

Your provider's IP ranges are not yours, and they change without telling you. The moment Google or SendGrid adds a range, your flattened record is wrong — and the mail sent from the new range fails SPF. Nothing alerts you. The record still looks valid.

You have traded a visible failure (permerror, which a checker catches immediately) for an invisible one (a slowly rotting IP list). That is a bad trade unless the flattening is automated and re-run continuously.

Try these first

1. Remove what you no longer use. Most over-limit records contain at least one include for a platform that was cancelled years ago. This is free and it is usually enough.
2. Check what each include actually costs. They vary enormously — some providers cost one lookup, others cost seven. Dropping one expensive include often beats dropping three cheap ones.
3. Move senders to a subdomain. Marketing mail from news.yourdomain gets its own SPF record and its own ten-lookup budget. This is the cleanest fix and it costs nothing.
4. Lean on DKIM. DMARC needs one aligned pass. A sender with working DKIM does not need to be in SPF at all.

If you flatten anyway

Automate it. A flattened record maintained by hand will break, the only question is when. Re-resolve the source includes on a schedule, diff against what is published, and alert on change. And keep the original include-based record in a comment somewhere, because in a year nobody will remember which ranges came from where.

Check your domain