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

Configuring RUA and RUF in the DMARC record

Both addresses are configured in the _dmarc record:

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

• rua=: the destination address for aggregate reports. Several can be listed, 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.

Where RUF isn't wanted (by compliance choice, or simply because nobody reads them), omitting ruf= and fo= is enough. The aggregate report (RUA) is the real value.

How reports drive the progression toward p=reject

The primary value of DMARC reports isn't confirming that the mail passes — it's showing how to make it pass. An RUA report is a map of the sending flows: each <record> block is a source, and its authentication result names exactly what needs fixing. The process is iterative by nature.

At the start, with p=none, the reports arrive without anything being blocked. That's the observation phase: it reveals which IPs send in the domain's name, which pass, which fail, and which nobody even knew about. Legitimate sources then get fixed one by one — enabling DKIM, aligning SPF, excluding unknown sources — with the reports watched to confirm each fix took hold.

Once reports show the vast majority of legitimate sources passing (typically >95%), the policy moves to p=quarantine. The same logic applies: watching the reports, verifying that no legitimate source is impacted, refining. Then comes p=reject. At each step, RUA reports are the measurement instrument: they say where the rollout stands, not just whether it passes or breaks.

Identifying the sources in the reports

A raw report gives an IP. A well-used report gives the owner of 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), though a few key IPs can also be handled by hand via reverse resolution tools.

IPs that consistently show dkim=pass, spf=pass, dmarc=pass are the well-configured sources — they need nothing. IPs that consistently fail on a recognized source are the correction priorities. Unknown IPs with dmarc=fail are either forgery (nothing to do, p=reject handles it) or a forgotten legitimate source (to fix, or to confirm as decommissioned).

What actually needs doing

For the vast majority of deployments, RUA reports are more than enough. They give a complete view of who sends in the domain's name, with what results, from which IPs. Analyzing them regularly — or handing that job to a tool, or to Thomas — names the sources to fix, in what order, and the moment the policy is ready to tighten.

RUF reports are useful for diagnosing a very specific problem: a particular type of message that fails, an unknown source sending in the domain's name. But they should only be opened with their potentially sensitive content in mind, and above all never forwarded to third parties without a check on what they contain.

Frequently asked questions

Is ruf= necessary? No. RUA reports are sufficient for the vast majority of cases. ruf= is worth configuring only where a specific forensic diagnostic need exists and the privacy implications have been assessed.

How long before the reports arrive? A few hours to 24 hours after the DMARC record goes live. The first ones often land 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 — a reason to handle them with care.

Can reports go to an external address? Yes, but the receiving address's domain must be authorized via a TXT record at _dmarc.external-domain.com. For an address on the domain itself, it's automatic.

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

Are both rua= and ruf= needed? No. rua= is the important one for day-to-day monitoring. ruf= is optional and only worth configuring where a specific forensic diagnosis need exists and the GDPR implications have been assessed (see forensic reports and privacy).

Reading the first RUA reports: a practical approach

The first DMARC report to land is not the one to read <record> by <record> in detail. A quick triage comes first: how many records are there, and how many show dmarc=fail in policy_evaluated? Records that mostly show pass mean the posture is sound and the remaining work is in the details. Records that mostly show fail mean the configuration is still early in its life — and the report is the roadmap out.

For each failing record, the diagnostic path is the same: auth_results shows whether SPF or DKIM failed, header_from confirms alignment, and source_ip says whether this is a legitimate source (to fix) or an unknown one (to leave to the policy once it reaches 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: p=none + rua= published, one week of waiting, then a first read of the reports. Every sending source gets identified (one by one if needed) and fixed: DKIM alignment enabled, SPF records updated, CNAME selectors configured for the platforms that support them. The reports get re-read after each fix. A source that consistently shows dmarc=pass for several days is ready. Only once all legitimate sources pass consistently — ideally 95%+ of the message volume — does the policy move to p=quarantine. Then the same monitoring repeats. Then p=reject. That's the full journey, and RUA reports are the compass at every step.

Letting Thomas read the reports

Receiving RUA reports is one thing; making use of them is another. Thomas, the virtual CISO, reads the reports instead, names 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 a domain for free or create an account for DMARC reports decoded automatically.