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 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 shows you each record to publish, sub-records first and the root record last. 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 that contains only ip4: and ip6: entries, with no DNS lookups required at delivery time.

The SPF 10 lookup limit (PermError)

RFC 7208 §4.6.4 states that SPF evaluation must abort after 10 DNS lookups. 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.

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 catch SPF failures as they happen.

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 does not offer a hosted SPF service today. A Dynamic SPF feature is planned for the MSP plan, and this section will be updated when it is available. Until then the realistic options are the ones described above: re-flatten on a schedule yourself, or use an established third-party provider.

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.