Are DMARC Forensic Reports (ruf) Worth Enabling?

Short answer: for most domains, DMARC forensic reports are not worth enabling. Start with aggregate (rua) reports and leave the ruf tag off. Whether DMARC forensic reports are worth enabling turns on two facts most setup guides skip — the largest mailbox providers do not send them, and the ones that do can hand you copies of message content you may not be allowed to keep.

A forensic report — the standard calls it a failure report — is a near-real-time copy of a single message that failed DMARC, delivered to the address in your ruf tag. In a narrow debugging window that can help. But Gmail and Microsoft 365 do not generate them, so on a typical domain a ruf address collects little beyond the occasional report from a smaller receiver, plus a standing privacy liability.

The ruf mechanism has been part of DMARC since the original specification (RFC 7489, 2015). It was designed for a narrow diagnostic window: a team actively chasing an alignment failure who needs the exact headers of the failing message, not just counts in a daily XML file. That original use case still exists — but it has always depended on receiver support that the largest providers have never provided, which is the central problem with treating ruf as a routine reporting channel.

This guide covers what a failure report contains, why the major receivers withhold them, how to add a ruf tag if you have a specific reason to, and what to check when the reports never arrive. The recommendation sits at the top and does not change: rua first, ruf only for a reason.

Before you decide: rua vs ruf#

DMARC has two reporting channels, set by two separate tags, and they do very different jobs. Mixing them up is the root of most bad ruf decisions.

The rua tag collects aggregate reports — a daily XML summary of counts and pass/fail results, grouped by sending IP, with no message content. The ruf tag collects failure reports — an individual copy of a failing message, sent within moments of the failure, that can include the message's headers and, depending on the receiver, its subject, recipients and body.

That difference is the whole decision. One channel tells you which sources fail and how often; the other hands you the failing messages themselves. The first is safe to run indefinitely. The second is not.

How to add a ruf tag, if you have a reason to#

If you have a specific, time-boxed reason — you are chasing a stubborn alignment failure and the aggregate reports aren't enough to pin it down — here is how to add ruf without making a mess. Treat it as temporary from the start.

1. 1

   Create a dedicated mailbox

   Point ruf at a shared mailbox or group made only for reports, never a person's inbox. Use a separate address from your rua mailbox so failure reports don't drown the aggregate stream you actually read.

2. 2

   Add the ruf tag alongside your existing rua

   Append the ruf value to your current record and keep rua in place. For example: v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]. Keep p=none while you diagnose so you don't reject mail you are still investigating.

3. 3

   Plan for the content, don't rely on redaction

   The failure-reporting options (fo) tag governs what triggers a report and how much of it arrives. fo=0 (the default when the tag is absent) sends a report only when every checked authentication mechanism fails — the strictest filter and the fewest reports. fo=1 sends a report when any single mechanism fails, which is more verbose but catches more of the alignment edge cases that fo=0 would suppress. fo=d and fo=s narrow reports to DKIM-only or SPF-only failures respectively. For a focused debugging session, fo=1 is usually the most useful value: it surfaces the alignment failures that the default would miss because one mechanism happened to pass. Whatever you set, assume every report may contain live message data. Some receivers strip content, but you cannot count on it, so treat the mailbox as sensitive from day one.

4. 4

   Set a removal date

   Put a calendar reminder to strip the ruf tag once you have found the problem. A ruf tag left on indefinitely collects almost nothing from the major providers and everything from a spoofing run — the wrong side of both trades.

Which providers actually send failure reports?#

This is the fact that settles the question for most domains. The receivers that hold the bulk of the world's mailboxes do not send failure reports, and they say so in their own documentation.

The deeper question is why — and the answer is not technical. The ARF format works perfectly well, and the infrastructure cost of generating a per-message report is not the blocker. The reason most large receivers stopped sending failure reports, or never started, is the legal and privacy arithmetic. Under the GDPR and equivalent regimes that came into force around 2018, forwarding the content of a real message to a third-party address — even the sending domain's own reporting mailbox — requires a legal basis the receiver cannot establish on the sender's behalf. If the failing message is legitimate mail that broke on a misconfiguration, the receiver is effectively routing personal data from its own users to an endpoint controlled by the sending domain, without any specific consent from those users. That is a liability major providers declined to carry. The result is that failure reporting became quietly vestigial even in standards that still include it.

Microsoft is explicit: Microsoft 365 does not send DMARC forensic reports, also known as failure reports, even when a valid ruf address exists in the sending domain's record. Google's DMARC documentation describes only aggregate (rua) reports and offers no failure reporting. So on a domain whose mail lands mostly at Gmail and Outlook, a ruf address hears from neither of the two biggest sources. The providers that do occasionally send failure reports tend to be smaller, regional mail operators or self-hosted mail servers where an administrator kept the feature on from an earlier era. Even then, what arrives is often stripped: headers only, no body, sometimes not even a complete header set. It is technically an ARF failure report, but it rarely tells you more than a careful reading of your aggregate data already would.

The table below is current as of August 2026. Providers change reporting policy, so confirm on each receiver's own postmaster or admin documentation before you rely on any single row.

Why am I not receiving DMARC forensic reports?#

If you added a ruf tag and nothing arrives, the usual cause is not a broken record — it's that the receivers you send to don't send failure reports. Before you assume a DNS problem, rule out the ordinary explanations.

• Your mail lands mostly at Gmail and Microsoft 365. Neither sends failure reports, so the two biggest sources are silent by design. This is the most common reason, and there is nothing to fix.
• Your rua works but your ruf does not. That is expected: aggregate support is near-universal, failure support is rare. Seeing daily aggregate reports but no failure reports is normal, not a misconfiguration.
• Your report address is in a different domain and isn't authorized. If your ruf mailbox is at a domain other than the one being monitored — for example, your sending domain is company.com but your ruf address is [email protected] — then example.net must publish a TXT record at _report._dmarc.company.com within the example.net zone, containing v=DMARC1. Without it, compliant receivers silently drop the forensic report rather than deliver it, and no error is surfaced anywhere. The same mechanism applies to rua aggregate reports: if your aggregate reports are arriving from the same cross-domain mailbox, the authorization record is in place and the absence of forensic reports is purely a receiver-support issue, not an authorization gap.
• A syntax error in the tag. A malformed ruf value is silently ignored. Recheck the full record with a DMARC lookup and confirm there is only one _dmarc TXT record.
• The receiver redacts or rate-limits. Some receivers that technically support failure reports send them sparingly or strip content down to near-uselessness — so even a working setup can look empty.

A faster way to handle the reports that do arrive#

Whether or not you enable ruf, the reports you do get — aggregate XML every day, plus the rare failure report — land as attachments in a mailbox, and left alone they bury the mail you actually read. The manual fix is a dedicated mailbox and a set of filters. That works, and the steps above still stand.

Doing it continuously is where a mail client helps. AI Emaily is an AI email client, not a DMARC monitor — it does not parse these reports into dashboards, and if you want per-source trend charts you should use a dedicated DMARC reporting service. What it does own is the inbox the reports arrive in: its rules and Context Brain can file every DMARC report out of your main view, keep failure reports — which may carry live message data — in a locked-down folder, and run the same phishing defense across them as the rest of your mail. We build AI Emaily; you can see what it does in one page at aiemaily.com.