Publishing `p=none` with an aggregate-report address is the easy part of DMARC. The difficult part is turning the reports into a trustworthy sender inventory. A report can contain a familiar provider that fails alignment, an unfamiliar source sending legitimate mail for a forgotten team, forwarded messages, or straightforward spoofing. The XML does not label those categories for you. It records what a receiver observed and how it evaluated the messages, leaving the domain owner to connect each source with a business purpose.
Aggregate reports summarize groups of messages. They normally identify the reporting organization and time range, repeat the DMARC policy the receiver found, then group traffic by source IP and policy-evaluation result. Authentication results show domains used by SPF and DKIM. Counts represent messages in that group, not a list of individual recipients or full message contents. This makes aggregate data suitable for coverage and trend analysis, but not for reconstructing a particular phishing message or proving which person sent it.
The first useful output is a table of sources with an owner and a disposition: expected and aligned, expected but broken, unknown and under review, or known abuse. Preserve message counts and report dates, but do not let volume make the decision by itself. A low-volume payroll or legal sender can be more important than a large marketing stream. Repeated unknown traffic may deserve blocking, while a large aligned source may need no action. Classification comes before policy changes.
Quick path: Use DMARC Builder to draft or inspect the policy record, then process the XML reports delivered to the `rua` destination with a report parser or your own pipeline. Use SPF Builder and DKIM Discovery to investigate authentication gaps. DomScan builds and checks the DNS controls; it does not ingest aggregate report mailboxes.
Why DMARC report analysis matters in practice
DMARC passes when at least one supported path both authenticates and aligns with the visible RFC 5322 From domain. For SPF, the authenticated envelope domain must align. For DKIM, the signing `d=` domain must align. A row can therefore show `spf=pass` yet fail DMARC because the SPF domain belongs to a vendor and does not align with the visible From address. The same applies to a valid DKIM signature from an unrelated signing domain. Raw pass values are not enough; the identifiers matter.
A receiver's reported disposition also needs context. The domain publishes a requested policy such as none, quarantine, or reject, but receivers retain local discretion and can override the requested action. Aggregate rows can include reasons for those decisions. Do not read `disposition=none` as proof that the message passed, or `disposition=reject` as proof that every message was rejected during SMTP. Compare the published policy, the DMARC result, and any override reason recorded by the reporter.
- A passing SPF result still does not help DMARC if the authenticated domain is not aligned.
- High-volume unknown sources usually deserve faster investigation than low-volume noise.
- Report trends are often more useful than any single report window.
- Assigned notes for recurring sources make enforcement safer over time.
How DMARC report analysis works
Start with the report metadata. Check the reporter, report identifier, beginning and end timestamps, and the policy domain. Duplicate report IDs or overlapping date ranges can inflate totals if a pipeline imports the same attachment twice. Confirm that the policy shown in the report matches the policy you expected during that interval. If it does not, check DNS history, organizational-domain handling, and whether the receiver queried a stale record.
Then inspect each record group. The source IP and count describe where the receiver accepted messages from, while policy-evaluated fields show alignment outcomes and disposition. The authentication-results section can contain several DKIM signatures or SPF identities, especially when intermediaries add signatures. Use those domains to identify providers and configuration paths. Do not assume the source IP alone maps cleanly to one vendor, because shared mail infrastructure and relays can aggregate unrelated tenants.
If aggregate reports go to a domain other than the one publishing DMARC, the receiving domain must authorize that external destination through DNS. A policy can look correct while reports never arrive because this authorization is missing, the mailbox rejects large attachments, or a parser ignores a reporter's compression format. Test the reporting path, monitor its failures, and retain the original report files so normalized data can be reprocessed when parsing rules change.
{
"source": "198.51.100.14",
"count": 15432,
"spf_aligned": false,
"dkim_aligned": true,
"owner": "transactional-mail",
"action": "verify branded return-path and keep enforcing"
}Where teams usually get it wrong
A report parser can make XML readable, but it cannot decide whether a source is authorized by the business. Teams get stuck when they sort by failure count and open tickets without identifying the application, vendor account, envelope domain, DKIM selector, or owner. The same provider can host both legitimate and abusive traffic. Before allowlisting a source range or changing DNS, find the actual sending configuration and a recent message sample from that workflow.
Another failure is demanding a zero-failure report before moving beyond monitoring. Forwarding and mailing-list transformations can break one authentication path, and some noise will remain on a public domain. The enforcement decision should focus on whether legitimate, business-owned streams have a reliable aligned path. Track unknown and failing traffic, but do not let unaffiliated spoofing keep the policy at `p=none` indefinitely. Spoofing is one of the reasons to enforce.
A more reliable operating model
Maintain a sender register beside the report data. Each entry should name the business service, technical owner, provider, visible From domains, envelope domains, DKIM signing domains and selectors, expected source ranges if stable, and retirement date. Link each aggregate source to that register when evidence supports the match. If nobody owns a stream, give the investigation a deadline rather than silently treating it as legitimate forever. This turns later reports into comparison work instead of repeated discovery.
A practical workflow
Import reports with deduplication and normalize timestamps, IPs, domains, counts, alignment results, and override reasons. Group records first by policy domain, then by source and authentication identity. Keep the reporter visible because different receivers see different slices of mail and may classify the same stream differently. Aggregate totals across a consistent date range only after removing duplicates and correcting for reports that cover partial or overlapping windows.
Triage expected failures by business impact. If SPF passes without alignment, configure a branded envelope sender where the provider supports it or make aligned DKIM the dependable path. If DKIM fails, inspect selector publication, key rotation, canonicalization, and message modification. Do not change SPF merely because a DKIM-aligned stream appears from an unfamiliar source range. SPF authorization should follow the envelope path, and broadening it unnecessarily can create new exposure.
For unknown sources, search the sender register, vendor contracts, help-desk tickets, and message samples before deciding. Record the evidence for the classification. Known spoofing needs no authentication repair, but it helps validate that enforcement will have an effect. Once important legitimate traffic aligns consistently across representative reporting windows, move policy in controlled steps and watch for changes in both authentication and delivery. Rollback criteria should name specific business streams, not a generic increase in failures.
What good monitoring looks like
Useful monitoring reports changes that someone can act on: a new high-volume source, an expected sender losing its aligned path, a retired provider reappearing, a sudden fall in report volume, or a receiver reporting a different published policy. Attach the sender owner and recent trend to the alert. A daily message that merely says thousands of failures occurred teaches the team to ignore the mailbox and hides the one failure that affects a critical stream.
Coverage is never complete. Not every receiver sends aggregate reports, reporters can be late, and the traffic they see may not represent the whole audience. A week with fewer failures may mean a fix, lower mail volume, or a missing reporter. Compare aligned and failing counts with internal sending metrics where possible. Treat aggregate reports as receiver telemetry, not as a billing ledger or a complete census of mail sent under the domain.
Aggregate data still deserves access control and a retention policy. Source IPs, sending domains, message counts, and time windows can reveal vendors, campaign schedules, or internal systems. Restrict report access to the people doing mail operations and security work. Preserve enough history to compare normal sending cycles and investigate changes, but do not keep raw files indefinitely without a stated reason. Reporting visibility should not become an unmanaged archive of infrastructure metadata.
Where DomScan helps
DomScan's DMARC Builder creates and validates policy syntax, including alignment and aggregate-report settings. SPF Builder estimates the direct lookup-causing terms in a proposed record, and DKIM Discovery checks published selectors. These tools help investigate the DNS controls exposed by a report. They do not receive, parse, deduplicate, or classify `rua` reports, so keep the report-analysis pipeline and sender ownership data in a system designed for that job.
Independent references: Review RFC 7489 and Google Email Sender Guidelines for baseline details and neutral operational guidance.
The decision at the end of a report review should be concrete: fix an expected sender, retire it, classify the source as unaffiliated, or advance the policy because important mail is aligned. If the analysis produces only charts, the domain is no closer to enforcement than it was when the XML arrived.