SPF Flattening: When to Do It, How, and Why It Quietly Breaks

SPF has a limit that most people discover by accident: a check may cause at most ten DNS lookups. Go over, and the receiver returns a permanent error for the whole record. Your mail doesn't get a soft warning, it simply loses its SPF pass, and with it half of its DMARC protection.

What counts toward the ten

Each include, a, mx, ptr, exists and redirect term costs one lookup, and so does every such term inside the records you include. ip4, ip6 and all cost nothing. That is why a record that looks short can be over the limit: include your mailbox provider, a marketing platform, a CRM, a support desk and a transactional service, and each of those includes its own includes.

See your real lookup count and include tree

Try these before flattening

• Remove senders you no longer use. SPF records collect includes from tools abandoned years ago, and this is often enough on its own
• Move bulk or marketing mail to a subdomain. Mail.yourdomain.com gets its own SPF record with its own ten lookups, and it keeps that stream's reputation apart from your main domain
• Use a custom return-path (bounce) domain at the sending service. SPF is checked against the return-path domain, so when the service uses its own, your record doesn't need to include it at all
• Replace a and mx terms with explicit ip4 and ip6 ranges, which cost nothing and rarely change for your own servers

What flattening is

Flattening replaces an include with the IP ranges it resolves to. The lookup disappears, because the addresses are now written into your record directly. You can flatten some of the includes and leave the rest, which is usually the better choice.

The catch: the addresses are a snapshot

An include is a live pointer. When a provider adds or changes a sending IP, your record follows automatically. A flattened record is a copy taken on the day you made it. When the provider rotates addresses, mail from them starts failing SPF, and nothing tells you. There is no error, no bounce, just a gradual decline in authentication results that you find in DMARC reports or in a deliverability drop weeks later.

That makes flattening a good fit for senders whose IPs barely change, such as your own servers or a small provider with a fixed range, and a poor one for large providers such as Google, Microsoft and the big sending platforms, which publish and rotate many addresses.

Doing it safely

• Flatten only as much as you need to get comfortably under ten, and leave the includes of providers that change their IPs often
• Watch the length. A single TXT record that grows past roughly 450 characters risks not fitting in one DNS response. Split the addresses across sub-records such as spf1.yourdomain.com and include them from the main record
• Keep the old record's value so you can roll back, and publish with a short TTL at first
• Re-check on a schedule, or use a service that re-flattens automatically. A flattened record that is never refreshed is the one that breaks
• Confirm the result with an SPF check after publishing, and watch propagation before you rely on it

Flatten selected includes and get a ready-to-publish record

Check that the new record has propagated

Flattening turns a loud failure into a quiet one. Do it only where you must, and put the re-check in the calendar the day you publish.