DMARC produces two kinds of feedback, and the rua and ruf tags decide which you receive. Aggregate reports (rua) are daily XML summaries of every source sending as your domain, and they are the backbone of any DMARC deployment. Failure reports, also called forensic reports (ruf), are per-message samples of individual emails that failed authentication, and most large mailbox providers no longer send them for privacy reasons. For nearly all domains, rua is the tag that matters and ruf is optional.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
The two report types at a glance
DMARC was originally defined in RFC 7489 (2015) and was updated in 2026 by the DMARCbis specifications: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. In every version, the protocol asks receiving mail servers to send feedback to the domain owner, and that feedback comes in two formats with very different purposes.
| Attribute | Aggregate (rua) | Failure / forensic (ruf) |
|---|---|---|
| What it contains | Counts of messages grouped by sending IP, with SPF, DKIM, and DMARC results | A single failed message: headers, and sometimes subject and body |
| Format | XML, usually gzip compressed | AFRF, based on ARF (RFC 6591 and RFC 5965) |
| Cadence | Once per day per receiver (default) | Near real time, per failing message |
| Personal data | None. Only metadata and counts | High. Can expose recipient addresses and content |
| Who sends them | Google, Yahoo, Microsoft, and most large receivers | Very few receivers; almost none of the large ones |
| Primary use | Ongoing monitoring and reaching enforcement | Deep debugging of a specific failure |
The short version: aggregate reports tell you what is happening across all of your mail, and failure reports tell you exactly what one broken message looked like. You build a DMARC program on the first and occasionally supplement it with the second.
Aggregate reports (rua): the workhorse
An aggregate report is an XML document a receiver sends, typically once every 24 hours, summarizing all the mail it saw claiming to be from your domain. It does not contain message content. Instead it groups messages by source IP address and reports, for each group, how many messages passed or failed SPF, how many passed or failed DKIM, and how DMARC alignment resolved.
That structure is what lets you see your entire sending ecosystem: your own mail servers, your marketing platform, your helpdesk tool, and any spoofer or misconfigured forwarder using your domain. Each record also carries the policy the receiver applied, so you can confirm whether your published p= value is actually being honored. Because the data is counts rather than content, aggregate reports carry no meaningful privacy risk, which is why essentially every major receiver sends them.
You add aggregate reporting with the rua tag in your DMARC record:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
A few details worth knowing:
- You can list multiple destinations separated by commas, for example
rua=mailto:reports@example.com,mailto:vendor@dmarc-vendor.com. - The optional
ritag sets the requested reporting interval in seconds. The default is86400(one day). Most receivers send daily regardless of what you request, soriis rarely worth setting. - The raw XML is tedious to read by hand. A parser or dashboard turns it into something usable. See our guide on how to read a DMARC aggregate report at /en/guides/how-to-read-dmarc-aggregate-report.
Aggregate reports are how you move safely from p=none to enforcement. You watch until every legitimate source aligns, fix the ones that do not, and only then tighten the policy. That progression is covered in /en/guides/how-to-move-dmarc-from-none-to-reject. If reports show mail failing even though the sender authenticates correctly, the cause is usually alignment rather than a broken signature, which is a separate diagnosis explained in /en/guides/dmarc-relaxed-vs-strict-alignment.
Failure reports (ruf): detailed but rarely delivered
A failure report is generated the moment a single message fails DMARC evaluation at a participating receiver. Rather than a daily summary, it is a copy or partial copy of the offending email, sent in the AFRF format (Authentication Failure Reporting Format, RFC 6591), which extends the Abuse Reporting Format (ARF, RFC 5965) with authentication-specific fields.
The appeal is obvious. Instead of seeing that IP 203.0.113.5 failed DKIM 40 times, you see the actual headers of one of those messages. You can read the From header, the Authentication-Results header, the sending path, and often the Subject. That makes failure reports genuinely useful for one job: diagnosing why a specific legitimate source is failing when aggregate data alone does not explain it.
You request failure reports with the ruf tag, and you shape them with the fo (failure options) tag:
v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; fo=1
The fo tag controls when a report is generated. It is ignored unless a ruf tag is also present.
fo value | When a failure report is generated |
|---|---|
0 (default) | Only when all authentication mechanisms fail to produce an aligned pass |
1 | When any mechanism produces something other than an aligned pass |
d | When a DKIM signature fails evaluation, regardless of alignment |
s | When SPF fails evaluation, regardless of alignment |
fo=1 is the most informative setting because it flags a message even when one mechanism passed, which is exactly the situation where a source is half-configured. You can combine values with colons, for example fo=d:s. There is also an rf tag for report format; its default is afrf, and there is no practical reason to change it.
Why Google and Yahoo do not send RUF
Here is the catch that surprises people who carefully add a ruf tag and then wait for reports that never arrive. The large mailbox providers do not send them.
The reason is privacy. A failure report can contain the recipient address, the subject line, and message headers that reveal personal or confidential information. Forwarding that data to whatever address is listed in a ruf tag, potentially in another jurisdiction, conflicts with data protection obligations such as the GDPR. Google has never sent forensic reports. Yahoo and Microsoft do not send them to arbitrary domains either. The result is that the receivers responsible for the overwhelming majority of consumer inboxes contribute nothing to your ruf stream.
Some smaller or enterprise receivers still send failure reports, sometimes with sensitive fields redacted. So a ruf tag is not useless, but you should treat any forensic data you receive as an occasional bonus, never as a monitoring foundation. Any product sold on the promise of rich forensic visibility is describing a capability that the real world stopped delivering years ago.
Which should you use?
For the vast majority of domains, the answer is straightforward.
- Always set
rua. Aggregate reporting is the core of DMARC monitoring. Without it you are enforcing a policy blind. If you have no DMARC record yet, start at /en/guides/how-to-set-up-dmarc, and if a scan says you are missing one, see /en/guides/fix-no-dmarc-record. - Add
rufonly if you have a specific reason and can handle the data. A good reason is actively debugging a stubborn alignment failure at a receiver you know sends forensic reports. If you add it, addfo=1so you capture partial failures, and make sure the destination mailbox is secured, since the contents may include personal data. - Do not rely on
ruffor coverage. Because Google, Yahoo, and Microsoft stay silent, your forensic feed will always be sparse and skewed toward smaller senders.
If you are early in your rollout and unsure how strict to be, the trade-offs between p=none, quarantine, and reject are explained in /en/guides/dmarc-policy-none-quarantine-reject.
Reporting to a domain you do not control
Both tags accept destinations outside your own domain, for example a DMARC processing vendor. To prevent abuse, where someone names your address as a report sink, the receiver checks for authorization. If the destination domain differs from the domain the DMARC record is published on, you must publish a TXT record at a special hostname on the destination domain confirming it accepts reports for you:
example.com._report._dmarc.vendor.example IN TXT "v=DMARC1"
Without that record, receivers will not send reports to the external address. This applies to both rua and ruf, and DMARCbis keeps the check mandatory for failure destinations as well. It is a plain DNS TXT record like any other; see /en/guides/what-is-a-dns-txt-record if you need a refresher.
Frequently asked questions
Do I need RUF if I already have RUA?
No. Aggregate reports (rua) give you everything required to monitor sources and move to enforcement. Failure reports (ruf) only add value when you are debugging a specific message failure, and even then most large providers will not send them.
Why am I not receiving any DMARC forensic reports?
Because the biggest receivers, including Google, Yahoo, and Microsoft, do not send ruf reports at all, citing privacy and data protection concerns. Unless a smaller or enterprise receiver that still supports forensics happens to see your failing mail, your ruf mailbox will stay empty even with a correct tag.
What is the difference between the fo=0 and fo=1 settings?
fo=0, the default, only generates a failure report when every authentication method fails to produce an aligned pass. fo=1 generates one when any method produces something other than an aligned pass, so it catches partial failures such as SPF passing while DKIM fails. Both settings require a ruf tag to have any effect.
Are DMARC aggregate reports a privacy risk?
No. Aggregate reports contain only counts and metadata grouped by sending IP address, with no message content, subject lines, or recipient addresses. That is precisely why nearly every receiver sends them while so few send content-bearing forensic reports.
Want to see exactly what your current DMARC record requests, and whether your SPF, DKIM, and alignment hold up? Run a free scan with SPFWise and get a plain-language breakdown of your rua, ruf, and policy tags in seconds.