DMARC RUA vs RUF: Aggregate vs Forensic Reports

DMARC rua requests aggregate reports: summaries of authentication results observed by participating receivers. ruf requests message-specific failure reports, historically called forensic reports, which may expose headers and message content. The practical DMARC RUA vs RUF choice is to start with rua for ongoing visibility and use ruf only for a deliberate, privacy-aware diagnostic need. Neither tag guarantees reports, controls enforcement by itself, or guarantees inbox placement.

The current standards are RFC 9989 for DMARC and its reporting tags, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. Published in May 2026, these replace the historical RFC 7489 specification.

Use Inbox Pulse to check visible public DMARC DNS configuration, including whether reporting tags are present in the record. Use the free 10-domain agency audit when email DNS should be reviewed alongside broader client-domain health. Review the CertPilot methodology when explaining that CertPilot checks public records and does not process private mailbox or DMARC aggregate-report data.

Quick answer: DMARC rua vs ruf

rua identifies the destinations requested for aggregate reports. A mailto: URI names a report-receiving address; it does not create a mailbox or a report-processing service.

ruf identifies the destinations requested for message-specific failure reports. Receiver support and reporting policy determine whether reports are sent; not every DMARC failure creates a report.

Illustrative record requesting both report types, only where failure reporting is actually needed:

v=DMARC1; p=none; rua=mailto:dmarc-aggregate@example.com; ruf=mailto:dmarc-failures@example.com

These are example addresses, not a working reporting service. Publishing an address alone does not guarantee delivery. These tags request report destinations, not enforcement: p= expresses the requested DMARC policy, while receivers determine message handling after authentication and alignment checks.

If a checker says rua or ruf is missing, do not treat that as the same kind of finding as missing DMARC. A domain can publish a valid DMARC record without report destinations. The decision is whether the client needs report processing, who owns the destination, and whether a dedicated DMARC platform is required.

What rua means

The rua tag identifies where aggregate DMARC reports are requested. RFC 9990 defines XML reports that summarize sending sources, message counts, authentication results, alignment, and policy handling observed by participating receivers. They do not contain full message bodies and are not a complete view of every receiver or a deliverability guarantee.

They may help answer:

• Which IPs or services are sending mail using the client's domain?
• Which sources pass or fail SPF?
• Which sources pass or fail DKIM?
• Which sources align with the visible From domain?
• How much mail is being observed by a receiver?

For agencies, rua is useful only if someone or some platform can process the reports. A mailbox full of XML attachments is not a monitoring system by itself.

What ruf means

The ruf tag identifies where message-specific failure reports may be sent. These can include message headers and potentially the entire message, exposing personal information, private correspondence, or confidential business data. Redaction is possible, but you must not assume every report is redacted.

RFC 9991's privacy guidance explains that many large-scale providers limit or disable failure reporting. It recommends aggregate reporting for general visibility and encourages operators using failure reports to limit scope and duration, control recipients, minimize exposed data, and transmit reports securely. Adding ruf does not oblige every receiver to send reports.

Agencies should be careful with ruf because failure reports may expose more sensitive message-level details than aggregate reports. Before adding it, clarify:

• Does the client actually need message-specific failure details?
• Who will receive them?
• Can the recipient handle privacy obligations?
• Does the target mailbox provider send useful ruf reports?
• Is a DMARC platform better suited to handle the workflow?

Many domains start with rua only.

DMARC RUA vs RUF: aggregate vs failure reports

The cleanest way to explain rua and ruf to a client is to compare the report type, the operational use, and the risk of enabling it.

• Tag: rua
  • Report type and detail: Aggregate XML summaries of sources, counts, and authentication results
  • Typical purpose: Ongoing authentication visibility across participating receivers
  • Privacy exposure: Operational source and domain data, not full message bodies; still restrict access
  • Availability: Depends on receiver participation; not every receiver sends reports
  • Recommendation: Normal starting point when someone will process and review the reports
  • Common value: mailto:dmarc@example.com
• Tag: ruf
  • Report type and detail: Message-specific failure reports, also known as forensic reports
  • Typical purpose: Targeted investigation of authentication failures
  • Privacy exposure: May include personal identifiers, headers, and message content
  • Availability: Many large providers limit or disable it; no report for every failure is guaranteed
  • Recommendation: Optional; use only with a specific diagnostic need and appropriate data handling
  • Common value: mailto:dmarc-failures@example.com

The p= policy is a separate decision from choosing reporting destinations. This comparison is not an enforcement-rollout guide.

Do I need rua, ruf, or both?

For a normal IT or agency team seeking ongoing visibility, start with rua and an owned process for reviewing the reports. You do not need ruf merely because a checker notices it is absent. Add it only when message-specific failure details are useful, the relevant receivers support it, and the recipients can handle the privacy exposure. Both tags are optional in DMARC; neither is a substitute for authentication and alignment.

Many domains start with a DMARC record like:

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

This requests aggregate reports without requesting quarantine or rejection under DMARC. It is an illustrative monitoring record, not a recommendation to replace an existing enforcement policy with p=none. It avoids requesting the more sensitive failure reports, but the mailbox or service still needs to exist and process incoming reports. Receivers may still filter mail under their own policies.

For an agency, this is often the safest path when:

• The client has multiple senders.
• Sender ownership is unclear.
• The domain has not previously monitored DMARC.
• Nobody has reviewed SPF/DKIM alignment.
• The client does not have a DMARC reporting platform yet.

Use the DMARC record not found guide when a domain has no record at all.

What to do when a checker says RUA or RUF is missing or invalid

Different tools word reporting findings differently. Treat the wording as a prompt for review, not as an automatic DNS change.

• Checker finding: rua missing
  • What it usually means: The DMARC record does not request aggregate reports
  • Agency action: Decide whether the client has a process or platform to receive reports
• Checker finding: ruf missing
  • What it usually means: No forensic-report destination is published
  • Agency action: Usually acceptable unless the client has a specific failure-reporting need
• Checker finding: rua destination not valid
  • What it usually means: The address or URI format may be wrong, or an external destination may need authorization
  • Agency action: Confirm provider instructions before editing DNS
• Checker finding: Reports sent to an old mailbox
  • What it usually means: Reporting exists but nobody owns the destination
  • Agency action: Move to an owned mailbox or DMARC platform after client approval

For agencies, the useful deliverable is not “add rua everywhere.” It is a short decision: whether reporting is needed, who receives it, how it will be processed, and what policy step it supports.

Reporting address ownership

Reporting address ownership is easy to overlook. The address in rua or ruf should belong to a team or platform that will actually process the reports.

Agencies should avoid sending reports to:

• A personal employee mailbox.
• An unmonitored support inbox.
• A developer's address that will be abandoned later.
• A mailbox that cannot handle volume.
• An external domain that has not been authorized where required.

If reports go to another domain or provider, do not assume that adding its address to rua or ruf is enough. The report generator must verify external destinations under RFC 9990's external-destination procedure; RFC 9991 applies that procedure to failure reports too. Without successful authorization, reports must not be sent to that destination.

For example, if the policy domain is example.com and the destination is dmarc@reports.example.net, the external destination's DNS operator can authorize it with a TXT record at example.com._report._dmarc.reports.example.net whose value is v=DMARC1. This authorization belongs on the receiving domain, not in a second DMARC policy record on the sending domain. Use the provider's exact instructions; authorization permits reporting but does not guarantee report generation or delivery.

Privacy and operational considerations

DMARC reports can contain operationally sensitive information. Aggregate reports reveal sending sources and authentication results. Failure reports can expose personal identifiers, private headers, and potentially complete message content. Treat access, retention, recipient approval, and data minimization as real operational decisions, not as a checkbox that makes reporting legally compliant.

Before configuring reporting, ask:

• Does the client approve where reports are sent?
• Is the destination mailbox or vendor appropriate for client data?
• Who can access the reports?
• How long are reports retained?
• Is there a data-processing agreement if a third-party platform is used?
• Does the agency have authority to receive reports for the client?

For routine agency operations, a dedicated DMARC platform may be cleaner than raw mailbox handling.

Why raw DMARC reports need processing

Raw DMARC aggregate reports are not designed for casual reading. They are often compressed XML files from many receivers. A client or agency can technically receive them in a mailbox, but turning them into decisions requires parsing, grouping, source identification, and trend review.

Without processing, agencies may struggle to answer:

• Is this source legitimate?
• Is this a forwarded message pattern?
• Is this a vendor that needs DKIM setup?
• Is this spoofing, or just a misaligned platform?
• Is it safe to move from p=none to enforcement?

This is why rua is configuration, not the whole DMARC program.

When to use a DMARC monitoring platform

Use a dedicated DMARC monitoring platform when the client needs:

• Ongoing aggregate report processing.
• Source identification.
• Policy progression planning.
• Multi-domain portfolio reporting.
• Alerts when new senders appear.
• Evidence before moving to p=quarantine or p=reject.
• Operational dashboards for compliance or security teams.

Inbox Pulse is useful for checking whether the public DNS configuration exists. It is not a replacement for a platform that processes aggregate reports over time.

DMARC reporting-address review checklist

Before adding or changing rua or ruf, check:

• [ ] Does the domain already publish a DMARC record?
• [ ] Is the DMARC policy appropriate for the client's current sender alignment?
• [ ] Is rua present?
• [ ] Who owns the rua destination?
• [ ] Can the destination process XML aggregate reports?
• [ ] Is the destination on the same domain or an external provider?
• [ ] If external, has authorization been configured where required?
• [ ] Is ruf genuinely needed?
• [ ] Has privacy review covered personal data, headers, and potential message content in failure reports?
• [ ] Is there a cadence for reviewing report findings?

What Inbox Pulse can check

Inbox Pulse can check visible DNS configuration in the DMARC TXT record, including whether reporting tags such as rua or ruf appear in the public record. It can help agencies spot missing or unusual reporting configuration during DNS QA.

CertPilot / Inbox Pulse does not receive RUA XML reports, ingest RUF failure reports, parse DMARC aggregate feeds, or inspect mailbox content. It does not classify sending sources from report history, send test emails, or guarantee report delivery. Treat it as a public DNS configuration auditor, not a report-receiving service.

What Inbox Pulse does not process

Inbox Pulse does not process:

• DMARC aggregate XML reports sent to rua.
• Forensic or failure reports sent to ruf.
• Inbox placement tests.
• Message headers from live mailboxes.
• Mailbox-provider reputation dashboards.
• Historical deliverability trends.

That distinction matters. A public DNS check can tell you what the domain asks receivers to do with reports. It cannot tell you what all receivers have reported over time.

Frequently Asked Questions

What does DMARC rua mean?

DMARC rua means the domain is publishing one or more destinations for aggregate reports. These reports summarize authentication results observed by participating receivers. The common format is rua=mailto:dmarc@example.com. The tag does not enforce policy by itself; it only tells receivers where aggregate reports should be sent.

What does DMARC ruf mean?

DMARC ruf publishes destinations for message-specific failure reports, historically called forensic reports. These may contain personal identifiers, headers, and potentially message content. Use it deliberately, with a defined diagnostic need and appropriate handling of sensitive data.

What is the difference between DMARC RUA and RUF?

rua requests aggregate summaries of authentication results; ruf requests message-specific failure details. Start with aggregate reporting for ongoing visibility. Failure reports are more sensitive and have limited receiver support.

Does every email provider send RUF reports?

No. RFC 9991 notes that many large-scale providers limit or disable failure reporting. Publishing ruf does not guarantee that a receiver will generate a report for each failure, or send any failure reports at all.

Is rua required for DMARC?

No, a DMARC record can exist without rua, but without aggregate reports the client has less visibility into sending sources and authentication results. For domains that plan to progress toward stricter policy, rua is often useful. The value depends on whether someone can process and act on the reports.

Does CertPilot receive DMARC reports?

No. CertPilot / Inbox Pulse checks published DNS-based email-authentication configuration. It does not receive RUA XML reports, ingest RUF failure reports, parse aggregate feeds, inspect mailbox content, or guarantee report delivery. Use an appropriately configured mailbox or dedicated report-processing service for receiving and analyzing reports.

Do I need both RUA and RUF?

No. rua is the normal starting point for ongoing authentication visibility when you have a process for reviewing aggregate reports. ruf is optional and better reserved for a specific, privacy-aware diagnostic need. A missing ruf tag is not by itself an invalid DMARC record.

Do rua and ruf enforce DMARC?

No. rua and ruf are reporting tags. They do not enforce DMARC policy, reject messages, quarantine mail, or improve inbox placement by themselves. Enforcement posture is controlled by the p= policy and receiver behavior after DMARC alignment checks.