How can DMARC RUF reports support incident response?

Your domain is being spoofed in a phishing campaign. You've got DMARC set up, and RUF reports are flowing in. Now what? This is exactly the moment RUF reports earn their keep.

DMARC RUF reports (the "forensic" ones, as opposed to the aggregate RUA reports) are per-message failure reports. When an email fails DMARC authentication and the receiving mail server supports RUF reporting, it sends a copy of that failed message back to the address you specified in your DMARC record. You get the actual email, or at least a redacted version of it, not just a summary.

During an incident, here's what RUF reports actually show you:

• The "From" address being spoofed. Exactly how the attacker is crafting it (captain@yourcompany.com vs captain@yourcompany.com.evil.io, for example)
• The sending IP address. This tells you what infrastructure the attacker is using
• Authentication failure details. Whether SPF failed, DKIM failed, or both, and what alignment the message had
• Message headers. Routing path, timestamps, and any X-Mailer or User-Agent hints
• Subject lines and partial body. Enough to understand the attack's angle (urgency, wire transfer scam, fake login page link)
• Receiving domain. Which of your customers or partners is being targeted

In practice, you might receive a RUF report that shows an IP in a country you've never sent from, a spoofed address that almost matches yours, and a subject line that screams "urgent invoice." That's your attack signature right there. You can feed that IP into blocklist lookups, cross-reference it against Spamhaus data, and start building a picture of the campaign.

Timing matters here. RUF reports arrive near real-time, usually within minutes of a failure. That's the key difference from aggregate RUA reports, which batch everything into daily summaries. If you're actively being spoofed, RUF is your early warning system.

That said, there are real limitations to know about:

• Not every mailbox provider sends RUF. Gmail and Microsoft 365 don't send forensic reports at all. You'll get them from some smaller providers and corporate mail systems, but coverage is patchy.
• Privacy filtering removes content. Many providers strip message bodies before sending RUF, so you might only get headers. That's still useful, but it's not always the full picture.
• Volume can be overwhelming. If your domain is being heavily spoofed or if you have legitimate authentication issues, your RUF inbox can flood fast. It's worth using a dedicated RUF processing tool rather than trying to read raw reports by hand.

A sensible incident response workflow looks something like this. First, parse the RUF reports to extract unique sending IPs. Second, cluster them to spot whether it's one source or a distributed network. Third, check those IPs against blocklists and abuse databases. Fourth, use the header forensics to identify the sending infrastructure or service being abused. Fifth, document the attack pattern and report it to the abuse contacts for the sending IPs.

RUF reports won't stop an attack on their own. But they hand you the evidence you need to understand what's happening, where it's coming from, and who's being targeted. That's a big head start. If your domain is actively being spoofed right now and you're not sure how to read what's coming in, our SOS hotline is free and we'll help you make sense of it.