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

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, with the report formats in two companion documents:

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 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 explain every tag, and the DMARC Record 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 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:

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 suggests a simpler route: use an address on your own domain and forward it automatically to the external mailbox.

The 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 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 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 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 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 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 builds it.
4. If you use a reporting service, add its address and confirm it publishes the _report._dmarc authorization. Run the DMARC Checker to verify.
5. Wait a day or two, then open the first reports. The DMARC Report Analyzer turns the XML into a readable table, and 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, or run a full 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.
• If you're tuning alignment, read 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 show what was held, and you can add the report senders to an allow list.

Browse our other SPF, DKIM and DMARC guides.