dmarc temperror: mail that passes sometimes and defers other times

A temperror is a transient lookup failure, not a broken record. Here is how to read it, separate it from permerror, and remove the DNS instability behind it.

Standards basis: Advice based on RFC 9989 for DMARC policy records, RFC 9990 for aggregate reports, and RFC 9991 for failure reports. Historical RFC 7489 behavior is called out where relevant.

Quick answers

What does dmarc temperror mean?
It means DMARC evaluation hit a transient error, almost always a DNS failure, while looking up the policy or the underlying SPF or DKIM record. RFC 7208 defines temperror as a transient error where a later retry may succeed without any DNS operator action. It is not a malformed record.
What is the difference between temperror and permerror?
Temperror is temporary: a DNS timeout, SERVFAIL, or rate limit that may clear on retry. Permerror is permanent: a malformed record, a syntax error, more than ten SPF DNS lookups, or duplicate records, and it needs you to fix the record. Do not edit your record on a temperror, and do not wait and retry on a permerror.
Why does my email pass DMARC sometimes and fail other times?
Intermittent results point to unstable DNS rather than your record content. One authoritative nameserver may be slow or unreachable, a large TXT answer may be truncated over UDP on some paths, or DNSSEC validation may fail at some resolvers. The record is fine; the lookup is flaky.
Will receivers reject mail on a temperror?
Usually not outright. Because the failure is transient, many receivers return a 4xx temporary SMTP error and the sending server retries later, so the message is deferred rather than bounced. Permanent rejection on a temperror is uncommon, but a sustained climb in temperror still hurts deliverability and report accuracy.
How do I fix a recurring temperror?
Stabilize the DNS that serves the failing record. Check every authoritative nameserver responds quickly, fix any broken DNSSEC delegation or expired signatures, shorten or flatten oversized TXT records that truncate over UDP, and use authoritative DNS that answers reliably over both UDP and TCP.

What a dmarc temperror is

A temperror result means DMARC evaluation, or one of the SPF and DKIM lookups it depends on, hit a transient error and could not complete. The error vocabulary comes from the underlying mechanism specs. RFC 7208 §2.6.6 defines an SPF temperror as "a transient (generally DNS) error while performing the check," and adds that "a later retry may succeed without further DNS operator action." Read that last clause literally: there is nothing in your record to fix. A lookup failed, and the same lookup may well succeed on the next attempt.

This is different from permerror. RFC 7208 §2.6.7 defines a permerror as a state where "the domain's published records could not be correctly interpreted," and says it "definitely requires DNS operator intervention to be resolved." A permerror is a malformed record, a syntax mistake, more than the ten SPF DNS lookups RFC 7208 §4.6.4 allows, or duplicate records. DMARC itself does not define the temperror or permerror tokens. DMARC carries these same SPF and DKIM outcomes through to its aggregate reports, in the <auth_results> block, so the transient versus permanent meaning you read in a report is inherited from RFC 7208 (SPF) and RFC 6376 (DKIM). What DMARC does add is the handling rule: RFC 9989 §5.3.6 says that if the required DNS queries fail, the message cannot be judged pass or fail and the disposition is the receiver's call.

Practical translation. A temperror says "try again later, nothing to fix." A permerror says "your record is broken, fix it." If you are looking at intermittent failures, where the same sender passes on Monday and defers on Tuesday, you are dealing with a temperror and a DNS stability problem, not a record problem.

How receivers treat a temperror

Because a temperror is transient, a receiver should not treat it as a hard policy failure. The DMARC layer is explicit about this: RFC 9989 §5.3.6 (the DMARCbis revision that obsoletes RFC 7489) says that when the required DNS queries fail, whether temporarily or permanently, the message cannot be considered to pass or fail and the disposition is left to the Mail Receiver's discretion. The common choice for a transient authentication failure is to return a temporary SMTP error so the sending MTA retries. In practice that looks like a 4xx deferral rather than a 5xx bounce. The exact code and text are receiver-specific and not defined by any RFC, so treat the following only as an illustration of the shape: 

Illustrative only, exact wording is receiver-specific:
451 Temporary failure, please try again later

The signal to watch for is the 4 at the front: a 4xx is a defer, the sender keeps the message queued and retries, and the mail usually goes through on a later attempt once DNS recovers. State this carefully: receivers may defer on a temperror, they are not required to. Some will accept the message and simply record dmarc=temperror in the headers without taking policy action.

Read the temperror in the message headers

Pull the Authentication-Results header from a deferred or delivered message. A transient failure shows up as temperror on the mechanism that could not resolve: 

Authentication-Results: mx.receiver.example;
  spf=temperror (DNS error) smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=temperror header.from=example.com

Read it mechanism by mechanism. Here SPF returned temperror from a DNS error while DKIM passed, and DMARC reports temperror because the SPF leg could not complete. Compare that to a permanent failure, which names a concrete defect: 

Authentication-Results: mx.receiver.example;
  spf=permerror (too many DNS lookups) smtp.mailfrom=example.com

The wording in parentheses is the receiver's free-text reason, so it differs between providers, but the temperror and permerror tokens themselves are defined by RFC 7208 and are reliable. If you have the raw headers, paste them into the email header analyzer to break out each authentication result. If you are reading this from aggregate report XML, the DMARC report decoder turns the <auth_results> blocks into a readable per-source view so you can see which sources carry the temperror.

Cause 1: resolver timeouts and unreachable authoritative nameservers

The most common cause is one authoritative nameserver that is slow or unreachable. If your zone is served by several nameservers and one of them times out, a receiver that happens to query that server gets no answer in time and records a temperror, while a receiver that hits a healthy server gets a clean pass. That is exactly the "passes sometimes, defers other times" pattern.

Query the policy and the SPF record from more than one public resolver to see whether answers are consistent: 

dig +short TXT _dmarc.example.com @1.1.1.1
dig +short TXT _dmarc.example.com @8.8.8.8
dig +short TXT example.com @1.1.1.1

The +short flag prints only the record value. The @1.1.1.1 and @8.8.8.8 select Cloudflare and Google resolvers so you can cross-check what the wider internet sees rather than trusting a possibly stale local cache. Then check each authoritative server directly. List the nameservers, then query the record on each one and watch the response times: 

dig +short NS example.com
dig TXT _dmarc.example.com @ns1.example.com
dig TXT _dmarc.example.com @ns2.example.com

A nameserver that hangs, returns SERVFAIL, or answers far slower than its peers is your problem server. Use +trace to follow the delegation from the root down and confirm which authoritative server actually answers, which surfaces a stale or missing NS delegation: 

dig +trace _dmarc.example.com

Note that +trace queries the root and authoritative servers iteratively and bypasses your local resolver cache, so it shows the live authoritative chain.

Cause 2: DNSSEC validation failure (SERVFAIL)

If your zone is DNSSEC-signed and the chain of trust is broken, a validating resolver returns SERVFAIL instead of your record. A non-validating resolver may still hand back the answer, so the failure looks intermittent: it depends entirely on whether the receiver validates. Common triggers are a nameserver move that left stale DS records at the registrar, expired signatures (RRSIG), or a key rollover that did not propagate.

Request the DNSSEC records and look for validation problems: 

dig TXT _dmarc.example.com +dnssec
dig TXT _dmarc.example.com @9.9.9.9 +dnssec

The +dnssec flag asks for the RRSIG records that prove the answer is signed, and Quad9 (@9.9.9.9) is a validating resolver, so a SERVFAIL there with a clean answer elsewhere is a strong DNSSEC signal. If you need to see the data a validating resolver would otherwise withhold, add +cd to disable checking on the query: 

dig TXT _dmarc.example.com @9.9.9.9 +dnssec +cd

If DNSSEC is the cause, fix the delegation first: correct the DS records at the registrar, re-sign the zone, or complete the key rollover. Editing the DMARC or SPF record changes nothing until validation succeeds again.

Cause 3: oversized TXT answers and UDP truncation

DNS answers travel over UDP by default. When a TXT response is large, a long SPF record with many include mechanisms, or several records sharing a name, it can exceed what fits in a UDP packet on a given path. The server sets the truncation (TC) flag and the resolver is expected to retry over TCP. If a firewall or middlebox blocks DNS over TCP on port 53, that retry fails and the resolver records a temperror.

Reproduce it by forcing TCP and watching for truncation: 

dig TXT example.com
dig TXT example.com +tcp

If the plain UDP query shows ;; flags: ... tc; in its header, the answer was truncated. If the +tcp query then succeeds while the UDP one is incomplete, a blocked-TCP path will produce intermittent temperrors. Two fixes apply:

  • Allow DNS over TCP on port 53 to and from your authoritative nameservers. TCP fallback is part of DNS, not optional.
  • Shrink the records. An SPF record must stay within the ten DNS-lookup limit of RFC 7208 §4.6.4, and a smaller record is also less likely to truncate. Rebuild it with the SPF record generator and flatten nested include chains where you can.

Cause 4: rate limiting and flaky split-horizon DNS

Two more causes produce the same intermittent signature. First, query rate limiting: if an authoritative server or an upstream provider throttles a burst of lookups, some queries are dropped and the resolver times out into a temperror. High-volume senders to large receivers hit this most often. Second, split-horizon DNS, where internal and external resolvers serve different views of the zone. If the external view is incomplete or one view's nameservers are unstable, public receivers can intermittently fail to resolve the record even though it looks correct from inside your network.

Always test from outside your own network, using public resolvers, so you see the same answer a receiver does: 

dig +short TXT _dmarc.example.com @1.1.1.1
nslookup -type=TXT _dmarc.example.com 1.1.1.1
nslookup -type=TXT example.com 8.8.8.8

The nslookup forms are useful on a Windows host without dig, though nslookup has no +dnssec, +trace, or +short equivalent, so prefer dig for the diagnostics above.

Confirm the temperror is gone

After you stabilize DNS, fix DNSSEC, or shrink the record, wait at least one TTL and then re-check the record from several resolvers and confirm no validation error: 

dig +short TXT _dmarc.example.com @1.1.1.1
dig +short TXT _dmarc.example.com @8.8.8.8
dig TXT _dmarc.example.com @9.9.9.9 +dnssec

You want one clean v=DMARC1 answer from every resolver, no SERVFAIL, and no truncation. Then run the domain through the free DMARC checker for a posture snapshot, and watch a few days of DMARC aggregate reports: a temperror that was caused by DNS instability disappears from the per-source breakdown once the lookups are reliable. If you need a faster signal than the roughly one-day lag on aggregate reports, send a fresh message through Inbox Inspector and read the verdict timeline directly.

Was this page helpful? Send us feedback

Last updated: May 2026

Standards basis: Advice based on RFC 9989 for DMARC policy records, RFC 9990 for aggregate reports, and RFC 9991 for failure reports. Historical RFC 7489 behavior is called out where relevant.

← All guides Start now

Need expert help with email deliverability?

Hire an email deliverability consultant who has shipped billions of emails. Free assessment, hands-on engagement, written quote before any work starts.

Talk to a consultant