Under RFC 9989 §9.2, a dmarc=permerror result says the receiving system encountered an evaluation error it considers unlikely to resolve on a later attempt. It does not mean that every legitimate sender is unauthorised, and it does not identify the exact repair without supporting evidence.
Read the complete result, its trusted source and the associated diagnostic text. Then separate policy parsing, discovery and underlying authentication so that a persistent defect is repaired at the right layer.
Preserve the observed result and its source
For delivered mail, keep the original message and the trusted receiver's complete Authentication-Results field under RFC 8601 §7.1. Record its authentication service identifier, the method name, result and any associated properties or explanation.
For rejected mail, preserve the full returned SMTP text and sending-platform event. There may be no delivered headers. The word “permanent” in an SMTP failure is not by itself proof that the receiver reported dmarc=permerror.
Attach the visible From domain, sending account, message reference, recipient and time. These details let another operator reproduce the relevant lookup and evaluate the same route.
Keep five cases distinct
The following synthetic investigation matrix describes different evidence, not guaranteed labels from every product:
- Case: Improperly formatted policy candidate; Evidence to retain: Exact returned strings and parser explanation; Repair direction: Correct the identified grammar defect
- Case: Multiple policy candidates at one target; Evidence to retain: Full TXT record set and discovery trace; Repair direction: Reconcile candidates and inspect any fallback
- Case: No policy found through discovery; Evidence to retain: Negative-answer context and queried names; Repair direction: Establish the intended policy publication
- Case: Required DNS query unavailable; Evidence to retain: Response status, resolver and timing; Repair direction: Investigate resolution and infrastructure
- Case: Valid policy, no passing aligned identity; Evidence to retain: Message identities and authentication results; Repair direction: Correct the legitimate sender's supported configuration
A valid DMARC fail is different from an evaluation error. An absent policy is also different from a server that could not answer the query.
Use the alignment guide when the evidence shows ordinary raw authentication or alignment failures rather than broken policy processing.
Inspect the record before generalising the error
Under RFC 9989 §4.7, the version tag must be first with the exact value DMARC1. Use registered lower-case tag names and each tag's defined value rules. Inspect actual record boundaries instead of a manually concatenated screenshot.
Do not turn every imperfection into a universal permerror claim. RFC 9989 defines ignored unknown tags, tag-specific defaults and conditional policy handling. Under RFC 9989 §4.10.1, its current discovery rules continue as p=none when p is missing or invalid, or sp or np is invalid, only if rua contains at least one syntactically valid reporting URI. Otherwise no DMARC processing applies to that message under those rules.
That condition is not a general pardon for an arbitrary malformed record. First establish that the record reached the relevant parsing and discovery stage. Record which specification and implementation produced the observed classification.
Examine duplicate candidates through discovery
Under RFC 9989 §4.10, current tree-walk rules discard multiple DMARC policy records returned for a single target. They do not merge the values.
A missing valid policy at the first query can lead to further discovery. A policy found at another applicable location may then govern the message. A tool that shows only the first target has not established the complete result.
Preserve the actual receiver diagnostic and compare the complete lookup path. The subdomain guide is useful when the affected From domain differs from the organisational domain.
Do not confuse SPF permerror with DMARC permerror
Authentication-Results methods have their own outcomes. An spf=permerror indicates an SPF evaluation problem for its evaluated identity; it is not automatically the receiving system's DMARC result.
For example, in a synthetic case with successful DMARC policy discovery, an SPF syntax defect can coexist with a valid aligned DKIM signature. That signature can supply a message-level DMARC passing path under RFC 9989 §5.3.5. Repair the SPF defect and assess broader participation requirements, but do not relabel the observed DMARC result.
Similarly, identify whether a reported DKIM error concerns a key, signature or lookup. Preserve the mechanism-specific evidence rather than assuming that one DNS edit fixes every method.
Repair one established defect and retest
Save the complete before-state and the intended approved record set. Identify the exact responsible owner name and DNS authority. A reporting integration or administrative edit may have created the persistent problem.
Make the targeted correction and validate the resulting authoritative data. Check relevant recursive observations and allow for cached earlier data. Then send a controlled representative message through the same account and route and inspect the new trusted result.
If the result persists, compare the new evidence with the original. A new failure at a different stage is progress in diagnosis, but it still needs its own explanation and repair.
Close the incident with a specific cause
“DMARC was broken” is not a useful closure. A stronger record states which record or dependency caused the observed error, how it was corrected and what the retest established.
Retain any implementation difference that remains consequential. Current RFC 9989 requirements and older receiver behaviour can differ; do not promise that an untested change will produce one label everywhere.
A permanent error is best handled as a precise configuration or evaluation finding. Restore a valid operating path, then return to the separate work of maintaining legitimate aligned mail.
Keep the decision and evidence separate
In the SPF-error fixture, record spf=permerror and the separately established dmarc=pass rather than replacing one method’s result with another’s. Keep the SPF repair open even if the message has a surviving aligned DKIM path. For cached changes, RFC 8767 §4 permits qualifying stale-answer use after expiry. No real receiver diagnosis or repair is claimed.