A report can show a published reject policy without reporting a rejection. Read the reporting profile before interpreting the disposition: current RFC 9990 defines pass for a message passing DMARC under an enforcing policy, while older reports can use none for a passing message. Interpret the policy context, authentication results and handling decision as distinct evidence. Their relationship, rather than a single field, explains what needs investigation.
Read the observed configuration first
policy_published records the policy configuration observed by the receiver for the report's policy domain. It is historical reporting evidence, not a fresh DNS lookup. If you query DNS today, keep that result and timestamp separate. A policy may have changed during or after the reported interval.
RFC 9990 allows multiple reports when configurations changed during a period; otherwise a reporter should note the final observed configuration. One policy snapshot therefore cannot always explain every message-time condition. Retain the interval and change history before accusing a reporter of inconsistency.
Evaluate the author domain and aligned paths
A record's header_from supplies the author domain. It can differ from the policy domain when subdomains rely on another domain's policy. Determine the applicable policy relationship rather than assuming every row uses the top-level p value in isolation.
The dkim and spf values under policy_evaluated describe DMARC-related identifier evaluation. They differ from raw results under auth_results. A passing aligned path can satisfy DMARC; an unrelated passing identity cannot. A message that passes DMARC is not a policy-rejection candidate merely because the domain publishes p=reject.
Read disposition with override reasons
Illustrative current-profile case one: policy_published shows p=reject, aligned DKIM passes and disposition is pass, as described in RFC 9990 Appendix A and illustrated in Appendix B. Case two: both aligned paths fail, but disposition remains none with a local-policy reason. The report describes a receiver override, not a repaired authentication result. Preserve the failure and the reason separately.
RFC 9990 requires a reason when alignment fails and applied policy does not match the configured policy. Missing or unexpected information should be flagged for investigation rather than filled in with an invented explanation. A reason string is the reporter's explanation and may still need corroboration.
These cases are synthetic. Neither disposition none nor a passing authentication result proves inbox placement. Other filtering and delivery decisions can exist outside the DMARC handling described by the report.
Investigate a real mismatch methodically
Compare the report's period, observed policy, author domain, alignment mode and raw identifiers with your dated DNS changes and controlled message evidence. Confirm the sender is an authorized business route. If the report remains internally inconsistent, preserve the XML and record the uncertainty.
Do not weaken a domain policy simply to make a dashboard's labels agree. Fix a verified sending defect when one exists; separately document receiver overrides and reporting limitations. The result should be a narrative another administrator can reproduce from the same fields.
Compare two explicit field fixtures
Both partial synthetic maps use the current RFC 9990 reporting profile and policy domain and header_from brand.example, p=reject, relaxed alignment and epoch interval 1704067200–1704153600 (1 January 2024 00:00 to 2 January 2024 00:00 UTC). In the first, count=25, raw SPF passes for vendor.example and DKIM passes for brand.example/selector billing1. The computed aligned results are SPF fail and DKIM pass; DMARC passes. The supplied disposition is pass under the current RFC 9990 reporting profile.
In the second, count=4 and both raw mechanisms pass for vendor.example, with DKIM selector v1. Neither identity aligns, so the computed DMARC result fails. The supplied disposition is still none, accompanied by reason type local_policy and the explicitly synthetic comment “trusted-forwarder handling exception.” That reason explains fictional handling without changing the failed alignment.
The field comparisons explain both authentication outcomes; the second example explicitly supplies a reason. These partial field maps are not complete XML or live observations. The receiver's handling decision is an input, not a consequence inferred from authentication alone.
Choose the next action
- Aligned pass plus current-profile disposition pass (or legacy-profile none): no DMARC rejection is requested for that passing message; investigate delivery separately if needed.
- Both aligned paths fail plus disposition none: inspect the override reason and corroborate the sender, rather than relabelling the authentication as passing.
- Report and current DNS disagree: compare the report interval with the dated policy-change history.
- Required reason missing: preserve the report and flag an unexplained mismatch. Do not invent a local-policy exception.
Distinguish current and legacy dispositions
RFC 9990 Appendix A defines disposition pass as no action for passing DMARC with an enforcing policy. It retains none as no action taken. Older RFC 7489-format reports lack the pass disposition and can report none for a passing message. Check the namespace, reporting profile and aligned results together: none is not universally invalid, but it should not silently stand in for the current-profile pass example. Neither value proves inbox placement.