rfc9991.original   rfc9991.txt 
DMARC S. Jones (ed) Internet Engineering Task Force (IETF) S. Jones, Ed.
Internet-Draft DMARC.org Request for Comments: 9991 DMARC.org
Obsoletes: 7489 (if approved) A. Vesely (ed) Obsoletes: 7489 A. Vesely, Ed.
Updates: 6591 (if approved) Tana Updates: 6591 Tana
Intended status: Standards Track 18 April 2026 Category: Standards Track May 2026
Expires: 20 October 2026 ISSN: 2070-1721
Domain-based Message Authentication, Reporting, and Conformance (DMARC) Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
Failure Reporting Failure Reporting
draft-ietf-dmarc-failure-reporting-25
Abstract Abstract
Domain-based Message Authentication, Reporting, and Conformance Domain-based Message Authentication, Reporting, and Conformance
(DMARC) is a mechanism by which a Domain Owner can request feedback (DMARC) is a mechanism by which a Domain Owner can request feedback
about email messages using their domain in the From: address field. about email messages using their domain in the From: address field.
This document describes "failure reports", or "failed message This document describes "failure reports", or "failed message
reports", which provide details about individual messages that failed reports", which provide details about individual messages that failed
to authenticate according to the DMARC mechanism. to authenticate according to the DMARC mechanism.
This document updates RFC 6591 and obsoletes RFC 7489. This document updates RFC 6591 and obsoletes RFC 7489.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 20 October 2026. 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 Notice Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Please review these documents carefully, as they describe your rights carefully, as they describe your rights and restrictions with respect
and restrictions with respect to this document. Code Components to this document. Code Components extracted from this document must
extracted from this document must include Revised BSD License text as include Revised BSD License text as described in Section 4.e of the
described in Section 4.e of the Trust Legal Provisions and are Trust Legal Provisions and are provided without warranty as described
provided without warranty as described in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
1.2. Document Status . . . . . . . . . . . . . . . . . . . . . 4 1.2. Document Status
2. DMARC Failure Reports . . . . . . . . . . . . . . . . . . . . 4 2. DMARC Failure Reports
3. Other Failure Reports . . . . . . . . . . . . . . . . . . . . 5 3. Other Failure Reports
4. Reporting Format Update . . . . . . . . . . . . . . . . . . . 5 4. Reporting Format Update
5. Verifying External Destinations . . . . . . . . . . . . . . . 6 5. Verifying External Destinations
5.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Transport
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations
6.1. Feedback Report Header Fields Registry Update . . . . . . 7 6.1. Feedback Report Header Fields Registry Update
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 7. Privacy Considerations
7.1. Data Exposure Considerations . . . . . . . . . . . . . . 8 7.1. Data Exposure Considerations
7.2. Report Recipients . . . . . . . . . . . . . . . . . . . . 8 7.2. Report Recipients
7.3. Additional Damage . . . . . . . . . . . . . . . . . . . . 9 7.3. Additional Damage
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations
8.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 10 8.1. Denial of Service
9. Normative References . . . . . . . . . . . . . . . . . . . . 10 9. References
10. Informative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References
Appendix A. Example Failure Report . . . . . . . . . . . . . . . 11 9.2. Informative References
Appendix B. Change Log {change-log} . . . . . . . . . . . . . . 15 Appendix A. Example Failure Report
B.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses
B.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 16
B.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 16
B.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 16
B.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 16
B.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 16
B.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 17
B.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 17
B.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 17
B.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 17
B.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 17
B.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 17
B.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 17
B.14. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 17
B.15. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 18
B.16. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 18
B.17. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 18
B.18. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 18
B.19. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 18
B.20. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 18
B.21. 20 to 21 . . . . . . . . . . . . . . . . . . . . . . . . 18
B.22. 21 to 22 . . . . . . . . . . . . . . . . . . . . . . . . 19
B.23. 22 to 23 . . . . . . . . . . . . . . . . . . . . . . . . 19
B.24. 23 to 24 . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
The source for this draft is maintained in GitHub at:
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting
(https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting)
Domain-based Message Authentication, Reporting, and Conformance Domain-based Message Authentication, Reporting, and Conformance
(DMARC) [I-D.ietf-dmarc-dmarcbis] is a mechanism by which a mail- (DMARC) [RFC9989] is a mechanism by which a mail-originating
originating organization can express domain-level policies and organization can express domain-level policies and preferences for
preferences for message validation, disposition, and reporting, that message validation, disposition, and reporting that can be used by a
can be used by a mail-receiving organization to improve mail mail-receiving organization to improve mail handling. This document
handling. This document focuses on one type of reporting that can be focuses on one type of reporting that can be requested under DMARC.
requested under DMARC.
Failure reports provide detailed information about the failure of a Failure reports provide detailed information about the failure of a
single message, or a group of similar messages failing for the same 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 reason. Their purpose is twofold. On the one hand, they are meant
aid in cases where a Domain Owner wishes to determine the cause of to aid in cases where a Domain Owner wishes to determine the cause of
failures that were part of aggregate reports (see failures that were part of aggregate reports (see [RFC9990]). On the
[I-D.ietf-dmarc-aggregate-reporting]). On the other hand, they can other hand, they can allow the Domain Owner to quickly identify and
allow the Domain Owner to quickly identify and address harmful address harmful messages involving direct domain abuse. It is
messages involving direct domain abuse. It is important to note that important to note that these reports can contain the header fields or
these reports can contain the header fields or sometimes the entire sometimes the entire content of a failed message, which may contain
content of a failed message, which may contain personally personally identifiable information (PII). The potential disclosure
identifiable information (PII). The potential disclosure of PII of PII should be considered when deciding whether to request failure
should be considered when deciding whether to request failure reports reports as a Domain Owner, or what information to include or redact
as a Domain Owner, or what information to include or redact in in failure reports when creating them as a Mail Receiver, or whether
failure reports when creating them as a Mail Receiver, or whether to to create failure reports at all. Refer to Section 7 for more
create failure reports at all. Refer to Section 7 for more
discussion on privacy considerations. discussion on privacy considerations.
1.1. Terminology 1.1. Terminology
There are a number of terms defined in Section 3.2 of There are a number of terms defined in Section 3.2 of [RFC9989] that
[I-D.ietf-dmarc-dmarcbis] that are used within this document. are used within this document. Understanding those definitions will
Understanding those definitions will aid in reading this document. aid in reading this document.
The format of DMARC failure reports is derived from Authentication The format of DMARC failure reports is derived from "Authentication
Failure Reporting Using the Abuse Reporting Format ([RFC6591]) and Failure Reporting Using the Abuse Reporting Format" [RFC6591], and
the terms defined there are used here. the terms defined there are used here.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Document Status 1.2. Document Status
This document, in part, along with DMARCbis [I-D.ietf-dmarc-dmarcbis] This document, in part, along with [RFC9989] and [RFC9990], obsoletes
DMARCbis Aggregate Reporting [I-D.ietf-dmarc-aggregate-reporting], and replaces [RFC7489].
obsoletes and replaces [RFC7489].
2. DMARC Failure Reports 2. DMARC Failure Reports
Besides the header fields or the entire contents of a failed message, Besides the header fields or the entire contents of a failed message,
failure reports supply details about transmission and DMARC failure reports supply details about transmission and DMARC
authentication, which may aid a Domain Owner in determining the cause authentication, which may aid a Domain Owner in determining the cause
of an authentication failure. of an authentication failure.
Failure reports are normally generated and sent almost immediately Failure reports are normally generated and sent almost immediately
after the Mail Receiver detects a DMARC failure. Rather than waiting after the Mail Receiver detects a DMARC failure. Rather than waiting
for an aggregate report, these reports are useful for quickly for an aggregate report, these reports are useful for quickly
notifying the Domain Owners when there is an authentication failure. notifying the Domain Owners when there is an authentication failure.
Failure reports also provide more information about the failed Failure reports also provide more information about the failed
message than is available in an aggregate report. This allows the message than is available in an aggregate report. This allows the
failure report consumer to better determine whether the failure is of failure report consumer to better determine whether the failure is of
a message that the domain owner intended to authenticate or one for a message that the Domain Owner intended to authenticate or one for
which use of its domain was not authorized. which use of its domain was not authorized.
These reports should include as much of the message header fields and These reports should include as much of the message header fields and
body as possible, consistent with the reporting party's privacy body as possible, consistent with the reporting party's privacy
policies, to enable the Domain Owner to diagnose the authentication policies, to enable the Domain Owner to diagnose the authentication
failure. failure.
When a Domain Owner requests failure reports for the purpose of When a Domain Owner requests failure reports for the purpose of
forensic analysis, and the Mail Receiver is willing to provide such forensic analysis, and the Mail Receiver is willing to provide such
reports, the Mail Receiver generates and sends a message using the reports, the Mail Receiver generates and sends a message using the
format described in [RFC6591]; this document updates that reporting format described in [RFC6591]; this document updates that reporting
format, as described in Section 4. format, as described in Section 4.
The destination(s) to which failure reports are sent, and options for 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 when they will be sent, are defined by the "ruf" and "fo" tags as
provided in Section 4.7 of [I-D.ietf-dmarc-dmarcbis]. provided in Section 4.7 of [RFC9989].
When multiple URIs are provided to receive failure reports, the When multiple URIs are provided to receive failure reports, the
report generator MUST make an attempt to deliver to each of them. report generator MUST make an attempt to deliver to each of them.
External destinations MUST be verified, see Section 5. Report External destinations MUST be verified (see Section 5). Report
generators MUST NOT consider "ruf" tags in DMARC Policy Records generators MUST NOT consider "ruf" tags in DMARC Policy Records that
having a "psd=y" tag, unless there are specific agreements between have a "psd=y" tag, unless there are specific agreements between the
the interested parties. interested parties.
Report generators MUST implement a rate-limit on outgoing reports so Report generators MUST implement a rate-limit on outgoing reports so
as not to flood report consumers with excessive reports, which would as not to flood Report Consumers with excessive reports, which would
allow denial-of-service; see Section 8.1. allow denial of service (see Section 8.1).
3. Other Failure Reports 3. Other Failure Reports
This document describes only DMARC failure reports. DKIM failure This document only describes DMARC failure reports. DomainKeys
reports and SPF failure reports are described in [RFC6591]. A Mail Identified Mail (DKIM) failure reports and Sender Policy Framework
Receiver generating DMARC failure reports MAY issue failure reports (SPF) failure reports are described in [RFC6591]. A Mail Receiver
specific to the failed authentication mechanism instead of, or in generating DMARC failure reports MAY issue failure reports specific
addition to, DMARC failure reports, based on its own policy, the to the failed authentication mechanism instead of, or in addition to,
failure in question, and the content of the "fo" tag in the retrieved DMARC failure reports, based on its own policy, the failure in
DMARC Policy Record. 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 Note that DKIM failure reports and SPF failure reports can also be
requested using the methods described in [RFC6651] and [RFC6652], requested using the methods described in [RFC6651] and [RFC6652],
respectively. Report Generators are free to follow any of the respectively. Report generators are free to follow any of the
specifications. specifications.
4. Reporting Format Update 4. Reporting Format Update
Operators implementing this specification also implement an augmented Operators implementing this specification also implement an augmented
version of [RFC6591] as follows: version of failure reporting described in [RFC6591] as follows:
1. A DMARC failure report includes the following ARF header fields, 1. A DMARC failure report includes the following Abuse Reporting
with the indicated normative requirement levels: Format (ARF) header fields, with the indicated normative
requirement levels:
* Identity-Alignment (REQUIRED; defined below) * Identity-Alignment (REQUIRED; defined below)
* Delivery-Result (OPTIONAL) * Delivery-Result (OPTIONAL)
* DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED for DKIM * DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED for DKIM
failures of an aligned identifier) failures of an aligned identifier)
* DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL * DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL
if reporting a DKIM failure) if reporting a DKIM failure)
* SPF-DNS (REQUIRED for SPF failure of an aligned identifier) * SPF-DNS (REQUIRED for SPF failure of an aligned identifier)
2. The "Identity-Alignment" field is defined to contain a comma- 2. The Identity-Alignment field is defined to contain a comma-
separated list of authentication mechanism names that failed to separated list of authentication mechanism names that failed to
authenticate an aligned identity, or the keyword "none" if all of authenticate an aligned identity or the keyword "none" if all of
the attempted methods were successful at authenticating an the attempted methods were successful at authenticating an
aligned identity. ABNF ([RFC5234], importing CFWS from aligned identity. Here is the ABNF [RFC5234] (importing comments
[RFC5322]): and/or folding white space (CFWS) from [RFC5322]):
id-align = "Identity-Alignment:" [CFWS] id-align = "Identity-Alignment:" [CFWS]
( "none" / ( "none" /
dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) ) dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) )
[CFWS] [CFWS]
dmarc-method = ( "dkim" / "spf" ) dmarc-method = ( "dkim" / "spf" )
; each may appear at most once in an id-align ; each may appear at most once in an id-align
3. Authentication Failure Type "dmarc" is defined for the Auth- 3. Authentication Failure Type "dmarc" is defined for the Auth-
Failure field, which is to be used when a failure report is Failure field, which is to be used when a failure report is
generated because some or all of the authentication mechanisms generated because some or all of the authentication mechanisms
failed to produce aligned identifiers. Note that a failure failed to produce aligned identifiers. Note that a failure
report generator MAY also independently produce an ARF message report generator MAY also independently produce an ARF message
for any or all of the underlying authentication methods. for any or all of the underlying authentication methods.
5. Verifying External Destinations 5. Verifying External Destinations
It is possible to specify destinations for failure reports that are It is possible to specify destinations for failure reports that are
outside of the Organizational Domain of the DMARC Policy Record that outside of the Organizational Domain of the DMARC Policy Record that
was requesting the reports. These destinations are commonly referred was requesting the reports. These destinations are commonly referred
to as "external destinations" and may represent a different domain to as "external destinations" and may represent a different domain
controlled by the same organization, a contracted report processing controlled by the same organization, a contracted report processing
service, or some other arrangement. service, or some other arrangement.
In case of external destinations, a Mail Receiver who generates In case of external destinations, a Mail Receiver who generates
failure reports MUST use the Verifying External Destinations failure reports MUST use the Verifying External Destinations
procedure described in Section 4 of procedure described in Section 4 of [RFC9990], substituting the "ruf"
[I-D.ietf-dmarc-aggregate-reporting], substituting the "ruf" tag tag where the "rua" tag appears in that procedure.
where the "rua" tag appears in that procedure.
This prevents a bad actor from publishing a DMARC Policy Record This prevents a bad actor from publishing a DMARC Policy Record
requesting failure reports to an external destination, and then requesting failure reports to an external destination and then
deliberately sending messages that will generate failure reports as a deliberately sending messages that will generate failure reports as a
form of abuse. It also prevents a Domain Owner from unilaterally form of abuse. It also prevents a Domain Owner from unilaterally
publishing a DMARC Policy Record with an external destination for publishing a DMARC Policy Record with an external destination for
failure reports, forcing the external destination to deal with failure reports, forcing the external destination to deal with
unwanted messages and potential privacy issues. unwanted messages and potential privacy issues.
5.1. Transport 5.1. Transport
Email streams carrying DMARC failure reports SHOULD be DMARC-aligned. Email streams carrying DMARC failure reports SHOULD be DMARC-aligned.
We recommend that reporters set a reasonable rate-limit for the We recommend that reporters set a reasonable rate-limit for the
number of failure reports sent to any recipient to avoid overloading number of failure reports sent to any recipient to avoid overloading
recipient systems. Unaligned reports may in turn produce subsequent recipient systems. Unaligned reports may in turn produce subsequent
failure reports that could cause mail loops. failure reports that could cause mail loops.
6. IANA Considerations 6. IANA Considerations
6.1. Feedback Report Header Fields Registry Update 6.1. Feedback Report Header Fields Registry Update
IANA is requested to change the "Identity-Alignment" entry in the IANA has updated the reference and description for the "Identity-
"Feedback Report Header Fields" registry, which is part of the Alignment" entry in the "Feedback Report Header Fields" registry
"Messaging Abuse Reporting Format (MARF) Parameters" registry group, within the "Messaging Abuse Reporting Format (MARF) Parameters"
as follows: registry group, as follows:
* "Reference" should change to this document
* "Description" should change to "a list of authentication mechanism Field Name: Identity-Alignment
names that failed to authenticate an aligned identity, or 'none' Description: a list of authentication mechanism names that failed to
if all were successful". authenticate an aligned identity, or "none" if all were successful
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Reference: RFC 9991
Status: current
7. Privacy Considerations 7. Privacy Considerations
The generation and transmission of DMARC failure reports raise The generation and transmission of DMARC failure reports raise
significant privacy concerns that must be carefully considered before significant privacy concerns that must be carefully considered before
deployment. deployment.
Given these factors, many large-scale providers limit or entirely Given these factors, many large-scale providers limit or entirely
disable the generation of failure reports, preferring to rely on disable the generation of failure reports, preferring to rely on
aggregate reports, which provide statistical visibility without aggregate reports, which provide statistical visibility without
exposing sensitive content. Operators that choose to enable failure exposing sensitive content. Operators that choose to enable failure
reporting are strongly encouraged to: reporting are strongly encouraged to:
* Limit the scope and duration of use to targeted diagnostic * Limit the scope and duration of use to targeted diagnostic
activities. activities;
* Ensure that reporting URIs are carefully controlled and validated.
* Ensure that reporting URIs are carefully controlled and validated;
* Apply minimization techniques, such as redaction of message bodies * Apply minimization techniques, such as redaction of message bodies
and header fields, to reduce sensitive data exposure. and header fields, to reduce sensitive data exposure;
* Always transmit reports over secure channels. * Always transmit reports over secure channels.
In summary, while DMARC failure reports can offer diagnostic value, In summary, while DMARC failure reports can offer diagnostic value,
the associated privacy concerns have led many operators to restrict the associated privacy concerns have led many operators to restrict
their use. Aggregate reports remain the recommended mechanism for their use. Aggregate reports remain the recommended mechanism for
gaining visibility into authentication results while preserving the gaining visibility into authentication results while preserving the
confidentiality of end-user communications. confidentiality of end-user communications.
Particular privacy-specific issues are explored below. Particular privacy-specific issues are explored below.
7.1. Data Exposure Considerations 7.1. Data Exposure Considerations
Failure reports may include PII and non-public information (NPI) from Failure reports may include PII and non-public information (NPI) from
messages that fail to authenticate, since these reports may contain messages that fail to authenticate, since these reports may contain
message content as well as trace header fields. These reports may message content as well as trace header fields. These reports may
expose sender and recipient identifiers (e.g., RFC5322.From expose sender and recipient identifiers (e.g., RFC5322.From
addresses), and although the [RFC5965] format used for failed-message addresses), and although the [RFC5965] format used for failed-message
reporting supports redaction ([RFC6590]), failed-message reporting is reporting supports redaction [RFC6590], failed-message reporting is
capable of exposing the entire message to the Report Consumer. They capable of exposing the entire message to the Report Consumer. They
may also expose PII, sensitive business data, or other confidential may also expose PII, sensitive business data, or other confidential
communications to unintended recipients. Such exposure can create communications to unintended recipients. Such exposure can create
regulatory, legal, and operational risks for both senders and regulatory, legal, and operational risks for both senders and
receivers. Examples include product launches, termination notices receivers. Examples include product launches, termination notices
for employees, or calendar data. Even innocuous-seeming failures for employees, or calendar data. Even innocuous-seeming failures
(such as malformed or "broken" calendar invitations) can result in (such as malformed or "broken" calendar invitations) can result in
the leakage of private communications. the leakage of private communications.
Domain Owners requesting reports will receive information about mail Domain Owners requesting reports will receive information about mail
skipping to change at page 8, line 36 skipping to change at line 331
This might provide valuable insight into content used in abusive This might provide valuable insight into content used in abusive
messages, but it might also expose PII or NPI from legitimate messages, but it might also expose PII or NPI from legitimate
messages mistakenly or accidentally failing authentication. messages mistakenly or accidentally failing authentication.
Information about the final destination of mail, where it might Information about the final destination of mail, where it might
otherwise be obscured by intermediate systems, may be exposed through otherwise be obscured by intermediate systems, may be exposed through
a failure report. A commonly cited example is exposure of members of a failure report. A commonly cited example is exposure of members of
mailing lists when one list member sends messages to the list, and mailing lists when one list member sends messages to the list, and
failure reports are generated when that message is delivered to other failure reports are generated when that message is delivered to other
list members. Those failure reports would be sent to the Domain list members. Those failure reports would be sent to the Domain
Owner of the list member posting the message, or their delegated Owner of the list member posting the message or their delegated
Report Consumer(s). Report Consumer(s).
Similarly, when message forwarding arrangements exist, Domain Owners Similarly, when message forwarding arrangements exist, Domain Owners
requesting reports may receive information about mail forwarded to requesting reports may receive information about mail forwarded to
domains that were not originally part of their messages' recipient domains that were not originally part of their messages' recipient
list. This means that destinations previously unknown to the Domain list. This means that destinations previously unknown to the Domain
Owner may now become visible. Owner may now become visible.
7.2. Report Recipients 7.2. Report Recipients
A DMARC Policy Record can specify that reports should be sent to a A DMARC Policy Record can specify that reports should be sent to a
Report Consumer operating on behalf of the Domain Owner. This might Report Consumer operating on behalf of the Domain Owner. This might
be done when the Domain Owner sends reports to an entity to monitor be done when the Domain Owner sends reports to an entity to monitor
mail streams for deliverability, performance issues, or abuse. mail streams for deliverability, performance issues, or abuse.
Receipt of such data by third parties may or may not be permitted by Receipt of such data by third parties may or may not be permitted by
the Mail Receiver's privacy policy, terms of use, et cetera. Domain the Mail Receiver's privacy policy, terms of use, etc. Domain Owners
Owners and Mail Receivers should both review and understand whether and Mail Receivers should both review and understand whether their
their own internal policies constrain the use and transmission of own internal policies constrain the use and transmission of DMARC
DMARC reporting. reporting.
Some potential exists for Report Consumers to perform traffic Some potential exists for Report Consumers to perform traffic
analysis, making it possible to obtain metadata about the Mail analysis, making it possible to obtain metadata about the Mail
Receiver's traffic. In addition to verifying compliance with Receiver's traffic. In addition to verifying compliance with
policies, Mail Receivers need to consider that before sending reports policies, Mail Receivers need to consider that before sending reports
to a third party. On the other hand, a Domain Owner may publish a to a third party. On the other hand, a Domain Owner may publish a
destination address that appears to be an Internal Report Consumer destination address that appears to be an Internal Report Consumer
but is actually a forwarding address; in this case, the final but is actually a forwarding address; in this case, the final
destination of a report is not guaranteed. destination of a report is not guaranteed.
7.3. Additional Damage 7.3. Additional Damage
The risks associated with failure reports are compounded by volume The risks associated with failure reports are compounded by volume
and content distribution concerns. Partially or unredacted reports and content distribution concerns. Partially or unredacted reports
may propagate large amounts of spam, phishing, or malware content, may propagate large amounts of spam, phishing, or malware content,
all of which may require special handling by Report Consumers or all of which may require special handling by Report Consumers or
other recipients to avoid incidents. This underscores the need to other recipients to avoid incidents. This underscores the need to
avoid misconfiguration of the destinations in the "ruf" reporting avoid misconfiguration of the destinations in the "ruf" reporting
URIs, and the suggestions for redaction in this document, for example URIs and the suggestions for redaction in this document, for example,
using the method described in [RFC6590]. All of these concerns are using the method described in [RFC6590]. All of these concerns are
heightened for high-volume domains. To mitigate such concerns, the heightened for high-volume domains. To mitigate such concerns, the
following steps should be considered: following steps should be considered:
By report generators: By report generators:
* Help prevent accidental access to potentially-malicious URIs by * Help prevent accidental access to potentially malicious URIs by
substituting hxxp for http; substituting hxxp for http;
* remove attachments which could embed malicious payload.
* Remove attachments that could embed malicious payload.
By report consumers: By report consumers:
* isolate report streams from other mail streams; * Isolate report streams from other mail streams;
* use sandboxes in evaluating failure reports;
* use network segmentation; * Use sandboxes in evaluating failure reports;
* limit access to failure reports to authorized individuals with
* Use network segmentation;
* Limit access to failure reports to authorized individuals with
appropriate security training. appropriate security training.
8. Security Considerations 8. Security Considerations
While reviewing this document and its Security Considerations, the While reviewing this document and its security considerations, the
reader should also review the Privacy Considerations above, as well reader should also review the privacy considerations above, as well
as the Privacy Considerations and Security Considerations in sections as the privacy considerations and security considerations in Sections
10 and 11 of [I-D.ietf-dmarc-dmarcbis]; and in sections 7 and 8 of 10 and 11 of [RFC9989] and in Sections 7 and 8 of [RFC9990].
[I-D.ietf-dmarc-aggregate-reporting].
8.1. Denial of Service 8.1. Denial of Service
Failure reports represent a possible denial-of-service attack that Failure reports represent a possible denial-of-service attack that
could be perpetrated by an attacker who sends numerous messages could be perpetrated by an attacker who sends numerous messages
purporting to be from the intended victim Domain Owner but which fail purporting to be from the intended victim Domain Owner but which fail
both SPF and DKIM; this would cause participating Mail Receivers to both SPF and DKIM; this would cause participating Mail Receivers to
send failure reports to the Domain Owner or its delegate(s), send failure reports to the Domain Owner or its delegate(s),
potentially in large numbers. Accordingly, participating Mail potentially in large numbers. Accordingly, participating Mail
Receivers are encouraged to aggregate these reports as much as is Receivers are encouraged to aggregate these reports as much as is
practical, using the Incidents field of the Abuse Reporting Format practical, using the Incidents field of the ARF [RFC5965]. Indeed,
[RFC5965]. Indeed, the aim is not to count each and every failure, the aim is not to count each and every failure but rather to report
but rather to report different failure conditions. Various pruning different failure conditions. Various pruning techniques are
techniques are possible, including the following: possible, including the following:
* store reports for a period of time before sending them, allowing * Store reports for a period of time before sending them, allowing
detection, collection, and consolidation of like incidents; detection, collection, and consolidation of like incidents;
* apply rate limiting, such as a maximum number of reports per * Apply rate-limiting, such as a maximum number of reports per
minute that will be generated (and the remainder discarded.) minute that will be generated (and the remainder discarded).
9. Normative References
[I-D.ietf-dmarc-aggregate-reporting] 9. References
Brotman, A., "Domain-based Message Authentication,
Reporting, and Conformance (DMARC) Aggregate Reporting",
Work in Progress, Internet-Draft, draft-ietf-dmarc-
aggregate-reporting-32, 17 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-
aggregate-reporting-32>.
[I-D.ietf-dmarc-dmarcbis] 9.1. Normative References
Herr, T. and J. R. Levine, "Domain-based Message
Authentication, Reporting, and Conformance (DMARC)", Work
in Progress, Internet-Draft, draft-ietf-dmarc-dmarcbis-41,
4 April 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-dmarc-dmarcbis-41>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
skipping to change at page 11, line 32 skipping to change at line 460
[RFC6692] Clayton, R. and M. Kucherawy, "Source Ports in Abuse [RFC6692] Clayton, R. and M. Kucherawy, "Source Ports in Abuse
Reporting Format (ARF) Reports", RFC 6692, Reporting Format (ARF) Reports", RFC 6692,
DOI 10.17487/RFC6692, July 2012, DOI 10.17487/RFC6692, July 2012,
<https://www.rfc-editor.org/info/rfc6692>. <https://www.rfc-editor.org/info/rfc6692>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10. Informative References [RFC9989] Herr, T., Ed. and J. R. Levine, Ed., "Domain-Based Message
Authentication, Reporting, and Conformance (DMARC)",
RFC 9989, DOI 10.17487/RFC9989, May 2026,
<https://www.rfc-editor.org/info/rfc9989>.
[RFC9990] Brotman, A., Ed., "Domain-Based Message Authentication,
Reporting, and Conformance (DMARC) Aggregate Reporting",
RFC 9990, DOI 10.17487/RFC9990, May 2026,
<https://www.rfc-editor.org/info/rfc9990>.
9.2. Informative References
[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
(DKIM) for Failure Reporting", RFC 6651, (DKIM) for Failure Reporting", RFC 6651,
DOI 10.17487/RFC6651, June 2012, DOI 10.17487/RFC6651, June 2012,
<https://www.rfc-editor.org/info/rfc6651>. <https://www.rfc-editor.org/info/rfc6651>.
[RFC6652] Kitterman, S., "Sender Policy Framework (SPF) [RFC6652] Kitterman, S., "Sender Policy Framework (SPF)
Authentication Failure Reporting Using the Abuse Reporting Authentication Failure Reporting Using the Abuse Reporting
Format", RFC 6652, DOI 10.17487/RFC6652, June 2012, Format", RFC 6652, DOI 10.17487/RFC6652, June 2012,
<https://www.rfc-editor.org/info/rfc6652>. <https://www.rfc-editor.org/info/rfc6652>.
skipping to change at page 15, line 16 skipping to change at line 648
To: users@forwarder.example To: users@forwarder.example
Authentication-Results: consumer.example; auth=pass (details omitted) Authentication-Results: consumer.example; auth=pass (details omitted)
From: Message Author <author@consumer.example> From: Message Author <author@consumer.example>
In-Reply-To: <20220718102753.0f6d9dde.cel@example.com> In-Reply-To: <20220718102753.0f6d9dde.cel@example.com>
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit
[ Message body was here ] [ Message body was here ]
--=_mime_boundary_-- --=_mime_boundary_--
The Source-Port field definition is given by [RFC6692] The Source-Port field definition is given by [RFC6692].
In the final MIME entity, the local-parts of To and From addresses 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, are reported unredacted. Since we know that the local parts are PII,
we can reduce the privacy risk by redacting them. In the example, we can reduce the privacy risk by redacting them. In the example,
the report generator could have replaced "users" with "lRLxexey" and the report generator could have replaced "users" with "lRLxexey" and
"author" with "RT47aVey" throughout the entity. "author" with "RT47aVey" throughout the entity.
If the body of the message is not included, the last MIME entity If the body of the message is not included, the last MIME entity
would have "Content-Type: text/rfc822-headers" instead of message/ would have "Content-Type: text/rfc822-headers" instead of "message/
rfc822. rfc822".
Appendix B. Change Log {change-log}
[RFC Editor: Please remove this section prior to publication.]
B.1. 00 to 01
* Replace references to RFC7489 with references to I-D.ietf-dmarc-
dmarcbis.
* Replace the 2nd paragraph in the Introduction with the text
proposed by Ned for Ticket #55, which enjoys some consensus:
https://mailarchive.ietf.org/arch/msg/dmarc/
HptVyJ9SgrfxWRbeGwORagPrhCw
(https://mailarchive.ietf.org/arch/msg/dmarc/
HptVyJ9SgrfxWRbeGwORagPrhCw)
* Strike a spurious sentence about criticality of feedback, which
was meant for feedback in general, not failure reports. In fact,
failure reports are not critical to establishing and maintaining
accurate authentication deployments. Still attributable to Ticket
#55.
* Remove the content of section "Verifying External Destinations"
and refer to I-D.ietf-dmarc-aggregate-reporting.
* Remove the content of section "Security Considerations" and refer
to I-D.ietf-dmarc-dmarcbis.
* Slightly tweak the wording of the example in Appendix A.1 so that
it makes sense standing alone.
* Remove the sentence containing "must include any URI(s)", as the
issue arose <eref
target="https://mailarchive.ietf.org/arch/msg/dmarc/
mFk0qiTCy8tzghRvcxus01W_Blw"/>.
* Add paragraph in Security Considerations, noting that note that
Organizational Domains are only an approximation...
* Add a Transport section, mentioning DMARC conformance and failure
report mail loops (Ticket #28).
B.2. 01 to 02
* Add a sentence to make clear that counting failures is not the
aim.
B.3. 02 to 03
* Updated references.
B.4. 03 to 04
* Add an example report.
* Remove the old Acknowledgements section.
* Add a IANA Consideration section
B.5. 04 to 05
* Convert to markdown
* Remove irrelevant material.
B.6. 05 to 06
* A Vesely was incorrectly removed from list of document editors.
Corrected.
* Added Terminology section with recoomended boilerplate re:
RFC2119.
B.7. 06 to 07
* Reduce Terminology section
* minor nits
B.8. 07 to 08
* Specify what detailed information a report contains, in the 1st
paragraph of Section 2
* A couple of typos
B.9. 08 to 09
* Replace &lt; with < and &gt; with > in Appendix B
B.10. 09 to 10
* Add an informative section about other failure reports (DKIM, SPF)
B.11. 10 to 11
* Remove appendix with redundant examples - pull request by Daniel
K.
B.12. 11 to 12
* Reference Terminology in [I-D.ietf-dmarc-dmarcbis]
* Expand the Verifying External Destinations section and reference
[I-D.ietf-dmarc-aggregate-reporting]
B.13. 12 to 13
* Update references to numbered sections of
[I-D.ietf-dmarc-dmarcbis] and [I-D.ietf-dmarc-aggregate-reporting]
* Clarify potential information disclosures when failure reports are
sent
* Minor edits for readability and clarity
B.14. 13 to 14
* In the introduction (last paragraph) mention that the purpose is
twofold, debug and anti-abuse.
* In Section 2 (2nd paragraph) clarify that failure reports allow
better determining the failure reason.
B.15. 14 to 15
* Expanded Privacy Considerations section as discussed on list.
* Add tentative IANA Consideration subsections.
B.16. 15 to 16
* Qualification of RFCs 6651/2 in Section 3.
* Spell "Auth-Failure" at bullet 3 of Section 4.
* Cite RFC 6590 when mentioning redaction.
* s/using the wrong sending path/failing authentication/.
* Remove unnecessary IANA Considerations.
B.17. 16 to 17
* Remove the last paragraph of Secority Considerations.
B.18. 17 to 18
* Reword the first purpose (Intro) and cite aggregate-reporting.
* Forward reference to Privacy Consideration.
* s/fo=/"fo"/, /ruf=/ruf/, /urls/URIs/.
* Specify parent registry in IANA Considerations.
B.19. 18 to 19
* Remove the term "scalable" from Abstract and Introduction.
* s/Sender Domain/Domain Owner/.
* Reference to dmarcbis, section 3.2 on its own line.
* Remove the phrase (sometimes referred to as "forensic reports").
* Note that Domain Owner can use dot-forward to not decalre
consumer.
* Mention we could have encrypted the example.
* Don't mention MX.
B.20. 19 to 20
* Replace "dot-forward" with a periphrasis to downplay final
destination.
B.21. 20 to 21
* Move the last paragraph of Section 2 to Security Considerations.
* Explicitly say we obsolete 7489 and update 6591 in the abstract.
* Reword "Without this check, a bad actor ..." in Section 5.
* Fix IANA request.
* Mention RFC 6591 in Terminology (Section 1.1).
B.22. 21 to 22
* Reword obsoleting sentence in the abstract and move it to
Section 1.2.
B.23. 22 to 23
* Merge Med's pull request
B.24. 23 to 24
* "Defang" issue.
* Avoid using "defined by" twice (Section 2, paragraph 5).
* Fix the normative part of rate-limiting (Section 2, paragraph 6).
* Recommend (non-2119) to rate limit (Section 5.1, paragraph 2).
* Reference RFC 5322 (Section 4, bullet 2).
Authors' Addresses Authors' Addresses
Steven M Jones Steven M. Jones (editor)
DMARC.org DMARC.org
Email: smj@dmarc.org Email: smj@dmarc.org
Alessandro Vesely Alessandro Vesely (editor)
Tana Tana
Email: vesely@tana.it Email: vesely@tana.it
 End of changes. 52 change blocks. 
384 lines changed or deleted 169 lines changed or added

This html diff was produced by rfcdiff 1.48.