The rua tag in a DMARC record sets the mailbox where aggregate reports are sent, and the ruf tag sets the mailbox for forensic (failure) reports. Both take mailto URIs, both can list more than one destination, and both have a catch that trips people up: if you send reports to a domain other than the one the DMARC record belongs to, that receiving domain has to publish an external-destination verification TXT record first, or the reports never arrive. This guide covers the configuration side of rua and ruf, the multiple-destination syntax, and the external-domain record, not how to read the report XML once it lands.
What rua and ruf actually collect
DMARC produces two kinds of reports, and the two tags map to them one to one. The rua tag requests aggregate reports: once-a-day XML summaries from each receiving provider that count how many messages claimed your domain, how many passed SPF and DKIM alignment, and what each source IP was. They contain no message content and are the reports almost everyone wants.
The ruf tag requests forensic reports, sometimes called failure reports: near-real-time copies of individual messages that failed DMARC, including header detail. Because they can carry recipient data, most large providers have stopped sending them for privacy reasons, so a ruf tag often produces little or nothing as of November 2026. Aggregate reports via rua are where the useful signal lives, which is why the guide to reading a DMARC aggregate report focuses on the rua XML.
The basic syntax
Both tags take one or more mailto URIs. A minimal record that collects aggregate reports looks like this:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Add forensic reporting by appending a ruf tag:
v=DMARC1; p=none; rua=mailto:agg@example.com; ruf=mailto:fail@example.com
The mailto scheme is required. A bare address with no mailto prefix is invalid and will be ignored. The policy tag, p, is independent of the reporting tags: you can collect reports at p=none while you observe, then raise the policy later. If you are still assembling the record from scratch, start with the how to create a DMARC record walkthrough.
Sending to more than one mailbox
To send the same reports to several places, separate the URIs with commas inside the same tag. This is common when an in-house mailbox and a third-party DMARC analytics service both need a copy.
v=DMARC1; p=none; rua=mailto:dmarc@example.com,mailto:reports@analytics-vendor.com
Order does not matter, and receivers are expected to deliver to each listed address. You can also cap the size of aggregate reports per destination with the ri interval and the optional size limit syntax, though most operators leave those at defaults and simply list the mailboxes they want.
The external-destination record that catches everyone
Here is the mechanic that silently breaks reporting. If the mailbox in your rua or ruf tag is at a different domain than the one publishing the DMARC record, the receiving domain must authorize the arrangement by publishing a verification TXT record. Without it, conformant report senders will not send to that external address, and you will wonder why no reports arrive.
Say example.com publishes rua=mailto:dmarc@reports-vendor.com. Because reports-vendor.com is a different domain, it has to publish, at the name example.com._report._dmarc.reports-vendor.com, a TXT record with the value v=DMARC1. That record is the receiving domain saying it is willing to accept DMARC reports on behalf of example.com. Most DMARC analytics vendors generate this record for you and tell you exactly what to publish, but when you point reports at your own secondary domain you have to create it yourself.
rua versus ruf at a glance
| Aspect | rua (aggregate) | ruf (forensic) |
|---|---|---|
| What it sends | Daily XML summary counts | Copies of individual failing messages |
| Message content | None, metadata only | Headers and sometimes body |
| Frequency | Roughly once per day | Near real time |
| Provider support in 2026 | Widely sent | Rarely sent for privacy reasons |
| Multiple destinations | Comma-separated mailto URIs | Comma-separated mailto URIs |
| External-domain record needed | Yes, when the mailbox is off-domain | Yes, when the mailbox is off-domain |
Setup checklist
- Pick a dedicated mailbox or inbox for aggregate reports so they do not drown a shared address.
- Write the rua tag with the full mailto URI, and add a second comma-separated URI if a vendor also needs a copy.
- Decide whether you want ruf at all; if a provider you care about no longer sends it, skip it to keep the record clean.
- If any report mailbox is on a different domain, publish the matching
_report._dmarcverification TXT record on that receiving domain. - Publish the DMARC record at
_dmarc.yourdomain.comand confirm it resolves with a live lookup. - Wait a day or two, then confirm aggregate reports are arriving before you touch the policy.
You can confirm the published record parses correctly and see the authentication picture it reports on with the Valla DNS domain health report, which reads your live DMARC, SPF, and DKIM together.
Frequently asked questions
What is the difference between the rua and ruf tags?
The rua tag sets where aggregate reports go: daily metadata summaries with no message content. The ruf tag sets where forensic reports go: copies of individual failing messages. Most operators rely on rua because many providers no longer send forensic reports.
Can I send DMARC reports to more than one address?
Yes. List multiple mailto URIs separated by commas inside the same tag, for example rua=mailto:a@example.com,mailto:b@example.com. Each listed mailbox should receive a copy of the reports.
Why am I not receiving any DMARC reports?
The most common cause is sending to an off-domain mailbox without the external-destination verification record. If the report address is on a different domain than the DMARC record, that domain must publish the matching _report._dmarc TXT record authorizing it.
What does the _report._dmarc record look like?
It is a TXT record published on the receiving domain at the name example.com._report._dmarc.receiving-domain.com, with the value v=DMARC1. It signals that the receiving domain agrees to accept reports on behalf of the sending domain.
Do I need a ruf tag at all?
Usually no. Forensic reports are rarely sent by major providers in 2026 and can carry recipient data, so most operators configure only rua for aggregate reporting and leave ruf out entirely.
Get the rua destination and the external-domain record right and the reports flow on their own. Confirm your live record with the domain health report before you raise your policy.