SPF record flattening: a practical guide

You added Google Workspace, then SendGrid for transactional emails, then Mailchimp for newsletters, then Zendesk for support. Each vendor says "add this include: to your SPF record." You do, and everything works, until one day SPF starts failing for no obvious reason.

The cause: your SPF record now requires more than 10 DNS lookups, and RFC 7208 treats that as a hard failure. The receiving server returns PermError, SPF fails, and if DKIM is missing or misconfigured, your DMARC policy kicks in. Emails get quarantined or rejected.

SPF flattening is one way to fix this, but it should not be your first move. This guide walks through the problem, the simpler fixes, and when flattening is actually the right call.

The 10-lookup limit

Every time a receiving mail server evaluates your SPF record, it performs DNS lookups for each mechanism that requires one. RFC 7208 caps this at 10 lookups per evaluation.

The problem is that include: mechanisms are recursive. When you write include:_spf.google.com, the receiver looks up that record (1 lookup), then evaluates the mechanisms inside it. If Google's record has more include: directives, those count too. A single Google Workspace include can use 3 to 4 lookups from your budget of 10.

Here is a record that looks like 5 mechanisms but actually triggers 12 or more lookups:

Why the limit exists

It is a security measure against DNS amplification attacks. RFC 7208, Section 11.1 describes the scenario: an attacker publishes an SPF record that references a victim's domain many times, then sends emails to many mail servers. Each server performs DNS lookups against the victim's domain while evaluating SPF, turning the attacker's email traffic into a distributed denial-of-service attack against the victim's DNS. The 10-lookup cap limits this amplification.

What counts toward the limit

The initial DNS query to retrieve the SPF TXT record itself does not count. The limit applies to mechanisms evaluated within the record.

The void lookup limit

There is a second limit, less well known. RFC 7208 Section 4.6.4 recommends that implementations limit void lookups (queries that return NXDOMAIN or empty answers) to 2. Most major receivers enforce this, and exceeding it triggers PermError. This matters because stale include: references to decommissioned vendor domains or typos can hit this limit. Two such stale references anywhere in the chain, including inside nested includes, will break SPF.

Try these before flattening

Flattening creates its own problems (stale IPs, maintenance burden). Before going there, three simpler approaches can often bring you back under 10 lookups.

1. Remove includes you do not need

This is the most effective step and the one most often skipped. SPF validates the Return-Path (envelope sender) domain, not the visible From header. Many providers, such as Mailchimp, HubSpot, Brevo, Zendesk, and Freshdesk, use their own domain as the Return-Path. SPF validation happens against their DNS, not yours. Adding their include: to your record wastes a lookup and does nothing for DMARC compliance. These providers rely on DKIM alignment instead.

2. Move email streams to subdomains

Each subdomain gets its own SPF record with its own 10-lookup budget. Instead of cramming everything into your root domain:

This also isolates sender reputation: marketing campaigns do not affect transactional email deliverability. The trade-off is DMARC alignment. Your DMARC record on the root domain must use relaxed alignment (aspf=r, the default) for SPF on subdomains to pass. For details, see our guide on DMARC, SPF, and DKIM alignment.

3. Rely on DKIM instead of SPF

DMARC passes if either SPF or DKIM passes with alignment. For services where DKIM is properly configured, you can remove the SPF include entirely. Configure DKIM signing with your domain on the provider's side, verify it in your DMARC reports, and drop the include.

How SPF flattening works

If you have trimmed unnecessary includes, moved streams to subdomains, and confirmed DKIM alignment, and you are still over 10 lookups, flattening is the next step.

The idea is simple: replace include: mechanisms with the ip4: and ip6: addresses they resolve to. Since IP mechanisms do not trigger DNS lookups, this reduces your count.

Before and after

The flattened record is longer (more bytes), but it uses zero DNS lookups. You traded the lookup limit problem for a maintenance problem: when Google, SendGrid, or Microsoft change their IP ranges, you need to update this record.

Manual flattening

Resolve each include yourself using dig and collect the IP ranges:

Manual flattening is free and gives you full control. For one or two stable includes, it works fine with weekly monitoring. For three or more, the operational burden adds up fast.

Automated flattening services

Automated services resolve your includes, publish the flattened IPs behind a single hosted include:, and monitor for changes. Your SPF record points to their hosted record, so it stays at 1 DNS lookup regardless of how many services are behind it. The service detects IP changes and updates its record automatically.

Risks of flattening

Flattening solves the lookup count, but it creates new failure modes.

Stale IP addresses

Email providers rotate their sending IPs. With include:, your SPF record references theirs dynamically, and changes propagate automatically. With flattened IPs, you have a snapshot. When the provider adds a new IP, emails from that IP fail SPF. As Mailhardener documented, this is the most common flattening failure: a provider adds a new IP to their pool, and SPF silently breaks for a subset of outbound emails.

TTL and propagation delays

Even after you update your flattened record, DNS caches worldwide may serve the old version until the TTL expires. With a 3600-second TTL (1 hour), there is up to a 1-hour window where some receivers see old IPs and others see new ones. For flattened records, keep the TTL short: 300 seconds (5 minutes) is a reasonable trade-off between propagation speed and DNS query volume.

TXT record size limits

Each include: you flatten expands into multiple ip4:/ip6: entries. DNS TXT records have a 255-byte limit per string (RFC 1035), and the total response should stay under 512 bytes to avoid UDP truncation. Large flattened records may need to be split or delegated behind a hosted include.

Lost troubleshooting context

include:sendgrid.net tells you which service is authorized. ip4:167.89.0.0/17 does not. Flattened records are harder to debug.

Macros cannot be flattened

Some providers use SPF macros (RFC 7208, Section 7) like %{i} or %{d}. These resolve dynamically based on the sending context. You cannot flatten them into static IPs. Any include containing macros must stay as-is.

Best practices if you flatten

Keep TTLs short

Set the TTL on your SPF TXT record to 300 seconds (5 minutes) while actively managing a flattened record. Increase it once the record is stable and monitoring is in place.

Monitor for provider IP changes

If you flatten manually, re-resolve the original includes at least weekly (daily is better) and compare against your published record. If you use an automated service, verify it is detecting changes by checking its logs.

Do not flatten macros or your own infrastructure

Keep a, mx, direct ip4:/ip6: entries, and any macro-based mechanisms as-is. Only flatten include: mechanisms that resolve to static IP lists from third-party providers.

Test before publishing

After building a flattened record, check that:

• The total DNS lookup count is within the 10-lookup limit
• The TXT record is syntactically valid
• The record fits within DNS size limits (under 512 bytes, or split across delegated records)
• All your legitimate sending IPs are covered

Our free domain checker shows your current DNS lookup count and validates SPF syntax.

Decision framework

Sources and further reading

• RFC 7208: the SPF specification. Section 4.6.4 covers DNS lookup limits, Section 11.1 covers the amplification attack rationale.
• RFC 7208 §4.6.4: the authoritative definition of how DNS lookups are counted toward the 10-lookup limit.
• SPF overview: strengths and weaknesses: full SPF protocol guide, including the Return-Path provider tables showing which services need SPF includes.
• Free SPF record generator: build a clean SPF record from scratch and count DNS lookups before publishing.
• Free domain checker: check your current SPF record, lookup count, and email authentication status.