SPF Flattening: How to Fix the 10-Lookup Limit and Stop SPF Failures

If your business uses more than two email platforms, say, Google Workspace for internal mail and Mailchimp for campaigns, there is a strong chance your SPF record is silently failing authentication. The culprit is almost always the SPF 10-lookup limit: a hard ceiling built into the SPF specification that causes authentication errors the moment your record requires more than ten DNS queries to resolve.

This guide, written by the HasheTools team, explains exactly what SPF flattening is, why the lookup limit exists, how exceeding it breaks your email delivery, and most importantly, how to fix it permanently. We also cover the risks of naïve flattening and how dynamic flattening tools solve the maintenance problem that catches most teams off guard.

What is SPF, and why does it matter?

SPF (Sender Policy Framework) is an email authentication standard defined in RFC 7208. It allows a domain owner to publish a list of IP addresses and mail servers that are authorised to send email on behalf of that domain. When a receiving mail server gets a message claiming to be from your domain, it checks your SPF record in DNS to verify whether the sending IP is on your approved list.

Without a valid SPF record, your domain is an open target for email spoofing and phishing attacks. Worse, major email providers like Gmail and Outlook use SPF results as one of the primary signals for spam filtering; a failing SPF record sends your legitimate marketing emails straight to the junk folder.

A basic SPF record looks like this:

The v=spf1 tag identifies this as an SPF record. The include: mechanisms tell receiving servers to also check the SPF records of the listed domains. The -all at the end means: reject any mail that doesn’t match the above.

The SPF 10-lookup limit: what it is and why it exists

The SPF specification imposes a hard limit of ten DNS lookups during SPF record evaluation. This limit exists for a practical reason: every DNS query adds latency to the email authentication process. If a single SPF check could trigger dozens of recursive lookups, it would slow down mail servers and open a potential vector for denial-of-service attacks against DNS infrastructure.

The following SPF mechanisms each count as one lookup toward the limit:

• include: fetches another domain’s SPF record
• a: resolves a domain’s A/AAAA records
• mx: resolves a domain’s MX records
• exists: checks whether a domain exists in DNS
• redirect= redirects evaluation to another SPF record (counts as one lookup)

Crucially, lookups are recursive: when you include _ spf.google.com, that record itself may include further domains, each adding to your count. There is also a void lookup limit of two DNS queries that return no results (NXDOMAIN or empty responses), which are capped at just two before authentication fails with a PermError.

Why modern SPF records exceed the lookup limit

A decade ago, most organisations sent all their email through a single provider. Today, the average mid-sized business uses five or more email platforms simultaneously. Each platform requires its own include statement, and most of those platforms have complex SPF records of their own with multiple nested lookups.

Consider a common setup:

None of the above services is an unusual choice. Yet together they breach the limit before you’ve added your transactional email provider, your CRM, or your customer support tool. The problem isn’t any one platform; it’s the compounding effect of a modern multi-vendor email stack.

What is SPF flattening?

SPF flattening is the process of resolving all include: mechanisms and nested SPF records down to their underlying IP addresses, then replacing the include: chains with direct ip4: and ip6: entries. Because IP address references require zero DNS lookups to validate, a fully flattened SPF record can stay well within the 10-lookup limit regardless of how many email providers you use.

Before flattening

After flattening

The result is functionally identical; the same IP ranges are authorised, but the authentication process now completes in a single DNS query instead of eight or more.

How SPF flattening works step by step

Whether you use a tool or do it manually, the flattening process follows the same logic:

1. Retrieve your current SPF record from your DNS zone (query your domain’s TXT records).
2. Recursively resolve each include: mechanism. For example, resolving _ spf.google.com reveals further includes, which resolve to CIDR IP ranges.
3. Collect all resulting IP addresses across every include chain, both IPv4 (ip4:) and IPv6 (ip6:) ranges.
4. Deduplicate and consolidate overlapping or adjacent CIDR ranges where possible to reduce record length.
5. Write the new TXT record using only ip4:/ip6: entries plus your termination qualifier (-all, ~all, etc.).
6. Publish and test the new record using an SPF validator tool before removing the old one.

The risks of static SPF flattening and how to avoid them

Flattening sounds simple, but there is a critical problem with the naive approach: the IP addresses belonging to providers like Google, SendGrid, and Microsoft change regularly. When SendGrid adds a new sending range, your static flattened record won’t include it, and legitimate emails sent through that new IP will fail SPF authentication.

Static flattening risks

• IP drift: Providers rotate or expand their sending IP ranges without notifying customers.
• Record length: A fully flattened enterprise record can exceed 255 characters (the DNS TXT record string limit) or 512 bytes (the UDP DNS response limit). This requires careful CIDR aggregation or record splitting.
• Maintenance burden: Manual re-flattening every time a provider changes IPs is tedious and error-prone.

Dynamic SPF flattening: the better solution

Dynamic SPF flattening tools solve the maintenance problem by automating the entire process. Instead of publishing IP addresses directly in your TXT record, they give you a managed include statement that points to their DNS infrastructure. Their system continuously monitors your providers for IP changes and updates the underlying resolution automatically.

Your SPF record becomes something like:

This gives you the deliverability benefits of flattening with none of the maintenance risk.

SPF flattening tools: a practical comparison

Choosing the right tool depends on whether you need a simple one-time fix or ongoing automated management. Here is how the leading options compare:

For most organisations sending more than 10,000 emails per month, a dynamic flattening tool is worth the investment. The cost of a single deliverability incident, lost revenue, and damaged sender reputation typically exceeds a year of tool subscription fees.

Common SPF errors explained

SPF PermError: too many DNS lookups

The most common error. Exceeding ten lookups during SPF evaluation causes a permanent failure. It cannot be retried; the message is treated as definitively unauthenticated. Fix: flatten your record or reduce the number of include mechanisms.

SPF SoftFail (~all)

The sending IP is not listed as authorised, but the domain owner has not issued a hard rejection. Receiving servers may accept the message but mark it as suspicious. If your record ends in ~all instead of -all, a softfail will not block delivery but will hurt your sender’s reputation over time.

SPF HardFail (-all)

The sending IP is explicitly not authorised. Combined with a strict DMARC policy (p=reject), this causes outright rejection of the message. This is the correct configuration once your SPF record is fully validated.

SPF None

No SPF record was found for the domain. This is treated as authentication, not a missed opportunity, but rather a failure, which means the domain does not protect against spoofing.

Multiple SPF records

A domain must have exactly one SPF TXT record. If you have two (a common mistake when migrating providers), SPF validation returns PermError. Delete the old record when publishing a new one.

How to fix SPF failures: a step-by-step process

1. Check your current record. Use the HasheTools SPF Checker (hashetools.com) or Google’s Admin Toolbox to retrieve your current record and count the actual number of DNS lookups it triggers.
2. Identify which includes are driving the count. Most tools will show a recursive tree of lookups. Find the deepest chains; these are your main targets for flattening.
3. Remove redundant or outdated includes. Do you still use every service in your SPF record? Old CRMs, discontinued email tools, and deprecated IP ranges are common culprits. Audit each include against your current email stack.
4. Consolidate where possible. If you’re using both Outlook and Microsoft 365, you may only need one include. Check for overlapping ranges.
5. Choose a flattening approach. Manual one-time flattening for simple setups; a dynamic flattening tool for any organisation with three or more active email providers.
6. Publish the new record and test. Use an SPF validator to confirm the lookup count is below 10 and that all expected IPs are covered. Send test emails through each of your email platforms.
7. Monitor. Set a reminder to re-audit your SPF record quarterly, or use a dynamic tool with automated alerting.

SPF vs DKIM vs DMARC: how they work together

SPF alone is not sufficient for complete email security. It is one layer of a three-part authentication stack. Understanding how each protocol contributes helps you configure them correctly and interpret failures accurately.

DMARC is the enforcement layer that ties SPF and DKIM together. Even if your SPF record is perfectly flattened, a p=none DMARC policy means failures have no consequence. Work toward quarantine and eventually reject once you are confident your SPF and DKIM configurations are solid.

SPF record best practices

• One record per domain. Never publish two SPF TXT records. Merge everything into a single record.
• End with -all, not ~all. SoftFail provides false security. Once your configuration is verified, use a hard fail qualifier.
• Monitor for provider IP changes. At a minimum, check your main providers’ SPF records every quarter. Better yet, use a dynamic flattening tool.
• Test after every DNS change. Any DNS update, even unrelated to SPF, warrants a re-check of your SPF lookup count.
• Document your email stack. Keep a record of every service authorised to send email on your domain, with the corresponding include: mechanism and the person responsible for it.
• Don’t include providers you no longer use. Every legacy includes a security risk and a wasted lookup.
• Align SPF with DMARC. Ensure the domain in your SPF record’s envelope sender aligns with your From: header domain, or DMARC will still fail even if SPF passes.

How SPF flattening improves email deliverability

Email deliverability is ultimately about sender reputation. Gmail, Outlook, Yahoo Mail, and other major providers evaluate every inbound message against a set of signals, and authentication results sit near the top of that list.

A correctly configured, flattened SPF record contributes to deliverability in several concrete ways:

• Eliminates authentication errors that trigger spam filters regardless of content quality.
• Strengthens your DMARC pass rate, which feeds directly into sender reputation scoring at major inbox providers.
• Reduces soft bounces caused by SPF failures on messages that should have been delivered.
• Protects your domain reputation by preventing spoofed emails (which would fail your strict SPF) from damaging how providers perceive your domain.

For transactional emails, especially password resets, order confirmations, and account notifications, a deliverability failure is not just a metric problem. It has a direct impact on user experience and business continuity.

Frequently asked questions

What is SPF flattening?

SPF flattening is the process of converting SPF include: mechanisms into direct IP address entries (ip4:/ip6:). This eliminates recursive DNS lookups and keeps the SPF record within the 10-lookup limit required by the SPF specification (RFC 7208).

What exactly counts toward the 10-lookup limit?

The following mechanisms each count as one lookup: include:, a:, mx:, exists:, and redirect=. The ptr: mechanism also triggers lookups, but is deprecated and should never be used. IP4: and IP6: entries do not trigger any DNS lookups and therefore do not count.

Can SPF flattening break my email delivery?

Yes, if done incorrectly. Static flattening that is not kept up to date will break delivery when email providers change their sending IPs. The solution is either to use a dynamic flattening tool that automatically updates or to schedule regular audits (at least quarterly) if managing the record manually.

My SPF record has only 8 includes. Am I safe?

Not necessarily. The count is on DNS lookups, not including statements. A single include can trigger three or four additional lookups through its own nested includes. Use the HasheTools SPF Checker (hashetools.com), which counts actual recursive lookups, not just surface-level mechanisms.

Do I need both SPF and DKIM?

Yes. DMARC requires at least one of SPF or DKIM to pass, but best practice is to have both configured correctly. DKIM is particularly important because it survives email forwarding (where SPF often fails), and it verifies message content integrity in a way SPF cannot.

How often should I audit my SPF record?

At a minimum, every quarter, or immediately after adding or removing any email service from your stack. Major providers (Google, Microsoft, Twilio/SendGrid) update their sending infrastructure periodically. If you use a dynamic flattening tool, it handles this automatically.

What is the difference between SPF SoftFail and HardFail?

SoftFail (~all) means the domain owner believes the sending IP is not authorised, but has not issued a hard rejection; receiving servers may still accept the message. HardFail (-all) is a firm declaration that the IP is not authorised, and combined with DMARC p=reject, it causes outright message rejection.

Conclusion

SPF flattening is an essential solution for fixing the 10 DNS lookup limit and preventing SPF authentication failures in modern email systems. As businesses use multiple email platforms like Google Workspace, Microsoft 365, Mailchimp, and SendGrid, SPF records often become complex and exceed the allowed lookup limit, leading to delivery issues and PermError failures.

By flattening your SPF record, you reduce DNS lookups, improve email deliverability, and ensure your messages consistently reach inboxes instead of spam folders. It also strengthens your overall email authentication setup when combined with DKIM and DMARC.

For long-term reliability, especially in dynamic email environments, using an SPF flattening tool or automated solution like HasheTools helps keep your records optimized and up to date.

In short, SPF flattening is not just a fix; it’s a best practice for maintaining secure, stable, and high-performing email delivery.