DMARC Failure Reports (RFC 9991)

RFC 9991 (Standards Track, May 2026; part of the DMARCbis set with RFC 9989 and RFC 9990; updates RFC 6591 and replaces the failure-reporting portion of RFC 7489) defines failure reports (often called "forensic reports"): per-message reports sent when a specific message fails DMARC, as opposed to the daily statistical aggregate reports.

They serve two purposes: diagnosing individual authentication failures first spotted in aggregate data, and rapidly surfacing active direct-domain abuse.

Triggering: the ruf and fo tags

Configured in the domain's DMARC record (see the tag registry):

Tag	Role
ruf=	Comma-separated mailto: URIs to receive failure reports. All listed destinations must receive delivery attempts. External destinations must be verified exactly as for aggregate reports (<policy-domain>._report._dmarc.<destination-host>).
fo=	When to report: 0 (default) = only when no mechanism produced an aligned pass; 1 = when any mechanism failed; d = on any DKIM failure regardless of alignment; s = on any SPF failure regardless of alignment. Values may be combined colon-separated (e.g. fo=1:d:s).

Reports are "normally generated and sent almost immediately after the Mail Receiver detects a DMARC failure" — near-real-time, unlike daily aggregates.

Report format

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

Field	Req?	Contents
Identity-Alignment	Required	Comma-separated list of 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 signature breakage.

The report typically embeds the failed message's headers (and possibly body), which is what makes this format both useful and privacy-sensitive.

Privacy considerations

Failure reports can expose PII: sender and recipient addresses, message content, and — for mailing-list traffic — list membership. RFC 9991 directs report generators to:

• limit scope to targeted diagnostics rather than blanket streaming;
• validate reporting URIs carefully (external-destination verification);
• apply redaction to 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 exposures. Publishing ruf= costs nothing, but expect sparse coverage — aggregate reports are the reliable signal; failure reports are opportunistic extra detail.

Security considerations

Failure reporting creates a report-flood DoS vector: an attacker spraying spoofed mail "from" a victim domain can cause receivers to bombard the victim's ruf mailbox. Mitigations required of generators: aggregating related events (the ARF Incidents field) and rate-limiting (a maximum number of reports per time unit).

Operational use

• Use failure reports to answer why a source seen failing in aggregate data fails: a wrong selector, a signature broken by a footer-adding gateway (compare the canonicalized fields), an unaligned bounce domain, etc.
• Route ruf= to a locked-down mailbox — the reports may contain third-party message content.
• Don't build monitoring on failure reports alone; coverage is receiver-dependent and biased toward smaller providers.

Related

• DMARC · DMARC standard reference · DMARC aggregate reports
• DKIM — interpreting the DKIM-* diagnostic fields