Source review dated 8 November 2026. Operational steps are proposed; only the explicitly labelled offline demonstration is executed. No live tenant, DNS or mail delivery is claimed.
A DMARC failure report can reveal why an individual message did not authenticate as expected. It may contain authentication details, message headers or message content that an aggregate report does not include. That extra detail can be useful, but it also creates privacy and security obligations.
Failure reporting is optional in practice. Publishing a request does not compel every receiver to produce a report. RFC 9991 notes that many large operators restrict or disable this reporting because of privacy concerns. Treat it as a possible source of diagnostic evidence, not the foundation of a complete incident-detection promise.
Know what is being requested
The ruf tag identifies destinations for message-specific failure information, while fo expresses reporting options. RFC 9989 defines those tags, and RFC 9991 defines DMARC failure reporting. Aggregate reporting uses rua and serves a different purpose: counts and authentication observations over an interval rather than the same level of message detail.
Failure reports are normally sent soon after detection, but that is not a guaranteed alerting deadline. Rate limits, receiver decisions and delivery conditions affect what reaches the consumer. Multiple failures can be represented in ways that do not provide a one-report-per-message accounting system.
Choose a narrow diagnostic question
Before requesting these reports, identify the failure being investigated and the information needed to resolve it. A controlled test and received-message headers may already answer the question without collecting unrelated communications. Prefer the least intrusive evidence that works.
Illustrative question: a known forwarding path appears to invalidate a signature, but aggregate data does not show the relevant message transformation. A willing receiver's appropriately handled failure report might provide useful headers. Its absence would not disprove the problem, and its contents should not be assumed to include a full unredacted message. This is a hypothetical use case, not a claim that any named provider supplies such reports.
Prepare the destination before publishing it
Use a dedicated, restricted report intake with an owner, retention policy and safe parsing process. Verify external-destination authorization where required. RFC 9991 uses the external-destination verification procedure from RFC 9990 with ruf substituted for rua. DNS authorization of a destination is not a substitute for the organization's permission to send sensitive data there.
Confirm that redirects or forwarding do not silently deliver reports to a broader audience. Review the processor's access and handling arrangements before inviting reports. Do not use a general shared support mailbox merely because it is easy to monitor.
Interpret each report in context
Correlate the report with the author domain, time, reported authentication details and a known route when possible. Preserve the distinction between reported evidence and your inference about cause. A report can describe unauthorized mail using your domain, or legitimate mail that failed accidentally.
Treat embedded content as untrusted. Do not open links or attachments as though the report were a harmless notification. RFC 9991 recommends separating report streams and using sandboxing, segmentation and trained authorized reviewers. Minimize copies into tickets or chat systems.
Stop collection when its purpose ends
Set a review date for the diagnostic request. If the question is answered, reassess whether continued failure-report collection is justified. Preserve only the evidence needed under an approved retention decision, and use aggregate reporting for ongoing visibility where appropriate.
A final diagnosis should state which reports were available, which hypothesis they support, what remained unobserved and whether a controlled retest confirmed the repair. Avoid promises that ruf will expose every failure or eliminate the need for application and receiver evidence.
Primary section references: RFC 9991 §2, RFC 9991 §5, RFC 9991 §7, RFC 9991 §7.3, RFC 9991 §8.1, RFC 9989 §4.7, RFC 9990 §4.