PermError means the receiver could not evaluate the SPF record at all. It is worse than a fail, because a record that cannot be evaluated protects nothing, and many receivers treat it as an authentication failure for every message from the domain.
Most common causes
- Recursive includes exceed the 10 DNS-querying-term budget
- Invalid SPF syntax
- Multiple SPF records are published
- Circular, missing or broken dependencies prevent evaluation
What to verify next
- Run the SPF Dependency Graph
- Remove stale sender authorizations
- Check for duplicate SPF TXT records
- Simulate the proposed replacement before publishing
The lookup limit is the usual cause
RFC 7208 allows ten DNS-querying mechanisms per evaluation, counting includes recursively. Vendors get added over years, each include expands into several more, and one day the count crosses ten. Nothing in the visible record changes; a vendor updating its own SPF can push a domain over.
Separately, two or more void lookups — includes that return no record — also produce PermError. Retired vendor hostnames are the typical source, and they are invisible without resolving the tree.
Other error conditions
Multiple SPF records published at once are an error, not a merge. Syntax mistakes — a missing colon, an unknown mechanism, a stray character — invalidate the record. A redirect to a domain with no record fails. Records assembled by hand or by a DNS panel that added a second record during vendor onboarding are the common origins.
The SPF Dependency Graph shows the resolved tree, the count, void lookups and syntax problems in one view.
- More than ten DNS-querying mechanisms.
- Two or more void lookups.
- Multiple records or invalid syntax.
Reducing lookup pressure safely
Inventory which platforms still send, remove the authorizations for those that do not, and consolidate. Prefer literal ip4 and ip6 mechanisms for infrastructure you control, since they cost no lookups. Simulate the proposed record before publishing and leave headroom for the next vendor.
Flattening vendor includes into IP ranges is an option with a maintenance cost: the ranges must be refreshed when vendors change. Treat it as an operational commitment, not a one-time fix.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisSPF Dependency Graph
Resolve recursive authorization paths, lookup pressure and the effective sender policy.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- Lookup counts depend on vendor records at evaluation time and can change without any action on your side.
- Receivers differ in how strictly they treat PermError; some soft-fail, others reject.
Common questions
My record has only three includes. Why over the limit?
Includes nest. Each vendor’s record can contain further includes, and every one counts.
Does record length matter?
Not for this. The limit counts DNS-querying mechanisms, not characters. Length has its own 255-byte string rule.
How do I know which include costs the most?
Resolve the tree with the dependency graph; it attributes lookups to each branch.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.