# DMARC rua and ruf: how to set up DMARC reporting addresses

URL: https://iblockspam.com/blog/dmarc-rua-ruf-reporting-addresses
Last updated: 2026-10-10
Published: 2026-10-10
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> What DMARC rua and ruf do, the mailto syntax, how to send reports to another domain with a _report._dmarc record, failure report privacy and report volume.

## Short answer

rua asks receivers to send daily aggregate DMARC reports; ruf asks for per-message failure reports. Both take mailto: addresses separated by commas, such as rua=mailto:dmarc@example.com. If the address is on a different organizational domain, that domain must publish a TXT record like example.com._report._dmarc.reports.example.net containing v=DMARC1, or receivers ignore it.

The `rua` and `ruf` tags are the reporting half of DMARC. Without them, you can publish a policy but you'll never see who sends mail as your domain, which makes it hard to move safely to enforcement. This guide covers the syntax, sending reports to another domain, the privacy trade-offs of failure reports, and what to expect in your inbox.

## What are rua and ruf?

Both tags are defined in [RFC 9989, section 4.7](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7), with the report formats in two companion documents:

| | `rua` | `ruf` |
|---|---|---|
| Report type | Aggregate | Failure (once called forensic) |
| Defined in | [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) | [RFC 9991](https://www.rfc-editor.org/rfc/rfc9991.html) |
| What's in it | Counts per sending IP, SPF/DKIM/DMARC results, alignment, disposition | Details of one failed message: headers, sometimes the body |
| When it arrives | "Daily (or more frequent)" (RFC 9990) | "Almost immediately" after a failure (RFC 9991) |
| Format | Gzipped XML attachment | Abuse Reporting Format (ARF) message |
| Who sends it | Most large mailbox providers | Few; "most Mail Receivers refuse to send them out of privacy concerns" (RFC 9989, section 10.2) |
| Needed? | Yes, for any rollout | Optional, for diagnosis |

If a tag is missing, receivers MUST NOT generate that kind of report for your domain. No `rua` means no aggregate reports at all.

## How do you write rua and ruf addresses?

The syntax is a comma-separated list of URIs. Receivers that send reports MUST support `mailto:`, and RFC 9990 notes that other delivery methods could be added later, so in practice every address is a `mailto:`:

```
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
```

The rules that trip people up:

- **Include `mailto:`.** `rua=dmarc@example.com` isn't a valid URI, and receivers won't send to it.
- **Separate addresses with commas**, each with its own `mailto:`: `rua=mailto:a@example.com,mailto:b@example.net`. [Section 4.6](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.6) says a report "SHOULD be sent to each listed URI".
- **Don't use a semicolon** between addresses. Semicolons separate tags, so anything after one is read as a new tag.
- **Encode commas and exclamation points** inside an address. The ABNF in section 4.8 says they "MUST be encoded".
- **Drop size limits.** RFC 7489 allowed a suffix like `!10m`. RFC 9989 marks it obsolete and says reporters should ignore it.

`ruf` uses the same syntax. The `fo` tag controls when failure reports are generated and is ignored unless `ruf` is present: `fo=0` (default) when SPF and DKIM both fail to produce an aligned pass, `fo=1` when either does, `d` for any DKIM failure and `s` for any SPF failure. Our [DMARC record examples](https://iblockspam.com/blog/dmarc-record-examples) explain every tag, and the [DMARC Record Generator](https://iblockspam.com/tools/dmarc-generator) writes the syntax for you.

## How do you send DMARC reports to another domain?

Reports often go to a reporting service, or to a mailbox on a different domain you own. To stop abuse, receivers check that the other domain agreed.

### Why the check exists

Without it, [RFC 9990, section 4](https://www.rfc-editor.org/rfc/rfc9990.html#section-4) explains, an attacker could publish a DMARC record pointing reports at a victim's address, then send lots of failing mail "to a wide variety of destinations," and "the victim will in turn be flooded with unwanted reports." RFC 9991 applies the same check to failure reports.

### When it applies

The check runs when the organizational domain of your DMARC record isn't the same as the organizational domain of the report address. So:

| Your domain | Report address | Authorization needed? |
|---|---|---|
| `example.com` | `dmarc@example.com` | No |
| `example.com` | `dmarc@reports.example.com` | No: same organizational domain |
| `example.com` | `dmarc@example.net` | Yes, from `example.net` |
| `example.com` | `abc123@rua.reportingservice.example` | Yes, from the service |

### The record the other domain publishes

The receiver builds a name from three parts: your domain, `_report._dmarc`, and the host part of the report address. Then it looks for a TXT record there that starts with `v=DMARC1`.

For `example.com` sending reports to `dmarc@example.net`, the owner of `example.net` publishes:

```
example.com._report._dmarc.example.net.  TXT  "v=DMARC1"
```

A few details from RFC 9990:

1. **The other domain publishes it, not you.** Reporting services do this for each customer domain, or use a wildcard.
2. **A wildcard works.** A record at `*._report._dmarc.example.net` containing `v=DMARC1` accepts reports for any domain.
3. **The destination can override the address.** The authorization record may include its own `rua` or `ruf`, but only with the same destination host.
4. **Failure means silence.** If the check fails, "the URI MUST be ignored by the Mail Receiver generating the report." You get no error; the reports simply never arrive.

If you own both domains, [RFC 9989, section 11.6](https://www.rfc-editor.org/rfc/rfc9989.html#section-11.6) suggests a simpler route: use an address on your own domain and forward it automatically to the external mailbox.

The [DMARC Checker](https://iblockspam.com/tools/dmarc-checker) looks up the authorization record for each outside `rua` address and warns if it's missing.

## Should you ask for failure (ruf) reports?

For most small businesses, no. Treat `ruf` as a diagnostic tool you switch on briefly, not a permanent setting.

### Privacy

Failure reports are about individual messages. [RFC 9991, section 7](https://www.rfc-editor.org/rfc/rfc9991.html#section-7) says they "may include PII and non-public information (NPI)" because "these reports may contain message content as well as trace header fields." Its examples include "product launches, termination notices for employees, or calendar data." They can also reveal who is on a mailing list or where mail was forwarded.

RFC 9991 notes that "many large-scale providers limit or entirely disable the generation of failure reports." [Microsoft](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) is explicit: "Microsoft 365 doesn't send DMARC Forensic reports (also known as DMARC Failure reports), even if a valid ruf=mailto: address exists."

If you do turn them on, RFC 9991 recommends that you:

- limit them to "targeted diagnostic activities" for a limited time,
- control and validate the reporting addresses carefully,
- keep report mail separate from other mail and limit access to trained people,
- open them in a sandbox, since unredacted reports can carry phishing links and malware.

### Security

Section 11.6 of RFC 9989 warns that `ruf` addresses "are thus more attractive targets for intrusion attempts" than `rua` addresses, and that an attacker who tampers with your DNS could redirect failure data. It recommends DNSSEC if this is a concern.

### Aggregate reports are low-risk

[RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) says aggregate reports contain no "individual mail addresses, IP addresses of individuals, or the content of any messages." RFC 9989 section 10.1 adds one caveat: for a small organization, a report from a particular domain can still reveal sensitive business information. Use a mailbox with appropriate access controls.

## How many DMARC reports should you expect?

It depends on how many organizations you send to, not just how much you send. [Google](https://knowledge.workspace.google.com/admin/security/about-dmarc-reports) says the number "depends on how much email your domain sends and how many domains you send to," that you "can receive many reports every day," and that "large organizations might get up to hundreds or even thousands of reports daily."

A few patterns help set expectations:

- **One report per receiver per period.** Each reporting receiver sends a summary, usually covering one UTC day.
- **Separate reports per policy domain.** RFC 9990 says a separate report must be generated for each DMARC policy domain, so a subdomain with its own record gets its own reports.
- **Quiet days are normal.** A small business that emails a few dozen organizations may get a handful of reports a day, and none from receivers that don't report.
- **Failure reports can spike.** If you enable `ruf` during a spoofing campaign, every failing message can trigger one. RFC 9991 requires report generators to rate-limit, but the limits are theirs to choose.

For context, in our [scan of the Tranco top 1,000 domains](https://iblockspam.com/research/email-security-top-1000) in October 2026, 68.6% of domains requested aggregate reports with `rua`.

## How do you set up the reporting mailbox?

1. **Create a dedicated address**, such as `dmarc-reports@yourdomain`. Google and Microsoft both recommend a dedicated mailbox or group rather than a person's inbox.
2. **Make sure it accepts the reports.** They're automated emails with `.xml.gz` or `.xml` attachments. Check that your spam filter doesn't quarantine them or block compressed attachments for this address. RFC 9990 requires report emails to pass DMARC themselves, which helps you trust them.
3. **Add `rua` to your record**, with `p=none` if you're just starting. The [DMARC Record Generator](https://iblockspam.com/tools/dmarc-generator) builds it.
4. **If you use a reporting service,** add its address and confirm it publishes the `_report._dmarc` authorization. Run the [DMARC Checker](https://iblockspam.com/tools/dmarc-checker) to verify.
5. **Wait a day or two**, then open the first reports. The [DMARC Report Analyzer](https://iblockspam.com/tools/dmarc-report-analyzer) turns the XML into a readable table, and [how to read DMARC reports](https://iblockspam.com/blog/how-to-read-dmarc-reports) explains each field.
6. **Add `ruf` only if you need it**, for a fixed period, and remove it when you're done.

## Next steps

- Check that your record has a working `rua` address with the [DMARC Checker](https://iblockspam.com/tools/dmarc-checker), or run a full [Email Health Check](https://iblockspam.com/tools/email-health-check).
- Use the reports to find every service that sends as your domain, then follow [moving DMARC from p=none to p=reject](https://iblockspam.com/blog/dmarc-none-to-reject-small-business).
- If you're tuning alignment, read [DMARC alignment: relaxed vs strict](https://iblockspam.com/blog/dmarc-alignment-relaxed-vs-strict).
- If reports never arrive, check whether your inbound filtering is holding them. With iBlockSpam, each user's [quarantine and digest emails](https://iblockspam.com/features/quarantine-and-digests) show what was held, and you can add the report senders to an [allow list](https://iblockspam.com/features/allow-block-lists).

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### What is the difference between rua and ruf in DMARC?

rua requests aggregate reports: summaries, usually daily, of how much mail used your domain, from which IP addresses, and whether SPF, DKIM and DMARC passed. ruf requests failure reports about individual messages that failed, which can include headers or content. Most domains only need rua.

### Can I send DMARC reports to an email address on another domain?

Yes, but the other domain has to agree. Receivers look for a TXT record at yourdomain._report._dmarc.theirdomain starting with v=DMARC1. If it isn't there, they ignore that address. DMARC reporting services publish this record for their customers; for your own second domain, you publish it yourself.

### Why am I not getting any DMARC reports?

Common causes are a missing mailto: prefix, an address on another domain without the _report._dmarc authorization record, a mailbox that rejects or filters the report emails, or simply low mail volume. Reports also only come from receivers that send them, and they typically cover a full UTC day, so allow a day or two.

### Do I need a ruf address?

Usually not. Failure reports can contain personal data and message content, and many large receivers don't send them. Microsoft 365 says it doesn't send them even when a valid ruf address exists. Add ruf for a short diagnostic period if you have a specific failure to investigate and a safe place to store the reports.

### Can I list more than one rua address?

Yes. Separate them with commas, for example rua=mailto:dmarc@example.com,mailto:id@reports.example.net. RFC 9989 says a report should be sent to each listed address. Each address on another organizational domain needs its own authorization record from that domain.

### Do DMARC aggregate reports contain personal information?

RFC 9990 says they contain no individual mail addresses, no IP addresses of individuals and no message content. RFC 9989 still warns that for a small organization, reports may give some insight into sending patterns, so restrict who can read the reporting mailbox.

## Sources

- [RFC 9989: DMARC, sections 4.7, 10 and 11.6](https://www.rfc-editor.org/rfc/rfc9989.html)
- [RFC 9990: DMARC Aggregate Reporting, section 4 (Verifying External Destinations)](https://www.rfc-editor.org/rfc/rfc9990.html#section-4)
- [RFC 9991: DMARC Failure Reporting, section 7 (Privacy Considerations)](https://www.rfc-editor.org/rfc/rfc9991.html#section-7)
- [Google Workspace Admin Help: About DMARC reports](https://knowledge.workspace.google.com/admin/security/about-dmarc-reports)
- [Microsoft Learn: Set up DMARC to validate email in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure)

## Free tools for this guide

- [DMARC Record Generator](https://iblockspam.com/tools/dmarc-generator): Build a DMARC record with the right policy, reporting and alignment settings.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [DMARC Report Analyzer](https://iblockspam.com/tools/dmarc-report-analyzer): Read DMARC aggregate reports (XML, gzip or zip): see who sends as your domain and what fails — runs in your browser.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.

---

Source: iBlockSpam, https://iblockspam.com/blog/dmarc-rua-ruf-reporting-addresses (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt