DMARC RUA and RUF Explained: Understanding DMARC Reports

Learn what DMARC RUA and RUF tags do, how aggregate and forensic reports differ, and how to set up DMARC reporting for your domain.

DMARC reports are the foundation of email authentication monitoring. Without them, you're flying blind. The rua and ruf tags in your DMARC record control where these reports are sent and what they contain.

RUA vs RUF at a Glance

RUA (Aggregate)RUF (Forensic)
**What it sends**Daily summary of all email activityIndividual failure details
**Format**XML (compressed)Email message format
**Frequency**Daily (default)Per-failure
**Privacy**Anonymized statisticsMay contain message content
**Support**All major providersLimited (many providers don't send)
**Purpose**Monitor trends, find issuesDebug specific failures

RUA: Aggregate Reports

The rua tag tells receivers where to send daily aggregate reports. These are the backbone of DMARC monitoring.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

What's in an Aggregate Report

Each aggregate report is an XML file (usually gzipped) containing:

  • Reporting organization — who sent the report (Google, Microsoft, Yahoo, etc.)
  • Date range — the period covered
  • Your DMARC policy — what policy was published during that period
  • Source IPs — every IP that sent email claiming to be from your domain
  • Authentication results — SPF and DKIM pass/fail for each source
  • Alignment results — whether the domains aligned with your From address
  • Message counts — how many messages from each source

Reading Aggregate Reports

Raw XML reports look like this (simplified):

<record>
  <row>
    <source_ip>203.0.113.1</source_ip>
    <count>1500</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

This tells you: IP 203.0.113.1 sent 1,500 emails for your domain, and they all passed DKIM and SPF.

Multiple RUA Addresses

You can send reports to multiple addresses:

rua=mailto:dmarc@yourdomain.com,mailto:reports@thirdparty.com

This is useful for sending reports to both your inbox and a DMARC analysis service.

Use a dedicated address

Don't send DMARC reports to your personal inbox. Even a moderately busy domain generates dozens of reports daily. Use a dedicated address or a DMARC analysis tool.

RUF: Forensic Reports

The ruf tag tells receivers where to send forensic (failure) reports. These provide details about individual messages that failed DMARC.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com

What's in a Forensic Report

Forensic reports may include:

  • The email headers of the failing message
  • The From, To, and Subject fields
  • Authentication results (SPF, DKIM, DMARC)
  • The source IP
  • Sometimes a redacted copy of the message body

The Reality of RUF

Many email providers don't send forensic reports due to privacy concerns. Google, for example, does not send RUF reports. Microsoft sends limited reports.

Providers that commonly send forensic reports:

  • LinkedIn
  • Some smaller email providers
  • Enterprise email security gateways

Because RUF support is inconsistent, you shouldn't rely on it as your primary monitoring method. Use RUA reports for the big picture and RUF as supplementary data when available.

The fo Tag: Controlling Forensic Reports

The fo tag controls when forensic reports are generated:

ValueMeaning
`0`Generate a report if **both** SPF and DKIM fail (default)
`1`Generate a report if **either** SPF or DKIM fails
`d`Generate a report if DKIM fails (regardless of alignment)
`s`Generate a report if SPF fails (regardless of alignment)

For the most useful forensic data, use fo=1:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1

The ri Tag: Report Interval

The ri tag sets how often aggregate reports are sent, in seconds:

ri=86400

The default is 86400 seconds (24 hours). Some providers support shorter intervals, but most send reports daily regardless of this setting.

Sending Reports to External Domains

If your report address is on a different domain than the one being monitored, the receiving domain needs a special DNS record to authorize it:

Monitored domain: yourdomain.com Report address: reports@analytics.com

The analytics.com domain needs this TXT record:

yourdomain.com._report._dmarc.analytics.com  TXT  "v=DMARC1"

Without this authorization record, providers will not send reports to external addresses.

Setting Up Reports

Basic Monitoring Setup

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Full Reporting Setup

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1

With External DMARC Service

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com,mailto:your-id@service.dmarcanalyzer.com

Use DMARC Creator to build a record with the right reporting configuration for your needs.

Check Your Reporting Setup

Verify your DMARC record has reporting configured correctly:

Monitor Your DMARC Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.

Never miss a DMARC issue

Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.

Start Monitoring