PermError
The SPF result meaning the record could not be evaluated because it is invalid or exceeds a processing limit. It is a failure, not a neutral outcome, and applies to every message the domain sends. Defined in RFC 7208 section 2.6.
SPF’s permanent failure. The record could not be evaluated, so nothing it authorises counts.
The usual cause is the ten DNS lookup limit in RFC 7208 section 4.6.4. Lookups inside your includes count against the same total, so a record with four entries can be over the limit through a vendor’s own record. Once over, receivers must return PermError.
Other causes: two v=spf1 records at the same name, more than two lookups returning nothing, a syntax error, or a macro the receiver cannot expand.
The consequence is easy to underestimate. PermError is a failure, not a shrug. Every message the domain sends fails SPF from that moment, and if DMARC alignment depended on SPF, DMARC fails with it.
Related
- SPFSender Policy Framework: a DNS TXT record listing the servers authorised to send mail using a domain in the SMTP envelope sender. Defined in RFC 7208.
- DMARCDomain-based Message Authentication, Reporting and Conformance: a DNS record that requires SPF or DKIM to pass for the visible From domain, and instructs receivers what to do when neither does. Defined in RFC 9989.
- SPF: too many DNS lookupsTen is the limit, the lookups inside your includes count against it, and past ten SPF fails for every message you send. Here is how to get back under.
- SPF TestFull chain walk with the exact 10-lookup count, plus the void lookups nobody else checks.
- SPF FlattenerOver the lookup limit? Expand the chain into addresses, with the staleness cost stated up front.
Every fix on this site is yours to implement. If you would rather someone did it, I take this work directly.