Solving the SPF 10-Lookup Limit: A technical guide for MSPs

Executive summary Every domain's SPF record is capped at 10 DNS lookups — a constraint set in 2006 that hasn't kept pace with the modern SaaS stack. For MSPs managing dozens of client domains, each running its own mix of email, marketing, billing, and support tools, breaching the limit is almost inevitable. When it happens, legitimate email silently fails authentication, DMARC alignment breaks, and support tickets start piling up. This guide walks MSPs through the mechanics of the lookup limit, how to audit client domains at scale, why traditional fixes like flattening and subdomain delegation fall short, and how Dynamic SPF eliminates the constraint entirely — turning SPF management from a reactive firefight into an automated, scalable service.

Key takeaways

• Each SPF include, a, mx, redirect, exists, and ptr mechanism counts toward the 10-lookup cap — and nested includes within third-party records consume hidden lookups that are easy to miss during manual review.
• A typical mid-market client using seven or more SaaS tools is already at or near the threshold, meaning a single new service addition can trigger PermError and break deliverability without warning.
• Google and Microsoft now explicitly enforce SPF compliance for high-volume senders, making the lookup limit a deliverability requirement rather than a best-practice recommendation.
• SPF flattening creates a maintenance liability because cloud providers rotate sending IPs regularly, causing flattened records to go stale across a portfolio
• Dynamic SPF consolidates all authorised senders into a single, auto-updating include that stays under the limit regardless of how many services a client runs.
• MSPs should audit every client domain on onboarding, flag anything at 8+ lookups as at-risk, and treat SPF resolution as the gateway to moving clients from DMARC monitoring to full enforcement.

A client adds HubSpot to their marketing stack. A week later, their CFO's invoices start landing in spam. The support ticket comes in, and the root cause turns out to be something that never appeared on any onboarding checklist: the client's SPF record just exceeded its tenth DNS lookup, triggering a permanent authentication failure that no amount of inbox troubleshooting will fix. For MSPs managing dozens of client domains, each running its own mix of email services, CRM platforms, and support tools, this scenario plays out with increasing frequency. 

Platforms like Red Sift OnDMARC address the problem through Dynamic SPF, which eliminates the lookup limit constraint entirely. But understanding why the limit exists, how it breaks, and what traditional workarounds get wrong is essential knowledge for any MSP building a DMARC practice.

This guide explains the SPF 10-lookup limit in practical terms, walks through the common workarounds and their shortcomings, and covers the automated approaches that let MSPs scale email authentication across client portfolios without hitting this wall.

• What the SPF 10-lookup limit actually means
• Why MSPs hit the limit more often than anyone else
• How to audit a client's SPF record
• Traditional workarounds and why they fail
• Dynamic SPF: the automated solution
• Building an SPF management workflow for your MSP
• FAQ

SPF (Sender Policy Framework) lets domain owners declare which mail servers are authorised to send email on their behalf. Receiving servers check the SPF record for the sender's domain and verify whether the originating IP address is permitted. The protocol works, but it carries a hard constraint defined in RFC 7208: an SPF evaluation must not require more than 10 mechanisms or modifiers that trigger additional DNS lookups [1].

The limit exists to protect DNS infrastructure. Without it, a malformed or malicious SPF record could trigger unbounded chains of DNS queries, consuming receiver resources and creating denial-of-service conditions. The cap keeps evaluation predictable and bounded.

A critical nuance: the limit counts the number of mechanisms that require lookups, not the total number of DNS queries generated [2]. An mx mechanism counts as one toward the limit, even though it may trigger multiple follow-up queries to resolve each mail server's address. This distinction matters when optimising records, because replacing mx with ip4 entries saves one lookup regardless of how many MX records the domain has.

When a receiving server exceeds the 10-lookup threshold during evaluation, it returns PermError, a permanent SPF failure. The consequence depends on the receiver's configuration: some reject the message outright, others route it to spam, and some treat it as a neutral result. In all cases, DMARC alignment breaks if SPF was the sole passing mechanism, which can trigger quarantine or reject policies downstream.

The SPF lookup limit was defined in 2006 and codified in RFC 7208 in 2014, when a typical organisation might use one or two email-sending services. The modern SaaS landscape looks very different. A single mid-market client can easily require SPF includes for:

• Email platform (Google Workspace or Microsoft 365)
• Marketing automation (HubSpot, Marketo, or Mailchimp)
• CRM system (Salesforce)
• Support desk (Zendesk or Freshdesk)
• Billing and invoicing (QuickBooks, Xero)
• HR and recruiting (Greenhouse, BambooHR)
• Transactional email (SendGrid or Amazon SES)

Each of these services typically requires its own include mechanism in the domain's SPF record. Seven services means seven lookups before counting the domain's own a or mx mechanisms. Add a single additional tool, and the record crosses the threshold.

For MSPs, the problem compounds because every client domain presents its own version of this challenge. A portfolio of 30 client domains means 30 different SaaS combinations, 30 SPF records to monitor, and 30 potential breakage points. The moment a client's IT team or marketing department adds a new service without consulting the MSP, the SPF record can silently exceed its limit. Emails start failing intermittently (because PermError only triggers when evaluation reaches the 11th lookup, and not every receiver evaluates all mechanisms for every message), making the problem difficult to detect and reproduce.

Google now requires SPF compliance for organisations sending more than 5,000 emails daily [3], and Microsoft has introduced similar requirements with explicit guidance to keep SPF within the 10-lookup limit [4]. For MSPs, bulk sender compliance is no longer optional for any client running email campaigns at scale.

Before fixing the problem, MSPs need to quantify it. A systematic audit identifies how many lookups a client's SPF record currently requires and where the excess originates.

Step-by-step audit process:

1. Query the SPF record using a tool like Red Sift's SPF Checker or a command-line DNS query (dig TXT example.com) to retrieve the raw record
2. Map the include chain by expanding each include mechanism recursively. Each include adds one lookup, and the included record may contain further nested includes
3. Count all lookup-generating mechanisms including include, a, mx, redirect, exists, and ptr
4. Identify unused services by cross-referencing SPF includes against the client's actual email-sending infrastructure. Dormant services that no longer send email still consume lookups
5. Document the current count and flag any domain at 8 or more lookups as at risk (two new services away from breakage)
6. Check for nested depth because some third-party SPF records themselves contain multiple nested includes. A single include:thirdparty.com might consume three or four lookups once fully expanded

Running this audit across an entire client portfolio reveals the scale of the problem. Most MSPs find that a significant portion of client domains are either over the limit or within one service addition of exceeding it.

MSPs encountering the 10-lookup limit for the first time typically reach for one of several common workarounds. Each has limitations that make it unsuitable for production use at scale.

Flattening replaces include mechanisms with their resolved IP addresses (ip4 and ip6 entries), reducing the lookup count to zero for those services. The approach works in theory but fails in practice because cloud email providers rotate their sending IP addresses regularly. When a provider like Google adds new sending infrastructure, the flattened record becomes stale, and legitimate email starts failing authentication.

Manual flattening requires the MSP to monitor every provider's IP ranges and update DNS records whenever changes occur. Across a portfolio of 30 client domains, each with different providers, this maintenance burden becomes unsustainable. A single missed IP rotation can cause widespread deliverability failures.

Publishing more than one SPF TXT record for a domain violates the SPF specification [1]. Receivers encountering multiple records are required to return PermError, which means this approach actively breaks authentication rather than solving the limit.

Moving different email services to separate subdomains (marketing.example.com, support.example.com) distributes SPF lookups across multiple records. This reduces the count per subdomain but introduces complexity in DMARC alignment, requires careful Return-Path configuration, and creates operational overhead that scales poorly across many client domains.

Some MSPs discover that not all receivers enforce the 10-lookup limit strictly. This leads to a "it seems to work" approach where the over-limit record stays in place. The risk is that enforcement behaviour varies across receivers and can change without notice. Both Google and Microsoft explicitly reference SPF compliance in their bulk sender requirements, meaning this approach carries increasing deliverability risk.

Dynamic SPF takes a fundamentally different approach to the lookup limit. Rather than working within the 10-lookup constraint through manual record management, Dynamic SPF consolidates all authorised sending sources into a single, automatically maintained include that stays under the threshold.

How it works:

1. Continuous monitoring: the platform tracks IP address ranges for all authorised email-sending services (Google Workspace, Microsoft 365, Salesforce, HubSpot, and others) in real time
2. Intelligent consolidation: domain-based include mechanisms are resolved to their current IP addresses and combined into a single optimised record
3. Automatic updates: when a provider changes its sending infrastructure, the Dynamic SPF record updates within minutes, with no manual DNS intervention required
4. Single include: the client's SPF record references one Dynamic SPF include, consuming a single lookup regardless of how many underlying services are authorised

The result is that MSPs can add new email services to client domains without worrying about the lookup count. A client with fifteen sending services uses the same single lookup as a client with three. The technical barrier that previously blocked DMARC enforcement disappears.

For MSPs evaluating DMARC platforms, Dynamic SPF capability should be a core selection criterion. The SPF, DKIM, and DMARC protocol differences matter, but the practical question is whether the platform can handle the lookup limit at scale across a diverse client portfolio.

Solving the SPF lookup limit for one client domain is straightforward. Solving it across an entire portfolio requires a repeatable process.

Recommended MSP workflow:

1. Portfolio audit: run SPF lookup counts across all client domains during onboarding. Flag every domain at 8+ lookups as at risk
2. Prioritise by impact: address domains actively exceeding the limit first, then those at risk. Clients with DMARC at p=quarantine or p=reject are highest priority because SPF failures directly impact delivery
3. Deploy Dynamic SPF: migrate client domains to a platform with Dynamic SPF management. Red Sift's MSP partner programme provides multi-tenant infrastructure designed for service providers managing many domains simultaneously
4. Establish change control: create a process that requires email-sending service additions to go through the MSP. This prevents client teams from adding SaaS tools that would have previously broken SPF
5. Monitor continuously: use automated alerting to detect new sending sources, configuration drift, and any SPF evaluation failures across the portfolio
6. Report to clients: include SPF health metrics in regular client reporting. Authentication pass rates, sender inventory changes, and lookup utilisation demonstrate ongoing value

MSPs that standardise this workflow reduce the per-domain cost of SPF management significantly. The initial audit and migration require effort, but ongoing maintenance becomes automated rather than reactive.

SPF management fits naturally within tiered DMARC service packages. The lookup limit is often the specific technical obstacle preventing clients from progressing beyond monitoring (p=none) to enforcement (p=reject). Addressing SPF breakage across the portfolio unlocks the path to full enforcement, which represents the highest-value tier of managed email authentication services.

[1] Kitterman, S. "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1." IETF RFC 7208, 2014. https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4

[2] Mailhardener. "The SPF lookup limit explained." Mailhardener Blog, 2024. https://www.mailhardener.com/blog/spf-lookup-limit-explained

[3] Google. "Email sender guidelines." Google Workspace Admin Help, 2024. https://support.google.com/a/answer/81126

[4] Microsoft Defender for Office 365 Team. "Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders." Microsoft Tech Community, 2025. https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730

The receiving mail server returns PermError, a permanent SPF failure. Depending on the receiver's policy and the domain's DMARC configuration, this can cause messages to be rejected, quarantined to spam, or treated as unauthenticated. The failure is intermittent because it only triggers when evaluation actually reaches the 11th lookup, which varies by message and receiver.

Flattening replaces include mechanisms with static IP addresses, which reduces lookups but creates a maintenance burden. Cloud providers rotate sending IPs regularly, meaning flattened records become stale and cause authentication failures. For a single domain this might be manageable, but across a portfolio of client domains with different providers, manual flattening does not scale.

Dynamic SPF automates the consolidation and maintenance process. The platform continuously monitors provider IP ranges and updates the SPF record automatically when changes occur. Traditional flattening is a point-in-time snapshot that requires manual updates, while Dynamic SPF provides ongoing, real-time accuracy with no intervention required.

Google requires SPF compliance for bulk senders exceeding 5,000 daily messages [3]. Microsoft explicitly states that senders should keep SPF within the 10-lookup limit as part of their high-volume sender requirements [4]. Both platforms apply progressively stricter filtering to non-compliant messages.

Start with domains actively exceeding the limit (currently returning PermError), then address domains at 8-9 lookups (one service addition from breakage). Within those groups, prioritise clients with DMARC enforcement policies (p=quarantine or p=reject) because SPF failures have immediate deliverability consequences for those domains.