SPF 'Too Many DNS Lookups' Error: What It Means and How to Fix It

What Is the SPF 10 DNS Lookup Limit?

If you've ever tried to add a new email service to your domain's SPF record and hit the error "too many DNS lookups", you've run into one of the most common — and most frustrating — email authentication problems.

The SPF specification (RFC 7208) limits each SPF record to a maximum of 10 DNS lookups. Exceed this limit and your entire SPF record becomes invalid — resulting in a permerror that provides zero SPF protection for your domain.

This article explains why the limit exists, what causes you to exceed it, and how to fix it permanently.

Why Does the 10 Lookup Limit Exist?

The limit exists to prevent denial-of-service attacks and excessive DNS load. When a receiving mail server processes an incoming email, it queries the sender's SPF record. Each include:, a:, mx:, and redirect= mechanism requires an additional DNS query.

Without a limit, a malicious actor could craft an SPF record that forces receiving servers to make hundreds of DNS queries per email, effectively weaponising email delivery into a DDoS attack on DNS infrastructure.

The 10-lookup cap is a trade-off: enough flexibility for most legitimate configurations, while preventing abuse.

What Happens When You Exceed the Limit?

When your SPF record requires more than 10 DNS lookups, the receiving server returns a permerror (permanent error). This is not a soft failure — it means:

• Your SPF record is treated as completely invalid
• SPF provides no protection for your domain
• DMARC alignment via SPF always fails
• Your emails are more likely to land in spam or be rejected

In other words, exceeding the 10-lookup limit is worse than having no SPF record at all, because it actively generates authentication failures.

What Counts as a DNS Lookup?

Not every mechanism in your SPF record uses a lookup. Here's what counts and what doesn't:

Mechanisms That Use DNS Lookups (Each = 1 Lookup)

• include:example.com — and any nested includes within that record also count
• a: — resolves a hostname to IP addresses
• mx: — resolves MX records, then the hostnames they point to
• redirect= — redirects SPF processing to another domain
• exists: — checks if a DNS record exists

Mechanisms That Don't Use DNS Lookups

• ip4:203.0.113.0/24 — IP address ranges are checked directly
• ip6:2001:db8::/32 — IPv6 ranges likewise
• all — the catch-all mechanism at the end

The Nested Lookup Problem

The lookup count includes nested includes. If your SPF record includes include:_spf.google.com, that's 1 lookup. But _spf.google.com itself includes references to _netblocks.google.com, _netblocks2.google.com, and _netblocks3.google.com — that's 3 more lookups. So a single Google Workspace include actually costs you 4 lookups.

Microsoft 365 is similarly expensive: include:spf.protection.outlook.com typically costs 2–3 lookups when nested records are counted.

Common Causes of Exceeding the Limit

The typical scenario: a business uses multiple email-sending services, and each one requires an include: in the SPF record.

Here's a realistic example for a mid-sized Australian business:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.mailchimp.com include:mail.zendesk.com include:spf.freshdesk.com ~all

Counting lookups:

• Google Workspace: 4 lookups (1 + 3 nested)
• Microsoft 365: 2 lookups (1 + 1 nested)
• SendGrid: 1 lookup
• Mailchimp: 1 lookup
• Zendesk: 2 lookups (1 + 1 nested)
• Freshdesk: 1 lookup

Total: 11 lookups — over the limit. And this is a modest configuration. Businesses with more services can easily hit 15–20 lookups.

How to Fix SPF Lookup Limit Issues

Option 1: Remove Unused Services

Start by auditing which services are actually sending email from your domain. It's common to find includes for services you no longer use — an old marketing platform, a decommissioned helpdesk, or a testing service that was never removed.

DMARC reports are the best tool for this audit. They show you exactly which services are sending email as your domain, so you can remove includes for services that show zero volume.

Option 2: Replace Includes with IP Addresses

For services that send from a small, static set of IP addresses, you can replace the include: mechanism with ip4: entries. This eliminates the DNS lookup entirely.

However, this approach is fragile. If the service changes its IP addresses — which cloud providers do regularly — your SPF record becomes incorrect, and emails from that service will fail authentication. You'd need to manually monitor and update IP addresses, which is impractical at scale.

Option 3: SPF Flattening

SPF flattening resolves all include: directives down to their underlying IP addresses and replaces the includes with ip4: and ip6: entries. This can dramatically reduce lookup counts.

The problem: manual flattening has the same fragility issue as Option 2. IP addresses change, and if you don't re-flatten regularly, your SPF record becomes stale.

Option 4: SPF Delegation (Recommended)

The most robust solution is SPF delegation. Instead of managing a single, monolithic SPF record, you delegate SPF management to a subdomain:

v=spf1 include:_spf.yourdomain.com ~all

The _spf subdomain then contains your actual SPF mechanisms, managed automatically. This is the approach DMARC Busta uses — your root SPF record stays simple (1 lookup), and the delegated record handles the complexity.

How DMARC Busta Solves This Permanently

DMARC Busta takes a fundamentally different approach to SPF management:

• SPF delegation — your domain's SPF record points to a managed subdomain, keeping your root record at just 1 lookup
• Automatic IP consolidation — when individual IPs belong to known email services, they're automatically consolidated into efficient include directives
• AI-powered source management — DMARC reports are analysed automatically to identify and authenticate legitimate sending services
• Continuous optimisation — as services are added or removed, the managed SPF record is regenerated automatically
• DNS lookup monitoring — Autopilot ensures your SPF record never exceeds the 10-lookup limit

The result: you never have to think about SPF lookup limits again. Add a new email service, and DMARC Busta detects it from DMARC reports and handles the SPF configuration automatically.

Real-World Example: An Australian Business With Too Many Services

Consider a typical mid-sized Australian business using the following email services:

• Google Workspace for staff email (4 lookups)
• Xero for invoicing (1 lookup)
• HubSpot for marketing emails (1 lookup)
• Zendesk for customer support (2 lookups)
• SendGrid for transactional emails (1 lookup)
• Salesforce for CRM notifications (2 lookups)

That's 11 lookups — already over the limit. And they haven't even added their web hosting server or any additional services.

Before DMARC Busta, this business would need to choose between removing services from SPF (leaving those emails unauthenticated) or manually flattening IP addresses (fragile and high-maintenance). With SPF delegation, all services are managed automatically under the 10-lookup limit.

The Danger of Ignoring SPF Errors

Some businesses see an SPF permerror in their DMARC reports and assume it's a minor issue. It isn't. When your SPF record exceeds 10 lookups:

• Every email fails SPF — not just some, all of them. The entire record is invalid.
• DMARC alignment via SPF fails — if you're relying on SPF for DMARC alignment (which many businesses do), DMARC also fails.
• Deliverability degrades — Google, Yahoo, and Microsoft all factor authentication results into spam filtering. Consistent SPF failures push your domain toward spam.
• You lose visibility — without working SPF, you can't distinguish between legitimate email that fails SPF and spoofed email that fails SPF. Everything fails.

The fix doesn't have to be complicated, but it does need to be done. Start by scanning your domain to see your current lookup count and identify which mechanisms are using the most lookups.

How to Audit Your Current SPF Lookups

Before making changes, it's worth understanding your current situation:

1. Scan your domain with DMARC Busta's free scanner — it counts your DNS lookups and flags if you're over the limit
2. Identify each include — list every include: mechanism in your SPF record
3. Count nested lookups — each include may have its own includes, which all count toward your 10-lookup limit
4. Cross-reference with DMARC reports — identify which services are actually sending email and which includes are unused

Frequently Asked Questions

Does the 10-lookup limit apply to ip4: and ip6: mechanisms?

No. The ip4: and ip6: mechanisms are checked directly against the sending IP address without any DNS query. They don't count toward the 10-lookup limit. This is why IP flattening (replacing includes with IP addresses) reduces your lookup count — but it creates a maintenance burden because IP addresses can change.

What about the "void lookup" limit?

In addition to the 10-lookup limit for mechanisms that resolve to addresses, RFC 7208 also limits "void lookups" (DNS queries that return no records) to 2. Exceeding this limit also causes a permerror. This typically happens when an include points to a domain that doesn't have an SPF record.

Can I split my SPF record across multiple DNS TXT records?

No. Each domain can have only one SPF record. If you publish multiple TXT records starting with v=spf1, SPF processing returns a permerror. If your SPF record is too long for a single DNS TXT record (255 characters per string), your DNS provider should handle splitting it into multiple strings within a single record — but you cannot have multiple SPF records.

Does the "all" mechanism count as a lookup?

No. The all mechanism is a literal match — it doesn't require a DNS query. Similarly, ip4: and ip6: mechanisms don't require lookups. Only mechanisms that reference hostnames or domains require DNS resolution.

For more on email authentication requirements, see our guide on DMARC compliance in Australia for 2026. If your emails are already landing in spam due to SPF issues, read why emails go to spam and how to fix it.