Under RFC 9989 §9.2, a temporary DMARC error means the evaluation encountered a problem that may resolve on a later attempt. It does not mean the domain has no policy or that legitimate mail has conclusively failed authentication.
Treat the result as the start of a resolution investigation. Establish which required lookup failed, whether the data exists at its authority and what prevented the receiving system from obtaining a usable answer.
Capture the failed evaluation
Save the complete trusted result or returned SMTP response, time, From domain and sending route. Note which authentication method the error belongs to. A temporary SPF or DKIM problem is not automatically the same as dmarc=temperror.
Retain the exact lookup name and record type when logs expose them. A policy TXT query, an SPF dependency and a DKIM selector lookup can involve different names and authorities. Testing only the domain root can miss the failed dependency.
Preserve a small evidence packet before making changes. Repeated queries may succeed after the incident, so a later healthy answer cannot replace the original failure record.
Follow a response-based decision path
This is a diagnostic decision table, not a universal mapping from DNS status to one email disposition:
- Query observation: Relevant complete answer with NOERROR; What it establishes: That query returned usable data at that time; Next investigation: Compare it with the receiver's earlier observation
- Query observation: Complete no-data response; What it establishes: The requested record set was not found in that response context; Next investigation: Check exact name, authority, aliases and discovery
- Query observation: NXDOMAIN without an alias complication; What it establishes: The queried owner name does not exist; Next investigation: Confirm the query scope and applicable fallback
- Query observation: SERVFAIL; What it establishes: Resolution did not complete successfully; Next investigation: Inspect authority, delegation, validation and resolver logs
- Query observation: REFUSED; What it establishes: A server declined the query; Next investigation: Check query policy and the server's intended role
- Query observation: Timeout; What it establishes: No usable response arrived within the attempt's limits; Next investigation: Check reachability, transport, loss and server health
DNS response codes are defined by RFC 1035 §4.1.1; negative answers by RFC 2308 §2.1 and RFC 2308 §2.2. A query for _dmarc.example.com concerns that owner name. Its negative answer does not by itself establish that example.com does not exist. Follow alias chains before attributing an absence to the original queried name.
Compare authoritative and recursive paths
First identify the correct authoritative servers, including any delegated subdomain. Test the relevant name at each authority and compare answers. If the authorities disagree, investigate the zone's serving state and recent changes.
Then inspect the recursive path used by the affected receiving system where evidence is available. Compare query time, status, answer and TTL. An operator's local resolver and a remote receiver can have different cached or validation state.
The following fictional abbreviated transcript illustrates the comparison:
14:02 UTC | recursive resolver R | _dmarc.example.com TXT | SERVFAIL
14:04 UTC | authoritative server A | same name/type | NOERROR, policy returned
14:04 UTC | authoritative server B | same name/type | NOERROR, policy returned
14:09 UTC | resolver R after investigated repair | same name/type | NOERRORThose observations narrow the investigation toward the recursive or intervening path. They do not prove the cause without logs, and they do not establish what every receiver experienced.
Include DNSSEC validation in the investigation
Under RFC 4035 §5.5, a validating resolver can reject data that fails DNSSEC validation even when a direct query to an authoritative server returns text. Check delegation and validation evidence, including key or signature changes, using the responsible DNS team's supported tools and logs.
A direct answer from an authority does not itself reproduce the receiver's validation decision. Likewise, one SERVFAIL does not prove a DNSSEC problem; it can have several causes.
Repair the established validation defect if there is one. Disabling validation to hide the symptom is not evidence that the intended secure resolution path recovered.
Test both UDP and TCP where relevant
DNS transport can be part of the failure. A small UDP query succeeding does not establish that a larger answer, a truncated-response retry or TCP works along the same path.
RFC 7766 RFC 7766 §5 requires general-purpose DNS implementations to support both UDP and TCP. Compare the relevant name and type over each transport when diagnosing reachability or size-related failures. Inspect the truncation flag and network evidence rather than assuming every timeout has the same cause.
A transport test is a diagnostic observation. It should not be turned into a production workaround that bypasses the intended resolver or validation path without a reviewed design.
Keep absence and failed resolution separate
Under RFC 2308 §5, negative answers can be cached, as can positive data. A newly added record may remain absent in a recursive view until the earlier negative cache state expires. That is different from an authoritative server being unreachable.
A configuration defect can also persist while the observed error remains classified as temporary. “Temporary” describes the evaluation category, not a promise that waiting will repair a broken delegation or signature.
Use the missing-record guide for confirmed absence and the publication workflow to verify the actual name and authority.
Verify recovery before reconsidering policy
Current RFC 9989 §4.10.1 leaves handling of policy-lookup DNS errors to the receiver. The evaluation guidance in RFC 9989 §5.3.6 says that required DNS queries not completed because of DNS errors do not establish a DMARC pass or fail, and the domain-owner assessment policy cannot be applied on that incomplete result. Receiver handling can still differ.
Changing p does not repair an unreachable required lookup. Restore usable resolution first, then retest the same route and inspect the new method-specific results. Preserve any business recovery decision as a separate scoped change.
The final record should identify the failed dependency, established cause, repair and receiver evidence after recovery. That makes the next intermittent failure easier to diagnose without weakening a working policy reflexively.
Keep the decision and evidence separate
For the fictional 14:02–14:09 transcript, authority success narrows but does not identify the failed component. Require the actual resolver or network finding before naming DNSSEC, transport or a particular server as the cause. RFC 8767 §4 permits qualifying stale-answer use; freshness alone is not a universal outage or recovery clock. These observations are invented teaching fixtures, not performed tests.