spf=temperror means a DNS lookup failed while the receiver was checking your SPF record: a server failure or a timeout, not a problem with what the record says. It often clears on its own, but when it keeps coming back, something in DNS is failing: your nameservers, an included vendor’s, a DNSSEC chain, or the receiver’s resolver. Check your domain below: it makes the lookups in your SPF record tree from your browser and shows any that fail right now.
Last verified 8 October 2026.
You see it as spf=temperror in the Authentication-Results header of a received message (RFC 8601 §2.7.2 lists it among the SPF results), as Received-SPF: temperror, as <result>temperror</result> in the SPF part of a DMARC aggregate report (RFC 9990’s schema allows it), or in a deferral. RFC 7208, the SPF standard, defines it in §2.6.6:
“A ‘temperror’ result means the SPF verifier encountered a transient (generally DNS) error while performing the check. A later retry may succeed without further DNS operator action.”
It happens at two points. First, fetching your record. §4.4: “If the DNS lookup returns a server failure (RCODE 2) or some other error (RCODE other than 0 or 3), or if the lookup times out, then check_host() terminates immediately with the result ‘temperror’.” Second, any lookup a mechanism makes while the record is evaluated. §5: “if the DNS server returns an error (RCODE other than 0 or 3) or the query times out, the mechanism stops and the topmost check_host() returns ‘temperror’.” An include passes it up: in §5.2’s table, a recursive result of temperror causes the include to “return temperror”. So a failing nameserver at a vendor you include gives your domain a temperror.
There is also a time limit. §4.6.4: “MTAs or other processors SHOULD impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be ‘temperror’.”
The DNS answer decides which one you get. RCODE 0 is NOERROR, 2 is SERVFAIL (server failure), 3 is NXDOMAIN (the name doesn’t exist).
| Server failure, another error code, or a timeout | temperror. No answer at all. A retry may work without any change (§2.6.6). |
|---|---|
| NXDOMAIN, or NOERROR with no records | An answer, not an error. §5: “If the server returns ‘Name Error’ (RCODE 3), then evaluation of the mechanism continues as if the server returned no error (RCODE 0) and zero answer records.” These are void lookups; a third one makes SPF return permerror. See too many void lookups. |
| An include target that doesn’t exist or has no SPF record | permerror. The include’s check returns none, and §5.2 turns none into permerror. |
| Records that answer but can’t be interpreted | permerror. More than 10 lookups, a syntax error, two SPF records. §2.6.7 says it “definitely requires DNS operator intervention to be resolved.” See every cause of SPF PermError. |
Enter the domain in your envelope sender (Return-Path), or your From: domain if you don’t know it. The check runs in your browser against public DNS: it reads your SPF record, follows every include and redirect, and looks up every a, mx and exists name in it.
How to read it: a lookup that fails now is a temperror source. A receiver whose lookup fails the same way returns temperror for mail that reaches that term. If every lookup answers, the temperror you saw was likely transient or on the receiver’s side: nothing this check looks up is failing at the moment. The check also reports PermError causes it finds on the way, since those are the other reason SPF doesn’t pass.
The SPF record:
This reads what your DNS publishes right now through Cloudflare’s public resolver, or Google’s when Cloudflare’s fails, and asks a failed lookup a second time before reporting it. Both resolvers validate DNSSEC, so a broken DNSSEC chain shows as a failed lookup here too. A temperror that happens only now and then may not show up in one check; run it again a few times if you suspect an intermittent failure. Names built from macros (%{i} and the like) and ptr depend on the sending server, so they aren’t looked up. For an mx term it looks up the MX records, not the address of each mail server they name. For the full A–F grade with DMARC, DKIM and MTA-STS, use the DMARC checker.
RFC 7208 lets the receiver choose. §8.6:
“Checking software can choose to accept or temporarily reject the message. If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 enhanced status code (see Section 3.5 of [RFC3463]). These errors can be caused by problems in either the sender’s or receiver’s DNS software.”
So a deferral reading 451 4.4.3 with an SPF mention is most likely this error. Your sending server keeps the message and tries again, and if the DNS problem has cleared by then, the message goes through. Appendix G.4 notes the catch: “If ‘temperrors’ persist for multiple delivery attempts, it might be preferable to treat the error as permanent and reduce the amount of time the message is in transit.” A DNS failure that lasts for hours can end in a bounce. Other receivers accept the message and record spf=temperror, which is still not a pass.
Google’s SPF troubleshooting page groups the two errors: when the result after spf= “is temperror or permerror”, it points to verifying your SPF syntax, fixing too many DNS lookups, and checking with your domain provider “to rule out current issues with their DNS”. Both are worth ruling out, and the checker above reports PermError causes as well as failing lookups.
DMARC needs an aligned pass from SPF or DKIM. RFC 9989 §4.4.2: “If the use of the domain in the MAIL FROM identity is validated by SPF, then that domain is the SPF-Authenticated Identifier.” A temperror validates nothing. If an aligned DKIM signature passes, the message passes DMARC anyway (§5.3.5: “If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.”). If not, §5.3.6 covers DNS errors:
“If one or more DNS queries required to perform DMARC validation on the message do not complete due to temporary or permanent DNS errors, the message cannot be considered to pass or fail the DMARC mechanism check. In such cases, the Domain Owner Assessment Policy cannot be applied to the message, and any other handling decisions for the message are left to the discretion of the Mail Receiver.”
The RFC’s SMTP example (Appendix B.3.1) handles it with a retry: “If the DMARC check cannot be resolved due to transient network errors, then the Mail Receiver replies with a 4xy code to inform the sender as to the need to reattempt delivery later.” So an aligned DKIM signature keeps DMARC passing through an SPF lookup failure, unless the DKIM key lookup fails as well, which it will if your own nameservers are the problem. If DKIM is failing for another reason, see DKIM no key for signature and DMARC alignment failed.
Sources: RFC 7208 §2.6.6, §2.6.7, §4.4, §4.6.4, §5, §5.2, §8.6 and Appendix G.4; RFC 8601 §2.7.2; RFC 9989 §4.4.2, §5.3.5, §5.3.6 and Appendix B.3.1; RFC 9990 (aggregate report schema); Google Workspace Help, Troubleshoot SPF issues (checked 8 October 2026).
Every cause is a DNS lookup that doesn’t get an answer in time. Receivers evaluate mechanisms left to right and stop at the first match (§4.6.2), so a failure in your own record’s lookup hits every message, while a failure deep in an include hits only mail from servers not matched before it.
If your domain’s authoritative nameservers are down, overloaded, or answer with SERVFAIL or REFUSED, the very first lookup fails and every message gets temperror (§4.4). The checker above then says your SPF record can’t be looked up at all.
How to tell: dig +trace TXT example.com follows the delegation from the root to your nameservers and shows where it stops. Then ask each of your nameservers directly: dig @ns1.your-dns-host.example TXT example.com +norecurse. Every server listed in your NS records has to answer.
Fix: check your DNS host’s status page and support; remove nameservers that no longer answer from the NS set at your registrar.
Your record can be fine while a provider’s isn’t. The include returns temperror (§5.2) and so does your whole check, for mail that reaches that include. The checker shows the failing lookup with the include path that leads to it, such as “your record → include:vendor.example”.
Fix: you can’t repair another company’s DNS, so report it to the provider. If you no longer send through them, delete the include. If a failure is in a deep chain of includes you don’t need, a shorter record also means fewer lookups that can fail.
RFC 9499, the DNS terminology reference, quotes the classic definition: “A lame delegations exists [sic] when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone”. The usual story is a move to a new DNS host where the registrar, or the zone itself, still lists one of the old provider’s nameservers. Resolvers that ask that server get no usable answer. When none of the listed servers answers, resolvers that support Extended DNS Errors (RFC 8914) can report code 22, “No Reachable Authority”: “The resolver could not reach any of the authoritative name servers (or they potentially refused to reply).”
How to tell: compare the NS records at your registrar (dig +trace shows them as the delegation) with the NS records in your zone, and query each server directly as in cause 1.
Fix: make the two NS sets match, listing only servers that hold your current zone.
A validating resolver that can’t verify a signed answer doesn’t pass it on. RFC 4035 §5.5: “If the validation was being done to service a recursive query, the name server MUST return RCODE 2 to the originating client.” RCODE 2 is a server failure, so receivers using a validating resolver get temperror, while receivers whose resolvers don’t validate DNSSEC get your record. That is why this cause can hit some receivers and not others.
You can see it on dnssec-failed.org, a test domain with a deliberately broken chain. On 8 October 2026, Google Public DNS answered a TXT query for it with "Status": 2 and the comment “DNSSEC validation failure”, and Cloudflare with status 2 and “EDE(9): DNSKEY Missing”. The same query to Google with checking disabled (cd=1) returned "Status": 0 and the record v=spf1 -all. Run that domain through the checker above and the lookup fails.
How to tell: open https://dns.google/resolve?name=example.com&type=TXT with your domain. If it fails, add &cd=1. Google’s troubleshooting guide says that if the query then succeeds ("Status": 0), there is a DNSSEC problem. DNSViz (https://dnsviz.net/d/example.com/dnssec/) shows which link in the chain is broken. dig +cd does the same from a terminal.
Fix: one cause, as in the example above (“DNSKEY Missing”), is a DS record at the registrar that no longer matches the zone’s keys, for instance after a move to a new DNS host or a key change. Publish the DS record for the current key, or remove the DS record at the registrar if the zone is no longer signed, then wait for the old DS record’s TTL.
A receiver asks for every TXT record at your name, not only the SPF one. §3.4 warns: “Records that are too long to fit in a single UDP packet could be silently ignored by SPF verifiers due to firewall and other issues that interfere with the operation of DNS over TCP”… and adds that “one has to take into account any other TXT records published at the domain name.” Large answers need TCP, which DNS requires everywhere: RFC 7766 §5: “All general-purpose DNS implementations MUST support both UDP and TCP transport.” A firewall in front of a nameserver that drops DNS over TCP turns a large answer into a timeout, and a timeout is a temperror (§4.4).
How to tell: dig @ns1.your-dns-host.example TXT example.com +tcp should answer like the UDP query does. Count the TXT records on your domain: dig +short TXT example.com.
Fix: allow DNS over TCP (port 53) to your nameservers, and remove TXT records you no longer need at the same name, such as old site-verification tokens. §3.4 says answers ought to fit in UDP when the name plus all records of that type stay under 450 octets. Keep the SPF record itself short; see how long records are split.
Each nested include is another round trip, and §4.6.4 lets receivers stop after a time limit of at least 20 seconds with temperror (quoted above). Slow nameservers at two or three vendors add up.
Fix: remove includes for senders you no longer use, and prefer ip4/ip6 for your own servers, which need no lookup at all. This also keeps you under the 10-lookup limit.
§8.6 is explicit that these errors can come from “either the sender’s or receiver’s DNS software”. If every lookup answers in the checker above, repeatedly, and only one receiver reports temperror, the problem is likely on their side.
Fix: nothing changes in your DNS. Deferred mail is retried by your server. If it keeps happening at one receiver, send their postmaster the Authentication-Results header and the time of the message.
Sources: RFC 7208 §3.4, §4.4, §4.6.2, §4.6.4, §5.2, §8.6; RFC 4035 §5.5; RFC 7766 §5; RFC 8914 §4.23; RFC 9499 (lame delegation); Google Public DNS, Troubleshooting; dnssec-failed.org queried through dns.google and cloudflare-dns.com (checked 8 October 2026).
spf=temperror in the Authentication-Results header, or a 451 4.4.3 deferral. If it says permerror, go to the PermError guide instead.cd=1 (causes 1, 3 and 4).temperror to see whether it comes back.A temperror means a DNS lookup failed while the receiver was checking: a server failure, another DNS error, or a timeout. RFC 7208 says a later retry may succeed without further DNS operator action. A permerror means the records were retrieved but can’t be interpreted, such as more than 10 lookups or a syntax error, and it stays until you change DNS.
Usually not at first. RFC 7208 section 8.6 says the receiver can choose to accept or temporarily reject the message, and a rejection for this reason SHOULD use SMTP code 451 with enhanced status 4.4.3, so the sending server retries. Appendix G.4 adds that if temperrors persist for multiple delivery attempts, it might be preferable to treat the error as permanent, so a DNS problem that lasts can end in a bounce.
A temperror isn’t a pass, so SPF gives DMARC no authenticated identifier for that message. If an aligned DKIM signature passes, DMARC still passes. If not, RFC 9989 section 5.3.6 says that when DNS queries needed for DMARC validation don’t complete because of temporary DNS errors, the message cannot be considered to pass or fail, and handling is left to the receiver.
No. NXDOMAIN and a NOERROR answer with no records are answers, not errors. RFC 7208 counts them as void lookups: more than two make SPF return permerror, and an include of a name that doesn’t exist is a permerror. Only a server failure, another DNS error code, or a timeout is a temperror.
Because the failure was temporary or on the receiver’s side. RFC 7208 defines temperror as a transient, generally DNS, error, and section 8.6 says these errors can be caused by problems in either the sender’s or receiver’s DNS software. If every lookup answers in the checker on this page, look for intermittent failures at your DNS host, and if only one receiver keeps reporting it, ask that receiver.
If you manage domains for clients or brands, Email Security Signals checks a whole list and returns one row per domain with SPF, DKIM, DMARC and an A–F grade. It treats a failed DNS lookup as unknown, never as a missing record or a PermError. If a domain’s MX, TXT or _dmarc lookup fails, the row says to retry and the domain isn’t charged. If an include or redirect target’s lookup fails, the row sets lookupCountIsMinimum and a low-severity spf_lookup_count_truncated issue, so you know the lookup count is a floor. $0.02 per graded domain ($20 per 1,000); invalid inputs, domains that don’t exist, DNS lookup failures and duplicates are free.
Related: SPF PermError and every cause, fixing “too many void lookups”, fixing SPF “too many DNS lookups”, fixing an SPF record over 255 characters and the free DMARC, SPF and DKIM checker.