SPF Flattening: Free Tool and Honest Guide

Should you flatten your SPF record?

Often the answer is no. Flattening trades a DNS lookup problem for a maintenance problem, so it is worth knowing which of these three positions you are in before you publish anything. The tool above works out which one applies to your domain.

You are already under 10 lookups. Leave the record alone. The results above show your current lookup count against the RFC 7208 limit of 10. If you are under it you have no PermError to fix, and flattening only creates work: you would be swapping a record that maintains itself for a static list of IP addresses that you now own and have to keep current. The tool will still produce a flattened record so you can see what it looks like, but seeing it is not a reason to publish it.

You are over the limit and the flattened record fits. This is the case flattening is actually for. The resolved record comes in under the 255-character limit, you can publish it as a single TXT record, and the lookup count drops to zero because only ip4: and ip6: entries remain. The exception is an exists: term, as Salesforce uses: it cannot be turned into addresses, so it is kept as written and costs one lookup. The cost is the maintenance described below: you have taken a snapshot of your providers' infrastructure and it starts ageing the moment you publish it.

You are over the limit and the result is too big for one record. The tool splits the IPs across chained sub-records and, when the chain still means exactly what your record means and stays within the 10-lookup limit, shows you each record to publish, sub-records first and the root record last. If it cannot, it tells you why instead of handing you a record that would break your mail. Note what that costs: each chained record is itself a lookup, so you do not get back to zero, and you now have several records to keep in step rather than one.

Before flattening in any of these cases, check whether you still send from every service in the record. Removing an include: for a platform you stopped using two years ago is a permanent fix that costs nothing to maintain, and it is common to find one or two of them.

What is SPF flattening?

SPF (Sender Policy Framework) records tell receiving mail servers which IP addresses are authorised to send email on behalf of your domain. Most SPF records use include: mechanisms to reference third-party senders like Google Workspace, Microsoft 365, and SendGrid. Each include: causes a DNS lookup, and RFC 7208 limits SPF processing to 10 DNS lookups total.

SPF flattening resolves those includes at analysis time, replacing them with the actual IP addresses they expand to. The result is a flattened SPF record built from ip4: and ip6: entries, which need no DNS lookups at delivery time. An exists: term, which cannot be turned into addresses, still costs one, and so does each link in a chain of records.

The SPF 10 lookup limit (PermError)

RFC 7208 §4.6.4 states that SPF evaluation must abort after 10 DNS lookups. The cap stops SPF being used to overload the DNS: without it, a single inbound message could trigger a long chain of DNS queries on the receiving server. If your record causes more than 10 lookups, receivers return a PermError, a permanent failure that tells the receiving server your SPF record is invalid. The consequence is the same as having no SPF record at all: emails may be marked as spam or rejected outright.

Common causes of exceeding the limit: using many third-party email providers (each with their own include:), chained includes (an include that itself includes other domains), and mx: and a: mechanisms that each trigger a lookup.

How to fix SPF too many DNS lookups

A PermError costs you more than SPF. DMARC needs SPF or DKIM to pass and align with your From: domain, so wherever SPF returns PermError, DMARC rests on DKIM alone. Mail that one of your own gateways alters after signing, or that comes from a service you never set up DKIM signing for, then fails DMARC, and any quarantine or reject policy you publish is applied to it. The fixes below start with the cheapest.

Count your lookups

Every include:, a, mx, ptr, exists: and redirect= costs one lookup, and so does each one inside the records you include, at any depth, so the number of includes you can see is not the number receivers count. When we checked on 9 October 2026, include:spf.protection.outlook.com (Microsoft 365) and include:_spf.google.com (Google Workspace) cost 1 lookup each, because both records list only addresses, while include:mailgun.org cost 5 and include:email.freshdesk.com cost 7. This record has 3 includes and needs 13 lookups:

v=spf1 include:spf.protection.outlook.com include:mailgun.org include:email.freshdesk.com ~all

The tool at the top of this page walks every include for you, and its include tree shows what each one costs, so you can see where the lookups go. On a Microsoft 365 or Google Workspace domain the mailbox provider's include costs 1 lookup, so the rest of the budget goes on the other services in the record.

Remove what you no longer send from

The simplest fix is often the most effective, and it leaves nothing to maintain. Go through every include and ask whether that service still sends email for your domain. Common leftovers:

• A marketing platform you replaced but never took out of SPF.
• A helpdesk or ticketing system that was trialled but never adopted.
• A mail server that has been decommissioned.
• An a or mx mechanism pointing at servers that no longer send email.

Check with whoever runs each service before you delete its include. Your DMARC aggregate reports help, but they are not proof that a service has stopped: reports name only the last server that handed the mail over, so a signature or relay service that passes mail back through Microsoft 365 can send for you without ever appearing under its own name.

Give a sender its own subdomain

Each domain and subdomain has its own SPF record with its own budget of 10 lookups. If a service can use a subdomain such as marketing.example.com as its envelope sender (the Return-Path address), receivers check that subdomain's record instead. It needs to authorise only that one service, for example v=spf1 include:sendgrid.net ~all, and the service's include comes out of your main record.

For DMARC, SPF alignment has to be relaxed (aspf=r) so that marketing.example.com aligns with example.com in the From address, because both share the organisational domain. Relaxed is the default when your DMARC record leaves the tag out (RFC 9989, section 4.7), but setting it explicitly makes the intent clear to anyone reading the record.

Flatten what is left

If every remaining include is still needed, flattening is the fix that remains. The tool above replaces includes with the addresses behind them and offers a record only when it means the same as yours and stays within 10 lookups. The next two sections cover what a flattened record costs to maintain, and how Dynamic SPF on the Professional and MSP plans keeps one current for you.

Check the fix worked

1. Count again. Run your domain through the tool above or our SPF checker. The total must be 10 or fewer.
2. Send a test message through each service that sends for you, and look for spf=pass in the Authentication-Results header. Our email header analyser reads that header for you.
3. Read your DMARC aggregate reports over the next 24 to 48 hours. Any sender still failing SPF with a PermError needs another look. Reports come from receivers that send them, on days they see your mail, so a quiet day is not proof that nothing was sent.
4. Check your Security Grade, whose checks include SPF staying within 10 lookups.

Why SPF flattening requires ongoing maintenance

The critical caveat with SPF flattening: it is not a one-time fix. When you flatten an SPF record, you capture the IPs that your email providers use today. Email providers routinely add, remove or rotate IP addresses (sometimes weekly) to manage delivery infrastructure, handle growth, or respond to abuse reports.

When a provider adds a new IP range that isn't in your flattened record, legitimate emails sent from that IP will fail SPF. You'll have a window where emails are being marked as spam or rejected before you realise the record is stale.

Best practice: monitor provider change announcements, set a monthly calendar reminder to re-flatten, and use our DMARC monitoring to see SPF failures by sender in the aggregate reports receivers send, usually once a day.

Dynamic SPF and hosted flattening: how it works

The alternative to flattening a record yourself is a hosted SPF service, usually sold as Dynamic SPF. Instead of resolving every include down to static IPs and publishing them in your own zone, you publish a single include: pointing at the provider, and the provider maintains the underlying IP list, updating it as your senders change their infrastructure.

The trade-off is delegation. You stop doing the monthly re-flattening, but your SPF result now depends on a third party's DNS being correct and available. If their zone is wrong, or slow to answer, your mail is affected and the cause is harder to see from your side. Weigh that against how often your senders actually change.

ShieldMarc offers this as Dynamic SPF on the Professional and MSP plans. You publish one include, we keep the record current as your providers change their addresses and inside the 10-lookup limit, and if you ever leave we hand you a record built from your current senders and keep serving ours until your DNS has moved. The trade-off above applies to us as to anyone, so check how much of your mail also carries aligned DKIM before you delegate SPF: that mail keeps passing DMARC whatever happens to SPF.

Will DMARC still pass if SPF fails?

Yes. DMARC requires only one of SPF or DKIM to align. If your DKIM is correctly configured and the signing domain aligns with your From: header, DMARC will pass even when SPF fails. But relying solely on DKIM is fragile. SPF provides an additional layer of protection, and some receiving systems weight SPF failures negatively even when DMARC passes.