DMARC monitoring: making sense of aggregate reports (RUA)

So, you added rua=mailto:[email protected] to your DNS record. You expected clear reports on who is sending email as you.

Instead, your inbox is now being flooded with attachments named google.com!yourdomain.com!1712345600.zip containing unreadable XML files.

This is the “XML firehose.” And without a plan, it is useless.

What is a DMARC aggregate report? A DMARC aggregate report (RUA) is an XML summary that mail receivers such as Google, Yahoo, and Microsoft send to the address in your record’s rua= tag, at least daily per RFC 9989. It lists every source IP that sent mail claiming to be your domain, with message counts and SPF/DKIM results for each source. It contains statistics only, never the emails themselves. Message copies belong to the separate RUF failure-report channel, which is mostly dead.

1. What you actually receive (the RUA report)

DMARC aggregate reports (RUA) are not real-time alerts. They are batched summaries. The spec (RFC 9989 §8) says receivers should send them at least daily, and one report per receiver per day is what you will see in practice. (The old ri= tag that let you request a different interval was removed in DMARCbis; daily is now simply what you get.) Each report tells you:

• “Yesterday, we saw 5,000 emails claiming to be from you.”
• “4,950 came from your SendGrid IP (SPF pass, DKIM pass).”
• “50 came from a suspicious IP in Middle East (SPF fail, DKIM fail).”

The problem? It’s all wrapped in XML tags that are impossible for humans to parse quickly. Turning that XML into a per-source table you can act on is exactly what DMARCTrust’s reports view does.

2. Triage: what to ignore vs. what to panic about

When you use a tool (like DMARCTrust or open-source parsers) to visualize this data, you need a triage workflow.

Don’t panic

Forwarding artifacts are common. If you see weird failures from university domains or ISPs, it’s likely the forwarding issue we discussed previously.

SPF failures with DKIM passes are also normal for services like Gmail or Office 365. As long as DKIM aligns, DMARC passes. You are safe.

Do panic (investigate)

A new high-volume sender deserves immediate attention. If 10,000 emails suddenly appear from an IP identifying as “Mailgun” when you don’t use Mailgun, you’re looking at either spoofing or (most likely) Shadow IT.

SPF PermError means your DNS record might be broken. If you see “PermError” or “TempError”, check for too many lookups in your SPF record using our SPF generator.

DKIM pass with alignment fail is the “Shadow IT” killer. Someone is sending validly signed email, but using their domain (d=mailchimp.com), not yours.

3. The “external report” gotcha

A common mistake: You own mybrand.com, but you want reports sent to [email protected].

You set rua=mailto:[email protected].

Result: No reports arrive.

Why? To prevent spam, myholdingco.com must explicitly say “Yes, I agree to receive reports for mybrand.com.” You need to publish a special DNS record at the destination domain (RFC 9990 keeps the same mechanism RFC 7489 used):

mybrand.com._report._dmarc.myholdingco.com TXT "v=DMARC1"

Without this “external domain verification,” major receivers will silently drop the reports.

4. RUF failure reports (forensic reports): the ghost feature

You might have seen the ruf= tag. It requests failure reports. These are redacted copies of individual messages that failed DMARC, and most people still call them forensic reports. The current spec, RFC 9991, says “failure report” throughout; “forensic” survives as the everyday name because these reports exist for forensic analysis of individual failures.

Reality check: don’t hold your breath. RFC 9991 itself notes that many large-scale providers limit or entirely disable failure report generation, because a failure report can carry message bodies and headers full of PII. Google, Yahoo, and Microsoft simply do not send RUF reports.

Focus 99% of your energy on RUA (aggregate) reports.

5. DIY vs. SaaS

Can you do this yourself? Absolutely. Tools like parsedmarc (Python) are excellent. They can read from an IMAP inbox, parse the XML, and dump it into Elasticsearch or Grafana. You can even use our DMARC report analyzer to manually inspect individual reports.

But be warned: the maintenance burden is real. Handling gzipped attachments, zips, corrupted XML, and non-standard reports from small ISPs is a constant battle. That’s why services like ours exist: to abstract away the parsing pain so you can focus on the security decisions. You might want to use us for a few months and see if it’s worth enduring the pain of doing all the IT admin stuff yourself.

FAQ: quick answers

What is an RUA report?

An RUA report is a DMARC aggregate report: an XML summary of all traffic claiming to be from your domain, sent at least daily by participating email providers. The rua tag in your DMARC record lists the addresses these aggregate feedback reports go to (RFC 9989 §4.7).

What is a DMARC forensic report?

“Forensic report” is the common name for a DMARC failure report, requested with the ruf= tag: a per-message report, based on ARF, for an individual email that failed DMARC. RFC 9991 calls them failure reports, and most major mailbox providers do not send them at all.

Why are some receivers missing?

Not everyone sends DMARC reports. Google, Yahoo, and Microsoft do. Many smaller ISPs do not.

Why is SPF failing only in reports?

This often happens with forwarding. The IP address reported is the forwarder’s IP, which isn’t in your SPF record. If DKIM passes, DMARC still passes.