Triage Playbook: Deconstructing Your First DMARC 'ruf' Forensic Report

The alert fires. A new message has arrived at the special address you configured weeks ago, the one pointed to by the `ruf` tag in your domain's DMARC record. It’s an XML file, cryptic and dense. This isn't just another aggregate report; it’s a forensic sample, a direct copy of a malicious email that tried to impersonate your brand.

Most DMARC guides stop at aggregate (`rua`) reports, which are great for monitoring deliverability and broad trends. But `ruf` (forensic) reports are different. They are the high-fidelity signal, the ground truth. They contain a full copy of the offending email, including headers and body, as seen by the recipient's mail server.

While privacy concerns mean that not all receivers send `ruf` reports—Google and Microsoft notably do not—the ones that do provide an unparalleled view into the TTPs of attackers targeting you. Let's open one up and see what we can find.

Signal vs. Noise: Why Forensic Reports Are Worth the Effort

Your DMARC record can specify two reporting addresses. The `rua=mailto:address` tag requests aggregate data. These are the daily XML reports summarizing which IPs sent mail claiming to be you, their volume, and their SPF/DKIM/DMARC dispositions. They are essential for getting to `p=reject` without breaking legitimate mail flow.

The `ruf=mailto:address` tag is for forensic reports, also known as failure reports. The key is in the name: they are generated only when a message *fails* DMARC evaluation. You can control this with the `fo` tag in your DMARC record. The most useful setting is `fo=1`, which requests a report if *any* underlying authentication check (SPF or DKIM) fails to produce an aligned "pass" result.

Why are they so valuable? Because an aggregate report might tell you an IP failed DMARC, but a forensic report shows you the email with the fake invoice attachment sent from that IP. One is a statistic; the other is a weaponized payload and actionable intelligence.

Anatomy of a `ruf` Report: Parsing Key XML Tags

At first glance, the XML in a forensic report is intimidating. But it's highly structured, defined by RFC 7489's Abuse Reporting Format (ARF). You're really looking for a few key sections to begin your triage.

The Metadata Wrapper

The top level of the XML provides context about the report itself, not the malicious email. The `feedback_type` tag will be `auth-failure`. The `user_agent` tells you what software generated the report (e.g., OpenDMARC, a commercial gateway). The `source_ip` within the `record` section shows the IP address of the machine that sent the failing email. This is your first indicator of compromise (IOC).

<feedback>
<report_metadata>...</report_metadata>
<record>
<row>
<source_ip>198.51.100.24</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>yourbrand.com</header_from>
</identifiers>
<auth_results>...</auth_results>
</record>
</feedback> — Excerpt from a typical DMARC auth-failure report

The Crown Jewels: `original_mail`

The most important part of the report is often not in the XML itself. The report is delivered as a MIME multipart message. One part is the `text/xml` you see above, and the other part is a `message/rfc822` attachment. This attachment contains the *entire original email*, headers and all. Some providers, for privacy reasons, might redact the body or some headers, but the core routing and authentication headers are usually intact. This is where the real investigation begins.

Triage Scenario 1: Deconstructing a Classic Spoof

Let's imagine a `ruf` report lands. The XML shows an SPF `fail` and a DKIM `fail` for a message with a `header_from` of your company's domain. The `source_ip` is an unfamiliar address on a residential ISP network. This is the bread-and-butter of brand impersonation.

Your first step is to extract the `message/rfc822` attachment and open it as a raw text file. You're now looking at the headers as the recipient's mail server saw them. Pay close attention to the `Authentication-Results` header, inserted by the receiving mail transfer agent (MTA). It provides a concise summary of the security checks.

Reading the `Authentication-Results` Header

This header, defined in RFC 8601, is your best friend. It will look something like this: `Authentication-Results: mta.receiver.com; dkim=fail reason="signature_did_not_verify" header.d=yourbrand.com; spf=fail (sender IP is 198.51.100.24) smtp.mailfrom=yourbrand.com; dmarc=fail action=none header.from=yourbrand.com`. This line tells you everything: DKIM failed because the signature was invalid (meaning the attacker likely didn't have your private key), and SPF failed because the sending IP isn't in your SPF record. Because both failed to produce an aligned pass, DMARC failed.

Tracing the Path with `Received` Headers

Next, trace the `Received` headers from bottom to top. The bottom-most `Received` header shows the origin—the attacker's machine or an open relay they abused. You can correlate the IP address here with the `source_ip` from the XML report. This IP is your primary pivot point for blocking and further investigation.

Finally, examine the message body from the raw email. What was the payload? A link to a credential harvesting site? A malicious PDF? Now you have the full context of the attack that your DMARC policy helped expose.

Triage Scenario 2: Unmasking a Lookalike Domain

This case is more insidious. A `ruf` report comes in, but the `auth_results` in the XML show `dkim=pass` and `spf=pass`. How can that be? Your DMARC policy is set to `fo=1`, so something must have failed.

The failure isn't in authentication, but in *alignment*. DMARC requires that the domain used for SPF or DKIM validation (the `smtp.mailfrom` or the DKIM `d=` tag, respectively) aligns with the domain in the user-visible `From:` header. An attacker can set up a lookalike domain (e.g., `yourbrnad.com`), configure valid SPF and DKIM for *it*, and then send emails that visually appear to be from you.

The `ruf` report is critical here. Inside the `original_mail` headers, you'll see something like: `From: "Your Brand CEO" <ceo@yourbrnad.com>`. Then, in the `Authentication-Results` header: `dkim=pass header.d=yourbrnad.com`. The DKIM signature passed, but for the wrong domain. Because `yourbrnad.com` does not match `yourbrand.com`, DMARC alignment fails, and a report is generated.

This is a Business Email Compromise (BEC) attempt in progress. The `ruf` report didn't just tell you about a configuration error; it handed you the exact lookalike domain the attacker is using for their campaign.

From Intel to Action: Hardening Your Defenses

A DMARC forensic report isn't a trophy; it's a task list. The goal is to take the indicators you've just uncovered and use them to proactively defend your organization.

First, the low-hanging fruit. Is the `source_ip` from a spoof attempt a single static address? Block it at your firewall or email gateway. Is it a cloud provider's IP? Report the abuse to them with the forensic report as evidence. Did you discover a lookalike domain? Add it to your gateway's blocklist and use it as a keyword to search existing mail logs. You might find that the campaign has been active for weeks, but only now, with DMARC reporting, do you have visibility.

This is also a threat hunting opportunity. Take the subject line, any URLs from the body, and the attacker's domain, and pivot. Search your EDR logs, your proxy logs, and your SIEM. Did anyone in your organization receive and click on this threat *before* your DMARC policy was fully deployed or from a receiver that doesn't validate DMARC? The `ruf` report gives you the specific IOCs needed to answer that question.

Before You Begin: Validating Your `ruf` URI

There's a common 'gotcha' that prevents many organizations from ever receiving a forensic report. You can't just point the `ruf` tag at any email address you want. For an external domain to accept DMARC reports on behalf of your domain, you must explicitly authorize it.

Let's say your DMARC record is for `example.com`, and you set `ruf=mailto:reports@thirdparty.net`. When a mail provider like Comcast is about to send a forensic report to `reports@thirdparty.net`, it first performs a DNS check. It looks for a TXT record at a specially constructed name: `example.com._report._dmarc.thirdparty.net`.

That DNS record must exist and contain the value `v=DMARC1;`. This mechanism, specified in RFC 7489, confirms that `example.com` has given `thirdparty.net` permission to receive its reports. Without this record, most reporters will silently drop the report, and you'll be left wondering why you never see any forensic data. Check your DNS configuration before you start waiting for reports to flow.

The takeaway

DMARC aggregate reports tell you what happened. DMARC forensic reports show you how it happened and who did it. They transform DMARC from a deliverability tool into a near real-time threat intelligence feed focused on the attacks aimed squarely at your brand's reputation.

The volume may be low, and the format may be raw, but the value of each `ruf` report is immense. By learning to deconstruct them, you're not just cleaning up mail hygiene; you're actively hunting threats. Parsing them manually is a great skill, and for scaling this up, platforms like MailSleuth.AI can automate the extraction, correlation, and alerting process, turning raw XML into finished intelligence.