SPF Record Length Checker

The SPF Record Length Checker validates your SPF record against the two critical limits defined in RFC 7208: the 255-character TXT string limit and the 10 DNS lookup limit. Paste a record like v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all and instantly see the character count, lookup breakdown, and whether you are within safe thresholds.

Understanding SPF Limits

SPF records have two hard limits that, when exceeded, cause email authentication to break silently. The frustrating part is that you can publish an SPF record that looks perfectly valid, add one more include for a new marketing platform, and suddenly your legitimate email starts failing authentication -- with no obvious error message in your inbox. The failures only show up in DMARC aggregate reports or when recipients complain that your messages are landing in spam.

The first limit is the 10 DNS lookup cap. Every time SPF evaluation encounters a mechanism that requires a DNS query -- include, a, mx, ptr, exists, or redirect -- it counts against this limit. The critical detail that catches most administrators is that the count is cumulative across nested records. When you write include:_spf.google.com, that is 1 lookup for the include itself, but Google's SPF record contains 3 more includes, adding 3 more lookups. One line in your record costs you 4 lookups out of your 10. Add a couple more services and you are over the limit before you know it.

The second limit is the 255-character string boundary for DNS TXT records. This is less commonly hit because most DNS providers handle string splitting automatically, but it can cause problems with certain providers or when manually editing zone files. A 2048-bit DKIM key in the same zone already pushes this limit, so complex SPF records with many IP ranges can easily exceed it. This checker validates both constraints and shows you exactly where you stand.

How to Check SPF Record Length and Lookup Count

1. Paste your complete SPF record starting with v=spf1
2. The checker counts total characters and identifies if multi-string formatting is needed
3. Each DNS-querying mechanism is counted: include, a, mx, ptr, exists, redirect
4. IP-based mechanisms (ip4, ip6) are identified as non-counting
5. Review the breakdown showing which mechanisms consume DNS lookups
6. Address any warnings about exceeded or near-limit thresholds

SPF Lookup Count Examples

Mechanisms That Count as DNS Lookups

include:  -> 1 lookup (plus nested lookups from the included record)
a         -> 1 lookup
mx        -> 1 lookup
ptr       -> 1 lookup (deprecated, avoid using)
exists:   -> 1 lookup
redirect= -> 1 lookup

Mechanisms That Do NOT Count

ip4:203.0.113.0/24  -> 0 lookups
ip6:2001:db8::/32   -> 0 lookups
all                 -> 0 lookups

When to Use the SPF Length Checker

• After adding a new email service to verify you have not exceeded the 10-lookup limit
• Debugging "too many DNS lookups" errors in email authentication reports (DMARC aggregate reports)
• Inheriting a complex SPF configuration from a previous administrator to audit current state
• Before deploying SPF changes to production to prevent unintended delivery failures
• Optimizing SPF records by identifying which includes contribute the most nested lookups
• During DMARC rollout to ensure SPF is healthy before tightening your DMARC policy

How SPF Lookup Limits Work

The 10-Lookup Rule

RFC 7208 limits SPF evaluation to 10 DNS mechanisms to prevent denial-of-service attacks through recursive DNS queries. When the limit is exceeded, the SPF check returns a permanent error (permerror), which most receiving servers interpret as an SPF failure.

Nested Lookups Are Cumulative

The 10-lookup limit includes all nested lookups. Consider this chain:

Your record:     v=spf1 include:_spf.google.com include:spf.example.com -all
                 -> 2 direct lookups

_spf.google.com: v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all
                 -> 3 more lookups

Total:           2 + 3 = 5 lookups (before resolving spf.example.com)

Each include in Google's record counts against your domain's total. If spf.example.com adds 6 more lookups, you would reach 11 and trigger a permerror.

Typical Lookup Costs by Service

These counts can change when providers update their infrastructure. Always verify current counts with this checker.

The 255-Character String Limit

DNS TXT records store data in strings of up to 255 characters each. A single TXT record can contain multiple strings that are concatenated during retrieval. If your SPF record exceeds 255 characters, it must be split:

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 "
"include:_spf.google.com include:spf.protection.outlook.com -all"

Most DNS providers handle this splitting automatically, but some require manual formatting.

How to Reduce SPF Lookup Count

When you are at or near the 10-lookup limit, there are several strategies to bring the count down. The most effective approach is SPF flattening, where you replace include mechanisms with the ip4 and ip6 addresses they resolve to. For example, if include:mail.example.com resolves to a single IP, you can replace it with ip4:203.0.113.5, saving one lookup. The downside is that if the provider changes their IP addresses, your record becomes stale and legitimate mail will fail SPF. Automated flattening services solve this by periodically checking and updating your record.

Another common optimization is removing mechanisms you no longer need. Over time, organizations accumulate includes for services they have stopped using -- a former marketing platform, a decommissioned helpdesk, a legacy transactional email provider. Audit your includes against the services that actually send email today and remove any that are no longer active. You should also remove ptr mechanisms, which are deprecated by RFC 7208, unreliable, and waste a lookup.

• Replace include with ip4/ip6: Flatten included domains to their actual IP ranges (requires maintenance when providers change IPs)
• Remove unused services: Audit which services still actively send email for your domain
• Remove ptr mechanisms: They are deprecated by RFC 7208 and waste a lookup
• Use SPF record flattening services: Automated tools that resolve includes to IPs and keep them updated
• Remove redundant a and mx: If those IPs are already covered by ip4 mechanisms
• Use a dedicated SPF policy domain: Move complex SPF logic to a subdomain using redirect=

Frequently Asked Questions

What happens when you exceed the 10 DNS lookup limit?

The SPF check returns a permanent error (permerror). Most receiving mail servers treat this as an SPF failure. Combined with a strict DMARC policy, this can cause legitimate emails to be quarantined or rejected entirely. The dangerous aspect is that there is no immediate error you will see -- the failure only appears in DMARC reports or when recipients tell you your mail is landing in spam.

Do ip4 and ip6 mechanisms count toward the lookup limit?

No. Only mechanisms that require a DNS query count: include, a, mx, ptr, exists, and redirect. Literal IP address mechanisms (ip4, ip6) are evaluated locally and consume zero lookups. This is why flattening includes to IP addresses is an effective optimization.

How do I know how many lookups Google Workspace or Microsoft 365 uses?

Google's _spf.google.com currently resolves to 3 nested includes, consuming 4 total lookups (1 for the include itself plus 3 nested). Microsoft's spf.protection.outlook.com typically uses 2 total lookups. These counts can change when providers update their infrastructure, so check periodically with this tool.

Can I have more than 10 lookups if I split across subdomains?

Each domain's SPF record gets its own 10-lookup limit. If your main domain is at the limit, you cannot increase it by splitting. However, if different subdomains send email independently, each subdomain's SPF is evaluated separately against its own limit. The redirect= mechanism can point to a dedicated policy domain, but the lookups from the redirected record still count against the 10-lookup limit of the original evaluation.

Why does my SPF record work for some recipients but not others?

Different receiving servers may handle the lookup limit differently. Some servers stop evaluating at exactly 10 lookups, while others may allow 11 or 12 before returning a permerror. If your record is right at the boundary, it can pass on some servers and fail on others, leading to inconsistent delivery.

Related Tools

• SPF Record Builder - Build SPF records with proper syntax
• DKIM TXT Record Formatter - Format DKIM records with proper quoting
• DMARC Record Builder - Build DMARC records with all policy tags
• DNS Record Set Deduper - Find and remove duplicate DNS records
• Zone File Linter - Check zone files for syntax errors and duplicates