SPF PermError and SPF TempError are two separate SPF evaluation results, and they mean opposite things. PermError is a permanent problem in your published SPF record that will keep failing until you edit DNS. TempError is a temporary DNS failure during evaluation that often clears on its own, but tells you something is fragile. Neither one is a plain "fail," and treating them the same way is how domains stay broken for weeks.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
Both come from RFC 7208, the SPF specification. When a receiving mail server checks your SPF record, it returns one of several results: pass, fail, softfail, neutral, none, permerror, or temperror. The last two are error states, not authentication verdicts. They mean the receiver could not finish evaluating your record at all. The reason matters, because the fix is completely different depending on which one you get.
The core difference in one table
Read this first. It tells you whether to act now or watch and wait.
| SPF PermError | SPF TempError | |
|---|---|---|
| What it means | Your SPF record is invalid or unprocessable | The receiver hit a temporary DNS failure while checking |
| Cause type | Permanent misconfiguration | Transient network or DNS issue |
| Does it self-resolve? | No, it stays broken until you fix DNS | Often yes, on the next send |
| Typical root cause | More than 10 DNS lookups, two v=spf1 records, bad syntax | DNS timeout, SERVFAIL, a slow or unreachable include |
| Receiver behavior | May treat as fail, reject, or ignore SPF | Usually retries or defers the message |
| Your action | Fix the record today | Investigate if it repeats; ignore if it was a one-off |
| Deliverability risk | High and constant | Low if rare, high if chronic |
The mental model: PermError is a spelling mistake in a contract. It is wrong every single time until you rewrite it. TempError is a dropped phone call. Annoying, usually fine on redial, but a real problem if the line keeps cutting out.
What causes SPF PermError
PermError means the receiver parsed your record and decided it cannot be used. There are a handful of causes, and the first one is by far the most common.
More than 10 DNS lookups
RFC 7208 sets a hard limit of 10 DNS-querying mechanisms per SPF evaluation. Every include, a, mx, ptr, and exists mechanism counts against that budget, and includes are recursive, so one include can pull in several more lookups behind it. Blow past 10 and the receiver must return permerror.
This is the number one cause of SPF PermError in the wild. It happens gradually. You add Google Workspace, then a marketing platform, then a helpdesk, then a payment provider, and each one hands you another include. Nothing looks wrong in your DNS, but the total lookup count silently crosses 10.
A record like this is already at the edge:
v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.salesforce.com include:mailgun.org include:servers.mcsv.net -all
Those five includes can easily expand to more than 10 nested lookups. The fix is flattening or consolidating your includes, removing senders you no longer use, and cutting mechanisms that do not query DNS. We cover the full method in Fix SPF too many DNS lookups. Note that ip4 and ip6 mechanisms cost zero lookups, so replacing a heavy include with the actual IP ranges is one durable way to reclaim budget.
Two or more v=spf1 records
A domain must publish exactly one SPF record. If your DNS returns two TXT records that both start with v=spf1, the receiver returns permerror. This usually happens when a new provider tells you to "add this SPF record" and you paste a second one instead of merging the includes into your existing record.
You never stack SPF records. You merge them into a single line with one v=spf1 at the start and one all mechanism at the end.
Invalid syntax or a bad mechanism
Malformed terms also trigger permerror. Common offenders: two all mechanisms, a macro that does not parse, an unknown modifier, or a mechanism with a broken qualifier. Trailing spaces and a missing all are usually tolerated, but structural errors are not.
What causes SPF TempError
TempError means the receiver started evaluating your record and hit a temporary DNS resolution failure. The record itself may be perfectly valid. The problem is that a DNS query did not return an answer in time.
DNS timeout
The receiver queried your domain, or one of the domains in your includes, and the authoritative name server did not respond fast enough. This can be load on your DNS provider, a network hiccup between the receiver and your nameserver, or a rate limit. A single timeout is usually invisible to you and clears on the next attempt.
SERVFAIL
A SERVFAIL response means a DNS server tried to answer but failed, often due to a DNSSEC validation problem, a broken delegation, or an overloaded resolver. If SPF SERVFAIL shows up repeatedly, it points to a real configuration fault in your DNS zone or in one of your include domains' zones, not a random blip.
A slow or unreachable include
Your record might depend on a third-party include like include:_spf.vendor.com. If that vendor's DNS is slow or briefly down, the receiver can return temperror even though your own DNS is healthy. You inherit the reliability of every domain you include. This is a good reason to prune includes for senders you no longer use.
How receivers handle it
Because TempError is transient, most receivers do not reject the message on it. Many defer and retry, and the retry frequently passes. That is why a rare TempError does no lasting harm. The danger is a chronic pattern, because during every temperror your SPF result is effectively unknown, and DMARC may not get the SPF pass it needs for alignment.
How to tell which one you have, and the exact cause
The two errors look identical from the outside: mail behaves oddly, or a report shows something other than pass. You cannot guess which one it is. You have to look at the evaluation.
The fastest path is to check your domain and let the tool name the specific cause. The live checker above evaluates your published record the way a receiver does, counts your DNS lookups, detects duplicate v=spf1 records, and reports whether the failure is a permanent error or a transient one. Instead of a generic "SPF failed," you get the exact reason, such as a lookup count of 13 or a second SPF record, so you know whether to edit DNS now or watch for a repeat.
You can also read it from a received message. Open the Authentication-Results header and look at the SPF portion. It will say spf=permerror or spf=temperror along with the sending IP and domain. If you are not sure how to read that header, see How to read the Authentication-Results header. And if you want the full picture across all your mail sources, DMARC aggregate reports show SPF results at scale, which is how you catch an intermittent temperror that only affects one sending platform.
Why this matters for deliverability and DMARC
SPF does not work alone. DMARC needs either SPF or DKIM to pass and align with your visible From domain. A PermError means SPF contributes nothing to DMARC, so you are leaning entirely on DKIM. If DKIM also has a problem, DMARC fails and your mail can be quarantined or rejected. See SPF, DKIM and DMARC explained for how the three fit together.
A chronic TempError is quieter but still costly. Every time SPF cannot be evaluated, that message loses one of its two authentication signals, which nudges borderline mail toward the spam folder. If you are chasing inbox placement, why emails go to spam covers the other levers, but a stable SPF result is a prerequisite.
Fix PermError immediately, because it never heals itself. Treat a single TempError as noise, but investigate any TempError that recurs, because a repeating transient failure is a real DNS problem wearing a temporary disguise.
Frequently asked questions
Is SPF PermError the same as SPF fail?
No. A fail means SPF evaluated correctly and the sending IP is not authorized. A PermError means SPF could not be evaluated at all because the record is invalid, most often from too many DNS lookups or a duplicate v=spf1 record. They are separate results with separate fixes.
Will SPF TempError fix itself?
Often, yes. TempError is caused by a transient DNS failure such as a timeout or SERVFAIL, and the next send usually succeeds. But if it keeps happening, it is not really temporary. Check your DNS provider's reliability and any third-party include domains you depend on.
How many DNS lookups does SPF allow?
Ten. RFC 7208 limits an SPF evaluation to 10 DNS-querying mechanisms, counting every include, a, mx, ptr, and exists, including the ones nested inside your includes. Exceeding it forces a PermError. Flattening includes or using ip4 and ip6 ranges, which cost no lookups, brings you back under the limit.
Can I have more than one SPF record?
No. A domain must publish exactly one record starting with v=spf1. Two SPF records cause a PermError. When a new provider gives you an SPF record, merge its include into your existing single record rather than adding a second one.