Under RFC 9989 §5.4, a message can fail DMARC and still be accepted. Another can pass DMARC and be rejected. Those observations are not enough to conclude that the receiver ignored authentication or that the domain's DNS record is broken.
DMARC gives the receiver domain-authentication evidence and a domain-owner policy to consider. The receiver also controls its own mail handling. An investigation needs to separate those layers before it proposes a fix.
Use three columns rather than one status
Record the published policy, the message's DMARC validation result and the actual receiver action separately. Each answers a different question.
- Layer: Owner policy; Question it answers: What assessment did the applicable domain record request?; Useful evidence: Exact policy record and discovery path at the relevant time
- Layer: Validation; Question it answers: Did a passing authenticated identity align with From?; Useful evidence: Receiver authentication results and the relevant identities
- Layer: Handling; Question it answers: What did this receiver do with this message?; Useful evidence: SMTP response, delivery evidence or receiver logs
A policy of none does not mean that SPF, DKIM and other filtering are switched off. A pass does not force inbox placement. A reject policy does not remove receiver analysis of legitimate indirect routes or other relevant evidence.
For example, a sender may fix DKIM correctly and still receive a rejection caused by a separate receiver rule. Repeatedly changing DMARC DNS in that situation creates change risk without addressing the returned reason.
Work through an accepted failure
Consider a synthetic message with From notices@accounts.example. Its applicable policy requests reject, but the final receiver records DMARC failure after an indirect route. The message is accepted under the receiver's local handling.
The first investigation is whether the message was a legitimate indirect delivery, a configuration defect or unauthorised use. Preserve the connecting source, SPF identity, DKIM domains and results, relevant forwarding or list behaviour and any available policy-override reason.
RFC 9989 RFC 9989 §7.4 discusses receiver analysis beyond reject, including indirect-mail interoperability. Acceptance is therefore not proof of a successful DMARC validation. Equally, the fact that the receiver accepted the message does not prove that the message was benign.
The control owner should resolve the legitimate route if one exists, document receiver-specific findings and avoid claiming that the policy guarantees the same action everywhere. The aggregate-report walkthrough helps keep authentication and disposition fields distinct.
Work through a rejected pass
Now consider a different synthetic message. Its aligned DKIM signature passes and the receiver records DMARC pass, but the SMTP response identifies another policy or abuse concern.
DMARC has answered the domain-authentication question successfully. The next task is to examine the actual rejection, including the complete response text and the sender's relevant service evidence. A content, recipient, reputation or other local rule can affect handling without changing that DMARC result.
Do not add unrelated sending infrastructure to SPF just to make every displayed mechanism green. First establish which identity and route the receiver evaluated and which reason prevented delivery. A broad permission change can create a new problem while leaving the rejection unchanged.
Treat missing and error results carefully
Not every message yields an ordinary pass or fail. A missing applicable record differs from a failure to authenticate under an existing record. A DNS availability problem differs from a permanently malformed policy.
RFC 9989 RFC 9989 §9.2 separates these result conditions. Under RFC 9989 §5.3.6, if DNS errors prevent required DMARC validation, a normal pass or fail cannot be established and handling falls to the receiver's other decisions. Capture the error and affected query, rather than treating it as proof that the sender is malicious.
A temporary rejection can invite another delivery attempt; a later attempt may see a different DNS state. That is why a screenshot of today's record is weak evidence about a message processed yesterday.
Ask for evidence that can resolve the difference
For each disputed message, collect a small case record:
- Message and sending-attempt identifiers, with sensitive data redacted appropriately for triage. Keep an unmodified original controlled separately if DKIM re-verification is needed, because changing signed content can affect verification under RFC 6376 §3.7.
- Timestamp and receiver, including the full SMTP response if available.
- Visible From domain, SPF-evaluated domain and every relevant DKIM signing domain.
- Trusted receiver authentication results, where a message was delivered or logs are available.
- Applicable policy and DNS responses associated with that processing window.
- Known indirect route and any available override or local-rule explanation.
A rejected transaction may provide no delivered message headers at all. Use the sender's attempt logs, response and receiver assistance instead of requiring a header sample that cannot exist for that attempt. Under RFC 8601 §7.1, avoid treating untrusted headers added before the receiving boundary as the receiver's own conclusion.
Close the case with the smallest supported change
The resolution could be correcting a sender identity, fixing a DNS defect, repairing a report collector or addressing a receiver-specific issue. It can also be a documented interoperability decision for a particular legitimate route.
Retest the affected flow after the change and preserve the new evidence. If the result still differs across receivers, record what each actually observed and which implementation or local-policy difference remains unconfirmed. Do not generalise from one receiver's response to the whole ecosystem.
A useful explanation identifies the owner policy, the validation outcome and the handling decision separately, then points to evidence connecting them. That is enough to turn an apparent contradiction into an investigation with an owner and a next action.
Record a decision that can be reviewed
For the accepted-failure case, write p=reject, dmarc=fail and accepted as separate observations. For the rejected-pass case, retain dmarc=pass and the actual returned rejection reason; do not manufacture a DMARC repair. RFC 9990 §3.1.1 and RFC 9990 §3.1.6 likewise separate aggregate evaluation, disposition and override information. Both cases are hypothetical, not captured receiver logs.