Fix: SPF TempError

13 April 2026 · 11 min read

An SPF TempError almost always means the receiving mail server could not finish resolving your SPF record because of a temporary DNS failure, not because your record is wrong. That distinction matters enormously. A PermError is a verdict ("your SPF is broken, fix it"); a TempError is a shrug ("I could not check right now, try again later"). If you are seeing spf=temperror in headers or in your aggregate reports, the fix is rarely about the text of your v=spf1 record and almost always about how reliably that record, and everything it references, can be resolved under load.

This article explains exactly what a TempError is, how SPF evaluation produces one, why it is different from a PermError, how the big receivers (Google, Microsoft, Yahoo) treat it, and the concrete steps that make your SPF resolution reliable enough that TempErrors stop appearing in the first place.

What temperror actually means

SPF is defined in RFC 7208. When a receiver checks SPF, it does a sequence of DNS lookups: it fetches your v=spf1 TXT record, then resolves every mechanism that requires a DNS query (include, a, mx, ptr, exists, and redirect). The evaluation produces one of seven results:

• pass: the sending IP is authorised.
• fail: the IP is explicitly not authorised (-all).
• softfail: the IP is probably not authorised (~all).
• neutral: the domain makes no assertion (?all).
• none: there is no SPF record at all.
• permerror: the record is broken or cannot be interpreted (syntax error, too many lookups, and so on).
• temperror: a transient error, usually DNS, prevented the check from completing.

A TempError is the result the receiver returns when a required DNS query failed in a way that might succeed if retried. The classic triggers are:

• A SERVFAIL response from one of your authoritative nameservers.
• A DNS timeout because a nameserver did not answer in time.
• A truncated UDP response that the resolver could not recover over TCP.
• A transient failure resolving a nested include: domain run by someone else (your email provider, for example).

The key phrase in RFC 7208 is that a TempError "is a transient (generally DNS) error". The receiver is telling you: your SPF might be perfectly valid, but the DNS plumbing did not cooperate at that moment.

TempError versus PermError: the difference that changes your fix

People conflate these two because both show up as red in a report and both are not a pass. They are opposites in terms of what you should do.

A PermError is permanent and deterministic. Given the same record and the same DNS data, every receiver will reach the same PermError every time. The usual causes are structural:

• More than ten DNS-querying mechanisms (the famous "too many DNS lookups" limit).
• A syntax error, such as two v=spf1 records on the same name, or a malformed mechanism.
• A redirect or include pointing at a name that has no SPF record at all.

A PermError means the receiver gives up and treats SPF as unusable. Under DMARC, a PermError counts as an SPF failure for alignment purposes, so it can directly cause messages to fail DMARC. If you want the deep dive on that side, see the PermError glossary entry and run your domain through the SPF checker, which counts your lookups and flags structural breakage.

A TempError is, by definition, non-deterministic. The same lookup that failed will often succeed thirty seconds later. That is why you cannot reliably reproduce a TempError on demand, and why "I checked and it looks fine" is not proof the problem is gone. The fix for a PermError is to edit the record. The fix for a TempError is to make resolution robust, because the record is usually already correct.

Put simply:

PermError: your SPF is wrong. TempError: your SPF could not be reached. One is a content bug, the other is an availability bug.

How receivers treat a TempError

This is where TempError becomes operationally important, because receivers do not all behave the same way, and the DMARC layer adds a second twist.

At the SPF layer

When SPF returns temperror, the receiving server has a choice. RFC 7208 explicitly allows the receiver to either defer the message (a temporary SMTP rejection, a 4xx code, asking the sender to retry) or to accept it and carry on. In practice:

• Many receivers accept the message and simply record spf=temperror in the Authentication-Results header, then move on to DMARC.
• Some receivers, particularly when other signals look risky, will issue a 451 temporary failure so the sending server queues and retries later. A legitimate sender retries and usually succeeds on the next attempt once your DNS recovers.

The practical consequence of a 451 is delayed mail, not lost mail, provided the sender is a well-behaved MTA. But intermittent delays are still a real deliverability problem, especially for time-sensitive messages such as one-time passcodes and password resets.

At the DMARC layer

DMARC needs at least one of SPF or DKIM to pass and align. Here is the subtle part: if SPF yields a TempError and DKIM passes and aligns, DMARC still passes overall. DKIM saves you. But if you are relying on SPF for alignment (no DKIM, or DKIM broken), an SPF TempError means DMARC has no passing, aligned mechanism, so DMARC evaluation itself typically results in a temporary error or a fail.

Under RFC 7489, when the underlying authentication is a temporary error, a receiver "MAY" treat the DMARC result as a temporary error and defer rather than apply your p=reject policy. So a TempError will usually not get a legitimate message bounced under reject; it gets deferred and retried. The danger is not a hard bounce, it is:

1. Delivery delays when receivers defer on temperror.
2. Noisy reporting that hides real problems. A flood of temperror rows in your aggregate reports makes it harder to spot genuine misconfiguration.
3. Inconsistent enforcement, where the same message passes on retry but failed the first attempt, which is maddening to debug.

This is exactly the kind of intermittent signal that emailed monitoring catches and a one-off manual check misses. If your reports suddenly show a spike of spf=temperror, that is a DNS reliability event worth a change alert.

Reading a TempError in the wild

You will encounter a TempError in two places.

In a single message header. Look at the Authentication-Results line:

Authentication-Results: mx.google.com;
       spf=temperror (google.com: error in processing during
       lookup of user@example.com: DNS timeout)
       smtp.mailfrom=example.com;
       dkim=pass header.i=@example.com;
       dmarc=pass (p=reject sp=reject dis=none) header.from=example.com

Notice in that example DKIM passed, so DMARC still passed despite the SPF temperror. That is the resilience you want by default. Paste a full header into the email header analyzer to see each result broken out.

In aggregate (RUA) reports. Each row carries an SPF result. A handful of temperror rows scattered across millions of messages is normal background noise. A sustained band of temperrors from one receiver, or starting at a specific timestamp, points to a real DNS problem on your side or your provider's. The DMARC report analyzer groups results so you can see whether temperrors are isolated or systemic.

The real causes, and how to fix each one

A TempError is a symptom. Here are the underlying causes, ordered roughly by how often they bite, with the specific fix for each.

1. You are flirting with the 10-lookup limit

This is the single most common hidden cause of TempErrors, and it is widely misunderstood because everyone associates the limit with PermError. Here is the mechanism.

The SPF specification caps you at ten DNS-querying mechanisms. Crossing that cap is a PermError. But there is a separate, related limit: void lookups. RFC 7208 recommends that a receiver treat more than two lookups that return no records (NXDOMAIN or NODATA) as an error. And critically, the way many resolvers and SPF libraries handle the lookup budget means that when you are sitting at nine or ten lookups, you have zero margin for a single slow or failed sub-query. One nested include whose nameserver is briefly slow, and the whole evaluation runs out of road and returns a TempError rather than completing.

In other words, a bloated SPF record does not just risk PermError; it makes TempError far more likely, because each extra include is another remote nameserver that has to answer in time, every time, for every receiver, worldwide.

The fix:

• Count your lookups with the SPF checker. Aim to stay comfortably below ten, ideally at six or seven, so a transient hiccup in one nested include does not tip you over.
• Remove include entries for services you no longer send through. Stale include: of a former ESP is pure cost.
• Consider SPF flattening for stable senders, where you replace an include chain with the resolved IP ranges so the receiver does fewer remote lookups. Understand the trade-off first: flattening means you must track when the provider changes their IPs. See SPF flattening and the 10-lookup limit for the full picture.

2. Your authoritative DNS is slow or flaky

If your own nameservers occasionally SERVFAIL or time out, every SPF check that needs your TXT record can TempError.

The fix:

• Use a DNS provider with a fast, well-distributed anycast network. A geographically diverse authoritative setup answers quickly from anywhere a receiver happens to be.
• Run at least two nameservers, ideally on diverse infrastructure, so one provider blip does not take your SPF down.
• Check that your TXT record is not being truncated. A very long SPF record split into multiple strings is fine, but a single oversized response that forces TCP fallback can time out on resolvers that handle TCP poorly. Keep the record lean.

3. A nested include provider is having a DNS wobble

When your record says include:_spf.google.com or include:sendgrid.net, you are depending on that provider's nameservers being up and fast at the exact moment a receiver checks you. If their DNS has a transient issue, you inherit a TempError even though your own record is perfect.

The fix:

• You cannot fix someone else's nameservers, but you can reduce your exposure by minimising the number of third-party includes (see point 1).
• If a specific provider's include is repeatedly implicated in temperrors in your reports, raise it with them; it is their availability problem.
• For your most critical mail stream, lean on DKIM as the primary alignment mechanism. DKIM does not depend on a chain of remote SPF includes resolving in real time, so a DKIM pass keeps DMARC green even when SPF temperrors.

4. DNSSEC misconfiguration

A broken DNSSEC chain (expired signatures, a missing DS record, an algorithm mismatch) makes validating resolvers return SERVFAIL. To an SPF check, a SERVFAIL looks exactly like a transient failure, so it surfaces as a TempError, often intermittently as different resolvers cache different states.

The fix:

• If you run DNSSEC, validate the full chain after every key rollover. Expired RRSIG signatures are a classic cause of sudden, widespread temperrors.
• If you do not run DNSSEC, ensure you have not half-enabled it (a DS record at the registrar with no signing at the zone, or vice versa).

5. ptr mechanisms

The ptr mechanism is deprecated precisely because it is slow and unreliable: it forces reverse-DNS lookups that frequently fail or time out, which produces temperrors and void lookups. If your record still contains ptr, remove it. There is almost no legitimate modern reason to keep it.

A worked example

Suppose your record looks like this and you are seeing intermittent temperrors:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:spf.protection.outlook.com include:_spf.example-crm.com include:mail.zendesk.com ptr ~all

Two things jump out. First, ptr should go immediately. Second, six includes plus ptr is already a heavy lookup chain, and several of those nested includes themselves expand to multiple lookups, which can push you to the edge of the budget. Under load, any one of those remote providers answering slowly can produce a TempError.

A more resilient version, after auditing which services you actually send through and flattening the most stable one:

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com ip4:198.51.100.0/24 ~all

Here you have dropped dead services, removed ptr, replaced one volatile include with its resolved range, and given yourself headroom under the lookup limit so a single slow sub-query no longer tips the evaluation into TempError. Verify the rewrite with the SPF checker before you publish, then confirm the live record with the DMARC checker once DNS has propagated.

Belt and braces: do not let SPF be your only safety net

The most reliable way to make SPF temperrors harmless is to ensure DKIM is signing and aligned on every stream. Because DMARC passes if either mechanism passes and aligns, a solid DKIM setup means an occasional SPF temperror never affects delivery; it just shows up as a benign line in your headers. SPF will always depend on real-time DNS resolution of a chain you partly do not control; DKIM does not. Treat DKIM as your primary alignment mechanism and SPF as the secondary, and temperrors stop being an emergency.

That is also why moving to p=reject safely depends on watching both mechanisms over time rather than trusting a single snapshot. The requirements overview covers what Google, Yahoo and Microsoft expect, and the glossary has plain-English entries for every term used here.

How to confirm it is fixed (and stays fixed)

Because a TempError is intermittent, "it works when I test it" proves nothing. You need to watch over time:

1. Re-audit the record. Run the SPF checker and confirm your lookup count has real headroom and there are no ptr or stale includes.
2. Watch your aggregate reports. Open recent RUA data in the DMARC report analyzer and confirm the temperror band has shrunk to background noise rather than a sustained stripe.
3. Set up monitoring with change alerts. A temperror spike is, by nature, something that appears days after you last looked. Emailed monitoring tells you when your SPF or DNS reliability changes, so you find out from an alert rather than from a user who did not get their reset email.

The takeaway

An SPF TempError is a transient DNS failure, not a verdict on your record. It differs from a PermError in the most important way possible: PermError means edit your record, TempError means make your resolution reliable. The fixes are about availability, not syntax: stay well under the 10-lookup limit so you have margin for a slow sub-query, run fast and redundant authoritative DNS, prune stale and ptr mechanisms, keep your DNSSEC chain valid, and lean on DKIM so an occasional temperror never touches delivery. Receivers will usually defer rather than bounce on a temperror, so you rarely lose mail outright, but you do lose time and you do bury real signal in your reports.

Start by counting your lookups and pruning your record with the SPF checker, confirm the live state with the DMARC checker, and turn on monitoring so the next reliability wobble reaches you as an alert. If you would rather not babysit DNS resolution at all, our hosted SPF keeps your record lean, flattened where it makes sense, and continuously watched, so temperrors stop being your problem.