spf=temperror

spf=temperror means the SPF check broke down partway because a DNS lookup failed in a way that might clear up on its own: a timeout, or a server error from a nameserver. The receiver could not decide whether the sending IP was allowed. It says nothing about whether the message is genuine.

What the RFC says

RFC 7208 §2.6.6 defines temperror as a transient error, generally from DNS, where a retry may succeed without anyone changing anything. The lookup rules are specific: if the TXT query returns SERVFAIL or another error code apart from "no such name", or simply times out, evaluation stops with temperror (§4.4). Receivers are also told to cap the total time spent on one check, allowing at least 20 seconds, and to return temperror if they hit the cap (§4.6.4).

§8.6 lets the receiver either accept the message or refuse it temporarily, with SMTP code 451 and enhanced code 4.4.3, so the sender tries again later. If you are looking at the header, the receiver chose to accept.

Typical causes

• The domain's nameservers are slow, overloaded or partly down. One unreachable server out of several can be enough when the receiver's resolver happens to ask it.
• A problem further down the chain. The record may include: another provider's record, and a temperror inside an include ends the whole evaluation with temperror (§5.2).
• Long include chains that take too long to resolve under load.
• The receiver's own resolver having a bad moment. This one is outside the sender's control, and it shows up as scattered, one-off errors.

Authentication-Results: mx.example.org;
       spf=temperror (DNS timeout looking up example.com) smtp.mailfrom=example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

If you received this message

Treat SPF as absent and rely on the other results. In this snippet an aligned DKIM signature produced a DMARC pass, so the sender is authenticated anyway. If DKIM also failed, DMARC may itself report temperror: under RFC 9989 §5.3.6, a check whose DNS queries didn't complete can neither pass nor fail DMARC, so the domain's policy can't be applied. A temporary refusal during that window is also a common reason for delayed mail.

If you own the domain

One temperror is noise. A pattern is worth a look. Query your SPF TXT record against each of your authoritative nameservers directly, then do the same for every domain you include. Look for a nameserver that times out, a delegation pointing at a server that no longer answers, or DNSSEC signatures that have expired. Trimming a deep include chain also reduces the chance of timeouts. If the record itself is malformed, you will see permerror instead.