RUA vs RUF: DMARC report types

Updated 2026-08-03 · DMARC Fundamentals

A DMARC record can ask receivers for two very different kinds of feedback, requested by two different tags: rua for aggregate reports and ruf for forensic reports (also called failure reports). The names are similar; the reality could hardly be further apart. One is the foundation of every DMARC deployment. The other is a privacy-sensitive extra that, in practice, you will rarely receive.

Knowing the difference saves you both confusion and wasted effort — so here it is, honestly.

Aggregate reports (rua): the statistics that matter

Aggregate reports are the feedback loop that makes DMARC work. Add a rua=mailto: address to your record, and mail operators that evaluate your domain start sending you XML summaries — typically one per operator per day, each covering a 24-hour window.

An aggregate report answers, per sending IP address: how many messages arrived claiming to be your domain, whether SPF and DKIM passed, which domains they passed for, whether alignment held, and what the receiver did with failing mail. In other words: who sends as you, how much, and whether it authenticates.

Physically, each report is an email with a compressed attachment — a gzip or ZIP file containing one XML document. The attachment names alone tell a story: reporter, your domain, and the epoch timestamps of the reporting window, all packed into the filename.

Three properties make aggregate reports the workhorse:

• They are safe. No message content, no subject lines, no recipient addresses — only authentication statistics. You can collect and analyse them without touching anyone's private correspondence.
• They are comprehensive. Every message the reporter evaluated is counted — passing and failing, legitimate and forged — so you see your whole sending estate, including the services you forgot about.
• They are widely sent. Reporting is voluntary, but most large mailbox providers — Google, Microsoft, Yahoo and many others — send aggregate reports reliably. For a typical domain, that covers the bulk of real-world delivery.

The catch is the format: compressed XML attachments arriving daily from every reporting operator. Nobody reads those by hand at any real scale — How to read a DMARC report dissects one so you can, and the closing section of this article covers the sane alternative.

Forensic reports (ruf): per-message copies, rarely sent

Forensic reports are a different animal entirely. Where rua delivers daily statistics, ruf asks receivers to send you a redacted copy of each individual message that fails DMARC, in near real time.

That sounds wonderful for debugging — an actual failing message, headers and all. In practice, three things get in the way:

• Most major providers simply do not send them. A forensic report can contain personal data: sender and recipient addresses, subject lines, sometimes message fragments. Privacy law and internal policy have led most large operators to disable ruf reporting entirely, regardless of what your record requests.
• What does arrive is patchy. The few operators that send failure reports redact them to varying degrees and cover only a slice of traffic — you cannot treat the stream as complete or representative.
• You inherit a data-handling burden. If forensic reports do arrive, you are now storing other people's message metadata. That mailbox needs the same care as any store of personal data.

None of this makes ruf useless — a well-timed forensic report can occasionally pinpoint a misconfiguration faster than aggregate data. But it is an optional extra, not a foundation. If you request it, treat anything that arrives as a bonus.

Side by side

Which should you request?

Request rua, always. Without it you are flying blind: no visibility into which senders fail, no evidence for tightening your policy, no warning when spoofing starts. Every DMARC record should carry a rua address from day one — it is the difference between having DMARC and merely having a DNS record.

Treat ruf as optional. If you have a process for handling sensitive data and a specific debugging need, request it and accept that little may arrive. If you are unsure, leave it out — you lose almost nothing, because everything you need for a safe policy rollout is in the aggregate data.

In record form, the two requests sit side by side as the rua and ruf tags:

_dmarc.example.com.   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]"

Not sure what your current record requests? Run your domain through the free DMARC checker — it prints the raw record, so you can read both tags off it, and explains the rua address it finds, no sign-in needed.

A record with only the rua tag is complete and normal; a record with only ruf is a red flag, because it requests the rarely-sent report type while declining the essential one. The full tag syntax, including the fo= options that fine-tune failure reporting, is covered in DMARC record tags explained.

Where DMARCmetric fits

DMARCmetric parses aggregate (rua) reports — the type that gives you the full picture of your sending estate, and the type mailbox providers actually send at scale. You point the rua address in your DMARC record at us; we receive the XML, validate and parse it, and turn the daily stream into per-sender dashboards, alignment verdicts and policy guidance.

If untangling compressed XML by hand does not appeal, create a free account and let the reports flow — or see what parsed reports look like first in the live demo.