A DMARC result is a diagnosis category, not an instruction to change the published policy. fail, none, temperror and permerror point to different investigations. Treating them as interchangeable can leave the real fault unresolved and weaken protection unnecessarily.
Start with the receiving system's trusted evidence. An Authentication-Results header records a system's assertion; its presence alone does not prove that the assertion is reliable. Identify which receiving service generated it and which headers that service trusts. This boundary is explained in RFC 8601 §1.2 and RFC 8601 §7.1.
Read the method and result together
In a header containing spf=pass; dkim=pass; dmarc=fail, the three result words belong to different methods. The SPF and DKIM passes may authenticate domains that do not align with the visible From domain. Conversely, a DMARC pass can coexist with a failure of one underlying method if another passing path aligns.
Use the following diagnostic map. The result meanings come from RFC 9989, section 9.2; the next actions are operational recommendations.
- Result:
dmarc=none; Interpretation: No applicable policy was found for the Author Domain; First useful action: Reconstruct policy discovery for the actual From domain - Result:
dmarc=pass; Interpretation: An applicable policy exists and a passing authenticated identity aligns; First useful action: Identify the successful path and investigate any separate delivery problem - Result:
dmarc=fail; Interpretation: An applicable policy exists but no passing aligned identity was established; First useful action: Compare SPF and every relevant DKIM result with From - Result:
dmarc=temperror; Interpretation: Evaluation encountered an apparently transient error; First useful action: Capture the DNS or service error and compare a later controlled attempt - Result:
dmarc=permerror; Interpretation: Evaluation encountered an error unlikely to resolve merely through retry; First useful action: Inspect the exact policy data and receiver diagnostic for a persistent configuration problem
Do not infer the cause from the result word alone. A temporary DNS fault and a malformed policy can both prevent a normal conclusion, but they require different owners and different corrective work. Preserve any diagnostic comment rather than reducing the evidence to a dashboard colour.
Separate dmarc=none from p=none
dmarc=none is a reported evaluation result. p=none is a value in a published policy. A valid monitoring policy can still produce either dmarc=pass or dmarc=fail on individual messages.
Consider two synthetic cases. In the first, example.com publishes a valid monitoring record and a message has an aligned passing DKIM signature. The expected DMARC evaluation is pass even though the policy says none. In the second, no applicable policy can be discovered for the message's Author Domain. The receiver may report dmarc=none; there is no monitoring-policy promise to infer from that word.
If a colleague says “DMARC is set to none”, ask whether they mean the DNS policy, the message result or the final disposition. Record all three separately. That short clarification often prevents a DNS change aimed at the wrong problem.
Investigate fail through the identities
Obtain the original received message. Record the visible From domain, the SPF identity and result, and the d= domain and result for each relevant DKIM signature. Apply the configured alignment mode to passing identities. A selector is a key locator, not the domain used for DKIM alignment.
If SPF passes for a vendor domain and DKIM passes for another vendor domain, neither may align with your From domain. Editing the root SPF record is not automatically the fix. Establish which identity the service actually evaluates and which customer-domain authentication options it supports. The alignment failure guide walks through that comparison.
Investigate errors without guessing
For temperror, record the message time, receiver, queried name, error and resolver context if available. Compare authoritative DNS and recursive results. A later successful lookup supports a transient explanation, but does not prove what the receiver saw earlier. Ask the receiving operator for logs when that distinction matters.
For permerror, retrieve the complete relevant TXT record set. Check the publishing name, version placement, duplicate policy records and malformed values. Do not promise that every malformed record produces the same label: current DMARC in RFC 9989 §4.10 and RFC 9989 §4.10.1 defines specific recovery and default behaviour for some syntax and policy-value problems, and implementations may differ. Match the diagnostic to the applicable rule before changing it.
Preserve a before-and-after sample. If the new attempt succeeds, keep the exact repair and successful result together. Avoid closing an incident simply because a public checker now gives a green result.
Keep evaluation separate from delivery
Under RFC 9989 §5.4, a receiver can deliver a DMARC-failing message under its local handling rules, and it can block a passing message for spam, malware or other reasons. Collect the SMTP response or delivery disposition separately from the authentication result.
Your final incident note should say what was evaluated, by which trusted receiver, when, why the result occurred and what changed. A precise conclusion such as “the billing service now produces an aligned DKIM pass through its production route” is more useful than “DMARC fixed”. For missing-policy cases, continue with No DMARC record found.
Make the next decision explicit
In the monitoring-policy fixture, record p=none, dmarc=pass and actual disposition as three separate fields. If a valid policy exists but both passing mechanism identities are unaligned, the completed evaluation is fail. If required DNS queries do not complete, RFC 9989 §5.3.6 prevents a normal pass/fail conclusion. These are analytical classifications, not receiver logs.