SPF 10 DNS Lookup Limit Explained (And How to Fix it)

Understanding SPF record limitations starts with the 10 DNS lookup cap. If your SPF record triggers more than 10 DNS lookups, receiving mail servers return an “SPF PermError: too many DNS lookups,” and DMARC treats that as a hard fail. It results in legitimate emails getting rejected or sent to spam without warning.

This limit comes from RFC 7208, which caps SPF evaluation at 10 DNS-querying mechanisms per check. The challenge is that most domains exceed this limit without realizing it, often due to nested includes and outdated services.

In this guide, you’ll learn what counts toward the limit, why SPF records break silently, and how to fix and prevent lookup failures permanently.

SPF Checker: Check your current lookup count with our free SPF Checker

What is the SPF 10 DNS Lookup Limit?

The SPF specification, defined in RFC 7208, limits each SPF check to a maximum of 10 DNS-querying mechanisms.

In simple terms, every time a receiving mail server evaluates your SPF record and needs to perform an additional DNS query, it counts toward this limit.

These queries are triggered by mechanisms such as:

• include
• a
• mx
• ptr
• exists
• redirect

Once the 11th lookup is required, SPF evaluation stops immediately and returns:

SPF PermError: too many DNS lookups

Each DNS lookup consumes time and resources, like CPU, bandwidth, and memory, on the receiving server. Without a cap, a malicious actor could create an SPF record with deeply nested includes, forcing servers to perform hundreds of DNS queries.

This would effectively turn SPF evaluation into a denial-of-service (DoS) vector.

By enforcing a strict 10-lookup limit, the SPF specification ensures:

• predictable email processing times
• protection against DNS abuse
• stable performance across mail systems 

What Counts Toward the SPF 10 DNS Lookup Limit? 

Not every mechanism in your SPF record triggers a DNS lookup. Knowing what counts, and what doesn’t, is the fastest way to reduce your lookup count.

SPF mechanisms that count vs. don’t count

This is why include: and mx mechanisms are the biggest contributors to SPF failures, especially when they contain nested lookups.

Replacing lookup-heavy mechanisms with direct ip4: or ip6: entries (where possible) is one of the most effective ways to stay within the limit.

Common scenario: MSPs managing multiple client SPF records

Managed Service Providers often struggle with SPF limits when clients use multiple email platforms. A typical MSP client might use Office 365, Mailchimp, Salesforce, and HubSpot—each requiring include statements that can quickly approach the 10-lookup limit.

Why You’re Probably Hitting the SPF Limit (Nested Includes)

Your record might show only three or four include: lines but you’re still hitting the limit. Here’s why.

v=spf1 include:sendgrid.net include:_spf.google.com include:salesforce.com ~all

At first glance, this looks like 3 DNS lookups, but SPF evaluation doesn’t stop there. It follows each include recursively.

Here’s what actually happens:

1. include:sendgrid.net → SendGrid’s SPF record contains 2 additional include: mechanisms → 3 lookups total
2. include:_spf.google.com → Google’s SPF record contains 3 additional mechanisms → 4 lookups total
3. include:salesforce.com → Salesforce’s SPF record contains 3 additional mechanisms → 4 lookups total

Total: 11 DNS lookups

Every include: you add is not just one lookup. It’s one lookup plus however many that third-party’s SPF record requires. This is why the limit is hit much faster than most domain owners expect, especially when using multiple email service providers.

Why the SPF 10 Lookup Limit Exists

The 10 DNS lookup limit might seem restrictive, especially for organizations using multiple email service providers, but it exists for important security and performance reasons that administrators and security teams should understand.

Summary: The lookup limit protects DNS infrastructure from abuse while ensuring timely email processing, but requires careful SPF record management.

Preventing denial-of-service attacks

The limit of 10 additional lookups is imposed to avoid unreasonable load on the DNS and to prevent Denial-of-Service (DoS) attacks.

Without this cap, an attacker could craft an SPF record with hundreds of nested includes, forcing every receiving mail server that processes an email from that domain to perform an enormous number of DNS queries. This could overwhelm DNS servers and degrade performance across the internet.

Ensuring timely email processing

Every DNS lookup during an SPF check adds latency to the email delivery process. If SPF records were allowed unlimited lookups, the time required for SPF verification could grow significantly, leading to DNS query timeouts and temporary DNS server failures.

The 10 lookup limit ensures that SPF checks can be completed quickly and reliably without creating bottlenecks in email delivery.

Maintaining DNS stability

DNS infrastructure is a shared resource. Allowing uncapped lookups during SPF authentication would put excessive strain on recursive resolvers and authoritative nameservers, particularly for high-volume senders.

The limit protects the broader DNS ecosystem by keeping SPF-related query volumes manageable.

What Happens When You Exceed the SPF Lookup Limit

Exceeding the SPF lookup limit doesn’t just result in a minor warning. It causes a hard failure that can directly impact whether your emails reach your recipients’ inboxes.

SPF Evaluation Stops at Lookup 11

SPF is evaluated left-to-right. When the receiving server encounters the 11th DNS-querying mechanism or modifier in your SPF record, it immediately stops processing the record and returns:

SPF PermError: too many DNS lookups

This is a permanent SPF evaluation error, not a soft fail or neutral result. The receiver treats the SPF record as invalid because it cannot complete authentication.

DMARC Treats SPF PermError as an SPF Failure

Once SPF returns a PermError, DMARC interprets it as an SPF fail. If SPF alignment was required for DMARC to pass, the message may fail DMARC authentication entirely.

The outcome then depends on:

• Your DMARC policy (p=none, quarantine, or reject)
• The receiving server’s filtering rules
• Whether DKIM passes and aligns successfully

Emails may be rejected, quarantined, or sent to spam

When SPF fails because of a PermError:

• Some providers may reject the email outright
• Others may route it to spam or quarantine
• Security filters may flag the message as suspicious or unauthenticated

This becomes especially damaging with stricter DMARC policies such as p=quarantine or p=reject.

Microsoft environments are particularly sensitive here. Outlook and Exchange Online aggressively enforce authentication checks, so SPF PermErrors can significantly impact deliverability for organisations sending to Office 365 recipients.

Because SPF is evaluated left-to-right, some sending services may authenticate successfully before the lookup limit is reached, while others fail later in the chain.

That means:

• Some emails appear to deliver normally
• Others fail authentication unexpectedly
• The issue becomes difficult to diagnose without DMARC reporting and SPF analysis tools

This is why SPF lookup limit problems often go unnoticed until deliverability drops or DMARC reports reveal intermittent failures.

Other Causes of SPF PermError

Exceeding the 10 DNS lookup limit is the most common cause of SPF PermError, but it is not the only one. PermErrors can also occur when:

• Multiple SPF records exist for the same domain
• The SPF record contains syntax errors
• Deprecated or unsupported mechanisms are used
• Circular include: statements create infinite lookup loops

Any of these issues can break SPF authentication and negatively affect email deliverability.

Check your DMARC policy to understand your exposure with a DMARC Record Checker

Any of these issues can lead to SPF failure and undelivered emails, so it’s important to validate your entire SPF configuration regularly.

The SPF Void Lookup Limit: The Other Constraint You Might Be Hitting

Most SPF guides stop at the 10 DNS lookup limit but there’s a second constraint in RFC 7208 that can trigger the same failure even if you’re well under 10 lookups: The void lookup limit.

A void lookup is a DNS query that returns no usable result.

This happens when a lookup returns:

• NXDOMAIN (domain does not exist)
• NOERROR with no records (empty response)

RFC 7208 limits SPF evaluation to a maximum of 2 void lookups per check.

If a third void lookup occurs, the receiving server returns:

SPF PermError

This means:

You can trigger an SPF PermError even if your record has fewer than 10 DNS lookups.

That’s what makes void lookups dangerous because they’re harder to detect and often overlooked during SPF audits.

Void lookups usually come from stale or misconfigured SPF entries:

• include: pointing to a domain that no longer has an SPF record
• a or mx mechanisms referencing domains without valid DNS records
• Deprecated or decommissioned email service providers
• Typos in domain names inside SPF mechanisms

Even one outdated include can silently generate a void lookup on every SPF check.

Here’s how the 10-lookup limit and void lookup limit differ:

Both result in the same outcome: SPF PermError.

To prevent void lookup failures:

• Regularly audit your SPF record for outdated include: statements
• Remove services you no longer use
• Validate that all referenced domains return valid DNS records
• Use an SPF checker that flags void lookups, not just total lookup count

PowerDMARC’s SPF checker identifies both total lookups and void lookups, so you can catch these hidden errors before they impact deliverability.

How to Check if Your SPF Record Exceeds the Limit

Identifying whether your SPF record is over the 10 DNS lookup limit is the first step toward fixing deliverability issues. There are several ways to run an SPF record check and verify your current lookup count.

Summary: Regular SPF monitoring using diagnostic tools and manual validation helps prevent lookup limit violations before they impact email delivery.

Use an SPF diagnostic tool

Using an SPF diagnostic tool can help verify that an SPF record is valid and functioning correctly. These tools parse your SPF record, count every DNS lookup including nested includes, and flag any errors or warnings.

PowerDMARC’s free SPF record checker lets you instantly see your total lookup count, identify which mechanisms are consuming the most queries, and spot misconfigurations before they cause delivery problems.

Manually trace your SPF record

If you prefer to inspect your SPF record yourself, you can manually count the DNS lookups by walking through each mechanism in the record.

Start with your domain’s SPF TXT record and count every “include,” “a,” “mx,” “ptr,” “redirect,” and “exists” mechanism. Then, for each “include,” look up the referenced domain’s SPF record and count its lookup-causing mechanisms as well.

Nested includes add up quickly, which is why organizations that use multiple email service providers often exceed the limit without realizing it.

Monitor SPF validation over time

SPF records are not static. As you add or remove email service providers, change hosting environments, or update your email infrastructure, your SPF record changes too. It is recommended to validate SPF records after making changes to ensure compliance with the 10 lookup limit.

Setting up ongoing monitoring through PowerDMARC’s platform gives you continuous visibility into your SPF configuration and alerts you when changes push your record over the limit.

How to Fix and Optimize Your SPF Record

If your SPF record exceeds or is approaching the 10 DNS lookup limit, there are several practical steps you can take to reduce your lookup count without sacrificing email authentication coverage.

Summary: SPF optimization involves removing unused services, replacing lookup-heavy mechanisms with direct IPs, and implementing automated management for complex infrastructures.

Audit your current SPF record and count lookups

Start by analyzing your SPF record using a reliable SPF checker. This helps you identify your total DNS lookup count, including nested includes, and flags issues like void lookups or misconfigurations. It also highlights which mechanisms are consuming the most queries.

Manual counting is possible, but often inaccurate due to recursion within included domains so use a tool wherever possible.

Remove unused or unrequired services

The most straightforward optimization is to audit your SPF record and remove any mechanisms that reference services you no longer use.

Over time, organizations add email service providers, marketing platforms, and third-party tools to their SPF record but forget to remove them when they’re no longer active.

To reduce the number of required lookups, organizations should remove unused services from their SPF record. This also means removing default SPF values that were added during initial setup but serve no current purpose.

Avoid ptr and minimize unnecessary mx usage

The ptr mechanism is strongly discouraged by SPF standards. It performs reverse DNS lookups for each sending IP, making it slow, unreliable, and lookup-heavy. If present, remove it and replace it with direct IP references.

The mx mechanism can also inflate lookup count. It first resolves MX records and then performs additional lookups for each associated mail server. If your infrastructure is stable, replace mx with ip4: or ip6: entries for better efficiency.

Replace lookup-heavy mechanisms with ip4 or ip6

Every “include,” “a,” and “mx” mechanism requires at least one DNS lookup. Where possible, replace these with ip4 or ip6 mechanisms that specify the authorized IP addresses directly. Using ip4 or ip6 mechanisms in SPF records does not require additional lookups and can help maintain compliance with the lookup limit.

For example, if an email service provider’s SPF record resolves to a known set of static IP addresses, you can list those IPs directly rather than using an “include” that triggers multiple DNS lookups.

Use SPF flattening (short-term fix)

SPF flattening replaces include: mechanisms with their resolved IP addresses, reducing DNS lookups to near zero. To quickly bring your record back under the limit, use automated SPF flattening, then validate the updated record before publishing it.

However, it comes with trade-offs. If a provider changes its IP addresses and your record isn’t updated, legitimate emails can fail SPF. Manual flattening requires continuous monitoring and maintenance.

Use Hosted SPF or SPF Macros (permanent fix)

For long-term stability, consider a hosted SPF solution like PowerDMARC. These systems dynamically manage your SPF record using macros or external resolution, ensuring you stay within lookup limits automatically.

This approach eliminates:

• Manual updates when vendor IPs change
• Risks from outdated flattened records
• Ongoing maintenance overhead

It’s especially valuable for organizations using multiple third-party services or managing complex email infrastructures.

Avoid the ptr mechanism

The use of the ptr mechanism is strongly discouraged as it can cause an increase in required lookups, leading to Permerror issues.

The ptr mechanism performs a reverse DNS lookup for every connecting IP, which is both slow and unreliable. The SPF specification itself recommends against using it. If your SPF record currently includes a ptr mechanism, remove it and replace it with direct IP references.

Minimize use of the mx mechanism

Avoiding the MX mechanism in SPF records can help stay within the 10 DNS lookup limit. The mx mechanism first resolves the domain’s MX record and then performs additional lookups to resolve the IP address of each listed mail server.

If your domain has multiple MX records, a single “mx” mechanism can consume several lookups. Replace it with ip4 or ip6 entries for your mail servers where possible.

Consolidate include statements

If your SPF record has multiple “include” mechanisms pointing to related services, check whether they can be consolidated.

Some email service providers share overlapping infrastructure, meaning you may be performing redundant lookups. Review each include to determine whether it’s still necessary and whether the underlying IP addresses can be referenced directly.

Validate after every change

Validating SPF records after making changes is essential to ensure compliance with the 10 lookup limit.

Even a small modification, such as adding a single new “include” for a marketing platform, can push your record over the limit if it triggers nested lookups. Run your record through an SPF diagnostic tool after every update to confirm it remains valid.

SPF Record Flattening: What it is and When to Use it

SPF record flattening is a technique used to optimize SPF records to overcome the 10 DNS lookup limit for SPF. It’s one of the most discussed solutions for organizations with complex email infrastructures, but it comes with trade-offs that are important to understand.

For a full optimization guide on how to optimize your SPF record, read our SPF optimization guide blog

How SPF record flattening works

SPF record flattening replaces lookup-causing mechanisms in an SPF record with their corresponding IP addresses or CIDR ranges, reducing the number of DNS queries required to verify the SPF record.

Instead of including a reference like “include:emailprovider.com” that triggers one or more DNS lookups, you resolve that reference to its underlying IP addresses and list them directly in your record using ip4 or ip6 mechanisms.

For example, if “include:emailprovider.com” resolves to three IP addresses, flattening replaces the include statement with those three ip4 entries. The SPF check now returns the same result without requiring any additional DNS queries for that provider.

When flattening helps

Flattening an SPF record can reduce the number of DNS-querying mechanisms and modifiers so that it’s smaller than 10. This is particularly useful when:

• Your domain sends email through many third-party services and the include count alone exceeds 10
• You’ve already removed unused services and consolidated where possible but are still over the limit
• You need a quick way to bring your record into compliance while planning a longer-term optimization strategy

Why Manual SPF Flattening Is a Temporary Fix

SPF flattening can quickly bring your record under the 10-lookup limit but manually flattening your SPF record is not a long-term solution because it introduces a different set of risks that can break email delivery just as easily.

Risk 1: Vendor IPs change

Most email service providers rotate or expand their sending IP ranges without notice.

When you manually flatten your SPF record:

• you hardcode those IPs into your DNS
• but your provider keeps evolving behind the scenes

The moment their IP list changes, your SPF record becomes outdated and legitimate emails start failing authentication.

Risk 2: SPF record size (255-character + DNS limits)

Flattening replaces includes with multiple IP addresses, which can quickly bloat your SPF record.

This creates two problems:

• DNS TXT records are limited to 255 characters per string
• Overly long SPF records can break parsing or exceed DNS limits

Trying to “fix” lookup limits can accidentally introduce syntax errors or record truncation issues.

Risk 3: No monitoring or visibility

Manual flattening is static. There’s no built-in way to:

• detect when IP ranges change
• track lookup count over time
• alert you to authentication failures

This means problems often go unnoticed until deliverability drops.

Risk 4: Ongoing maintenance burden

Every time you:

• add a new email service
• change infrastructure
• or your provider updates IPs

you need to manually rebuild and validate your SPF record.

For teams managing multiple domains or clients, this quickly becomes unsustainable.

Manual SPF flattening solves the symptom (lookup limit), not the underlying complexity (dynamic infrastructure).

This is where hosted SPF solutions come in.

Instead of hardcoding IPs, platforms like PowerDMARC dynamically manage your SPF record using macros and automated updates so you stay within the lookup limit without constant manual intervention.

Other SPF Record Limitations to Know

The 10 DNS lookup limit is the most well-known SPF limitation, but it’s not the only one. Domain owners should be aware of these additional SPF record limitations to avoid unexpected authentication failures.

Summary: Beyond the 10 lookup limit, SPF has constraints on record count, character limits, void lookups, and forwarding scenarios that affect email authentication.

Only one SPF record per domain

The SPF specification requires that each domain publishes only a single SPF TXT record.

If the SPF record contains multiple SPF records for a domain, it can lead to an SPF PermError, and the receiving server may reject or mishandle the email. If you need to authorize additional senders, add them to your existing SPF record rather than creating a second one.

SPF checks the return-path, not the From address

SPF authenticates the domain in the return-path address, not the human-readable From field that the recipient sees. This means an attacker can spoof the From address while passing SPF by using a different return-path domain.

DMARC addresses this gap by requiring a match or alignment between the human-readable From field domain and the domain authenticated by SPF.

The 255-character string limit

While an SPF record can contain more than 255 characters total, a single DNS TXT record string is limited to 255 characters. Longer SPF records need to be split into multiple strings within the same TXT record.

Most DNS providers handle this automatically, but misconfigured splits can cause parsing errors.

Void lookup limit

In addition to the 10 DNS lookup limit, the SPF specification also limits the number of “void lookups,” which are DNS queries that return no records (either an empty answer or an NXDOMAIN response).

Exceeding this limit, which is typically two void lookups, can also trigger an SPF PermError.

No protection for forwarded emails

When an email is forwarded, the sending IP changes to the forwarding server’s IP, which is unlikely to be listed in the original sender’s SPF record. This can cause the forwarded email to fail SPF checks even when the original message was legitimate.

Best Practices to Stay Within the SPF Lookup Limit

Staying under the SPF 10 DNS lookup limit requires ongoing discipline. Use these best practices to keep your record optimized and prevent unexpected failures:

• Audit your SPF record every time you add or remove a sending platform
• Never publish more than one SPF record per domain
• Avoid the ptr mechanism, remove it if it exists in your record
• Use ip4: and ip6: wherever IP ranges are stable and known
• Set up DMARC reporting to catch intermittent SPF failures early
• Use automated monitoring (like PowerDMARC) to get alerts when your lookup count changes
• Consider Hosted SPF if you manage more than three or four third-party sending services

How PowerDMARC’s Hosted SPF Helps Prevent SPF Lookup Failures 

Manual SPF management breaks down quickly in modern email environments. Every new email platform, marketing tool, CRM, helpdesk, or cloud service can add SPF includes, nested lookups, and maintenance overhead.

Manual SPF flattening can reduce lookup count temporarily, but it creates another problem: keeping hardcoded IPs accurate as vendors update their sending infrastructure.

PowerDMARC’s Hosted SPF, or PowerSPF, addresses the underlying management problem by keeping SPF records updated as your sending infrastructure changes. Unlike static SPF flattening, Hosted SPF dynamically manages your SPF configuration behind the scenes, helping organizations stay aligned with RFC 7208 without constant DNS maintenance.

With PowerSPF, organizations can:

• Automatically update SPF records when vendor IPs change
• Use SPF macros to stay within the 10 DNS lookup limit and DNS character-length limits
• Make a one-time DNS change instead of manually editing SPF records repeatedly
• Manage complex SPF setups across multiple vendors, nested includes, regional infrastructure, and enterprise domains
• Monitor SPF failures, void lookups, and authentication issues before they affect deliverability

This is especially valuable for organizations using platforms like Microsoft 365, Salesforce, HubSpot, SendGrid, Mailchimp, and other third-party senders simultaneously, where nested includes can silently push SPF records beyond RFC limits.

With automated SPF flattening, real-time lookup monitoring, error alerts, and tools for SPF, DKIM, DMARC, and BIMI, PowerDMARC helps organizations keep SPF records within the lookup limit and maintain a cleaner authentication setup.

To start, check your SPF lookup count with PowerDMARC’s SPF Checker and identify issues before they affect email authentication.

Frequently Asked Questions

1. What is the SPF 10 DNS lookup limit?

The SPF specification, defined in RFC 7208, limits each SPF check to a maximum of 10 DNS-querying mechanisms.

If your SPF record requires more than 10 lookups during evaluation, the receiving server returns an SPF PermError, which is treated as a failure by DMARC. This can cause legitimate emails to be rejected or sent to spam.

2. Which SPF mechanisms count toward the 10-lookup limit?

The following mechanisms trigger DNS lookups and count toward the limit:

• include
• a
• mx
• ptr
• exists
• redirect=

These do not count:

• ip4, ip6 (direct IPs)
• all (catch-all)
• v=spf1 (version tag)
• The initial DNS query to retrieve your SPF record

3. What is an SPF PermError?

An SPF PermError (permanent error) occurs when a receiving server cannot properly evaluate your SPF record.

The most common cause is exceeding the 10 DNS lookup limit, but it can also happen due to:

• syntax errors
• multiple SPF records
• void lookup limit violations
• circular includes

When this happens, SPF fails completely and may impact email delivery.

4. What is the SPF void lookup limit?

In addition to the 10-lookup limit, RFC 7208 also restricts void lookups, DNS queries that return no result (NXDOMAIN or empty responses).

The limit is 2 void lookups per SPF check.

If your SPF record triggers a third void lookup, the receiving server returns a PermError even if your total lookup count is under 10.

5. Does SPF flattening fix the 10-lookup limit?

Yes but only temporarily.

SPF flattening replaces include mechanisms with direct IP addresses, reducing DNS lookups. However, it requires constant maintenance because email service providers frequently update their IP ranges.

If your flattened record becomes outdated, legitimate emails can fail SPF checks.

6. How do I check how many DNS lookups my SPF record uses?

You can use an SPF checker tool to analyze your record and count DNS lookups, including nested includes.

PowerDMARC’s SPF checker shows:

• total lookup count
• void lookup count
• which mechanisms are consuming lookups

This helps you identify issues before they impact deliverability.

7. What is the difference between SPF flattening and SPF macros?

SPF flattening statically replaces includes with IP addresses, reducing lookup count but requiring manual updates.

SPF macros (used in hosted SPF solutions) dynamically resolve SPF records during evaluation, allowing you to stay within lookup limits without maintaining IP lists manually.

Macros are more scalable and better suited for complex or multi-vendor email setups.

8. How often should I review my SPF record?

You should review your SPF record:

• whenever you add or remove an email service
• after infrastructure changes
• at least once a month

For complex setups, continuous monitoring is recommended to catch lookup limit issues early and maintain consistent deliverability.

• About
• Latest Posts

Ahona Rudra

Domain & Email Security Expert at PowerDMARC

Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.

Latest posts by Ahona Rudra (see all)

• How MSPs Can Manage Every Client’s DMARC Faster With PowerDMARC’s MCP Server - May 25, 2026
• How to Add an IP Address to Your SPF Record (Step-by-Step Guide) - May 11, 2026
• Avanan SPF Record: How to Set Up, Fix, and Optimize Your SPF for Check Point Harmony Email - May 7, 2026