What Is a DMARC RUA Aggregate Report?

What a DMARC RUA aggregate report is

A DMARC RUA aggregate report is a machine-readable summary that shows which sources sent mail using your domain and whether that mail passed SPF, DKIM, and DMARC alignment.

In a DMARC record, rua= lists one or more reporting URIs for aggregate feedback, usually mailto: addresses. A basic monitoring record looks like v=DMARC1; p=none; rua=mailto:dmarc@example.com. That address is where participating receivers can send summary reports about mail that used your visible From domain.

The report is an XML document, commonly delivered as a compressed attachment. Many large receivers send reports daily or more often, but reporting is voluntary and not universal. The current IETF references are RFC 9989 for the DMARC protocol and RFC 9990 for aggregate reporting. Those 2026 RFCs replace the relevant parts of RFC 7489. SPF is defined in RFC 7208 and DKIM in RFC 6376.

A RUA report is not a copy of your campaign or a per-recipient delivery log. It normally does not include message bodies, subject lines, or full recipient addresses. It can still reveal sending sources, domains, authentication results, and volume patterns, so route reports to a mailbox or processor you trust.

What the report shows

The useful parts are the sending source, the authentication result, the visible From domain, and the policy action the receiver applied or reported.

A typical report includes metadata about the reporting organization, the report time range, the policy found in DNS, and rows for groups of messages. Each row usually has a source IP address, a count, the DMARC disposition, the header From domain, SPF results, DKIM results, and whether each authenticated domain aligned with the visible From domain.

DMARC passes when SPF or DKIM passes and the passing authenticated domain aligns with the domain in the visible From header. SPF checks whether the sending IP is authorized by the envelope sender domain used in SMTP. DKIM checks whether the message has a valid signature from the domain in the d= value, using the selector in the s= value to find the public key. DMARC ties those results back to the domain people actually see in their mail client.

This is why RUA data matters. If your CRM, help desk, billing tool, and newsletter provider all send as your domain, the report shows which sources are passing and which are failing authentication or alignment. Without that evidence, moving from p=none to p=quarantine or p=reject is guesswork.

How to use RUA data without breaking mail

Start with monitoring, identify every legitimate sender, fix alignment, then enforce DMARC only after the report data is boring.

• Publish one DMARC TXT record at _dmarc.yourdomain. Start active domains with p=none and a RUA mailbox or reporting service.
• Collect reports across a normal sending cycle. Include newsletters, invoices, password resets, support mail, sales tools, and any vendor that sends as your domain.
• Map every known source IP or provider to a real system. Unknown high-volume sources may be spoofing, shadow IT, or a vendor you forgot.
• Fix SPF by keeping a single SPF record, using only the mechanisms and includes your senders require, avoiding +all, and staying within the RFC 7208 limit of 10 DNS-querying mechanisms and modifiers during evaluation. ~all returns softfail and is common during transition. -all returns fail and is stricter once the sender list is complete.
• Fix DKIM by enabling signing in each sender and publishing the selector records they give you. DKIM is often more stable than SPF for forwarded mail because forwarding can change the connecting IP and break SPF.
• Check DMARC alignment. Passing SPF or DKIM is not enough if the authenticated domain does not align with the visible From domain.
• Move gradually to p=quarantine, then p=reject only when legitimate mail is passing. Use reports to catch drift after every vendor or DNS change.

If the RUA destination is on a different domain from the protected domain, receivers may require the reporting destination domain to publish an authorization record before sending reports. That prevents one domain from forcing report traffic onto someone else's mailbox.

Where deliverability fits

DMARC reports do not decide inbox placement by themselves, but they show authentication signals Gmail, Outlook, and other providers use before reputation gets a fair chance.

Mailbox providers route unauthenticated or suspicious mail to spam, junk, or rejection because they need to protect users from spoofing, phishing, and abuse. Google sender guidelines say authenticated messages are less likely to be rejected or marked as spam, require SPF or DKIM for all senders, and require SPF, DKIM, and DMARC for bulk senders. Microsoft's email authentication guidance explains the same SPF, DKIM, and DMARC alignment model. None of that guarantees the inbox. Complaints, sending history, list quality, content, volume patterns, and recipient engagement still matter.

RUA reports are most useful when combined with the rest of the domain setup. SPF should authorize the right mail sources without exceeding the lookup limit. DKIM should sign every major stream with working selectors. DMARC should publish a clear policy. MX records are not a DMARC pass condition, but they matter because your domain should be able to receive replies, bounces, and operational mail. Blocklists are separate from DMARC, but a listed IP or domain can still pull authenticated mail toward spam.

You can check the public pieces in one pass with the free InboxRadar domain scorecard. It grades SPF, DKIM, DMARC, MX, and blocklist signals, then watches for drift so a deleted selector or broken SPF include does not sit unnoticed for weeks. For related setup help, see the InboxRadar guides.