DMARC forensic reports are individual failure reports that can be sent when a receiving mailbox sees a message that fails DMARC. They are sometimes called failure reports or RUF reports. Unlike aggregate reports, which summarize traffic in XML, a forensic report focuses on one message event and can help explain why a specific sender failed.
Forensic reports versus aggregate reports
Aggregate reports are the operational starting point for most DMARC programs. They show volumes, source IP addresses, authentication outcomes, and policy disposition over time. Forensic reports are narrower: they may describe a single failure with technical context. The DMARC report overview explains the wider reporting model, while the aggregate-report guide shows how to investigate trends safely.
Where the request is configured
The ruf tag in a DMARC record can specify a mailbox for forensic-report requests. For example, ruf=mailto:dmarc-failures@example.com asks participating receivers to send eligible failure reports there. The tag is a request, not a guarantee: many major mailbox providers do not send them, limit what they send, or redact message content to protect privacy.
Why delivery is inconsistent
Forensic reports can contain information about an individual message, so receiver privacy rules and anti-abuse controls are intentionally conservative. A lack of forensic reports does not mean DMARC is broken, and receiving one does not necessarily mean your policy is wrong. Treat aggregate reports and real-message headers as the dependable evidence sources; consider forensic reports supplemental signals when they arrive.
What a report may tell you
The useful details often include the reporting organization, time of the event, source IP address, visible From domain, evaluated SPF or DKIM results, and the reason DMARC failed. Use those fields to identify whether the source is an authorized vendor, a configuration gap, a forwarding scenario, or likely impersonation. Do not make a policy change from a single report without checking broader traffic.
Protect the reporting mailbox
Use a dedicated mailbox or controlled reporting service rather than a person’s everyday inbox. Give access only to people who need to troubleshoot email authentication, retain reports for a defined period, and avoid forwarding message-level data unnecessarily. If a report includes sensitive fragments, follow your organization’s privacy and incident-handling practices before sharing it.
Investigate a failure in sequence
First, confirm the visible From domain and the source IP. Next, determine whether the sender appears in your approved-sender inventory. Then compare the SPF envelope domain and DKIM d= domain with the From domain. SPF alignment and DKIM alignment explain why an authentication pass can still fail DMARC. Finally, find a fresh message header or aggregate-report evidence before changing DNS.
Do not expose message data unnecessarily
Forensic reporting is not a substitute for a general-purpose message archive. Avoid publishing RUF mailboxes broadly, and do not assume every recipient can safely receive every diagnostic detail. When a vendor asks for evidence, provide only the minimum fields needed to resolve the issue and remove identifiers where practical. This keeps troubleshooting useful without turning a DMARC mailbox into an unmanaged data store.
When to use the tag
Consider RUF only when your team has a clear monitoring owner, a secure destination, and a process for reviewing occasional failure evidence. It may be useful during a focused rollout or an investigation involving a known sender. If you do not have capacity to review it, prioritize aggregate reports, sender inventory, and header tests instead. More data is not automatically better data.
Keep the core program in place
Your essential DMARC work remains the same: publish a valid record, understand legitimate senders, verify aligned SPF or DKIM, and move policy gradually once monitoring is stable. Use the DMARC implementation checklist for that sequence. Beacon’s free domain check can confirm the public SPF, DKIM, and DMARC records before you interpret message-level failures.