DMARC Failure Reports (RFC 9991)

When your aggregate DMARC reports show a source failing, a failure report can show you a single failing message, so you can see why it failed. When your domain's DMARC record lists an address for failure reports, receivers can send that address a report each time a specific message fails DMARC. These failure reports are often called "forensic reports", and they differ from the daily statistical aggregate reports.

RFC 9991 defines them. It is a Standards Track specification published in May 2026, and one of the DMARCbis documents, with RFC 9989 and RFC 9990. It updates RFC 6591 and replaces the part of RFC 7489 that covered failure reporting.

Failure reports serve two purposes: diagnosing individual authentication failures first seen in aggregate data, and revealing quickly when someone is actively abusing your domain directly.

Triggering: the ruf and fo tags

These tags are set in the domain's DMARC record (see the tag registry):

Reports are "normally generated and sent almost immediately after the Mail Receiver detects a DMARC failure". They arrive almost in real time, unlike the daily aggregate reports.

Report format

Failure reports use the Abuse Reporting Format (ARF) of RFC 6591 (message/feedback-report, with the feedback type auth-failure), with fields added for DMARC:

The report usually includes the headers of the failed message, and possibly its body. That is what makes this format both useful and sensitive for privacy.

Privacy considerations

Failure reports can expose personal data: sender and recipient addresses, message content and, for mailing list traffic, who belongs to the list. RFC 9991 tells report generators to:

• limit reports to targeted diagnosis rather than sending everything;
• validate reporting URIs carefully (verification of external destinations);
• redact message content and identifiers;
• use secure transmission channels.

In practice, most large mailbox providers do not send failure reports at all, or send heavily redacted ones, precisely because of these privacy risks. Publishing ruf= costs nothing, but expect few reports. Aggregate reports are the reliable signal, and failure reports add detail when you get them.

Security considerations

Failure reporting can be used for a denial-of-service attack that floods a mailbox with reports. An attacker who sends large volumes of mail spoofed "from" a victim's domain can make receivers bombard the victim's ruf mailbox. Generators are required to reduce this risk by grouping related events (the ARF Incidents field) and by rate limiting (a maximum number of reports per unit of time).

Operational use

• Use failure reports to find out why a source that fails in aggregate data is failing: a wrong selector, a signature broken by a gateway that adds a footer (compare the canonicalized fields), a bounce domain that is not aligned, and so on.
• Send ruf= reports to a mailbox with restricted access, because the reports may contain the content of other people's messages.
• Do not build monitoring on failure reports alone. Coverage depends on the receiver, and the reports come mostly from smaller providers.

Related articles

• DMARC
• DMARC standard reference
• DMARC aggregate reports
• DKIM, for interpreting the DKIM-* diagnostic fields