Recommended Free Tools
DMARC aggregate reports can help you spot when participating mail receivers begin seeing a new sending IP, a change in message volume, or altered SPF and DKIM results. Treat those differences as clues, not a complete inventory or an explanation: reports are periodic and receiver-dependent, so confirm any suspected change against your approved sender list, DNS and provider records, and deployment or incident history.
What DMARC aggregate reports can reveal
Aggregate reports summarize mail observed by a reporting receiver during a period. Depending on the report, you can inspect source IP addresses, sending and receiving domains, message counts, SPF and DKIM identifiers and results, DMARC alignment, and the policy and disposition applied. Comparing those fields over time can expose a source that has appeared, disappeared, changed volume, or begun failing authentication.
As an Amazon Associate I earn from qualifying purchases.
RFC 9990 defines aggregate reporting and obsoletes RFC 7489; RFC 9989 is the current DMARC core specification. Reports are receiver-originated and periodic—daily or more frequently—not a real-time event feed. A report describes what that receiver observed and summarized, rather than every system authorized to send mail for your domain. Receivers are not universally required to send reports, and delivery can fail or reports can be discarded. Missing data therefore does not prove that no source sent mail. RFC 9990 RFC 9989
Build a baseline before treating a difference as a change
Keep an internal inventory of approved senders alongside the reports. For each sender, record its provider, expected IP ranges or other identifiers, and an accountable owner. Compare reports by reporting period and receiving domain so you can distinguish a persistent change from a difference in which receiver reported.
- Record source IPs and sending domains observed in each period.
- Track message counts to identify substantial volume shifts or a source that has stopped appearing.
- Compare SPF and DKIM results and whether their identifiers align with the domain evaluated by DMARC.
- Note reported policy and disposition. Reports may reflect different policy configurations, including within a period, so do not combine unlike policy states as if they were equivalent.
There is no universal threshold in the standard for deciding that a change is material. Set alert levels to suit your mail volume and risk, and treat them as operational choices rather than RFC requirements. RFC 9990
Investigate a newly observed or missing source
A new IP is an observation, not a diagnosis. It could reflect a legitimate provider migration, a newly enabled application, forwarding behavior, a configuration error, or abuse. Likewise, a source missing from a later report may have stopped sending, may not have been observed by that receiver in the period, or may simply be absent from the available reporting data.
Rank #2
- Confirm the observation. Check the reporting period, receiver, source IP, sending domain, message count, authentication results, alignment, and applied policy in the report.
- Check approved records. Ask the listed sender owner and provider whether a migration, new service, or routing change explains the source. Review DNS and mail-service changes, application launches, and deployment records.
- Check mail flow and context. Consider forwarding and other routing changes, then compare the timing with deployments and known incidents. A report alone cannot establish why a source appeared or disappeared.
- Validate and document. Escalate unknown high-volume sources or sources with failing authentication for investigation. Record what the receiver observed and what independent evidence confirmed the cause; keep unresolved observations labeled as such.
Use reports to improve authentication before enforcement
RFC 9989 describes monitoring mode as using p=none while collecting aggregate reports. Owners commonly begin with that policy and a rua destination to find authentication gaps before considering enforcement. The policy record requests reports through rua; report data is XML and may be GZIP-compressed. Collection is not guaranteed for every receiver, so use observed data to inform policy decisions without treating it as exhaustive proof that all legitimate senders are covered. RFC 9989 RFC 9990
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Protect reports and make comparisons dependable
Aggregate reports can expose sensitive business or personal information, especially for small organizations. Restrict access to the reporting address and stored reports according to your organization’s security needs. RFC 9989
If you process reports with tooling, evaluate whether it reliably ingests delayed reports and compressed XML, handles duplicates and multiple policy configurations, and preserves useful history. Check whether it makes IP and domain observations, SPF/DKIM results and alignment, and changes over time visible; whether alerts are configurable; and whether data can be retained, access-controlled, exported, and reconciled with your sender inventory. RFCs define report behavior and format, not a ranking of tools or a prescribed alerting algorithm.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
