What Are DMARC Forensic Reports?
DMARC forensic reports (also called RUF reports, from the ruf= tag) are per-message failure notifications sent by receiving mail servers when an individual email fails DMARC authentication. Unlike aggregate reports — which summarize traffic in bulk — forensic reports contain details about a single failing message.
They are delivered to the address specified in your DMARC record's ruf= tag, formatted as an email with an ARF (Abuse Reporting Format) attachment containing the message headers and authentication details.
What Triggers a Forensic Report?
The fo= tag in your DMARC record controls what triggers forensic report generation:
fo=0(default) — Generate a report only when both SPF and DKIM fail. The message must fail all underlying mechanisms to trigger a report.fo=1— Generate a report when any authentication mechanism fails, even if another passes. This produces the most reports.fo=d— Generate a report only when DKIM fails, regardless of SPF result.fo=s— Generate a report only when SPF fails, regardless of DKIM result.
Multiple options can be combined: fo=1:d:s
What Data Do Forensic Reports Contain?
A forensic report is structured as an email message with the original failing message's headers attached. The report typically includes:
- Authentication-Results header — The full SPF, DKIM, and DMARC evaluation results for the failing message.
- Original message headers — The
From:,To:,Subject:,Date:,Message-ID:,Received:chain, and any DKIM-Signature headers from the original email. - Delivery information — The source IP and envelope sender used during the SMTP transaction.
- Disposition — What the receiving server did with the message (none, quarantine, reject).
Notably, most forensic reports do not include the message body. The ARF format allows for body inclusion, but nearly all providers strip it for privacy reasons.
Privacy Concerns and Why Providers Don't Send Them
Forensic reports present a significant privacy challenge. Even without the body, the headers alone can reveal:
- The recipient's email address (
To:header) - The subject line, which may contain sensitive information
- The full routing path of the message via
Received:headers - Internal mail server hostnames and infrastructure details
For this reason, many large email providers have stopped sending forensic reports entirely or send them only in limited circumstances. As of 2024:
- Google (Gmail) — Does not send RUF reports.
- Microsoft (Outlook/365) — Does not send RUF reports.
- Yahoo/AOL — Sends RUF reports for some failure conditions.
- Smaller providers and self-hosted servers — Often send RUF reports if the receiving MTA is configured to do so (e.g., Postfix with opendmarc).
This means you should never rely on forensic reports as your primary monitoring mechanism. Aggregate reports are far more comprehensive and universally supported.
How Forensic Reports Differ from Aggregate Reports
- Granularity — Forensic: one report per failing message. Aggregate: bulk summary over 24 hours.
- Trigger — Forensic: only on authentication failures. Aggregate: sent regardless of pass/fail, covering all traffic.
- Provider support — Forensic: limited and declining. Aggregate: universal among major providers.
- Privacy impact — Forensic: exposes recipient data and routing details. Aggregate: only source IPs and counts, no recipient information.
- Volume — Forensic: can be extremely high if you receive a lot of spam using your domain. Aggregate: predictable, one report per provider per day.
When Are Forensic Reports Useful?
Despite their limitations, forensic reports can be valuable in specific situations:
- Diagnosing a configuration issue — If a specific legitimate sender is failing DMARC, a forensic report can show exactly which headers failed and why, making it easier to fix the SPF or DKIM configuration.
- Investigating an active spoofing campaign — Forensic reports from providers that still send them can help you see the structure of phishing emails using your domain — subject lines, routing paths, and sending infrastructure.
- Self-hosted infrastructure — Organizations running their own mail servers can configure opendmarc or similar tools to generate detailed forensic data for internal analysis without privacy concerns.
Setting Up Forensic Reports
To receive forensic reports, add the ruf= tag to your DMARC record:
v=DMARC1; p=reject; rua=mailto:dmarc-rua@yourdomain.com; ruf=mailto:dmarc-ruf@yourdomain.com; fo=1Consider using a dedicated mailbox for RUF reports, separate from aggregate reports. Even with declining provider support, you may still receive forensic reports from smaller providers and ISPs that can provide useful diagnostic information.
Frequently Asked Questions
Should I bother configuring the ruf= tag?
It's worth including, but don't make it your primary monitoring strategy. Aggregate reports (rua=) are far more important and universally supported. Setting ruf= costs nothing and may occasionally yield useful diagnostic data from providers that still send forensic reports.
Can I get overwhelmed by forensic reports?
Yes. If your domain is being actively spoofed in a spam campaign, you could receive thousands of forensic reports per hour, flooding the mailbox. Use a dedicated address and consider rate-limiting rules. Some DMARC tools can filter and aggregate forensic report data to make volume manageable.
Are forensic reports GDPR compliant?
This is a legal question specific to your jurisdiction and privacy program. The recipient data in forensic reports (email addresses, routing information) is personal data under GDPR. This is the primary reason major providers like Google and Microsoft have stopped sending them. If you're in the EU, consult your legal team about how you handle any RUF data you receive.