What is SPF flattening?

Flattening starts when the ten-lookup budget runs out. Google, a marketing platform, a helpdesk and an invoicing tool can spend it between them, and the eleventh include breaks evaluation for everything.

Resolving the chain yourself turns a handful of includes into dozens of ip4 blocks. The record gets long, ugly and fast, and it stops depending on anyone else's DNS.

The cost arrives later. Google publishes changes to its ranges and expects the include to carry them; a flattened copy does not move, and the mail from a newly added range fails SPF.

Automated flattening services re-resolve on a schedule and republish through a CNAME you delegate to them. That fixes the staleness and makes your authentication depend on their uptime instead.

Say your record reads v=spf1 include:_spf.google.com include:mail.crm-tool.example include:helpdesk.example include:invoices.example mx ~all. Google's include costs four lookups once its nested records are counted. Suppose the CRM's costs three, the helpdesk two, the invoicing tool one, and mx one more. That's eleven, and every message you send now evaluates to permerror.

You flatten the CRM include into the six ip4 ranges it resolves to today. The count drops to eight and mail authenticates again. Four months later the CRM vendor adds a seventh range for a new data center. Nothing in your DNS changes, nothing alerts you, and a share of the messages from that tool starts failing SPF.

Where you'd see it first is your DMARC aggregate reports. A row appears showing the CRM's new IP, your domain in the From header, and spf=fail. If DKIM is aligned for that tool the mail still passes DMARC, which is exactly why the problem can sit unnoticed for months.

You don't have to flatten everything. Pick the include that spends the most lookups and changes the least, and leave the others as includes so their owners keep them current. Google tells customers to use the include and updates its ranges behind it, so that's a poor candidate. A small vendor with one range that hasn't moved in years is a better one.

Then put a check on it, because a flattened record nobody watches is a fault waiting for a date. A short script can resolve the original include each night with dig +short TXT, compare the ranges with what you've published, and email you when they differ.

If you're weighing a hosted flattening service, ask how often it re-resolves, what it publishes if one of your vendors' DNS is down at that moment, and what happens to your record if you stop paying. That last answer matters most, since your SPF would then live inside someone else's zone.