DMARC Forensic (Failure) Reports Explained

What are DMARC forensic reports?

A DMARC forensic report, now called a failure report, is a copy of the headers of one message that failed DMARC, sent by the receiving mail server to the address in your record's ruf= tag. Unlike aggregate reports, which summarize a day of traffic in bulk, a failure report describes a single message. Since May 2026 they are defined by RFC 9991, which replaced the failure-reporting parts of RFC 7489.

Each report is an email with an attachment in the Authentication Failure Reporting Format (AFRF, RFC 6591), an extension of ARF. RFC 9989 removed the old rf= tag that let you ask for another format, because AFRF is the only one in use. A redacted report looks like this:

Content-Type: message/feedback-report

Feedback-Type: auth-failure
User-Agent: ExampleReceiver/1.0
Version: 1
Original-Mail-From: <bounce@mailer.example.net>
Arrival-Date: Thu, 01 Oct 2026 09:14:22 +0000
Source-IP: 198.51.100.24
Reported-Domain: example.com
Authentication-Results: mx.receiver.example;
  dmarc=fail (p=reject) header.from=example.com;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=fail header.d=example.com
Auth-Failure: dmarc
Delivery-Result: reject

This one says a message claiming to be from example.com arrived from 198.51.100.24, passed SPF for a different domain (so SPF did not align), failed DKIM, and was rejected under p=reject. The original headers follow in a second attachment.

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 do not 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 failure reports entirely or send them only in limited circumstances. Among the largest:

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=1

Consider 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 is worth including, but do not 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. Check your DMARC record to confirm both rua= and ruf= tags are configured.

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 are in the EU, consult your legal team about how you handle any RUF data you receive.

What changed for failure reports in RFC 9991?

RFC 9991, published in May 2026, moved failure reporting out of the core DMARC specification into its own document, replacing the matching parts of RFC 7489. RFC 9989 dropped the rf= tag at the same time, because the Authentication Failure Reporting Format (RFC 6591) is the only format. The ruf= and fo= tags stay in your DMARC record, so an existing record keeps working unchanged.

Sources

ShareX / TwitterLinkedIn