An SPF record can look valid and still produce PermError for either of two reasons: the domain publishes multiple SPF records at the same name, or evaluating one record exceeds SPF’s DNS lookup limits. A PermError means the published policy could not be correctly interpreted; it does not say whether the sender is authorized. The rules come from RFC 7208, with Microsoft’s Microsoft 365 SPF setup guidance reinforcing the one-record rule.
What SPF PermError means
SPF checks whether a sending host is authorized by the policy for the relevant email identity, such as the HELO or MAIL FROM domain. A PermError is different from an SPF fail: it means the receiver could not correctly interpret the published records, rather than establishing that the sender is unauthorized. RFC 7208 §2.6.7 defines the result in those terms.
As an Amazon Associate I earn from qualifying purchases.
Two configuration problems are especially easy to miss because the DNS data may look plausible when inspected casually: publishing more than one SPF record at a name, and exceeding the lookup budget as a policy and its references are evaluated.
Free tools Windows power users keep installed
One-click scans. No signup required.
Failure 1: multiple SPF records at the same name
An SPF record is a string in a DNS TXT resource record. There must be only one SPF record for a given owner name. If a receiver finds more than one, SPF processing returns PermError; it cannot choose or combine the records for you. Microsoft’s setup guidance likewise says to use one SPF TXT record per domain or subdomain.
#1 Best Overall
This often happens when separate mail services each provide an SPF entry and an administrator publishes both. Each may look well formed on its own, but together they do not make a valid single policy.
How to fix duplicate records
- Check the exact domain identity involved in the message, rather than assuming the root domain’s record applies. A subdomain may need its own SPF record.
- Inventory every legitimate service that sends mail using that identity, including services added by vendors or internal systems.
- Combine the required authorization mechanisms into one SPF record. Remove entries only after confirming that the associated service is no longer a legitimate sender.
- Query DNS again at that exact owner name and confirm that only one TXT value beginning with
v=spf1is published.
Failure 2: too many DNS lookups during evaluation
RFC 7208 §4.6.4 sets a limit of 10 DNS-lookup-causing terms during an SPF evaluation. The count applies across the evaluated policy, including referenced include and redirect policies—not just the visible terms in the first TXT record. Exceeding the limit must result in PermError.
The terms that can trigger DNS queries for this limit are include, a, mx, ptr, exists, and redirect. Not every SPF term counts: all, ip4, and ip6 do not cause DNS queries during SPF evaluation and are outside this particular limit. The exp modifier’s lookup occurs later, not during evaluation.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteBecause the evaluation follows referenced policies, a short-looking top-level record can still exceed the ceiling. The effective count can also change if a provider revises its SPF policy or a new sending service is added, so an earlier successful configuration is not proof that the current evaluation remains within the limit.
Other lookup-related limits
- Void lookups: Implementations should limit DNS lookups that return an empty successful response or a name error to two. This limit can be implementation-configurable; exceeding the configured limit produces
PermError. - MX address records: Each MX evaluation has a separate cap of 10 A or AAAA address records per MX record. This is distinct from the overall limit on DNS-causing terms.
Diagnose and repair the policy safely
- Check record selection. Query TXT records for the exact domain identity and count values beginning with
v=spf1. If there is more than one, identify all legitimate senders and consolidate their requirements into one policy. - Trace evaluation recursively. Expand every
includeandredirectand count the DNS-causing terms across the evaluation:include,a,mx,ptr,exists, andredirect. Keep the total at or below 10. - Check the secondary limits. Look for empty or nonexistent DNS answers that contribute to the void-lookup count, and examine the number of address records returned during each MX evaluation.
- Reduce unnecessary policy scope. Remove authorization for services confirmed to be retired. Where it suits the organization’s sending setup and identity, a dedicated subdomain can separate a mail stream. Do not publish a replacement until it still authorizes every legitimate sender.
- Verify the published result. Re-query authoritative DNS after changes and confirm the intended single policy and its evaluation limits. The time receivers see an update depends on the zone’s TTL and resolver caching; there is no universal propagation interval.
These checks address different failure modes: one asks whether the receiver finds exactly one SPF policy at the relevant name; the other asks whether evaluating that policy stays within the applicable lookup limits.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
