DMARC aggregate vs forensic reports: what RUA and RUF actually do

When you publish a DMARC record, two tags control where reports go: rua and ruf. They look similar and sit next to each other in the same line of DNS, but they do very different jobs. One is the foundation of every DMARC deployment. The other barely exists in practice. This post explains both honestly, so you know what you are actually getting and what you are not.

If you want a refresher on the record itself first, our DMARC record syntax explained guide covers every tag. Here we focus on the two reporting tags and the data behind them.

The two report types, in plain terms

DMARC, as defined in RFC 7489, defines two feedback mechanisms:

• Aggregate reports (rua) - regular summaries, usually daily, of every source that sent email claiming to be from your domain, and whether that email passed or failed SPF, DKIM and DMARC alignment.
• Forensic, or failure, reports (ruf) - individual reports generated at the moment a specific message fails DMARC, intended to contain detail about that single message.

The names matter less than the difference in what they tell you. Aggregate reports show you patterns across all your mail. Forensic reports were meant to show you the specifics of individual failures.

Aggregate reports (RUA): the part that does the work

Aggregate reports are the engine of DMARC. They arrive as XML files, usually once a day, from each receiving provider that processes your mail - Google, Microsoft, Yahoo and so on. Each report covers a 24-hour window and is grouped, or aggregated, by sending source.

For each source IP address, an aggregate report tells you:

• How many messages were sent from that IP claiming to be your domain
• Whether SPF passed and whether the SPF domain aligned with the From address
• Whether DKIM passed and whether the signing domain aligned
• The overall DMARC result, pass or fail
• The policy the receiver applied (none, quarantine or reject)

Crucially, aggregate reports contain no message content and no subject lines. They are statistical summaries built from email headers, not copies of your mail. That is why they are safe to collect at scale and form the basis of a normal DMARC rollout. For a deeper walkthrough of the fields, see what a DMARC report actually shows.

This is the data you use to build your list of legitimate senders, spot spoofing, and move safely towards enforcement. You cannot get to p=reject safely without reading aggregate reports first.

Why the raw XML is unreadable by hand

A single day can produce dozens of reports from different providers, each one nested XML referring to IP addresses rather than service names. A busy domain generates more of this than any person can usefully read. This is the entire reason DMARC monitoring services exist: to parse the XML, resolve IPs to recognisable senders, and present the data as something you can act on rather than a folder of attachments.

Forensic reports (RUF): the part that mostly does not happen

Forensic reports were designed to give you the detail aggregate reports leave out. When a message failed DMARC, the receiver would send a copy of that message, or large parts of it, back to the address in your ruf tag. In theory this lets you see exactly what a spoofed message looked like.

In practice, almost no major receiver sends them. Here is why.

• Privacy and data protection. A forensic report can contain the headers and sometimes the body of a real email, including personal data and recipient addresses. Sending that to a third party raises obvious problems under UK GDPR. Most large providers - Google and Microsoft included - decided years ago not to send forensic reports at all rather than carry that risk.
• Volume and abuse. A spoofing campaign can generate enormous numbers of failures, and sending a report per failure can flood the recipient.
• Limited extra value. Aggregate reports already tell you which sources are failing. The forensic copy adds detail, but for most organisations it is detail they never needed.

The result is that even if you set a ruf tag, you will likely receive few or no forensic reports. Setting one is not wrong, but you should not rely on it or assume its absence means something is broken.

If you do set ruf, set it carefully

Because forensic reports can carry personal data, you should only point ruf at an address you control on the same domain, and you should treat any reports that do arrive as sensitive. The few providers that still send them often redact the content heavily anyway. The NCSC email security guidance reflects the wider industry position: aggregate reporting is the practical mechanism, and forensic reporting is optional and inconsistent.

What to put in your record

A typical, sensible configuration looks like this:

• rua - set to the reporting address your monitoring service gives you, so aggregate data flows from day one
• ruf - either omitted entirely, or set only if you have a specific reason and a controlled mailbox to receive it

If you are publishing a record for the first time, the honest default is: configure rua, leave ruf out, and do not worry that you are missing anything important. The aggregate stream is where the value is.

Where the data goes after it arrives

Aggregate reports are summaries, but they still describe your sending infrastructure and the sources spoofing you, so it is reasonable to ask where that data is processed and stored. We set out our own approach in what happens to your DMARC data. The short version: aggregate XML is low-sensitivity because it contains no message content, but it should still be handled by a provider that is clear about retention and location.

The honest summary

Aggregate reports (RUA) are the working part of DMARC. They tell you who is sending in your name, whether it passes, and what receivers are doing about it - all without exposing message content. Forensic reports (RUF) were a good idea that data protection concerns and provider caution have largely retired. Configure the first, treat the second as a bonus that probably will not come, and judge your DMARC progress on the aggregate data you can actually read.