MailDingo

dmarc=temperror

dmarc=temperror

A temporary DNS problem stopped the receiver from finishing the DMARC check, so the domain's policy wasn't applied to this message.

dmarc=temperror means the receiver started a DMARC evaluation but couldn't finish it, because a DNS lookup failed in a way that might succeed later. The message was neither passed nor failed, and the domain's policy was not applied.

What the RFC says

RFC 9989 §9.2 defines temperror as a transient error during evaluation, giving an unreachable DNS server as the example. Two places in the standard lead to it:

  • The DMARC record lookup itself. §4.10.1 leaves DNS errors on the _dmarc query to the receiver. It can "fail open" and deliver, or "fail closed" with a temporary SMTP rejection, so the sender retries once DNS has recovered.
  • The underlying checks. §5.3.6 says that when the DNS queries a DMARC evaluation needs can't complete, the message can neither pass nor fail, and the policy cannot be applied. If SPF came back temperror (RFC 7208 §2.6.6) and DKIM came back temperror (RFC 8601 §2.7.1), with nothing else passing, there's no verdict to give.
Authentication-Results: mx.example.org;
       spf=temperror smtp.mailfrom=example.com;
       dkim=temperror (key query timeout) header.d=example.com;
       dmarc=temperror header.from=example.com

When all three fail together like this, the cause is almost always the sending domain's DNS, because SPF, DKIM keys and DMARC records all live in the same zone. One slow nameserver can take out all three.

Where to look

  • The sending domain's authoritative nameservers. An outage at the DNS host, an expired DNSSEC signature, or a delegation to a nameserver that no longer answers.
  • The receiver's resolver. A scattered pattern across many unrelated senders points here.
  • Timing. If the message was deferred and retried, the Received timestamps will show a gap. That is a common source of delayed mail.

If you received this message

The message is unauthenticated rather than suspicious. A domain with p=reject didn't get its policy applied, so a forged message could slip through during an outage. Judge it as you would any mail with no authentication: see whether the content, links and Reply-To make sense for the claimed sender.

If you own the domain

Query _dmarc.yourdomain, your SPF record and your DKIM selectors directly against each authoritative nameserver, over UDP and TCP. Check DNSSEC signature expiry if you sign the zone. If temperrors keep appearing in your aggregate reports from several receivers, your DNS hosting is the bottleneck. Consider a provider with more anycast capacity, or a secondary DNS service.

See it in your own message

Paste the headers into the analyser to see which domain DMARC checked and whether it lines up with the From address.

Open the analyser