dkim=temperror

dkim=temperror means the receiver tried to verify a DKIM signature but couldn't get the public key from DNS, and the problem looked temporary: no answer, a timeout, or a server failure. The signature may be perfectly good. It just couldn't be checked when the message arrived.

What the RFC says

RFC 8601 §2.7.1 defines temperror as a failure that is probably transient, and gives "a temporary inability to retrieve a public key" as the example. RFC 6376 describes the same state as TEMPFAIL (§3.9). The key-retrieval steps say a verifier may return it when the key query gets no response (§6.1.2, step 2). §6.3 lets a receiver refuse the message temporarily during delivery, with reply code 451 and enhanced status 4.7.5, so the sender retries once DNS recovers. That is a common cause of delayed mail. If you are reading a header that says temperror, the receiver accepted the message instead of deferring it.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k2026; ...
Authentication-Results: mx.example.org;
       dkim=temperror (key query timeout) header.d=example.com header.s=k2026;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

The key lives at k2026._domainkey.example.com. That is the name that failed to resolve in time.

Common causes

1. The signing domain's nameservers were slow or partly unreachable. The DNS is usually hosted by the domain owner or their DNS provider, not by the email service.
2. A CNAME chain to the email provider where the provider's DNS stumbled. Many services have you publish a CNAME that points to a key they host.
3. Large TXT responses. A 2048-bit key makes a DNS answer big enough that some resolvers need to retry over TCP. A network path that blocks TCP on port 53 can turn that into a timeout.
4. The receiver's resolver having trouble. You will see this as isolated failures across unrelated senders.

A caution on labels: RFC 6376 §6.1.2 says a key that doesn't exist at all is a permanent failure, but some receivers report a missing key as temperror. If the error repeats on every message, treat it as a missing key.

If you received this message

The result says nothing about authenticity either way. Check the other results: above, SPF carried DMARC to a pass. If nothing else passed, DMARC may also show temperror, because RFC 9989 §5.3.6 says a check whose DNS queries didn't complete can neither pass nor fail.

If you own the domain

Look up selector._domainkey.yourdomain against each authoritative nameserver, and follow any CNAME to the provider's target. Make sure TCP queries work as well as UDP. If the failures cluster at one receiver, wait and watch. If they show up everywhere, look at your DNS hosting.