DMARC aggregate reports explained

DMARC aggregate reports, often called RUA reports, are the daily or more frequent XML feedback files receivers can send when your DMARC record asks for reporting. They help a domain owner see which IPs are sending as the domain, which streams pass SPF or DKIM, and what DMARC policy effect receivers observed.

Check your DMARC reporting signal

Run the public DNS scan first, then use this guide to review whether your domain has a reporting destination and enough signal for a safer policy decision.

01$0Free scan

Check the public sender-auth records mailbox providers expect.

02$0Shareable action plan

Keep one URL with evidence, owner steps, and decisions.

03$49$49 fix plan

Add human review, provider context, and verification steps.

Optional. Most first scans can run with just the domain.

Checks Gmail, Yahoo, and Microsoft sender requirementsPublic DNS onlyNo mailbox login needed

Example result72/100Needs attention

Review DMARC policy strength before a high-volume send.

Public DNS evidence: DMARC/SPF/DKIM status and caveats are visible before you pay.
Owner-ready next step: The audit adds provider context and a verification checklist.

Get the exact fix plan for your domain.$49 readiness audit: prioritized owner actions, DNS evidence, and verification checks.

Get my $49 fix plan View sample

Sender readiness cockpitExample action plan

Public DNS workspace

Overall sender readiness

72/100

Needs attention

Sample output: one warning and one fail mean this domain is not campaign-ready yet.

DMARCPass

SPFPass

DKIMPass

MXPass

BIMIWarning

MTA-STSFail

Fix workspace preview

The scan becomes a focused work surface: evidence, owner action, verification, and the paid context a public lookup cannot infer.

HighDMARC

Review DMARC policy strength before a high-volume send.

Evidence: Evidence: a monitoring-only policy can satisfy visibility needs, but enforcement requires aligned legitimate senders.
Verify after change: Re-scan _dmarc after DNS propagation and confirm aligned SPF or DKIM senders before enforcement.
Paid audit adds: Policy sequence, starter record review, alignment questions, and enforcement caveats.

Get my fix plan

What aggregate reports are

RFC 9990 is the current Standards Track document for DMARC aggregate reporting and obsoletes the aggregate-reporting material that used to live in RFC 7489. The report is an XML document submitted by a receiver to the destination declared in the domain's DMARC policy record.

The useful business signal is not the XML itself. It is the pattern over time: which services send mail as your domain, whether those services authenticate and align, and which failures need to be fixed before moving past monitoring mode.

How to turn reports on

Aggregate reporting is requested with the rua tag in a DMARC TXT record at the _dmarc host for the domain. A cautious starter shape looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the mailbox with one you control, monitor, and can process. If the reporting address is on a different domain, publish the external report authorization record required by the report receiver domain, or receivers may ignore that destination.

What to read first

Source IP and countWhich connecting IP address sent mail claiming the domain, and how many messages matched that report row.

Published policyThe DMARC policy the receiver observed, such as none, quarantine, or reject, plus alignment settings when reported.

SPF and DKIM resultsWhether SPF and DKIM passed for the evaluated identifiers, and whether those identifiers aligned with the visible From domain.

DispositionWhat the receiver reports doing with the matching mail stream, while remembering that other filtering systems can still affect delivery.

Use reports before enforcement

Google recommends monitoring DMARC reports when DMARC is enabled because reports help show authorized services, pass rates, failing services, and receiver actions. That is exactly why p=none is useful at the beginning: it lets you collect real receiver feedback before asking receivers to quarantine or reject failing mail.

Group rows by source IP, sending service, and visible From domain.
Confirm every legitimate newsletter, support, billing, product, and CRM sender.
Fix missing DKIM, SPF alignment, and custom return-path issues before enforcement.
Watch for new or unknown senders after vendor changes and marketing launches.
Keep notes on any receiver override reason before treating a failure as customer fault.

When reports go missing

Missing reports can mean there is no rua tag, the mailbox cannot receive compressed XML attachments, the address is on an unauthorized external domain, the domain has not sent mail to participating receivers recently, or the reports are being filtered away from the mailbox you check.

A SenderReady scan can confirm whether the public DMARC record includes an aggregate reporting destination. It cannot prove that every receiver sends reports, that a mailbox can parse them, or that a third-party DMARC platform has finished onboarding.

DMARC aggregate reports FAQ

Do DMARC aggregate reports prove inbox placement?

No. They show authentication and policy feedback from participating receivers. They do not prove inbox placement, engagement, reputation, or legal compliance.

Should I read raw XML by hand?

Small domains can inspect samples, but regular operations usually need a parser, reporting mailbox, or DMARC service because reports arrive repeatedly and can be hard to compare manually.

Can I send reports to a third-party address?

Yes, but the receiving report domain may need a DNS authorization record. Without that external-destination authorization, receivers can ignore the reporting URI.

Want the report signal turned into a fix plan?

SenderReady readiness audits and monitoring organize public DNS findings into a cautious review packet for your DNS owner or mail administrator. They are diagnostics, not inbox-placement guarantees.

View audit options