DMARC Forensic Reports (RUF): When to Enable Them

DMARC Forensic Reports (RUF): When and Why to Enable Them

DMARC forensic reports — configured with the ruf= tag — send you message-level details when an individual email fails DMARC authentication. Unlike aggregate reports, which summarise authentication results across all mail from a sending source, forensic reports give you the headers, envelope, and metadata of specific failing messages.

They're genuinely useful in some situations. In others, they're noise you don't need.

What Forensic Reports Actually Contain

When a message fails DMARC and forensic reporting is enabled, the receiving server generates a report and sends it to the address in your ruf= tag. The report format is defined in RFC 7489, section 7.3.

A forensic report contains:

• The message's original headers (From, To, Subject, Date)
• The envelope sender (Return-Path)
• The authentication results: SPF, DKIM, DMARC pass/fail with reasons
• The sending IP address
• In some cases, a redacted or full copy of the message body

The last point — message body content — is why forensic reports are treated differently from aggregate reports. They can contain sensitive information: business communication, customer data, or authentication tokens included in automated emails.

The Privacy Problem With RUF Reports

Aggregate reports contain statistical summaries. Forensic reports contain individual message data.

That creates a real privacy consideration. Your ruf= address receives copies of emails that failed authentication, including emails that were legitimate messages with a misconfigured sender, not just spoofing attempts. If an employee's email to a client fails DMARC due to an SPF misconfiguration, that message header (including recipient and subject) ends up in a forensic report.

For this reason, most organisations either don't enable forensic reporting or enable it temporarily during debugging, then remove the ruf= tag.

There's also the mailbox provider problem: many major providers don't send forensic reports at all. Gmail stopped sending RUF reports years ago. Microsoft 365 is inconsistent. Yahoo sends them. The result is that your forensic reporting data is incomplete by default — you see failures only from providers willing to send them.

When Forensic Reports Are Worth Enabling

You're debugging a specific authentication failure. If a particular sending service is generating DMARC failures that you can't diagnose from aggregate data alone, enabling forensic reporting for a short period can show you the exact headers of failing messages. This is far faster than trying to reconstruct the issue from IP addresses and pass/fail counts.

You're investigating an active spoofing campaign. If you suspect attackers are actively sending phishing email using your domain, forensic reports (from providers that send them) give you sample message headers and sending IPs. That's useful intelligence — you can identify the infrastructure being used and escalate appropriately.

Your domain has consistent unexplained failures. Aggregate reports show a source is failing authentication but the cause isn't clear from the data. Forensic reports reveal the exact failure reason per message, which aggregate summaries don't always surface.

You run a low-volume domain where message-level detail is manageable. A domain sending a few hundred emails a day will generate a manageable number of forensic reports. A domain sending millions of messages will produce forensic report volume that's difficult to work with.

When to Leave RUF Disabled

Your domain handles sensitive communications. Healthcare, legal, financial services — any domain where message content is regulated or confidential. The risk that a legitimate message ends up in a forensic report sent to a third-party address isn't worth the debugging benefit.

You're already at p=reject and not seeing unexpected failures. Once your DMARC enforcement is stable and your aggregate reports show high compliance, forensic reports add little. You'd be collecting detailed data on sporadic edge cases.

You're not equipped to process the volume. A high-volume sending domain can generate thousands of forensic reports per day from providers that send them. Without tooling to parse and triage them, the data creates more work than it resolves.

You're relying on Gmail failures to surface. Google doesn't send RUF reports. If your primary concern is failures on Gmail recipients, forensic reports won't help regardless.

How to Configure Forensic Reporting

The ruf= tag accepts one or more email addresses, just like rua=:

v=DMARC1; p=none; rua=mailto:reports@simpledmarc.com; ruf=mailto:forensic@yourdomain.com; fo=1;

The fo= tag controls which failure conditions trigger a forensic report. Options:

fo=1 is the most useful setting for debugging — it captures any authentication failure, not just cases where both mechanisms fail.

To remove forensic reporting after debugging, simply delete the ruf= tag from your record:

v=DMARC1; p=none; rua=mailto:reports@simpledmarc.com; fo=1;

DNS propagates the change within minutes to hours depending on your TTL.

The ruf= Address Options

Three approaches are common:

Your own mailbox. Simple, but forensic reports are not human-readable without a parser. The report format is a MIME message with nested authentication headers. Most people who try this abandon it within a day.

Your DMARC platform's forensic reporting address. SimpleDMARC parses forensic reports automatically alongside aggregate reports, making them readable in the same dashboard. This is the most practical option if you want to act on forensic data.

A dedicated mailbox with parsing tooling. For organisations with security teams who want raw forensic data integrated into SIEM or incident response workflows, a dedicated address with forwarding to parsing infrastructure works well.

Sending forensic reports to an external address technically means forwarding message headers to a third party. Make sure your DMARC platform's privacy policy covers forensic report handling if you're in a regulated industry.

RUF vs RUA: The Summary

FAQ

Are DMARC forensic reports the same as DMARC failure reports?
Yes. Forensic reports, failure reports, and RUF reports all refer to the same thing: message-level DMARC failure reports generated by the ruf= tag. The DMARC specification calls them "failure reports," while practitioners often call them forensic reports because of the investigative use case they serve.

Does Google send DMARC forensic reports?
No. Gmail does not generate or send forensic reports. This is a documented policy, not a temporary limitation. If the majority of your email recipients use Gmail, forensic reports will give you an incomplete picture of your DMARC failures.

Can forensic reports contain the full email body?
Sometimes. The DMARC specification allows but does not require inclusion of the message body in forensic reports. Whether a receiving server includes body content depends on the provider's implementation and privacy policy. Most major providers redact or omit body content in practice.

How long should I enable forensic reporting for debugging?
A few days to a week is usually enough to capture the failing messages you're investigating. After the issue is diagnosed and fixed, remove the ruf= tag or route it to a low-priority address. There's no operational reason to collect forensic reports indefinitely once your authentication is stable.

What's the difference between fo=0 and fo=1?
fo=0 (the default) generates a forensic report only when both SPF and DKIM fail. fo=1 generates a report when either fails. For debugging, fo=1 is more useful — it captures cases where only one mechanism fails, which often points to alignment problems rather than outright authentication failure.