DMARC reporting can answer two different questions: what authentication patterns a receiver observed across a period, and what happened to a particular failing message. The rua and ruf destinations request different evidence. Choose them with an investigation purpose, a responsible recipient and a retention policy.
Use aggregate reports for patterns
The rua tag requests aggregate reporting. RFC 9990 describes XML reports containing policy context, connecting IP addresses, counts, identifiers and authentication results. These reports help identify sending routes, alignment gaps and changes in observed volume. They are not a complete transcript of every message and do not normally supply the message body.
Aggregate metadata still deserves protection. Domains, IP addresses and traffic patterns can reveal service relationships and communication activity. A report also reflects the reporting receiver's observations, not all mail sent worldwide. Missing reports or a quiet row do not establish that a service sent no mail.
Request failure detail only when it helps
The ruf tag requests failure reports, with reporting conditions influenced by fo. RFC 9991 explains that failure reports can contain message headers and sometimes the entire message. That can expose addresses, subjects, personal information and confidential content beyond the narrow authentication defect being investigated.
A request does not oblige every receiver to send a report. Receiver policy, privacy decisions and rate limiting affect availability and content. Avoid promising instant or exhaustive forensic coverage. Redaction can reduce exposure but can also remove evidence needed to reproduce a DKIM failure, so record what is absent rather than assuming a report is complete.
Make a deliberate evidence choice
Illustrative decision: an aggregate row shows a new unaligned sender for billing mail. The team first compares its sender inventory and a controlled invoice test. If that resolves the configuration issue, requesting message-level failure content may add little value. If individual failures remain unexplained, the team can assess whether failure reports are necessary and lawful for that investigation. This is a hypothetical workflow, not an observed privacy review.
Define who can read each report type, where it is processed, how long it is retained and whether it crosses organizational or geographic boundaries. Avoid forwarding raw failure reports to broad ticket queues. Treat report attachments as untrusted input and protect parsing and decompression resources.
Verify destinations and expectations
External report destinations need the authorization procedure described in RFC 9990; RFC 9991 applies that procedure to failure-report destinations. Destination authorization prevents unsolicited reporting abuse, but does not replace your organization's approval to share information with a processor.
Verify that the mailbox or processor can receive and safely parse the selected reports. Keep the request, recipient authorization, access policy and observed arrival evidence together. Review the setup when vendors, privacy requirements or investigation needs change. Start with the least detailed evidence that answers the question, and expand deliberately rather than collecting sensitive messages by default.
Make the minimum-data choice explicit
A hypothetical billing investigation chooses aggregate fields only: policy domain, source IP, count, author domain, raw and aligned authentication results, and reporting period. It excludes message bodies, subjects and recipient addresses, and does not request ruf. Its recipient is a fictional internal mail-security team with access limited to two designated incident handlers.
The example retains the raw sample for 14 days to compare two weekly windows, then deletes it. This is an illustrative operational choice, not a legal requirement or universal recommendation. Check that allowed and excluded field lists do not overlap and that failure reporting is not selected. This consistency check cannot approve the policy. Real recipient selection, access grants, retention and privacy approval remain pending before implementation. If the investigation requires failure content later, make a new necessity and disclosure decision rather than silently expanding collection.
Use a reporting decision card
- Start with the question: which sending route or alignment defect needs explanation?
- Prefer aggregate counts and controlled tests when they answer it.
- Before requesting failure content, document necessity, intended recipients, access restrictions and retention.
- For an external destination, verify both DNS authorization and your organization’s separate sharing approval.
- Success means usable evidence arrived and the question was resolved; a published rua or ruf request alone proves neither.