Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
DMARC aggregate reports can reveal when participating email receivers start seeing a new sending IP or domain, a shift in message volume, or a change in SPF, DKIM, alignment, or policy outcomes. Treat those differences as monitoring signals—not proof of what changed or why. Confirm them against your approved sender inventory, DNS and mail-service records, deployment logs, and incident context.
What DMARC aggregate reports can tell you
Aggregate reports summarize mail that reporting receivers observed for your domain. Depending on the report, you can inspect sending and receiving domains, source IP addresses, message counts, SPF and DKIM identifiers and results, DMARC alignment, and the policy and disposition applied. The RFC 9990 reporting standard describes this feedback as a way for domain owners to understand authentication results and the effect of DMARC policy on mail streams: RFC 9990.
That makes reports useful for detecting changes in the mail sources visible to participating receivers. A new IP, a missing source, a volume shift, or a changed authentication result can prompt an investigation. Reports do not provide a complete inventory of every system configured to send mail, and they are not a real-time event feed.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesWhy reports are an imperfect change monitor
DMARC aggregate reports are periodic—typically daily or more frequently—and are sent by receivers that choose to report. The domain owner requests them by publishing a reporting destination in the DMARC policy record’s rua tag. Reports are XML and may be compressed with GZIP. RFC 9990 specifies the reporting format and behavior, but receivers are not universally required to send reports; delivery may also fail or reports may be discarded. Consequently, missing data does not prove that no source sent mail.
#1 Best Overall
Reports are receiver-originated summaries of observed traffic. Coverage and timing can vary by receiver, and different reports may reflect different policy configurations during a period. Compare like with like—especially by reporting period, receiving domain, and policy state—rather than treating all files as interchangeable counts.
Build a baseline before treating differences as alerts
Keep an internal inventory of approved senders alongside the reports. For each sender, record its provider, expected IP ranges or identifiers, business purpose, and accountable owner. This lets you distinguish a known service from a newly observed source and gives an investigator a practical route to verification.
For each reporting period and receiving domain, track the sources and outcomes the reports actually show. Compare new reports with that baseline for:
- Newly present or absent source IPs and sending domains.
- Changes in message counts or volume patterns.
- Changes in SPF or DKIM identifiers and pass/fail results.
- Changes in whether SPF or DKIM identifiers align with the From domain for DMARC.
- Changes in reported policy or disposition.
Do not combine unlike periods or policy states without accounting for the distinction. The standards define the fields and reporting behavior, not a universal threshold for deciding that a change is material. Establish thresholds that fit your sender inventory and operational risk, and treat them as local monitoring rules rather than DMARC requirements.
Investigate a new, missing, or changed source
- Describe what the report shows. Note the reporting receiver and period, source IP or domain, message count, authentication results, alignment, and reported policy or disposition. Keep the finding tied to the observation rather than guessing at its cause.
- Check approved provider and sender records. Ask the listed owner whether a provider migration, newly enabled application, or other authorized change explains the source or volume.
- Review DNS and mail routing. Compare relevant DNS and mail-service changes with the period in question, including changes that could affect SPF or DKIM authentication.
- Check deployments and incident context. Look for application launches, configuration changes, forwarding behavior, or known incidents that could explain the observed traffic or results.
- Validate unknown or failing traffic. Escalate an unexplained high-volume source or a source with failing authentication for investigation. Record what corroborates the observation and who owns the follow-up.
A newly observed IP could reflect a legitimate provider migration, a newly enabled application, forwarding behavior, a configuration error, or abuse. The report establishes what a reporting receiver observed and summarized; it does not identify which explanation is correct.
Use monitoring mode to find gaps before enforcement
RFC 9989 describes monitoring mode as using p=none while collecting aggregate reports. Domain owners commonly start with p=none and a rua destination so they can find missed authentication configuration before applying enforcement. Use the observed mail streams to resolve legitimate sender and alignment gaps, then make policy decisions with an understanding of the traffic you can see. Reporting availability is receiver-dependent, so reports cannot guarantee visibility into every receiver’s mail handling. See RFC 9989.
Protect the reports as operational data
Aggregate reports can expose sensitive business or personal information, particularly for small organizations. Restrict access to the reporting destination and stored report files according to your organization’s security practices. The same reports that help identify mail infrastructure changes can reveal details about business activity and mail streams.
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.
