How SPF flattening works

28 May 2026 · The DMARC Engine Team · 14 min read

SPF flattening is one of the quietest sources of broken email authentication. Your record looks fine, it passes a casual glance, and then one day a major mailbox provider starts returning permerror and a chunk of your legitimate mail begins failing SPF. The cause is almost always the same: your record needs more than ten DNS lookups to evaluate, and the receiving server gives up.

This guide explains what flattening solves, how the SPF Flattening tab in DMARC Engine analyses a live record, how to read the Include Tree and the DNS lookup counter, and how hosted SPF keeps you permanently under the limit without you having to maintain a list of IP addresses by hand.

If you only want to check a record quickly without signing in, the free SPF checker runs the same resolution and counts lookups for any public domain. The dashboard tooling described here goes further: it lets you build, save and host the record so the limit can never be breached again.

What the ten-lookup limit is, and why it bites

SPF (Sender Policy Framework) tells receiving servers which hosts are allowed to send mail for your domain. You publish it as a single TXT record at the root of your domain, and it begins with v=spf1.

The record is made up of mechanisms. Some of them, such as ip4: and ip6:, list addresses directly and cost nothing to evaluate. Others force the receiving server to go and look something up in DNS:

• include: pulls in another domain's entire SPF record (one lookup, plus any lookups that record itself triggers).
• a and a: resolve a hostname to its addresses (one lookup).
• mx and mx: resolve a domain's mail exchangers (one lookup).
• ptr and exists: also cost a lookup each, though they are rarely used and ptr is discouraged.

The SPF standard, RFC 7208, caps the number of these DNS-resolving mechanisms at ten for a single evaluation. Cross that line and a conformant receiver must return permerror (a permanent error). When SPF returns permerror, alignment cannot be established through SPF, and depending on your DMARC policy the message may be quarantined or rejected.

The trap is that the count is recursive. You might publish a record with only four include: mechanisms, which feels comfortable, but each of those vendors maintains their own record that nests further includes. A single include: for a large email platform can quietly consume four, five or six lookups on its own. You stay under ten until a vendor adds one more nested include on their side, and then your perfectly untouched record tips over. You changed nothing; someone else's record did, and your mail starts failing.

This is exactly why a static, hand-counted SPF record is fragile, and why flattening exists. For a short conceptual primer, see the SPF flattening and permerror glossary entries.

What "flattening" actually means

Flattening is the process of resolving every include:, a and mx in your record all the way down to the actual IP addresses they ultimately authorise, and then replacing those lookup-costing mechanisms with plain ip4: and ip6: mechanisms.

The result is a record that authorises the same senders but costs almost no DNS lookups, because ip4: and ip6: do not require resolution. A record that needed twelve lookups can be flattened into one that needs zero.

Flattening solves the limit, but it introduces a maintenance problem of its own: vendor IP ranges change. If you flatten by hand and paste the result into DNS, your record is correct on the day you publish it and slowly rots from then on, because you are no longer following the vendor's include: and so you never see their additions or removals. Hosted SPF, covered at the end of this guide, is the answer to that problem. It flattens continuously and re-checks the upstream sources for you, so the record stays both small and current.

Where SPF flattening lives in the dashboard

In the dashboard, open Hosted SPF from the left navigation. The page header reads Hosted SPF, with the description "SPF record management with automatic flattening to stay under the 10 DNS lookup limit", and an Add Domain button on the right that takes you to your domain list.

Across the top you will see four tabs:

• Manage Records lists each of your domains as a card and shows whether hosted SPF is switched on.
• Record Builder is where you assemble an SPF record mechanism by mechanism and watch the lookup counter in real time.
• SPF Flattening is the analysis tab this guide focuses on: enter a domain, click Analyse, and read the resolved tree and flattened IP list.
• Vendor Management is a local helper for collecting the include domains of the services you send from.

Each tab is described below, starting with the analysis tab.

Using the SPF Flattening tab

Select the SPF Flattening tab. At the top you will see a card headed SPF Flattening Engine, which explains that it will "Resolve a domain's live SPF record into its full include tree and a flattened IP list, and count the RFC 7208 DNS lookups (limit is 10)."

To run an analysis:

1. Type the domain into the Domain field. The placeholder shows example.com. Enter the organisational domain whose SPF record you want to inspect, for example yourcompany.com, not a hostname or an email address.
2. Click Analyse. You can also press Enter from inside the field. While it works, the button label changes to Analysing... and a card appears reading "Resolving SPF record...".

The lookup is live. It does not read your saved configuration; it queries DNS for the record that is published right now, then walks every include:, a and mx it finds, recursively, exactly the way a receiving mail server would. That means you can analyse any domain, including one you do not own, which is useful for inspecting a vendor before you add their include: to your own record.

If the domain has no SPF record, or the lookup fails, an error panel appears beneath the field with the reason. Common causes are a typo in the domain, a domain that genuinely has no v=spf1 TXT record, or a temporary resolution failure that clears on a retry.

Reading the results: the lookup counter

When the analysis completes, the first results card is headed Results for followed by the domain in monospaced text. In the top-right corner of that card is the headline you came for: the DNS lookup count.

It reads as N DNS lookups (limit 10), where N is the total number of lookup-costing mechanisms across the whole resolved tree, not just the top-level record. The colour and icon tell you the verdict at a glance:

• A green tick and green text mean the record is within the limit and will evaluate cleanly.
• A red warning icon and red text mean the record exceeds ten lookups.

When the record is over the limit, a red panel spells out the consequence: "This record exceeds the RFC 7208 limit of 10 DNS lookups. SPF evaluation may fail with a permerror. Flatten or reduce includes to stay under the limit." That is your cue to either trim includes or, more reliably, switch to hosted SPF so the count is managed for you.

A record at exactly ten lookups is technically valid but has no headroom. If any upstream vendor adds a single nested include, you cross the line without touching your own record. Treat anything above seven as a record that needs attention, not a record that is fine.

Beneath the counter, the card shows the Raw SPF Record: the exact TXT value that is published for the domain today, as a single string starting with v=spf1. This is the literal record receivers see, before any flattening. Use it to confirm you are analysing what you think you are analysing.

Reading the Include Tree

The second results card is headed Include Tree. This is the most informative part of the page, because it shows you not just how many lookups you are using but precisely where each one comes from.

The tree is rendered as nested rows. The top row is the domain you analysed. Each include: it contains appears indented beneath it, with a small downward arrow showing the nesting, and any includes those records contain are indented again, and so on, all the way down. The structure mirrors the real resolution path a receiver follows.

Each node carries badges:

• A lookup count badge shows how many DNS lookups that specific node contributes. Nodes that cost a lookup are highlighted so they stand out from ip4: and ip6: entries, which cost nothing and so do not inflate the count.
• An error badge appears in red on any node that failed to resolve, that pointed at a record with no SPF data, or that itself pushed the running total over the limit.

Read the tree from the deepest, most indented branches first. That is usually where the surprises hide. A common pattern is a single top-level include: for an email platform that looks innocent but expands into three or four nested includes, each adding to the count. The tree makes that visible immediately: you can see one vendor quietly consuming half your budget.

Use the tree to decide your fix. If one branch is responsible for most of your lookups, you have three options:

• Remove the vendor entirely if you no longer send through it. Stale includes for services you stopped using are a frequent cause of bloat.
• Replace a heavy include: with the specific ip4: and ip6: ranges the vendor publishes, if they document a stable list. This trades lookups for IPs but means you must track changes yourself.
• Hand the whole problem to hosted SPF, which flattens every branch and keeps the result current.

Reading the Flattened IP Addresses

The third results card is headed Flattened IP Addresses. This is the payoff of the resolution: every IPv4 and IPv6 address that the entire tree ultimately authorises, collapsed into one flat list. A badge shows the total count, for example a small "42 IPs" marker.

This list is what a fully flattened version of the record would contain. Each address is shown in monospaced text, and the list scrolls if it is long.

In the top-right of the card is a Copy button. Clicking it copies the whole list, space-separated, to your clipboard, and a confirmation toast reads "Copied flattened IPs". You can paste that list straight into a record builder, a ticket to a colleague, or a comparison against a record you maintain elsewhere.

If the record contained only include: mechanisms that resolved to nothing usable, or contained no IP-bearing mechanisms at all, the card instead reads "No IP mechanisms resolved from this record." That is normal for a record that is purely structural.

A word of caution: copying this list and pasting it into your DNS by hand is a valid one-off fix, but it is a snapshot. The moment a vendor rotates an IP range, your pasted list is wrong and you will not know. If you are going to flatten, let the platform host the flattened record so it can keep re-resolving the sources. That is the difference between flattening once and flattening continuously.

How hosted SPF keeps you under the limit automatically

Analysis tells you where you stand. Hosted SPF fixes it and keeps it fixed. The principle is simple: instead of publishing a sprawling multi-include record at your domain, you publish one record with a single include: that points at a record DMARC Engine serves and maintains for you. Your domain therefore costs one lookup, no matter how many vendors sit behind the scenes, because the platform resolves and flattens all of them and keeps the served record small and current.

You set this up in the Record Builder and Manage Records tabs.

Building the record

Open the Record Builder tab. The left card is headed SPF Record Configuration and contains:

• A Domain dropdown. Choose the domain you are configuring. Until you pick one, a hint reads "Select a domain to save this record to." If you reached this tab by clicking Configure on a domain card, the dropdown is already set and any previously saved mechanisms are loaded.
• An SPF Mechanisms list. Click Add to append a row. Each row has a Type selector offering include:, ip4:, ip6:, a: and mx:, a value field (placeholder e.g. _spf.google.com), and a delete control to remove that row. Add one row per sending source. For most organisations these are include: mechanisms for the platforms you send from.
• A Default Qualifier selector that controls the trailing all mechanism, which decides what happens to senders not otherwise matched:
• ~all (SoftFail), the recommended default. Unlisted senders are marked as a soft failure: suspicious but not outright rejected. This is the safe choice while you are still confirming you have captured every legitimate source.
• -all (HardFail), the strict setting. Unlisted senders fail outright. Move to this only once you are confident every legitimate source is covered, otherwise you risk blocking your own mail.
• +all (Pass), which authorises everyone and is effectively no protection. Do not use it.
• ?all (Neutral), which makes no assertion at all. Useful only in narrow testing situations.

For more on choosing between soft fail and hard fail, see the SPF all qualifier glossary entry.

Watching the lookup counter as you build

The right-hand side shows a card headed Generated SPF Record containing the live TXT value as you edit. Below it is the lookup indicator, reading N/10 DNS lookups, with a coloured progress bar that fills as the count rises:

• Green up to and including seven lookups: comfortable, with headroom.
• Amber from eight up to ten: valid but tight, and worth flattening.
• Red above ten: over the limit, and the record will trigger permerror.

This counter is your early-warning system while you build. The card also offers Copy, to copy the generated value, and Save Record, to persist the configuration to the selected domain. Saving does not by itself flatten the record; it stores your intended mechanisms and, once a hosting slug is provisioned, lets the platform serve the optimised version.

The optimised single-include record

Below that is a card headed DNS Setup, which reads "Use a single include pointing to our flattened record". Once the domain has been saved and a hosting slug provisioned, this card shows an Optimised SPF Record of the form:

v=spf1 include:<your-served-host> ~all

The closing line notes the point of the whole exercise: "This reduces your DNS lookups to just 1. We automatically flatten and monitor all your sending sources." That single include: is the only thing you publish at your domain. Everything behind it, the resolution of each vendor and the flattening into IPs, happens on the served record, which the platform keeps under the limit and up to date as vendors change their ranges.

Switching hosting on

Open the Manage Records tab. Each domain appears as a card with a DNS icon and its name. A green SPF hosted badge appears once hosting is active for that domain. Each card offers:

• Configure, which loads that domain's saved record into the Record Builder so you can edit it.
• Withdraw, which unpublishes the hosted record and removes hosted SPF for the domain. You will be asked to confirm, since this changes what is served.

Below the buttons, each card shows the exact DNS instruction to publish: the hostname and the TXT value to add at your DNS provider. Add that record at your registrar or DNS host, wait for it to propagate, and your domain is now served by a single, continuously flattened include. From that point on the ten-lookup limit is the platform's problem to manage, not yours.

To learn how delegation is set up end to end, see Connecting your DNS and the broader Hosted SPF product overview.

Vendor Management: the include shortlist

The fourth tab, Vendor Management, is a convenience for assembling your include list before you build. Its card is headed Sending Vendors and carries a Builder-only label, because, as the description states, "This list is not saved to your account."

Click Add Vendor to open the Add Vendor modal. It contains:

• A Vendor Preset dropdown with common services such as Google Workspace, Microsoft 365 and SendGrid. Choosing a preset fills in the correct include domain automatically.
• An Include Domain field, pre-filled from the preset or editable for a vendor not in the list.

Click Add Vendor in the modal to add the vendor to the on-screen list, where each row shows the vendor name and its include domain with a delete control. Use this as a worksheet: list every service you send through, confirm none are missing, then recreate those as include: mechanisms in the Record Builder. The tab does not publish anything itself; it simply helps you avoid forgetting a sender, which is the most common reason legitimate mail fails SPF.

A recommended workflow

Putting the tabs together, a reliable path from "fragile record" to "permanently safe" looks like this:

1. In SPF Flattening, analyse your live domain. Read the lookup count and the Include Tree to see exactly where your lookups are spent and whether any branch errors out.
2. If you are over the limit, or sitting in the amber band near it, use Vendor Management to list every legitimate sender so nothing is dropped when you rebuild.
3. In Record Builder, select the domain, add an include: (or specific ip4:/ip6: ranges) for each sender, choose ~all (SoftFail) to start, and watch the N/10 DNS lookups counter stay green.
4. Click Save Record, then open Manage Records and publish the TXT instruction shown on the domain card. Your domain now resolves in a single lookup and the green SPF hosted badge confirms it.
5. Once you have watched reports for a couple of weeks and confirmed no legitimate source is failing, return to Record Builder and tighten the qualifier to -all (HardFail).

From there, monitor your authentication results through your DMARC reports to confirm SPF continues to pass and align. Because the hosted include is flattened continuously, a vendor changing their IP ranges no longer silently breaks your record, and the ten-lookup limit stops being something you have to think about.

Related reading

• Free SPF checker for a quick public analysis, and the DMARC checker, DKIM checker, BIMI checker and MTA-STS checker for the rest of the stack.
• SPF generator and the DMARC report analyzer for building records and reading aggregate data.
• Glossary: SPF, SPF flattening, the 10-lookup limit, the all qualifier, permerror and void lookups.
• Products: Hosted SPF, Hosted DMARC and Hosted DKIM.
• Background on email authentication requirements at Requirements.