RFC 9991 Proposed Standard Authentication

Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a mechanism by which a Domain Owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports", or "failed message reports", which provide details about individual messages that failed to authenticate according to the DMARC mechanism. This document updates RFC 6591 and obsoletes RFC 7489.

Status
Proposed Standard. On the standards track and stable enough to implement against. Most of the email stack stays at this level permanently.
Published
May 2026
Authors
S. Jones, A. Vesely
Read it
rfc-editor.org · DOI

Replaces RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC).

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 9 must, 1 should, 4 may.

2 DMARC Failure Reports

  • MUSTWhen multiple Uniform Resource Identifiers (URIs) are provided to receive failure reports, the report generator MUST make an attempt to deliver to each of them.
  • MUSTExternal destinations MUST be verified (see Section 5).
  • MUST NOTReport generators MUST NOT consider "ruf" tags in DMARC Policy Records that have a "psd=y" tag, unless there are specific agreements between the interested parties.
  • MUSTReport generators MUST implement a rate-limit on outgoing reports so as not to flood Report Consumers with excessive reports, which would allow denial of service (see Section 8.1).

3 Other Failure Reports

  • MAYA Mail Receiver that generates DMARC failure reports MAY choose to issue failure reports of the type specific to the authentication mechanism that failed instead of, or in addition to, the DMARC failure report type described here.
  • SHALLThe Receiver SHALL determine which failure report types, if any, to transmit based on its own policy, the failure in question, and the content of the "fo" tag in the retrieved DMARC Policy Record.

4 Reporting Format Update

  • REQUIRED* Identity-Alignment (REQUIRED; defined below)
  • OPTIONAL* Delivery-Result (OPTIONAL)
  • REQUIRED* DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED for DKIM failures of an aligned identifier)
  • OPTIONAL* DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL if reporting a DKIM failure)
  • REQUIRED* SPF-DNS (REQUIRED for SPF failure of an aligned identifier)
  • MAYNote that a failure report generator MAY also independently produce an ARF message for any or all of the underlying authentication methods.

5 Verifying External Destinations

  • MUSTIn case of external destinations, a Mail Receiver who generates failure reports MUST use the Verifying External Destinations procedure described in Section 4 of [RFC9990], substituting the "ruf" tag where the "rua" tag appears in that procedure.

5.1 Transport

  • SHOULDEmail streams carrying DMARC failure reports SHOULD be DMARC-aligned.

Every current email RFC