# DMARC Failure Reports (RFC 9991)

> Per-message DMARC failure ("forensic") reports — ARF format, required fields, the ruf/fo tags, privacy constraints, and why few providers send them.

Source: emailmarketing.net — https://emailmarketing.net/learn/authentication/dmarc-failure-reports

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](https://emailmarketing.net/learn/authentication/dmarc-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](https://emailmarketing.net/learn/authentication/dmarc-standard) and [RFC 9990](https://emailmarketing.net/learn/authentication/dmarc-aggregate-reports). 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](https://emailmarketing.net/learn/authentication/dmarc-standard)):

| Tag | Role |
|---|---|
| `ruf=` | A comma-separated list of `mailto:` URIs that receive failure reports. The receiver must attempt delivery to every destination listed. External destinations must be verified in the same way as for aggregate reports (`<policy-domain>._report._dmarc.<destination-host>`). |
| `fo=` | When to report. `0` (the default) means only when **no** mechanism produced an aligned pass. `1` means when **any** mechanism failed. `d` means on any DKIM failure, whatever the alignment. `s` means on any SPF failure, whatever the alignment. Values can be combined, separated by colons (for example, `fo=1:d:s`). |

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:

| Field | Required? | Contents |
|---|---|---|
| `Identity-Alignment` | Required | A comma-separated list of the mechanisms that failed alignment: `dkim`, `spf`, or `none`. |
| `DKIM-Domain`, `DKIM-Identity`, `DKIM-Selector` | Required for DKIM failures | Which signature failed (`d=`, `i=`, `s=`). |
| `SPF-DNS` | Required for SPF failures | The SPF DNS record involved. |
| `Delivery-Result` | Optional | What the receiver did with the message. |
| `DKIM-Canonicalized-Header`, `DKIM-Canonicalized-Body` | Optional | The canonicalized forms, for debugging broken signatures. |

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](https://emailmarketing.net/learn/authentication/dmarc)
- [DMARC standard reference](https://emailmarketing.net/learn/authentication/dmarc-standard)
- [DMARC aggregate reports](https://emailmarketing.net/learn/authentication/dmarc-aggregate-reports)
- [DKIM](https://emailmarketing.net/learn/authentication/dkim), for interpreting the DKIM-* diagnostic fields