DMARC reports: RUA vs RUF, what's the difference?

When you publish a DMARC record, you can ask to receive reports on your email authentication. But there are two very different types: RUA (aggregate reports) and RUF (forensic reports). Confusing them is common, and choosing wrong can leave you with either too little information to diagnose problems, or too much — with real privacy risks. This guide explains the difference, what each contains, how to configure them, and how to use them to progress toward p=reject.

RUA: aggregate reports, the flight statistics

RUA (Reporting URI for Aggregate) reports are sent by ISPs and major mailbox providers (Gmail, Yahoo, Outlook…) to the email address you specify. They summarize, for each sender, the authentication results observed over a period (often 24 hours): how many messages passed SPF, DKIM, DMARC, from which IP, with what result.

These are compressed XML files, sent daily by each receiver that chooses to send them. A typical RUA report says something like: "347 messages from IP 40.107.1.25 with spf=pass, dkim=pass, dmarc=pass — and 12 messages from 192.0.2.1 with spf=fail, dkim=fail, dmarc=fail."

They contain no message content: no subject, no body, no recipient address. Only statistical metadata. That's why RUA reports are both useful (global view) and GDPR-compliant (no personal data of recipients).

RUF: forensic reports, the detail of a failure

RUF (Reporting URI for Forensic) reports are an entirely different beast. Also sent to an address you choose, they are triggered by an individual event: a message that failed authentication. Each RUF report describes that failure in detail, and depending on the receiver's implementation, may include full message headers or even a body excerpt.

That's much more granular — and much more sensitive. An RUF report can contain the sender's email address, the subject line, the originating IP, and other metadata from the failed email. That's useful for diagnosing a specific problem ("why did this exact message fail?"), but it raises serious privacy and GDPR compliance questions — especially if the failed email came from a real user (see forensic reports and privacy).

Another reality: most major providers (Google, Microsoft, Yahoo) no longer send RUF reports. Google stopped in 2023. Forensic report support is much less universal than aggregate reports. In practice, you receive RUA from almost everyone, and RUF from only a handful of actors.

Configuring RUA and RUF in your DMARC record

Both addresses are configured in your _dmarc record:

_dmarc.your-domain.com.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:dmarc@your-domain.com;
   ruf=mailto:ruf@your-domain.com; fo=1"

• rua=: the address where you want to receive aggregate reports. You can list several, comma-separated.
• ruf=: the address for forensic reports. Often different, sometimes absent.
• fo=: controls when an RUF is generated. fo=0 (default) = only if all checks fail. fo=1 = as soon as any check fails. fo=d = only if DKIM fails. fo=s = only if SPF fails. In practice, fo=1 gives the most detail, but also the most volume.

If you don't want RUF (by compliance choice, or because you don't use them), simply omit ruf= and fo=. The aggregate report (RUA) is the real value.

How reports help you progress toward p=reject

The primary value of DMARC reports isn't confirming that your emails pass — it's showing you how to make them pass. An RUA report is a map of your sending flows: each <record> block is a source, and its authentication result tells you exactly what to fix. The process is iterative by nature.

At the start, with p=none, you receive reports without anything being blocked. That's the observation phase: you discover which IPs send in your name, which pass, which fail, and which you didn't even know about. You fix legitimate sources one by one — enabling DKIM, aligning SPF, excluding unknown sources — and watch reports to confirm each fix took hold.

Once reports show the vast majority of your legitimate sources pass (typically >95%), you move to p=quarantine. The same logic applies: watch reports, verify no legitimate source is impacted, refine. Then you move to p=reject. At each step, RUA reports are your measurement instrument: they tell you where you are, not just whether it passes or breaks.

Identifying sources in your reports

A raw report gives you an IP. A well-used report tells you who owns that IP. That conversion — IP → identified sending service — is what turns a report into an action plan. DMARC tools do this work automatically (see tools for analyzing reports), but you can also do it manually for a few key IPs via reverse resolution tools.

IPs that consistently show dkim=pass, spf=pass, dmarc=pass are your well-configured sources — don't touch them. IPs that consistently fail on a source you recognize are your correction priorities. Unknown IPs with dmarc=fail are either forgery (no action on your part, let p=reject do its work) or a legitimate source you'd forgotten (fix it or confirm it's decommissioned).

What you should actually do

For the vast majority of deployments, RUA reports are more than enough. They give a complete view of who sends in your name, with what results, from which IPs. Analyzing them regularly (or having a tool or Thomas analyze them for you) tells you which sources to fix, in what order, and when you're ready to tighten your policy.

RUF reports are useful if you need to diagnose a very specific problem: a particular type of message that fails, an unknown source sending in your name. But open them only knowing their potentially sensitive content, and especially don't forward them to third parties without checking what they contain.

Frequently asked questions

Do I need to configure ruf=? No. RUA reports are sufficient for the vast majority of cases. Configure ruf= only if you have a specific forensic diagnostic need and have assessed the privacy implications.

How long before I receive reports? A few hours to 24 hours after publishing your DMARC record. The first reports often arrive the next morning.

Do reports come from all receivers? No. Only from actors that have implemented the protocol. Gmail and Microsoft send very reliable reports; many small servers don't send any.

Do RUA reports expose personal data? No: aggregate reports contain statistics and IPs, but not message content or recipient addresses. RUF reports may contain that data — handle with care.

Can I receive reports at an external address? Yes, but the receiving address's domain must be authorized via a TXT record at _dmarc.external-domain.com. If the address is in your own domain, it's automatic.

How often are reports sent? Usually once per day per ISP, regardless of your ri= setting (see the reporting interval). The ri= tag expresses a preference, not a requirement — ISPs apply their own cadence, almost always daily.

Do I need to configure both rua= and ruf=? No. rua= is the important one for day-to-day monitoring. ruf= is optional and should only be configured if you have a specific forensic diagnosis need and have assessed the GDPR implications (see forensic reports and privacy).

Reading your first RUA reports: a practical approach

When you receive your first DMARC report, resist the urge to read every <record> in detail. Instead, start with a quick triage: how many records are there, and how many show dmarc=fail in policy_evaluated? If most of your records show pass, you're in good shape and the work is in the details. If most show fail, you're still early in the configuration process — and the report is your roadmap.

For each failing record, the diagnostic path is the same: check auth_results to understand whether SPF or DKIM failed, check header_from to confirm alignment, and check source_ip to understand whether this is a legitimate source (to fix) or an unknown one (to let your policy handle when it's at reject). Most configurations take 4-6 weeks of report reading and source correction to reach a state where the majority of traffic passes — that's normal, not a problem.

The progressiont from p=none to p=reject in practice

DMARC reports aren't just diagnostic tools — they're the feedback loop that makes progression possible. Without them, moving from p=none to p=quarantine or p=reject would be a leap of faith. With them, each tightening of policy is supported by data.

The typical progression: publish p=none + rua=, wait one week, read reports. Identify your sending sources (one by one if needed). Fix each one: enable DKIM alignment, update SPF records, configure CNAME selectors for platforms that support it. Read reports again after each fix. When a source consistently shows dmarc=pass for several days, it's ready. Only once all legitimate sources pass consistently — ideally 95%+ of your message volume — do you move to p=quarantine. Then repeat the same monitoring. Then p=reject. That's the full journey, and RUA reports are the compass at every step.

Let Thomas read your reports for you

Receiving RUA reports is one thing; making use of them is another. Thomas, your virtual CISO, reads your reports in your place, tells you which sources pass, which fail, why, and in what order to fix them. He turns raw XML into a clear action plan toward p=reject.

Analyze your domain for free → or create an account for DMARC reports decoded automatically.