DMARC rua vs ruf: Aggregate vs Forensic Reports Explained
VigilDog Team · October 13, 2026 · 6 min read
When you publish a DMARC record, the `rua` and `ruf` tags decide what feedback you get back from the mailbox providers checking your email. They sound like two flavors of the same thing, but in practice they're wildly different: one is the workhorse that makes DMARC useful, and the other is a rarely-delivered debugging tool most providers refuse to send at all. Here's what each one really gives you and how to set them up.
DMARC reporting in one minute
DMARC lets a domain owner tell receiving mail servers what to do with messages that fail authentication, and, crucially, to send feedback about what they saw. That feedback comes in two channels defined by two tags in your DMARC TXT record: rua for aggregate reports and ruf for forensic (failure) reports. Both take one or more mailto: addresses.
The reason this matters is that DMARC is safe to deploy only if you can *see* who's sending mail as your domain before you start rejecting failures. That visibility is what rua provides, and it's why reporting is the heart of any sane rollout rather than an afterthought. If your SPF, DKIM and DMARC records aren't in order yet, start with fixing the underlying records before you tune reporting.
rua: aggregate reports (the ones that matter)
Aggregate reports are XML files a receiver sends you, typically once a day, summarizing all the mail it saw claiming to be from your domain. Each report groups messages by sending source (IP), and for each source it tells you how many messages passed or failed SPF and DKIM, whether they aligned with your domain, and what DMARC policy was applied. There is no message content and no recipient data, it's counts and authentication results, not mail.
This is the data you actually act on. It reveals every system sending as you: your ESP, your CRM, that forgotten invoicing tool, and any spoofer. You use it to find legitimate sources that aren't authenticating yet, fix their SPF/DKIM, and confirm alignment before tightening policy. Raw aggregate XML is dense and gzipped, so nearly everyone feeds it into a processor rather than reading it by hand, you can drop a record into the DMARC checker to confirm your reporting addresses are even valid.
ruf: forensic / failure reports (rarely delivered)
Forensic reports are the opposite in shape: one report per failing message, sent close to real time, containing a redacted copy of the message that failed, headers, and sometimes body fragments. On paper this is great for debugging a specific spoofing incident or a misconfigured sender, because you see the actual failing message rather than a daily count.
In reality, ruf is mostly theoretical. The major receivers, Gmail, Microsoft, Yahoo, do not send forensic reports, largely because those reports can contain personal data from real messages and third parties, which is a privacy and GDPR minefield. So even with a perfectly configured ruf address, you'll receive few or none. Treat it as an occasional bonus from smaller providers, not a data source you can plan around, and remember that anything you do receive may contain PII you're now responsible for.
Configuring both tags correctly
A record using both looks like: v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; ri=86400. The fo tag controls when failure reports are generated (1 = on any SPF or DKIM failure, which is the useful setting), and ri sets the aggregate reporting interval in seconds (86400 = daily, the de facto standard regardless of what you request).
One gotcha trips up almost everyone: if your report addresses are on a *different* domain than the one publishing the DMARC record, the receiving domain must authorize it. The report-destination domain needs a TXT record at example.com._report._dmarc.<reportdomain> with the value v=DMARC1;. Without it, receivers will refuse to send reports to that address. This is exactly what breaks reporting when you point rua at a third-party analytics vendor.
Which should you actually use?
The practical answer: always publish rua, and treat ruf as optional with low expectations. Aggregate reports give you everything you need to move safely from p=none to quarantine to rejectsee your senders, authenticate them, watch failures drop, then tighten. Forensic reports add marginal debugging value on the rare occasions they arrive, at the cost of handling potentially sensitive data.
If you're planning that journey to an enforcing policy, our p=reject rollout guide walks through the staged approach using aggregate data as your safety net. The reports are the map; don't turn on enforcement until you've read them.