| RFC 9991 | DMARC Failure Reporting | May 2026 |
| Jones & Vesely | Standards Track | [Page] |
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.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9991.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC9989] is a mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting that can be used by a mail-receiving organization to improve mail handling. This document focuses on one type of reporting that can be requested under DMARC.¶
Failure reports provide detailed information about the failure of a single message or a group of similar messages failing for the same reason. Their purpose is twofold. On the one hand, they are meant to aid in cases where a Domain Owner wishes to determine the cause of failures that were part of aggregate reports (see [RFC9990]). On the other hand, they can allow the Domain Owner to quickly identify and address harmful messages involving direct domain abuse. It is important to note that these reports can contain the header fields or sometimes the entire content of a failed message, which may contain personally identifiable information (PII). The potential disclosure of PII should be considered when deciding whether to request failure reports as a Domain Owner, or what information to include or redact in failure reports when creating them as a Mail Receiver, or whether to create failure reports at all. Refer to Section 7 for more discussion on privacy considerations.¶
There are a number of terms defined in Section 3.2 of [RFC9989] that are used within this document. Understanding those definitions will aid in reading this document.¶
The format of DMARC failure reports is derived from "Authentication Failure Reporting Using the Abuse Reporting Format" [RFC6591], and the terms defined there are used here.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Besides the header fields or the entire contents of a failed message, failure reports supply details about transmission and DMARC authentication, which may aid a Domain Owner in determining the cause of an authentication failure.¶
Failure reports are normally generated and sent almost immediately after the Mail Receiver detects a DMARC failure. Rather than waiting for an aggregate report, these reports are useful for quickly notifying the Domain Owners when there is an authentication failure. Failure reports also provide more information about the failed message than is available in an aggregate report. This allows the failure report consumer to better determine whether the failure is of a message that the Domain Owner intended to authenticate or one for which use of its domain was not authorized.¶
These reports should include as much of the message header fields and body as possible, consistent with the reporting party's privacy policies, to enable the Domain Owner to diagnose the authentication failure.¶
When a Domain Owner requests failure reports for the purpose of forensic analysis, and the Mail Receiver is willing to provide such reports, the Mail Receiver generates and sends a message using the format described in [RFC6591]; this document updates that reporting format, as described in Section 4.¶
The destination(s) to which failure reports are sent, and options for when they will be sent, are defined by the "ruf" and "fo" tags as provided in Section 4.7 of [RFC9989].¶
When multiple URIs are provided to receive failure reports, the report generator MUST make an attempt to deliver to each of them. External destinations MUST be verified (see Section 5). Report 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.¶
Report 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).¶
This document only describes DMARC failure reports. DomainKeys Identified Mail (DKIM) failure reports and Sender Policy Framework (SPF) failure reports are described in [RFC6591]. A Mail Receiver generating DMARC failure reports MAY issue failure reports specific to the failed authentication mechanism instead of, or in addition to, DMARC failure reports, based on its own policy, the failure in question, and the content of the "fo" tag in the retrieved DMARC Policy Record.¶
Note that DKIM failure reports and SPF failure reports can also be requested using the methods described in [RFC6651] and [RFC6652], respectively. Report generators are free to follow any of the specifications.¶
Operators implementing this specification also implement an augmented version of failure reporting described in [RFC6591] as follows:¶
A DMARC failure report includes the following Abuse Reporting Format (ARF) header fields, with the indicated normative requirement levels:¶
Identity-Alignment (REQUIRED; defined below)¶
Delivery-Result (OPTIONAL)¶
DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED for DKIM failures of an aligned identifier)¶
DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL if reporting a DKIM failure)¶
SPF-DNS (REQUIRED for SPF failure of an aligned identifier)¶
The Identity-Alignment field is defined to contain a comma- separated list of authentication mechanism names that failed to authenticate an aligned identity or the keyword "none" if all of the attempted methods were successful at authenticating an aligned identity. Here is the ABNF [RFC5234] (importing comments and/or folding white space (CFWS) from [RFC5322]):¶
id-align = "Identity-Alignment:" [CFWS]
( "none" /
dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) )
[CFWS]
dmarc-method = ( "dkim" / "spf" )
; each may appear at most once in an id-align¶
It is possible to specify destinations for failure reports that are outside of the Organizational Domain of the DMARC Policy Record that was requesting the reports. These destinations are commonly referred to as "external destinations" and may represent a different domain controlled by the same organization, a contracted report processing service, or some other arrangement.¶
In 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.¶
This prevents a bad actor from publishing a DMARC Policy Record requesting failure reports to an external destination and then deliberately sending messages that will generate failure reports as a form of abuse. It also prevents a Domain Owner from unilaterally publishing a DMARC Policy Record with an external destination for failure reports, forcing the external destination to deal with unwanted messages and potential privacy issues.¶
Email streams carrying DMARC failure reports SHOULD be DMARC-aligned.¶
We recommend that reporters set a reasonable rate-limit for the number of failure reports sent to any recipient to avoid overloading recipient systems. Unaligned reports may in turn produce subsequent failure reports that could cause mail loops.¶
IANA has updated the reference and description for the "Identity-Alignment" entry in the "Feedback Report Header Fields" registry within the "Messaging Abuse Reporting Format (MARF) Parameters" registry group, as follows:¶
The generation and transmission of DMARC failure reports raise significant privacy concerns that must be carefully considered before deployment.¶
Given these factors, many large-scale providers limit or entirely disable the generation of failure reports, preferring to rely on aggregate reports, which provide statistical visibility without exposing sensitive content. Operators that choose to enable failure reporting are strongly encouraged to:¶
In summary, while DMARC failure reports can offer diagnostic value, the associated privacy concerns have led many operators to restrict their use. Aggregate reports remain the recommended mechanism for gaining visibility into authentication results while preserving the confidentiality of end-user communications.¶
Particular privacy-specific issues are explored below.¶
Failure reports may include PII and non-public information (NPI) from messages that fail to authenticate, since these reports may contain message content as well as trace header fields. These reports may expose sender and recipient identifiers (e.g., RFC5322.From addresses), and although the [RFC5965] format used for failed-message reporting supports redaction [RFC6590], failed-message reporting is capable of exposing the entire message to the Report Consumer. They may also expose PII, sensitive business data, or other confidential communications to unintended recipients. Such exposure can create regulatory, legal, and operational risks for both senders and receivers. Examples include product launches, termination notices for employees, or calendar data. Even innocuous-seeming failures (such as malformed or "broken" calendar invitations) can result in the leakage of private communications.¶
Domain Owners requesting reports will receive information about mail using their domain, but which they did not actually cause to be sent. This might provide valuable insight into content used in abusive messages, but it might also expose PII or NPI from legitimate messages mistakenly or accidentally failing authentication.¶
Information about the final destination of mail, where it might otherwise be obscured by intermediate systems, may be exposed through a failure report. A commonly cited example is exposure of members of mailing lists when one list member sends messages to the list, and failure reports are generated when that message is delivered to other list members. Those failure reports would be sent to the Domain Owner of the list member posting the message or their delegated Report Consumer(s).¶
Similarly, when message forwarding arrangements exist, Domain Owners requesting reports may receive information about mail forwarded to domains that were not originally part of their messages' recipient list. This means that destinations previously unknown to the Domain Owner may now become visible.¶
A DMARC Policy Record can specify that reports should be sent to a Report Consumer operating on behalf of the Domain Owner. This might be done when the Domain Owner sends reports to an entity to monitor mail streams for deliverability, performance issues, or abuse. Receipt of such data by third parties may or may not be permitted by the Mail Receiver's privacy policy, terms of use, etc. Domain Owners and Mail Receivers should both review and understand whether their own internal policies constrain the use and transmission of DMARC reporting.¶
Some potential exists for Report Consumers to perform traffic analysis, making it possible to obtain metadata about the Mail Receiver's traffic. In addition to verifying compliance with policies, Mail Receivers need to consider that before sending reports to a third party. On the other hand, a Domain Owner may publish a destination address that appears to be an Internal Report Consumer but is actually a forwarding address; in this case, the final destination of a report is not guaranteed.¶
The risks associated with failure reports are compounded by volume and content distribution concerns. Partially or unredacted reports may propagate large amounts of spam, phishing, or malware content, all of which may require special handling by Report Consumers or other recipients to avoid incidents. This underscores the need to avoid misconfiguration of the destinations in the "ruf" reporting URIs and the suggestions for redaction in this document, for example, using the method described in [RFC6590]. All of these concerns are heightened for high-volume domains. To mitigate such concerns, the following steps should be considered:¶
By report generators:¶
By report consumers:¶
While reviewing this document and its security considerations, the reader should also review the privacy considerations above, as well as the privacy considerations and security considerations in Sections 10 and 11 of [RFC9989] and in Sections 7 and 8 of [RFC9990].¶
Failure reports represent a possible denial-of-service attack that could be perpetrated by an attacker who sends numerous messages purporting to be from the intended victim Domain Owner but which fail both SPF and DKIM; this would cause participating Mail Receivers to send failure reports to the Domain Owner or its delegate(s), potentially in large numbers. Accordingly, participating Mail Receivers are encouraged to aggregate these reports as much as is practical, using the Incidents field of the ARF [RFC5965]. Indeed, the aim is not to count each and every failure but rather to report different failure conditions. Various pruning techniques are possible, including the following:¶
This is the full content of a sample failure message, including the message header.¶
The Source-Port field definition is given by [RFC6692].¶
In the final MIME entity, the local-parts of To and From addresses are reported unredacted. Since we know that the local parts are PII, we can reduce the privacy risk by redacting them. In the example, the report generator could have replaced "users" with "lRLxexey" and "author" with "RT47aVey" throughout the entity.¶
If the body of the message is not included, the last MIME entity would have "Content-Type: text/rfc822-headers" instead of "message/rfc822".¶