Last updated: July 2026

In short: The rua= and ruf= tags control DMARC feedback reporting. While rua= requests daily XML traffic summaries showing authentication trends across your entire domain, ruf= requests detailed per-message failure reports for troubleshooting specific delivery errors.

One of the most powerful architectural features of Domain-based Message Authentication, Reporting, and Conformance (DMARC) is its feedback reporting loop. When publishing a DMARC policy in your DNS, you use the rua= and ruf= tags to declare where receiving mail servers should send analysis reports.

Under RFC 7489, both tags accept a comma-separated list of DMARC URIs (typically mailto: addresses). However, the reporting data they deliver serves entirely different diagnostic purposes.

The rua= tag: aggregate XML summaries (the monitoring foundation)

The rua= tag requests daily aggregate reporting. Under RFC 7489: rua: Addresses to which aggregate feedback is to be sent (comma-separated plain-text list of DMARC URIs; OPTIONAL).

A standard DMARC record requesting aggregate reports looks like this:

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

Receiving mailbox providers (such as Gmail, Yahoo, and Microsoft 365) collect traffic data across all incoming mail claiming to originate from your domain and dispatch a consolidated XML file to the specified address—typically once every 24 hours. This XML report provides high-level visibility:

  • Every IP address attempting to send mail on your domain’s behalf.
  • Total message volumes delivered across each IP.
  • SPF and DKIM alignment results for every sending source.
  • The final policy disposition applied by the receiver (none, quarantine, or reject).

The rua= tag is critical during every phase of deployment. It enables domain administrators to discover legitimate cloud tools and verify alignment before moving to strict enforcement (p=reject).

The ruf= tag: forensic failure reports (granular troubleshooting)

The ruf= tag requests detailed per-message failure reporting (often referred to as forensic reporting). According to RFC 7489: ruf: Addresses to which message-specific failure information is to be reported (comma-separated plain-text list of DMARC URIs; OPTIONAL). If present, the Domain Owner is requesting Mail Receivers to send detailed failure reports about messages that fail the DMARC evaluation in specific ways

When combined with failure options (fo=), a complete record is written as:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; fo=1

Unlike rua= daily summaries, ruf= reports are generated almost immediately when an individual email fails DMARC evaluation. They contain detailed diagnostic snippets, including message headers, envelope parameters, and sometimes exact failure explanations, allowing security teams to investigate active spoofing or broken signing pipelines.

Why ruf= reports are rarely delivered today

While rua= aggregate reports are supported and delivered reliably by nearly all major global mailbox providers, ruf= reports are now rarely sent by large consumer email providers. The primary limitation is data privacy: because forensic reports include exact header data, subject lines, and potentially body snippets of failed messages, consumer providers often decline to generate them to prevent exposing user data under regulations such as GDPR.

However, ruf= remains useful within corporate B2B environments or specialized internal networks where granular visibility into spoofed or misconfigured mail is required.

Verifying your configuration

To verify that your reporting URIs are correctly formatted without syntax errors or invalid schemes, audit your domain using the free MXAudit scanner.

For comprehensive technical concepts and provider-specific setup guides, explore the DMARC hub and practical guides like IONOS DMARC setup.

Further reading