Introduction
RFC 9991 is the DMARCbis document that defines failure reporting — the message-specific reports a receiver may send when an individual message fails DMARC. Published in May 2026 with RFC 9989 (the core protocol) and RFC 9990 (aggregate reporting), it separates failure reporting into its own specification for the first time, replacing the relevant parts of the old RFC 7489. RFC 9991 also formally updates RFC 6591, the Authentication Failure Reporting Format that DMARC failure reports are built on — so the reporting format and the DMARC-specific use of it are now defined together rather than split across an older base specification.
For MSPs, the most useful thing this article can do is set expectations correctly. Failure reports sound like the most exciting part of DMARC — individual copies of suspicious messages — and they can be genuinely useful in an investigation. But they are inconsistent, privacy-sensitive and often simply not sent, which makes them a supplement to your operational picture rather than its foundation. Understanding that distinction is what keeps you from overpromising to a client. For the overview of all three RFCs, start with the pillar: DMARC has changed.
What failure reporting actually is
A failure report is generated for a specific message that failed authentication, and it is requested through the ruf= tag in a DMARC record. Where an aggregate report says "247 messages from this IP, with these results", a failure report is about one message. It may include message-specific detail — headers and, depending on the receiver and any redaction, some content — which is what makes it useful for understanding a particular spoofing attempt or a particular misconfiguration, and also what makes it sensitive.
This is fundamentally different from aggregate reporting, and the two should never be conflated. Aggregate reports, covered in RFC 9990 explained, are statistical, metadata-only, safe to collect at volume, and sent reliably by the major providers. Failure reports are granular, potentially content-bearing, privacy-sensitive, and sent inconsistently if at all.
Why "forensic reports" is a misleading name
For years these were commonly called "forensic reports", and DMARCbis deliberately prefers "failure reporting". The older term is worth retiring because it oversells what you get. "Forensic" implies a reliable evidentiary trail — the sort of complete, dependable record you could build an investigation on. In reality these reports are optional for receivers to send, frequently withheld for privacy reasons, often redacted when they are sent, and absent entirely from many providers. Calling them "failure reports" describes them honestly: reports about messages that failed, produced when a receiver chooses to produce them. When you are explaining this to a client or a colleague, using the accurate term helps set the accurate expectation.
Why receivers often do not send them
The reason failure reports are inconsistent is not laziness on the receivers' part — it is privacy and data protection. A failure report can carry personal data from inside a message, and forwarding that to a third-party reporting address raises real questions under privacy regimes. Many large providers therefore decline to send failure reports at all, or send heavily redacted versions. That is a reasonable and durable position, so an MSP should plan on the assumption that failure-report coverage will be partial and provider-dependent, not comprehensive.
Privacy and data-handling obligations
If you do enable ruf= for a client, you are inviting message-specific data — potentially including personal data — to flow to whatever mailbox or platform receives it. That carries responsibilities. The receiving address should be controlled and access-limited, retention should be deliberate rather than indefinite, and the arrangement should be consistent with the client's own privacy commitments. In practice, many MSPs leave failure reporting off by default and enable it only for a specific, time-boxed investigation with the client's knowledge. The point is not that failure reports are dangerous, but that they sit in a different data-handling category from aggregate reports and deserve a conscious decision rather than a default.
Do not overpromise failure-report visibility
Because failure reports look so appealing on a slide, it is tempting to promise clients that you will show them copies of every phishing message impersonating their brand. Do not make that promise. The coverage does not exist to back it up: the biggest mailboxes frequently send nothing, and what you do receive is uneven. A client who was told to expect a steady stream of caught spoof messages, and then sees a trickle, will reasonably feel misled. Set the expectation instead that failure reports are an occasional bonus signal — sometimes a useful lead during an incident — and never the core of the service.
Where failure reports do earn their place
None of this means failure reports are worthless. During an active investigation — a client is being impersonated, and you want to understand the shape of the attack — a genuine failure report can give detail that aggregate data cannot: the specific headers, the sending infrastructure, the exact pattern. When one arrives, it is a useful lead. The right mental model is a supplement you are glad to have when it appears, not a feed you can depend on. And because a failure report centers on a single message, the natural next step when you have one is to examine that message directly with an email header analyzer, reading its real SPF, DKIM and alignment results rather than relying only on what the report summarized.
A practical rule of thumb
A simple default serves most MSP fleets well: leave ruf= off across your managed domains, and treat it as a switch you flip deliberately. When a client reports an active impersonation campaign, you can enable failure reporting for that domain, gather whatever detail the sending receivers are willing to provide for the duration of the incident, and then turn it back off once the investigation closes. This keeps the privacy surface small during normal operations, avoids accumulating sensitive message data you have no plan for, and still gives you the option to reach for the extra detail when it genuinely helps.
When a report does arrive during such an incident, what it can show is concrete: the exact headers a spoofed message carried, the sending infrastructure behind it, and the precise way it tried to imitate the client's domain. That is the kind of detail that sharpens an incident write-up. Pair the whole arrangement with a clear note in the client's documentation about what failure reporting is, what it is not, and why coverage is inherently incomplete — so that the client's expectations are set on paper, not only in conversation.
Client impact: build the service on aggregate reports
The practical takeaway for a managed service is a matter of foundations. Aggregate reports (RFC 9990) are the reliable, daily, privacy-safe backbone that every operational decision should rest on — who is sending, what authenticates, whether it is safe to advance policy. Failure reports (RFC 9991) are a valuable but optional supplement: enable them deliberately when a situation warrants, handle the data responsibly, and describe them to clients as a bonus rather than a guarantee.
An MSP that builds its DMARC service on aggregate reporting, and treats failure reporting as an occasional investigative aid, will set expectations it can actually meet — which is the whole point of a managed service. The DMARC for MSPs pillar puts this in the context of the full service model, and the older primer DMARC failure reports: what they are and when to use them covers the mechanics in more depth.
Related articles
- DMARC has changed: RFC 9989, 9990 and 9991 for MSPs
- RFC 9990 explained: DMARC aggregate reporting for MSPs
- RFC 9989 explained: the new core DMARC standard for MSPs
- Why DMARC reports are not always perfect
- DMARC failure reports: what they are and when to use them
Tools mentioned
- Email header analyzer — inspect a specific message's SPF, DKIM and alignment results.
- DMARC checker — review a record's rua= and ruf= configuration.
- DKIM validator — confirm the DKIM key behind a failing or suspicious message.
Author: DMARC AI editorial team Last updated: August 2026