DMARC forensic reports (RUF) are per-message failure reports containing headers and sometimes partial body content of messages that failed authentication. Unlike aggregate reports, they are rarely sent in 2026 due to privacy concerns. This article explains what they are, why most large receivers no longer produce them, when they are still useful, and what to do instead.
ruf=fo= tag — controlling generationA forensic report is an email sent by a receiver at the moment a message fails DMARC. It includes:
Unlike aggregate reports, which are batched and delayed, forensic reports are potentially near-real-time — they can be triggered by each failing message individually.
The major providers — Google, Microsoft, Yahoo — stopped sending forensic reports in the mid-2010s. The reasons:
ruf= can themselves be used as amplification vectors in DoS attacks.The net effect: publishing ruf= in 2026 is largely a declaration of intent. You will rarely receive reports from major receivers. Smaller receivers and niche European providers sometimes still send them.
ruf=Syntactically similar to rua=:
ruf=mailto:[email protected]Multiple addresses allowed, separated by commas. Cross-domain publication requires the same authorisation record as rua: if pointing at a different domain, that domain must publish a TXT record at firm.co.uk._report._dmarc.target-domain.com confirming it accepts reports for firm.co.uk.
Because forensic reports contain message content, use a dedicated inbox with appropriate access controls.
fo= tag — controlling generationThe fo= tag tells receivers when to generate forensic reports. Four values, specifiable as a colon-separated list:
| Value | Meaning |
|---|---|
fo=0 | Default. Generate a forensic report only if both SPF and DKIM fail to produce aligned passes. |
fo=1 | Generate a report if either SPF or DKIM fails to produce an aligned pass. |
fo=d | Generate a report on any DKIM failure regardless of alignment. |
fo=s | Generate a report on any SPF failure regardless of alignment. |
Values can be combined: fo=d:s generates on any DKIM or SPF failure. fo=1 is the most commonly recommended; it catches failures before they are overridden by the other mechanism passing.
As of 2026, forensic reports are sent by:
Who does not send them:
For a UK business sending predominantly to consumer inboxes, the practical volume of forensic reports received is low — perhaps a handful per week at most.
Most DMARC processing services (dmarcian, Red Sift, EasyDMARC, Valimail, Mail Hardener) accept forensic report ingestion and surface them in dashboards alongside aggregate data. Because volumes are low, manual inspection in a dedicated mailbox is also feasible for smaller UK businesses.
When inspecting a forensic report, useful signals:
The intelligence value is highest when investigating an active spoofing campaign or building detection signatures for an email security gateway.
If forensic reports are too rare to be useful, alternatives exist:
[email protected], [email protected]) that receive no legitimate mail, and inspect whatever arrives.For most UK businesses, the combination of aggregate reports plus inbound mail logs is sufficient for operational DMARC monitoring. Forensic reports are a nice-to-have, not a must-have.
Forensic reports contain message content, which may include:
Under UK GDPR, receiving a forensic report arguably makes you a data processor for the personal data it contains. Mitigating factors:
Best practice: publish ruf= to an address under your own domain (not a third party), restrict access to the inbox, retain briefly (30-90 days) then delete, and document the purpose in your privacy notices as "security monitoring" under legitimate interest.
ruf= — reflecting the modern practical reality that most receivers do not send them. Customers who want forensic reporting can add the tag to their DMARC record and configure a processing inbox. Aggregate reports remain the primary monitoring tool.
Forensic reporting was designed into DMARC from the start in 2011-2012, alongside aggregate reports. Early adopters — PayPal, the major banks, Google itself — enthusiastically received and processed forensic reports, using them to develop phishing signatures and identify specific attack campaigns.
The shift began around 2016-2017, when European data protection authorities started asking pointed questions about cross-border transfer of email content. GDPR in 2018 tightened this further. Major receivers progressively stopped generating forensic reports, citing privacy as the primary concern but also acknowledging the operational cost.
By 2022 the practical reality was that almost no forensic reports reached domain owners from major UK-relevant receivers. The ruf= tag survived in the spec but became largely vestigial.
An example report (anonymised):
Subject: Forensic report for firm.co.uk
From: [email protected]
To: [email protected]
This is a DMARC forensic report for a message that failed authentication.
Failed-Authentication-Report:
Arrival-Date: Tue, 21 Apr 2026 14:23:00 +0100
Source-IP: 198.51.100.47
Reported-Domain: firm.co.uk
Delivery-Result: smg.reject
SPF-DNS: firm.co.uk
Authentication-Results: receiver.eu; dmarc=fail; spf=fail; dkim=none
Original-Message-Headers:
From: "Urgent: Invoice" <[email protected]>
To: [email protected]
Subject: Urgent - invoice overdue
Date: Tue, 21 Apr 2026 14:22:57 +0100
Message-ID: <[email protected]>
...From this a UK security team can see: attacker's IP (198.51.100.47), the pretext they used (urgent invoice), the targeted recipient ([email protected]), and broad attack infrastructure. Useful for incident response but not transformative.
In all four cases, aggregate reports plus your own mail server logs usually provide sufficient evidence. Forensic reports are supplementary intelligence.
Q: Should I publish ruf= at all?
A: Optional. It costs nothing to publish but rarely produces reports in 2026. Most UK businesses publish ruf= for completeness but rely on aggregate reports and honeypot addresses for per-message intelligence.
Q: What is the relationship between fo= and forensic reports?
A: fo= controls when forensic reports are generated. ruf= controls where they are sent. Publishing fo= without ruf= is pointless — the reports have nowhere to go.
Q: Are forensic reports useful for spam-filter tuning?
A: Occasionally. A forensic report revealing an active phishing campaign can inform signatures for your gateway. At typical UK business volumes, the operational value is modest.
Q: Do forensic reports show the recipient's mailbox address?
A: Yes, to the extent that the To/Cc headers are included. This is part of why they are privacy-sensitive.
Q: How do I authenticate that a forensic report is genuine?
A: Check the sending server and the Authentication-Results on the report email itself. Forensic reports are sometimes spoofed as part of secondary attacks on the RUF address.
Q: Is there a DMARCbis plan to change forensic reporting?
A: DMARCbis clarifies some language but does not fundamentally change RUF behaviour. The practical trajectory is clear: fewer and fewer receivers send forensic reports over time.
Q: Can I use forensic reports to prosecute attackers?
A: They are potential evidence for fraud investigation but rarely dispositive on their own. Combine with your own server logs, aggregate reports, and any law-enforcement-obtained records from the sending infrastructure provider.
Q: What happens if my RUF address is full or rejects mail?
A: The report bounces back to the receiver. Receivers do not retry. The gap is silent — monitor your mailbox health.
Q: Can I specify different ruf= addresses for different subdomains?
A: Yes, by publishing separate DMARC records for each subdomain with their own ruf=. Useful when different teams handle forensic data for different sender domains.
Q: Is there any scenario where a UK business should not publish ruf=?
A: Only where legal or compliance concerns explicitly prohibit receiving email content from third parties (rare, typically only for specific intelligence or defence contexts). Otherwise, publishing is optional and low-risk.
Q: How large are individual forensic reports?
A: Typically a few kilobytes — full headers plus optional body excerpt. Bandwidth impact is negligible even for organisations receiving dozens per day.
Q: Can forensic reports reveal outbound server details of the attacker?
A: Usually the source IP is the most useful forensic datum. Received headers (if included) may show the attacker's relay path. Message IDs sometimes reveal attacker tooling — certain ransomware groups have distinctive Message-ID patterns.
Q: Do any open-source mail servers send forensic reports as a receiver?
A: Yes — OpenDMARC configured with forensic reporting enabled will send them. Rare in production UK deployments but available for organisations running their own full mail stack.
Q: Is receiving a forensic report evidence of an attack?
A: It is evidence that some receiver saw a message that failed DMARC. Whether that was an attacker or just a misconfigured legitimate sender is not always immediately clear — examine the source IP, subject line, and pattern.
Q: Should I forward forensic reports to law enforcement?
A: If they are part of an active fraud case reported to Action Fraud or the UK's National Crime Agency, yes. In that case preserve them as evidence. For isolated low-volume spoofing, the reports alone are rarely actionable.
Q: Do forensic reports ever include the message body?
A: Sometimes. RFC allows for a summary to be included. Some receivers include a full sample of the body, others redact to just headers. Do not rely on body content being present.
Q: Can I substitute a third-party DMARC service's forensic handling for my own?
A: Yes — most DMARC services accept forensic report forwarding and process them in their dashboards. This also solves the GDPR question: the service's DPA covers their processing of the contained personal data.
Q: If I move my ruf= from [email protected] to a processing service's address, do I need to coordinate?
A: Yes — the service must authorise your domain to send reports to their ingest, and publish the cross-domain authorisation TXT record. Follow the service's onboarding steps.
Q: Is there a way to make forensic reports more privacy-safe by default?
A: Not really in the spec itself. Privacy practices are at the receiver's discretion. Some receivers redact recipient addresses; most do not. Handle receipt of forensic data appropriately regardless.
Q: How should I retain forensic reports?
A: Typically 30-90 days for operational value, unless specifically needed for a longer-running investigation. Most UK retention policies treat them the same as other security telemetry.
Q: What is the practical difference between forensic reports and SIEM logging of failed authentications?
A: Forensic reports come from the receiver; SIEM logging comes from your own mail infrastructure. Receivers see attacks you never see (because the mail never arrives at you), so forensic reports occasionally provide intelligence your SIEM cannot. But the volumes are small.
Q: If I disable ruf= entirely, am I missing important data?
A: In 2026, almost never. Aggregate reports and your own inbound logs cover the same ground. Many security-conscious UK organisations omit ruf= deliberately to reduce their data-handling burden.
Q: Are there any cases where publishing ruf= is actively harmful?
A: A misconfigured inbox that bounces forensic reports back as NDRs creates a small DoS amplification — not harmful to you specifically but not ideal. Ensure the ruf= address exists and accepts mail.
Q: Does Mail Hardener process forensic reports?
A: Yes, alongside aggregate. Mail Hardener is one of the UK-accessible services that ingests both types.
Q: Are there UK-specific regulatory expectations around forensic reports?
A: No specific mandate. NCSC guidance does not require ruf=; ICO guidance does not specifically address it. Organisations that publish forensic reporting do so as a matter of security best practice, not regulatory requirement.
Q: Is there a way to request more detailed information than forensic reports provide?
A: Some DMARC processing services offer complementary "message sampling" features where a small percentage of inbound messages to honeypot addresses are captured with full content for deep inspection. This is separate from forensic reports but serves a similar intelligence purpose.
Q: Will DMARCbis or a successor bring forensic reports back?
A: No signal of that. The trajectory is stable or declining. Aggregate reporting is where the specification is investing its future development effort.
Q: How do forensic reports interact with ARC-authenticated forwarded messages?
A: If ARC has preserved authentication and DMARC passes via the chain, no forensic report is generated. If DMARC fails despite ARC (for example, ARC was not signed by a trusted forwarder), a forensic report may be produced as normal. The ARC chain itself is not typically exposed in forensic reports.
Q: Can I set up my DMARC to use aggregate reports only?
A: Yes — simply omit ruf= from the DMARC record. Aggregate reports (rua=) still arrive and provide most of the operational value. This is the most common configuration in UK business deployments.