SPF PermError: Find and Fix Too Many DNS Lookups
SPF PermError means a receiving mail server could not evaluate your SPF policy successfully. One common cause is exceeding the limit of 10 DNS-querying terms during SPF evaluation. Nested includes can contribute to that limit, so a record with only a few visible mechanisms can still fail. Use the checker to inspect your SPF record, identify potential lookup problems, and review the affected mechanisms before changing DNS settings.
The count on this page is the number of lookup-causing terms on the published record. It does not walk nested include or redirect targets, so it is not a full evaluation-path trace.
Takes ~10 seconds
Which SPF mechanisms count toward the 10-lookup limit?
SPF evaluation allows at most 10 DNS-query-causing terms across the evaluation path. The terms that count are include, a, mx, ptr, exists, and redirect. ip4, ip6, and all do not count. An evaluation that exceeds the limit returns permerror.
An include counts as one of those terms and then evaluates the target's SPF record. Lookup-causing terms inside that target count as well when they are evaluated. redirect also counts, and evaluation continues at the target instead of using the rest of the current record. a and mx each count when they are evaluated. ptr counts too, and it is discouraged. The number of visible include tags is not the evaluated total.
A provider include does not have a fixed lookup cost. The cost depends on the policy that provider publishes and on the mechanisms the receiver actually evaluates. That cost can change when the provider changes its record. Specification: RFC 7208.
Mechanisms that COUNT
-
include: -
a(and a:domain) -
mx(and mx:domain) -
ptr(discouraged) -
exists: -
redirect=
Mechanisms that DON'T count
-
ip4: -
ip6: -
all -
exp=
Why SPF Records Get Too Long
Too many email services
Each sending service often adds an include. Nested terms inside that include count when they are evaluated. Several services can exceed the limit, but the total depends on the published policies and the evaluation path. It is not a fixed cost per provider.
Nested includes
An include evaluates another SPF record, and lookup-causing terms inside that record count when they are evaluated. The cost is not a fixed number for any provider, including Google. It depends on the published policy and the evaluation path, and it can change.
Legacy/unused includes
Old email services you no longer use may still be in your SPF. Audit your record and remove includes for services you've discontinued.
Using mx and a mechanisms
a and mx count toward the 10-term limit when they are evaluated. Replacing them with ip4 or ip6 removes those terms only if you can keep the addresses current. Do not replace a provider-managed include with a static address list unless you can maintain it.
Record too long (255 char limit)
A single DNS TXT character-string is limited to 255 octets, but a TXT record can contain multiple strings that are concatenated for SPF interpretation. Do not shorten an otherwise valid policy solely because its displayed text exceeds 255 characters. A string longer than 255 octets is a DNS publication problem. It is not the same failure as the 10-term lookup limit.
How to fix SPF PermError without breaking legitimate email
Start by listing every service that sends mail using the domain, including support tools, marketing platforms, and forwarded flows. Remove an include only after you have confirmed that the service is unused. Removing a live sender can make legitimate mail fail SPF.
A subdomain used for a separate mail stream, such as news.example.com, has its own SPF evaluation and its own 10-term limit. That helps only when the visible sender and the mail actually use that name. It does not raise the limit for the organizational domain.
Avoid unmanaged SPF flattening. Replacing a provider-managed include with static IP addresses removes nested lookups only for as long as those addresses stay correct. If you cannot update and monitor the list when the provider changes its infrastructure, keep the provider's include and follow its current published instructions.
Check the record again after any DNS change. This page can show the lookup-causing terms on the published record. It cannot show the nested evaluation path, and it cannot tell you whether a particular message passed SPF. For the broader syntax check, use the SPF checker. Specification: RFC 7208.
Frequently Asked Questions
What is SPF permerror?
SPF PermError means a receiving mail server could not evaluate the SPF policy successfully. One common cause is exceeding the limit of 10 DNS-querying terms during SPF evaluation. Other causes include a syntax error and more than one TXT record that begins with v=spf1. PermError is an evaluation result. It does not by itself decide whether the message is delivered.
How do I fix SPF too many DNS lookups?
Identify the services that still send mail for the domain and remove only authorizations you have confirmed are unused. A separate subdomain can have its own SPF evaluation when mail is actually sent from that name. Avoid replacing a provider-managed include with static IP addresses unless you can maintain that list as the provider changes its infrastructure. Flattening without an update and monitoring plan can authorize the wrong hosts or drop legitimate ones.
What counts as an SPF DNS lookup?
The mechanisms and modifier that count are include, a, mx, ptr, exists, and redirect, including terms evaluated inside nested include and redirect targets. ip4, ip6, and all do not count. The relevant count is the terms actually evaluated, not the number of visible include tags alone. A provider include does not have a fixed lookup cost. The cost depends on the published policy and the evaluation path, and it can change.
Related Guides
Related Tools
Fix SPF Permanently
Create a free account to monitor SPF lookups, get alerts when limits are exceeded, and see optimization recommendations.
Start Free Monitoring