Fixing SPF too many lookups

SPF (Sender Policy Framework) lets a receiving mail server check whether a message really came from somewhere you allow to send for your domain. The rules (RFC 7208) cap the number of DNS lookups a receiver will make while checking your record at 10. If you go over that, the receiver returns a permanent error that makes it treat your SPF as broken: it stops checking and fails the message, even when it is genuine. DMARCER shows you exactly where those lookups are being spent and gives you two ways to fix it: trim the record by hand, or hand the whole problem over to Hosted SPF Flattening.

What counts towards the 10 lookups

Only the parts of your record that need to look something up in DNS count. The expensive ones are include:, a, mx, ptr and the redirect= modifier. Each include: for a provider (Microsoft 365, your CRM, your help desk, your marketing platform) costs at least one lookup, and here is the catch: that provider's own record often contains further includes that each cost more. Those nested lookups are hidden from view in your published record, but they still count against your total. The parts that do not query DNS, such as ip4:, ip6: and all, are free.

Reading the lookup budget in DMARCER

Open the domain (from Domain Management, or from a customer's page on Customer Detail) and open the SPF window. The first tab, Analysis, runs the checks for you and shows a Lookup budget panel.

• The header shows a count out of the limit, for example 9 / 10. The progress bar is green while you are within budget, amber when you are within two of the limit, and red when you reach or go over 10.
• The Per-mechanism cost table breaks the total down. Each row shows the mechanism, the target or the provider it has identified, and how many lookups that branch costs once its hidden nested includes are added up. The costliest branches are highlighted, so you can see at a glance which provider is eating your budget.
• A short suggestions list points out the easiest wins, such as a sender you may no longer use.

[Screenshot: the Lookup budget panel on the Analysis tab showing the count out of 10 and the per-mechanism cost table]

Option 1: trim the record with the Builder

If only one or two providers are tipping you over the limit, the Builder tab is often all you need. Tick the services this domain actually sends through (use the Filter services box, or Show only selected to review what is already there), choose a Terminator, and add anything bespoke in the Extras box (one per line, for example an ip4: address or an a: host). The record updates as you go.

• Terminator: we recommend leaving this on -all (Hard fail), which tells receivers to reject anything not listed. ~all (Soft fail) is only meant as a stepping stone, and ?all (Neutral) is not recommended.
• Remove senders you no longer use. Every include you drop frees up its lookups and shortens the record.
• The badge next to the built record shows only the direct mechanism count. Each service you keep may add one to three hidden lookups of its own, so try to leave yourself at least two lookups of headroom under 10.
• Publish the result. Copy the value into the TXT record at the top level (apex) of your domain at your DNS host, or, if the domain is linked to a DNS integration, use the Publish button to push it automatically. DMARCER will refuse to save anything that would break SPF (over 10 lookups, or no mechanisms at all) and will warn you before it removes any sender it recognises.

Option 2: remove the limit with Hosted SPF Flattening

When trimming is not enough, the Flattening tab solves the problem for good. Flattening resolves all of your includes down to a simple list of IP addresses, hosted by DMARCER. Your published record then becomes a single include: pointing at DMARCER, so receivers see just one lookup no matter how many providers you authorise. DMARCER re-checks your providers' IPs every day, so when an upstream provider changes its sending IPs your SPF stays correct without you having to lift a finger.

The Flattening tab knows where you are in the process and walks you through each step:

• Enable SPF Flattening: DMARCER takes a snapshot of your current record, works out your senders, and creates a unique flattened-record subdomain for the domain.
• Activation: review the senders DMARCER found, make any edits, use Save senders, then Set up flattened zone to create the hosted record with the resolved IPs. Your own DNS is not touched yet.
• Switch your DNS: publish the new single-include record at your domain (copy it, or push it via your DNS integration). Publish the new record before removing the old one, so receivers always see a valid SPF during the change.
• Flattened (live): from here you can add or remove senders, and saving republishes the hosted record straight away; your own DNS does not need to change again. Refresh sender IPs re-checks your providers on demand, and Disable flattening starts the move back to a normal record.

Flattening first has to be set up for the platform by a Super User under Platform, Integrations, SPF Flattening. To turn it on for a domain you need to be a Tenant Admin (or have permission to manage SPF Flattening), because it changes how the domain's mail flows. If you cannot see these options, get in touch and we will help.

Common pitfalls

• More than one SPF record. Publishing two or more v=spf1 TXT records is itself a permanent error that makes receivers treat SPF as broken (RFC 7208 section 3.2), and SPF fails completely no matter how many lookups you have. The Analysis tab flags this with a red banner; merge everything into one record and delete the rest first.
• Hidden nested lookups. A record can look short and still fail, because a provider's include quietly pulls in more includes. Trust the Lookup budget total, not the number of includes you can actually see.
• Record length. Quite apart from the lookup limit, a record getting close to the 512-byte DNS limit can be cut short. DMARCER warns you at 450 characters. Flattening is the usual fix, as it packs long include chains into one short hosted record.
• Do not edit a flattened domain in the Builder. Once flattening is live the Builder is locked behind a warning card, because rebuilding and publishing there would overwrite the hosted include line and quietly disconnect the domain. Manage your senders from the Flattening tab instead.
• Check again after publishing. DNS changes take a little time to spread. Re-run the SPF check on the domain to confirm the lookup count has dropped and SPF now passes.