Source review dated 8 November 2026. Operational steps are proposed; only the explicitly labelled offline demonstration is executed. No live tenant, DNS or mail delivery is claimed.
Read a DMARC aggregate report in layers: who reported it and for what period, which policy was observed, which identities authenticated, whether they aligned and what disposition the receiver recorded. Those layers answer different questions.
The investigation should end with an action on a real service or a clearly recorded uncertainty. Start by establishing the report's population and field meanings, then connect material failures to the messages and workflows the organisation depends on.
Establish the report and policy context
Preserve the reporting organisation, reporting interval, report identifier, source file and processing history. Keep duplicate and overlapping observations under a documented rule so they do not silently inflate or reduce totals.
Check the policy configuration recorded by the reporter. A current DNS lookup does not reconstruct every observation made during an earlier report window. RFC 9990 §3.3 permits a reporting window to span a policy change: one report can contain dispositions from the old policy or a mixture, despite a single policy_published element, or the receiver can issue separate reports. Policy changes and differences between report formats need their own context.
RFC 9990 defines the current aggregate-reporting specification. Deployed collectors can also encounter legacy formats. Preserve schema and field meaning instead of forcing every file into an unexplained uniform interpretation.
Separate raw authentication, alignment and disposition
- Field group: report_metadata; Investigation use: Reporter, reporting interval and report identity
- Field group: policy_published; Investigation use: Policy configuration observed by the reporting receiver
- Field group: row/source_ip and count; Investigation use: Connecting infrastructure and grouped message count
- Field group: row/policy_evaluated; Investigation use: DMARC-aligned results and reported disposition
- Field group: identifiers; Investigation use: Relevant envelope and visible From identities
- Field group: auth_results; Investigation use: Underlying SPF and DKIM observations
In policy_evaluated, the SPF and DKIM results concern their DMARC alignment tests. The raw authentication information in auth_results can therefore contain a pass while the corresponding aligned result fails.
Disposition is another layer: it reports handling in the DMARC context. Local-policy overrides and other filtering mean it should not be used as a shortcut for either authentication success or final inbox placement.
Worked example: SPF passes for an unrelated domain
The following is a **synthetic record fragment**, not a complete report or schema-validation fixture:
<record>
<row>
<source_ip>192.0.2.44</source_ip>
<count>40</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<spf>
<domain>bounce.example.net</domain>
<result>pass</result>
</spf>
</auth_results>
</record>The raw SPF pass belongs to bounce.example.net. It does not align with the visible From domain example.com. With no aligned passing DKIM path in this illustrated row, the aligned results fail. The reported disposition of none does not repair that failure or prove inbox delivery.
To investigate, obtain a representative original message and the service configuration. Identify the application and its business owner. The IP alone does not establish which customer-specific service generated the mail.
Compare pass rates with business impact
This second synthetic example assumes that investigation has already identified the first two services:
- Investigated stream: Employee mail; Observed messages: 29,500; DMARC result: Pass
- Investigated stream: Password resets; Observed messages: 40; DMARC result: Fail
- Investigated stream: Unknown traffic; Observed messages: 460; DMARC result: Fail
The observed overall pass rate is about **98.33%** (29,500 / 30,000). Among the two identified legitimate streams, it is about **99.86%** (29,500 / 29,540). Yet the password-reset stream fails completely in this example.
Neither percentage is a reason to ignore it. Prioritise the critical legitimate failure, continue attribution of the unknown traffic and state exactly which population each percentage describes. Do not rename the 460 unknown observations as blocked attacks without supporting investigation.
Investigate the communications that matter
Start with the business services: customer access, billing, employee communication and outsourced notifications. Ask which are represented in the evidence, which fail and who owns the correction.
Do not accept a single percentage without its denominator. A low-volume password-reset service can be completely broken while employee mail dominates a healthy-looking total. Unknown traffic should also be distinguished from confirmed abuse.
The operating question is whether the team can move from a finding to a verified resolution, not how many rows its dashboard displays.
Understand coverage and protect report inputs
Aggregate reports represent observations from participating reporting receivers. They are not an exact ledger of all email the organisation sent. Reconcile them with sending and provider data cautiously, including time boundaries, missing reports, forwarding and retries where relevant.
Ask how the team establishes approved-service attribution, handles uncertainty and tracks remediation. A cloud ASN, reverse-DNS name or geolocation is an infrastructure clue, not a definitive business identity or attacker location.
Protect reporting data and ingestion. Aggregate metadata can reveal operational information, and report inputs can be forged or malformed. Keep resource limits on decompression and XML parsing, preserve provenance and restrict unnecessary data access. Message-specific failure reports have a different exposure profile and can include sensitive content.
Turn a finding into a verified action
For every material finding, record the service or unresolved identity, affected period, evidence, business impact, owner and next verification step. After a configuration fix, test the real route and check subsequent relevant observations rather than waiting for an unexplained percentage improvement.
Use alignment diagnosis for raw-pass failures, the selector workflow for signing identities and the monitoring guide for the policy decision. Keep the report as supporting evidence for that work, rather than treating the dashboard as the control itself.
The practical takeaway
For each material finding, retain the evidence, attribution confidence, business impact, owner and next test. After a correction, verify the affected route and review subsequent observations. This turns reporting into an operating process rather than a collection of unexplained percentages.
Primary section references: RFC 9990 §3.1.1, RFC 9990 §3.3, RFC 9990 §3.5.4, RFC 9990 §7, RFC 9990 §8, RFC 9989 §4.4, RFC 9989 §5.3.5.