Treat RUF failure reports as a short-lived diagnostic instrument, not the normal DMARC dashboard. Aggregate reports give the operating view without exposing message-level content and identifiers.
DMARC has two feedback channels that sound similar but behave very differently. Aggregate reports tell you what happened across a stream of messages. Failure reports, usually requested with ruf, can describe one failed message at a time.
The per-message detail is tempting. It can help diagnose a broken sender faster than waiting for tomorrow's aggregate XML. It can also expose message content, trace headers, sender and recipient identifiers, and operational details that do not belong in a broad reporting pipeline.
The record knobs
A basic DMARC record requests aggregate reports with rua. Failure reports are requested with ruf. The fo tag asks receivers which authentication failure conditions should trigger those per-message reports.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:agg@example.net; ruf=mailto:fail@example.net; fo=1"That record is a request, not a guarantee. Receivers decide whether they generate failure reports, what they include, how they redact, and whether they rate-limit. Many large-scale receivers limit or disable failure reporting because of the privacy and abuse surface.
In the current DMARC RFC set, ruf remains an active policy-record tag. The oldrf format-selection tag is historic. The practical format story moved to the failure-reporting document itself, RFC 9991, and the underlying authentication failure reporting format from RFC 6591.
Why aggregate reports are the operating view
RFC 9990 describes aggregate reports as the visibility layer for real-world mail streams: sources, volume, SPF results, DKIM results, alignment, and the disposition receivers applied. That is the information most teams need to move from p=none to enforcement.
- Which IPs and organizations are sending as the domain.
- Which senders pass SPF, DKIM, and DMARC alignment.
- Which legitimate streams are blocked by policy or provider changes.
- Which domains and subdomains are seeing spoof pressure.
- Whether policy changes reduced unauthorized mail without hurting owned mail.
That view is imperfect but operationally safe. It gives counts and authentication results, not a copy of the message that triggered the result.
Why failure reports are sensitive
RFC 9991 makes the privacy problem explicit: failure reports can include personally identifiable information, non-public information, message content, and trace headers. RFC 6591 also calls out redaction because reported messages can include identifiers associated with an end user.
This matters because DMARC failure reports cross organizational boundaries. A receiver generates a report about a message it processed, then sends it to the reporting URI in your DNS. If the URI points to a vendor, shared mailbox, ticketing tool, or mailing list, the failed message details may be stored and forwarded far beyond the small team that needs them.
- Envelope and header identifiers, including sender and recipient addresses.
- Authentication-Results and trace headers that reveal routing paths.
- Message snippets or bodies when a receiver does not fully redact.
- Subjects, URLs, and other content that may be sensitive even when bodies are removed.
When RUF is worth using
Failure reports still have a place. They are useful when the question is narrow, urgent, and not answerable from aggregate data alone.
- New sender diagnostics. A critical vendor claims DKIM is configured, but a small set of messages still fails alignment.
- Incident triage. A high-value domain is seeing a sudden spoofing pattern, and message-level headers may separate one attacker path from another.
- Receiver disagreement. One receiver reports failures that do not match other receivers, and you need exact authentication details.
Even then, treat RUF as a time-boxed diagnostic collection. Turn it on for the domain or subdomain under investigation, collect what you need, and turn it off.
The safe operating pattern
If you request failure reports, design the handling path before publishing the DNS record. The safe pattern is small and explicit.
- Use a dedicated reporting address, not a human mailbox or generic ticket queue.
- Restrict access to the few people diagnosing the issue.
- Apply short retention and delete raw reports after triage.
- Prefer redacted processing and avoid indexing message bodies in general search.
- Document why the collection exists and when it will be removed.
The most common mistake is publishing ruf because it feels more complete, then never reviewing whether anybody sends reports, what the reports contain, or who can read them.
Where DMARCify fits
DMARCify's normal operating model starts with aggregate reporting. That is enough to identify senders, discover unaligned vendors, measure spoof pressure, and decide when a policy can move toward enforcement.
For failure reports, the right product stance is narrower: accept them only when the user has a reason, isolate them from the ordinary dashboard path, surface the privacy warning, and make retention explicit. The default dashboard should not need message-level data to be useful.
The rule of thumb
Use rua as the operating system for DMARC. Use ruf like a packet capture: powerful, sensitive, short-lived, and justified by a specific diagnostic question.
Disclosure: AI tools were used in the process of creating this blog post.