DMARC Failure Reports: What They Are and When to Use Them

Reporting

Introduction

DMARC failure reports — sometimes called forensic reports — are the per-message companions to aggregate reports. Where aggregate reports give you statistical summaries, failure reports give you individual copies of messages that failed authentication. They're requested via the ruf= tag in your DMARC record and shipped in AFRF (Abuse Reporting Format) email.

This article covers what's actually in them, the privacy reasons most receivers don't send them, and the narrow use cases where they earn their place.

Why this topic matters

Most teams either enable ruf= because they assume more data is better, then drown in noise — or skip it entirely without knowing what they're missing. Both are mistakes. Failure reports are a specialized tool with a narrow but real role in incident investigation. Knowing when to switch them on is the difference between useful and overwhelming.

What a failure report contains

A typical failure report is an AFRF email with:

• A feedback-type: auth-failure header identifying it as a DMARC forensic report.
• The original failed message, often redacted to remove body content.
• Authentication metadata explaining why it failed (SPF result, DKIM result, alignment).
• Source-IP information for the failing send.

Compared to aggregate reports, which give you count=247 from 198.51.100.42, failure reports give you one copy of one specific message from that IP at a specific time.

Why most receivers don't send them

Two main reasons:

1. Privacy. Failure reports can include forwarded user mail. If a Gmail user receives mail that fails DMARC and forwards it through their own filter rules, the forwarded copy lands in your forensic report — sometimes with their content. This is a privacy concern most providers won't take on.
2. Volume. A successful brand-impersonation campaign can generate thousands of forensic reports in an hour. Most receivers throttle or skip entirely.

Practically, you'll see forensic reports from a handful of smaller receivers and approximately none from Gmail, Outlook, or Yahoo.

When failure reports earn their keep

Three scenarios make them worth enabling:

1. Active incident investigation. During a known brand-impersonation campaign, the per-message detail helps identify attack patterns, source IPs, and targeted recipients.
2. Sophisticated remediation work. When debugging why a specific legitimate sender is failing intermittently, per-message context can surface causes that aggregate stats hide.
3. Forensic compliance. A handful of regulated industries want per-incident message-level records of authentication failures.

For most domains, none of these apply, and the noise outweighs the value.

How to enable them carefully

If you decide to enable ruf=, do it deliberately:

“text v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1 “

The fo= tag controls which failures trigger reports:

• fo=0 — only if both SPF and DKIM fail (default, most restrictive)
• fo=1 — if either fails (most useful for debugging)
• fo=d — if DKIM fails
• fo=s — if SPF fails

For investigation, fo=1 is usually right. For most other cases, you shouldn't have ruf= at all.

Best practices

• Default to disabled. If you don't have a specific reason to enable ruf=, leave it out.
• Route to a dedicated mailbox. Forensic reports can leak content; treat the mailbox like any other privileged log.
• Set retention policies. 30-90 days is typical; longer retention raises privacy concerns.
• Don't enable ruf= on a new rollout. Wait until aggregate reports tell you a specific investigation needs the detail.
• Coordinate with your DMARC platform. Some platforms ingest forensic reports too; others treat them as out of scope.

Recommended next step

If you don't currently have ruf= in your record, don't add it without a specific investigation need. If you're in the middle of an incident, enable it temporarily with fo=1, ingest into your platform, and turn it off when the incident closes.

For most domains, aggregate reports provide all the operational data needed. The bar to enabling forensic should be a specific question you can't answer otherwise.

FAQ

Why don't I get forensic reports from Gmail?

Google explicitly does not send them, citing privacy concerns. Yahoo, Microsoft, and most other major providers do the same.

Are forensic reports the same as ARF reports?

AFRF is the format; ARF is a related abuse-reporting format. DMARC forensic reports specifically use AFRF.

Can forensic reports leak our customers' data?

Yes, in some edge cases. If a customer's failed message is forwarded to your domain and the receiver sends a forensic report, you can end up with a copy. This is the main reason to be conservative about enabling ruf=.

Are forensic reports useful for normal monitoring?

Not really. They're high-detail, sparse, and hard to aggregate. Use them for investigations, not for routine monitoring.

Does enabling ruf= affect deliverability?

No. The ruf= tag is a feedback channel; it doesn't change how mail is filtered or delivered. It only affects what reports you receive.

Final thoughts

DMARC failure reports are a specialized tool. The reason most domains don't use them isn't ignorance — it's that aggregate reports cover 95% of operational needs and forensic reports come with overhead that isn't justified outside specific investigations.

Keep ruf= out of your default record. Add it when you have a specific question that aggregate data can't answer; remove it again when that question is answered. That discipline keeps the signal-to-noise ratio high.