How to read a DMARC forensic report: a field-by-field guide

Your DMARC record can have a ruf= tag too, and it doesn't behave anything like rua=. Aggregate reports arrive once a day as a compressed XML file. Forensic (or also called failure) reports, when a receiver sends them at all, arrive close to real time, one per failing message, and they're built to be read by a person investigating a specific incident, not summarized by a dashboard. Here's what's actually inside one and how to read it without assuming it works like the reports you already know.

Keep this table nearby. Everything below walks through why each row matters and how to read it in a real report.

A DMARC forensic report, also called a failure report or RUF report, is a near-real-time notification generated by a receiving mail server the moment a single message fails DMARC evaluation. It carries message-level detail: which IP sent it, why authentication failed, and what the message actually looked like. That's a fundamentally different job from an aggregate report, which summarizes every sending source over a 24-hour window and never names an individual message.

Red Sift OnDMARC processes both report types, but forensic data specifically benefits from centralized, access-controlled handling, because unlike aggregate reports, it can carry personal information about your recipients. Understanding what's actually in a forensic report, and where the risk sits, makes the decision of whether to enable it at all a much easier one.

By the end, you'll be able to:

• Tell a forensic report apart from an aggregate report on sight, and know why the file formats differ
• Read every field in a real AFRF-format report without a reference sheet
• Understand what the fo= tag controls and which setting most teams should start with
• Recognize the four patterns that show up most often in forensic data
• Know when enabling forensic reports is worth the privacy tradeoff, and when it isn't

If you've read an aggregate report before, the first thing that trips people up about forensic reports is the format. Aggregate reports are XML because they're built for machines to parse in bulk. Forensic reports use a completely different format called AFRF, the Authentication Failure Reporting Format, which is a DMARC-specific extension of ARF, the general-purpose Abuse Reporting Format used across the email industry for spam and abuse complaints [1].

AFRF looks like a set of email headers, not a markup document. That's deliberate. ARF-family reports were designed decades ago to be readable by a human looking at a single problematic message, forwarded the way any other email would be. A forensic report is essentially a structured version of "here's the message that failed and why," wrapped in a machine-parseable header block instead of prose.

This is worth internalizing before you open your first one: if you go looking for <record> tags or a feedback root element like you'd find in an aggregate report, you won't find them. What you'll find instead is a block that reads more like a bounce notification than a data file.

Here's a representative forensic report, using reserved domains and IP ranges per RFC 5737 so nothing here points at a real sender or recipient.

Feedback-Type: auth-failure
User-Agent: RedSiftReporter/1.0
Version: 1
Original-Mail-From: <billing@vendor.example>
Original-Rcpt-To: <ap@redsift.example>
Arrival-Date: Wed, 19 Aug 2026 09:14:22 +0000
Message-ID: <a1b2c3d4@vendor.example>
Authentication-Results: dmarc=fail; dkim=fail; spf=pass
Identity-Alignment: dkim
Source-IP: 198.51.100.7
Reported-Domain: redsift.example
Original-Envelope-Id: <e5f6g7h8@vendor.example>
Dkim-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=vendor.example; q=dns/txt; s=mta; t=1788429698; x=1788436898; h=Message-Id: List-Unsubscribe-Post: List-Unsubscribe: To: To: From: From: Subject: Subject: Content-Type: Mime-Version: Date: Sender; bh=Qfn6ZXFS7sI6eJdL8VkYJGkZTxvNbH2aoX0/pIfZpWA=; b=0LACbKma2jAg+wWxUparh41AAGDpG5VXIHNg6iq8RoIn4cj6cChPfyZwkF+YmF8T5T7zB6mPYNSSo5ImUHA63Be+Dz39qwQZQXeb1X1f9KYSM0YH6UBpYS460gSS7OwS/mhdUdgodlI12iiG3ol4Ls9IyXWml9/p0PqFDZnPKgpkhbQuRtcyECWNQj6ZuaKVCKmiPALKa/8NOZaX9eXJ906LAEwzfkCjgR/9CSp1sITKtpZdIhHy0hb73lavr3BHKEsf/vsAayDvHH/leoTaIzO+lU3fHkXKmQWy9orGqEjHEmgQ4zUu5Q9HGNl+gPOs0+ILok5kzFUQkImuA9m91g==

Here's what each line is actually telling you:

• Feedback-Type: auth-failure confirms this is a DMARC failure report specifically, not a spam or abuse complaint. ARF is used for multiple report types, so this line is the one that tells you which kind you're looking at.
• User-Agent names the reporting software. Useful mainly for debugging a receiver that's sending malformed reports.
• Original-Mail-From is the envelope sender, the address used in the SMTP transaction. This is the same field SPF actually validates against, and it can differ from the visible From address a recipient sees.
• Original-Rcpt-To is the recipient. This is the field that makes forensic reports carry PII, since it's a real mailbox address rather than a domain-level summary.
• Arrival-Date timestamps exactly when the message landed, which matters for correlating against your own mail gateway logs.
• Authentication-Results is the headline field. Here, SPF passed but DKIM failed, and DMARC failed overall. Because DMARC only needs one of SPF or DKIM to align, a DMARC failure with SPF showing pass means the SPF pass didn't align with the visible From domain, not that SPF was broken.
• Identity-Alignment names exactly which mechanism(s) failed to authenticate an aligned identity, or reads "none" if every attempted method aligned. This field became required under the 2026 update, and it's the fastest way to confirm whether you're looking at a DKIM alignment problem, an SPF alignment problem, or both, without cross-referencing the raw Authentication-Results line yourself [2].
• Source-IP is the exact sending server. Cross-reference this against your approved sender inventory before assuming anything.
• Reported-Domain confirms which domain's policy triggered the report, useful when you manage forensic reporting across several domains at once.
• Dkim-Signature: The DKIM signature of the message.

Practical tip: work these four questions in order every time you open a forensic report. Is the Source-IP recognized? Did SPF or DKIM fail, or both? Is the Original-Mail-From aligned with your domain? Does this look like a forwarding artifact rather than an attack? If you can't answer confidently, route it to whoever owns the incident response rather than acting on it alone.

Some forensic reports go further and attach a redacted or full copy of the failing message's headers and subject line. That's the part that turns a diagnostic tool into a privacy consideration, covered below.

The fo= tag in your DMARC record controls when a receiver generates a forensic report at all. Most receivers only check this tag if you've also published a ruf= destination.

fo=1 gives the broadest visibility and is what most security teams reach for, because a message can fail DMARC on alignment even when one protocol technically passes, and fo=0 would miss that. The tradeoff is volume: fo=1 on a domain with any meaningful forwarding traffic can generate a report for every mailing list redistribution and every broken forwarding chain, most of which aren't attacks.

1. Locate your existing DMARC TXT record at _dmarc.yourdomain.com.
2. Add a ruf= destination. A representative record: v=DMARC1; p=quarantine; rua=mailto:aggregate@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1;
3. Set fo= deliberately, not by default.
4. If the destination domain differs from the sending domain, publish an authorization record at the destination, the same requirement that applies to rua= reports sent cross-domain.
5. Route the mailbox to a platform, not a person. A shared inbox receiving PII-bearing reports creates exposure that a centralized, access-controlled system avoids.
6. Allow for propagation. DNS changes can take up to 48 hours to reach every receiver.

For the broader DMARC record setup, including the rua=, p=, and alignment tags, see our guide to DMARC implementation.

An empty ruf= destination doesn't necessarily mean misconfiguration.

This is why aggregate reports remain the authoritative source for ongoing domain health monitoring, and forensic reports stay a supplemental tool for specific investigations rather than a replacement.

A forensic report can include a real recipient address, a subject line, and sometimes message content, which is exactly why major mailbox providers, including Gmail and Microsoft 365, generally don't send them at all. The privacy tradeoff is the whole reason forensic reporting has far weaker industry support than aggregate reporting: receivers have to weigh a domain owner's diagnostic need against their own users' privacy, and most default to not sending.

For organizations in regulated sectors, that data has real compliance weight under frameworks like GDPR and CCPA. A few practices matter more here than almost anywhere else in DMARC:

Route reports to a secure, access-controlled platform, never a general-purpose inbox.

Limit access by role. Not everyone who can see aggregate dashboards needs to see message-level forensic data.

Define a retention policy. Forensic data has a short useful shelf life for investigation purposes, and holding it longer than needed increases exposure without adding value.

Treat receivers that redact fields as doing you a favor, not withholding data. Some receivers strip subject lines or message bodies before sending; that's privacy-conscious behavior on their end, not a broken report on yours.

1. Legitimate sender, misconfigured alignment. SPF or DKIM passes on the raw check, but Authentication-Results shows a DMARC failure. This is almost always an alignment problem, not a spoofing attempt. Fix the sender's configuration rather than treating it as a threat.

2. Forwarding or mailing-list breakage. Source-IP belongs to a recognized forwarder or list server, SPF fails, but DKIM often still passes because DKIM signatures typically survive forwarding intact. Check whether DMARC can be satisfied through DKIM alignment alone before escalating.

3. Shadow IT. A Source-IP you don't recognize turns out to belong to a SaaS tool a team adopted without telling IT. The volume is usually small and consistent day over day, not a burst. Add the sender to SPF and move on.

4. Actual spoofing. An unrecognized Source-IP, no relationship to any known vendor or forwarding service, both SPF and DKIM failing, and no pattern that maps to internal explanation. This is the pattern worth escalating: confirm your policy is strong enough to quarantine or reject it, and loop in your security team if the volume is more than a one-off.

Validate any of these against your aggregate report trends and mail gateway logs before acting. A single forensic report is one data point, not a verdict.

Forensic reporting isn't a default-on setting. It earns its place in specific situations:

• You have a security team who will act on message-level data. Without someone to triage it, fo=1 volume becomes noise nobody reads.
• You're actively troubleshooting a specific sender and aggregate data isn't specific enough to diagnose it.
• You already run secure, access-controlled reporting infrastructure, so the added detail carries little marginal risk.

Skip it, or reconsider it, when reports would land in a shared inbox with no encryption or access controls, or when nobody owns triaging the output. In both cases, aggregate reports already cover the domain-health monitoring most teams actually need day to day.

In May 2026, the IETF replaced the original DMARC specification, RFC 7489, with three separate Standards Track documents: RFC 9989 covers the core protocol, RFC 9990 covers aggregate reporting, and RFC 9991 covers failure reporting specifically [2, 3]. Before this update, forensic reporting was covered only informally alongside the main DMARC spec. Giving it a dedicated document means failure reporting can now evolve on its own schedule, the same structural change that happened for aggregate reporting.

A few concrete changes are worth knowing about the next time you're in a report:

• Identity-Alignment is now a required field, naming exactly which mechanism (or mechanisms) failed to produce an aligned identity, rather than leaving you to infer that from the raw Authentication-Results line [2].
• DKIM-Domain, DKIM-Identity, and DKIM-Selector are now required whenever a DKIM failure involves an aligned identifier, and SPF-DNS is now required for SPF failures of an aligned identifier, tightening what used to be optional detail [2].
• External destination verification is now explicit. If your ruf= address points outside your organizational domain, receivers must verify that destination the same way they already verify external rua= destinations, closing a gap that previously let a bad actor redirect failure reports to an unauthorized address [2].

None of this changes the AFRF envelope itself or how the ruf= and fo= tags work day to day. What's changed is that fields security teams already relied on informally are now normatively required, so a report you receive going forward should be more consistently complete than reports were before May 2026.

Expecting XML. Forensic reports use AFRF, not the XML format aggregate reports use. Looking for <record> elements in a forensic report means looking in the wrong format entirely.

Treating a single report as a verdict. One forensic report tells you about one message. Validate against aggregate trends and logs before concluding anything.

Assuming every failure is spoofing. Most forensic reports reflect forwarding, alignment misconfiguration, or shadow IT, not an attack.

Routing reports to a shared inbox. Because forensic reports can carry PII, an unprotected inbox turns a diagnostic tool into a compliance liability.

Enabling fo=1 without a triage plan. High volume with no one to read it is noise, not visibility.

Assuming an empty ruf= mailbox means it's broken. Many major providers simply don't send forensic reports at all, for their own users' privacy.

A DMARC forensic report is a handful of header-style fields describing exactly one failing message, delivered in AFRF, not XML, and it exists to answer a narrower question than an aggregate report ever can. It's worth enabling when you have someone to read it and a secure place for it to land, and worth skipping when you don't.

For the report type most teams should start with, see our guide to reading a DMARC aggregate report. If you're troubleshooting a specific failure right now rather than deciding whether to enable forensic reporting at all, our guide to debugging DMARC failures walks through alignment fixes, DNS errors, and forwarding issues directly.

Red Sift OnDMARC centralizes both aggregate and forensic data, applies role-based access to sensitive report content, and surfaces the four patterns above automatically instead of asking you to read AFRF by hand. It also has special partnerships with providers, which means you will get more forensic reports than on a regular mailbox due to our data partnerships.

[1] RFC 5965 - An Extensible Format for Email Feedback Reports

[2] RFC 9991 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting

[3] RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)

[4] RFC 6591 - Authentication Failure Reporting Using the Abuse Reporting Format