The XML is a receiver ledger, not a domain score
A DMARC aggregate report describes messages a reporting receiver observed using your Author Domain during a stated period. It groups counts by source IP and evaluation outcome, then includes the SPF and DKIM domains it saw. It does not grade every sender you own or prove where each message landed.
RFC 9989 defines aggregate reporting as a way to identify fraudulent domain use and gaps in a domain owner’s own authentication. Receivers are recommended, not required, to provide reports. The current DMARC specification explains the purpose and coverage limit. Missing data is therefore an unknown, not a clean bill of health.
The useful reframe is to read each row as a routing clue. Your decision comes from joining that clue to a sender inventory, a controlled message and an accountable owner. The XML alone cannot tell you whether an unfamiliar shared IP belongs to an approved application.
Check the report envelope before trusting its rows
Start with report metadata. Record the reporting organisation, report ID, begin and end timestamps, policy domain and published policy values. Reject duplicate report IDs from your working totals. If the stated policy differs from what you expected, query live DNS and check whether the report covers an earlier cached or historical period.
Confirm that the attachment is actually XML or a recognised compressed XML file before opening it. Do not enable macros, run executable attachments or upload reports to an unknown converter. A dedicated parser should treat XML as untrusted input, reject dangerous external-entity behaviour and preserve the original file for comparison.
If the file is malformed, preserve it and record the sender. Do not hand-correct production evidence silently. A parser can skip a broken report while leaving an audit note, or the reporting receiver can be contacted if the issue persists.
If the relationship between authentication and the visible From address is unclear, revisit what DMARC actually checks before classifying a report row.
Policy-evaluated fields show the visible DMARC result
Within a record, the row usually gives a source IP, count and policy-evaluated values for DKIM, SPF and disposition. Those DKIM and SPF values are the alignment-aware DMARC evaluation for the row, not simply every raw authentication result that may appear later.
A disposition of none, quarantine or reject reports what the receiver says it did in the context of policy and any local override. It is not a universal instruction outcome. Preserve any override reason rather than treating it as noise, because forwarding, mailing lists or receiver policy can explain a surprising disposition.
Multiply nothing and infer no percentage until you have de-duplicated files and confirmed the count period. Compare counts as directional evidence. Aggregate data can combine several messages, so one row cannot provide an individual subject, recipient journey or application event.
Before acting on the disposition a report shows, understand the three policies in a DMARC p=none to reject guide.
Authentication results name the domains behind the verdict
The authentication-results area can contain DKIM domains and selectors plus SPF domains and scopes. These are the identities to compare with your route records. A passing DKIM result for a vendor domain may be valid but unaligned with your From domain. Likewise, SPF can pass for a provider-controlled envelope domain without satisfying DMARC.
DMARC passes only when a supported authentication mechanism passes and its domain aligns with the Author Domain. RFC 9989 defines the authenticated identifiers and alignment rule. This is why you should retain domains beside pass or fail values.
Several DKIM entries may appear because a message can carry several signatures. Do not discard the provider signature or assume the first entry is decisive. Look for any valid aligned signing domain, then confirm the route with a message header when the report row is operationally important.
Turn report rows into a sender map
- Normalise the policy domain and source. Keep the original source IP, but attach a provider or application only when contracts, controlled messages or reliable ownership evidence support it.
- Group by identity pattern. Compare header From, SPF domain, DKIM domain, disposition and result rather than grouping by IP alone.
- Join to the inventory. Mark authorised owner, expected route and last controlled test.
- Classify the row. Use authorised pass, authorised failure, likely unauthorised use, unknown or insufficient evidence.
- Choose one action. Repair a legitimate route, investigate ownership, retain evidence of abuse or monitor for recurrence.
A shared provider can change source IPs, while one IP can carry mail for many customers. Identity patterns and account evidence are more durable than a label copied from an IP lookup.
a route-based sender inventory templateAuthorised failure and abuse need opposite actions
For an authorised failure, find the route owner and send a controlled message. If SPF passes for an unaligned provider domain, consider an account-specific custom return path. If DKIM is absent or unaligned, enable custom domain signing with a unique selector. If a signature fails, query its exact selector and inspect whether an intermediary changed signed content.
For likely unauthorised use, do not add the source to SPF and do not weaken alignment to make the row pass. The failure is evidence that the control is distinguishing mail not authorised to use the domain. Preserve the pattern, confirm no internal owner recognises it and consider whether policy readiness supports stronger enforcement.
Unknown is a legitimate temporary status. Give it an owner and review date. Converting every unknown source into either trusted or hostile without evidence creates configuration mistakes and false incident claims.
The same failed row needs two very different responses depending on who owns the sender. A legitimately authorised system failing authentication points to a configuration repair on your side. A source you never authorised that passes or fails points to abuse or a stale record to retire. Reaching for 'add it to SPF' when the row is abuse, or 'tighten policy' when the failure is your own sender, moves you in the wrong direction, so classify ownership before choosing the action.
Compare several reporting views before changing policy
Google advises reviewing DMARC reports during a gradual rollout and provides current examples of monitoring and enforcement records. Google’s recommended DMARC rollout describes its operational approach. Its suggested time periods are guidance for its environment, not proof that every low-frequency business route has appeared.
Compare reports from different receivers and enough business cycles to include invoices, payroll, renewals, campaigns and seasonal systems. Track which major recipient populations are absent. Reconcile with application owners and provider logs, because DMARC reporting participation and visibility are incomplete.
Before a policy change, list authorised failures by count, business criticality and repair owner. A tiny payroll route can matter more than a large unauthorised stream. Counts support prioritisation; they do not decide risk for you.
email blacklist monitoringTreat report files as business records, not harmless XML
Keep each original XML or compressed report unchanged in a restricted reporting area. Record its reporting organisation, report ID, time range and file hash or stable evidence reference before parsing. The row table used for analysis should contain only the domains, source addresses, counts, results and route labels needed for classification. It should not be mixed with mailbox exports or copied into a public incident thread.
Aggregate reports omit bodies, but they can still expose customer platforms, sending volume and operating times. Give access to the report-processing owner and the people responsible for matched routes. When a supplier needs evidence, send only its source pattern, authenticated domains, relevant counts and period through the supplier’s secure account channel. A controlled-message header should be redacted separately and linked to the row, not embedded in the whole data set.
Set a retention rule for source files, parsed output and exports. Parser credentials, mailbox passwords, private DKIM keys and DNS recovery data belong elsewhere. If an unknown converter or analyst cannot explain where uploaded XML will be stored, do not send it. Ask the data or security owner to approve the processing route first.
Reproduce a report row before changing a sender
Select an operationally important row and note its report ID, period, source, header From, SPF domain, DKIM domains, count and evaluated result. Ask the route owner to trigger the matching business action using a unique, non-sensitive reference. At a controlled receiver, compare the new header with that identity pattern. This tells you whether the row belongs to the suspected application; an IP ownership label alone cannot.
For an authorised failure, acceptance means the repeated message now uses the intended aligned identity and the receiver records the expected DMARC outcome. For suspected abuse, acceptance means internal owners cannot match the pattern after a documented check and no authorisation was added merely to make it pass. Reprocess the original XML with the normal parser as a control if totals or fields looked surprising.
Keep the original file, parsed row, owner response, DNS queries and test header under one case reference. Future reports may arrive late or cover a different period, so compare IDs and dates before calling a recurrence. A changed source, parser discrepancy or new authentication domain is a new lead, not automatic proof of the same cause.
Pause when a row cannot support the claimed action
Stop configuration work if the report ID is duplicated, the XML is malformed, the policy period does not match the assumed DNS state, or the row cannot be joined to an owner or controlled message. Do not turn an unfamiliar IP into an SPF authorisation and do not call it hostile solely because no one recognises the address on first review.
Give parser problems to the report-processing owner. Give aligned-identity failures to the relevant sender and DNS owners, with the exact row fields and a redacted received header. If a live route worsens after a change, restore the isolated prior value where approved and pause that route while the evidence is compared.
Leave organisation-wide policy untouched when report coverage or attribution remains uncertain. Record the unresolved classification and review date. Resume only when the original report, parsed result and route evidence support the same explanation.
Sources and further reading
- RFC 9989: Domain-based message authentication, reporting and conformance
- Google recommended DMARC rollout