DMARC forensic reports (RUF) and privacy: what to know

GDPR implications

Where the decision is to receive and use RUF, these are the compliance points to consider:

Legal basis. Email headers contain personal data (email addresses, message metadata). Processing that data requires a legal basis under GDPR — typically legitimate interest (security of the information system), to be documented in the GDPR record.

Data minimization. RUF serve security diagnosis only, not other purposes. Retention stays limited to what's necessary (a few days to a few weeks is enough for a diagnosis).

Transfer to third parties. Forwarding RUF to a third-party DMARC platform makes that platform a data processor under GDPR — a DPA (Data Processing Agreement) must be in place, and the platform must meet the organisation's security requirements.

GDPR registry. Processing RUF means adding this processing to the GDPR registry (art. 30): purpose (email security), data category (headers, email addresses), retention period, legal basis.

Encryption and isolation. RUF should not end up in a shared mailbox or be accessible to people who don't need to read them. They belong in a dedicated mailbox with restricted access.

The question of real utility

Given current limitations (few ISPs that send RUF) and GDPR constraints, the question arises: are RUF worth the effort? For the vast majority of deployments, the answer is no. Aggregate reports (RUA) supply everything needed to identify and fix the sources: IPs, authentication results, volume. RUF bring detail about an individual message that is often unexploitable anyway (the ISP in question may not send them at all).

Cases where RUF still retain real utility: diagnosing a specific type of failing message, with confirmation that the ISP in question does send RUF; or a context where the messaging infrastructure is controlled end-to-end and the RUF land in the operator's own mailbox.

How to configure (or not configure) ruf=

Choosing not to use RUF — the recommendation for most cases — simply means omitting ruf= and fo= from the record. A DMARC record works perfectly with only rua=:

_dmarc.example.com.  IN TXT
  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Choosing to use RUF means adding:

ruf=mailto:ruf@example.com; fo=1

fo=1 generates an RUF as soon as any check fails — the most informative value, but also the highest volume. fo=0 (default) only generates an RUF if all checks fail — less volume, less information.

The current situation in 2025-2026

The market has largely settled the RUF question. Since Google stopped sending them in 2023, RUF coverage has collapsed: the major ISPs representing the bulk of global email traffic no longer send them. What arrives when ruf= is configured today comes primarily from smaller providers or self-hosted servers — often a minority of total traffic.

This operational reality makes RUF hard to use for the vast majority of deployments: no RUF arrives for messages that fail at Gmail (the most common recipients), which limits diagnostic value. On the other hand, for an organization sending primarily to internal servers (business-to-business mail to other corporate servers), or testing in a controlled environment, RUF can still be useful.

RUF in DMARCbis (RFC 9990)

DMARCbis — the new version of DMARC defined by RFCs 9989/9990/9991 — covers forensic reports in RFC 9990, separate from RFC 9989 which defines the protocol itself. RFC 9990 explicitly acknowledges the privacy problems with RUF and does not strengthen their use — it clarifies instead that implementations MAY choose not to emit them. That's official recognition of the current market state. A migration to DMARCbis (see migrating to the new standard) leaves the RUF strategy unchanged, or drops it entirely.

The privacy risk in practice: who is actually exposed?

A common misconception about RUF privacy risk is that it exposes the recipients' data. In reality, the exposure is almost the reverse: RUF reports cover messages that failed to authenticate from the domain. That means the people whose data appears in RUF are typically the domain's own users — employees or customers who sent email via a misconfigured route (a mobile app, an old mail client, a forwarding rule), not the recipients of those messages.

That distinction matters for the GDPR risk assessment. A domain used primarily for outbound transactional email (notifications, invoices, automated messages) may have very few people with "personal" email content failing authentication — the risk is low. A domain used by human employees for personal correspondence carries a much higher risk profile: a failed email from an employee could contain personal information that shouldn't flow through a third-party DMARC reporting tool.

Understanding who could appear in the RUF reports is the starting point for assessing whether to configure them at all — and if so, under what data governance terms.

A pragmatic approach: starting without RUF, adding only if needed

For the vast majority of organizations deploying DMARC for the first time, the right approach is to configure rua= only, without ruf=. Aggregate reports supply everything needed to identify sources, measure pass rates, and progress toward p=reject. Forensic reporting comes later — if and only if a specific diagnostic need arises that aggregate reports can't address (a particular message type failing, a source unidentifiable from IPs alone) and the GDPR implications have been assessed.

The fact that most major ISPs no longer send RUF anyway means omitting ruf= loses no diagnostic coverage — it merely keeps the record clean and the compliance burden minimal.

Frequently asked questions

Does Google still send RUF? No, Google stopped sending forensic reports. Most RUF that do arrive come from less well-known actors.

Are RUF dangerous for privacy? Potentially, depending on their content. They can reveal email addresses, message subjects, and sending routes. They deserve the same care as any other sensitive data.

Do I need to include fo= in my record? Only alongside a ruf=. Without ruf=, the fo= tag has no effect. And with no ruf= added, there's nothing to configure.

Can a third-party DMARC tool receive my RUF? Yes, with a ruf=mailto:address@third-party-tool.com. The tool must have signed a DPA (data processing agreement), and its processing terms must match the organisation's GDPR requirements.

How do I know if I'm receiving RUF? The ruf= mailbox tells: RUF arrive with a subject distinct from RUA, often as MIME text files (not XML like RUA, but message/feedback-report format).

Are RUF subject to a specific GDPR retention period? No — there's no legally mandated period for RUF as such. In practice, data minimization (GDPR principle) suggests keeping them only for the duration of the diagnosis, i.e. a few days to a few weeks. Beyond that, deletion or anonymization applies. This matters especially where they sit in a shared email mailbox.

Can I disable RUF if I've already configured them? Yes. Removing ruf= and fo= from the DMARC record is enough — ISPs that regularly read the record will stop sending RUF. DNS propagation applies, but new ones stop arriving within 24-48h.

Do RUF give access to recipient or sender messages? Only sender messages (messages that failed to pass DMARC from the domain or claiming to come from it). An RUF never contains the content of an incoming message addressed to one of the domain's users — it covers messages that used the domain's From: in a non-compliant way, legitimately or not. That's an important distinction for evaluating the real privacy risk: the risk is on senders from the domain itself (its own users sending via misconfigured routes), not on external recipients.

Thomas handles the reports

Whether the mailbox holds RUA, RUF or both, Thomas, the virtual CISO, handles reading, diagnosis and action planning. No XML file to open, no emails to sort, no statistics to calculate — Thomas names what matters and what to do.

Analyze a domain for free or create an account for complete DMARC management without friction.