<?xml version="1.0"encoding="utf-8"?> <!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc version="3" ipr="trust200902" docName="draft-ietf-dmarc-failure-reporting-25" number="9991" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" updates="6591" obsoletes="7489"indexInclude="true" consensus="true">tocInclude="true" consensus="true" symRefs="true" sortRefs="true"> <front> <title abbrev="DMARC FailureReporting">Domain-basedReporting">Domain-Based Message Authentication, Reporting, and Conformance (DMARC) FailureReporting</title><seriesInfo value="draft-ietf-dmarc-failure-reporting-25" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo>Reporting</title> <seriesInfo name="RFC" value="9991"/> <author initials="S."surname="Jones (ed)"surname="Jones" fullname="StevenM Jones"><organization>DMARC.org</organization><address><postal><street></street> </postal><email>smj@dmarc.org</email> </address></author><authorM. Jones" role="editor"> <organization>DMARC.org</organization> <address> <email>smj@dmarc.org</email> </address> </author> <author initials="A."surname="Vesely (ed)"surname="Vesely" fullname="AlessandroVesely"><organization>Tana</organization><address><postal><street></street> </postal><email>vesely@tana.it</email> </address></author><date/> <area>Application</area> <workgroup>DMARC</workgroup>Vesely" role="editor"> <organization>Tana</organization> <address> <email>vesely@tana.it</email> </address> </author> <date month="May" year="2026"/> <area>ART</area> <workgroup>dmarc</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t>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","failure reports", or"failed"failed messagereports",reports", which provide details about individual messages that failed to authenticate according to the DMARC mechanism.</t> <t>This document updates RFC 6591 and obsoletes RFC 7489.</t> </abstract> </front> <middle> <section anchor="introduction"><name>Introduction</name><t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: The source for this draft is maintained in GitHub at: <eref target="https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting">https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting</eref></t><t>Domain-based Message Authentication, Reporting, and Conformance (DMARC) <xreftarget="I-D.ietf-dmarc-dmarcbis"></xref>target="RFC9989"/> is a mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, andreporting,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.</t> <t>Failure reports provide detailed information about the failure of a singlemessage,message or a group of similar messages failing for the same reason. Their purpose is twofold. On the onehandhand, 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 <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>).target="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 <xreftarget="privacy-considerations"></xref>target="privacy-considerations"/> for more discussion on privacy considerations.</t> <section anchor="terminology"><name>Terminology</name> <t>There are a number of terms defined in <xreftarget="I-D.ietf-dmarc-dmarcbis"target="RFC9989" sectionFormat="of"relative="#" section="3.2"></xref>section="3.2"/> that are used within this document. Understanding those definitions will aid in reading this document.</t> <t>The format of DMARC failure reports is derived fromAuthentication"Authentication Failure Reporting Using the Abuse ReportingFormat (<xref target="RFC6591"></xref>)Format" <xref target="RFC6591"/>, and the terms defined there are used here.</t><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"></xref>target="RFC2119"/> <xreftarget="RFC8174"></xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section anchor="document-status"><name>Document Status</name> <t>This document, in part, along withDMARCbis<xreftarget="I-D.ietf-dmarc-dmarcbis"></xref> DMARCbis Aggregate Reportingtarget="RFC9989"/> and <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>,target="RFC9990"/>, obsoletes and replaces <xreftarget="RFC7489"></xref>.</t>target="RFC7489"/>.</t> </section> </section> <section anchor="failure-reports"><name>DMARC Failure Reports</name> <t>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.</t> <t>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 thedomain ownerDomain Owner intended to authenticate or one for which use of its domain was not authorized.</t> <t>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.</t> <t>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 <xreftarget="RFC6591"></xref>;target="RFC6591"/>; this document updates that reporting format, as described in <xreftarget="reporting-format-update"></xref>.</t>target="reporting-format-update"/>.</t> <t>The destination(s) to which failure reports are sent, and options for when they will be sent, are defined by the"ruf""ruf" and"fo""fo" tags as provided in <xreftarget="I-D.ietf-dmarc-dmarcbis"target="RFC9989" sectionFormat="of"relative="#" section="4.7"></xref>.</t>section="4.7"/>.</t> <t>When multiple URIs are provided to receive failure reports, the report generator <bcp14>MUST</bcp14> make an attempt to deliver to each of them. External destinations <bcp14>MUST</bcp14> beverified, seeverified (see <xreftarget="verifying-external-destinations"></xref>.target="verifying-external-destinations"/>). Report generators <bcp14>MUST NOT</bcp14> consider"ruf""ruf" tags in DMARC Policy Recordshavingthat have a"psd=y""psd=y" tag, unless there are specific agreements between the interested parties.</t> <t>Report generators <bcp14>MUST</bcp14> implement a rate-limit on outgoing reports so as not to floodreport consumersReport Consumers with excessive reports, which would allowdenial-of-service; seedenial of service (see <xreftarget="dos-attacks"></xref>.</t>target="dos-attacks"/>).</t> </section> <!--[rfced] To improve the readability of this sentence, may we update the punctuation as follows? Original: 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. Perhaps: 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 that are based on the Receiver's own policy, the failure in question, and the content of the "fo" tag in the retrieved DMARC Policy Record. --> <section anchor="other-reports"><name>Other Failure Reports</name> <t>This documentdescribesonly describes DMARC failure reports.DKIMDomainKeys Identified Mail (DKIM) failure reports andSPFSender Policy Framework (SPF) failure reports are described in <xreftarget="RFC6591"></xref>.target="RFC6591"/>. A Mail Receiver generating DMARC failure reports <bcp14>MAY</bcp14> 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""fo" tag in the retrieved DMARC Policy Record.</t> <t>Note that DKIM failure reports and SPF failure reports can also be requested using the methods described in <xreftarget="RFC6651"></xref>target="RFC6651"/> and <xreftarget="RFC6652"></xref>,target="RFC6652"/>, respectively. ReportGeneratorsgenerators are free to follow any of the specifications.</t> </section> <section anchor="reporting-format-update"><name>Reporting Format Update</name> <t>Operators implementing this specification also implement an augmented version of failure reporting described in <xreftarget="RFC6591"></xref>target="RFC6591"/> as follows:</t><ol><ol spacing="normal" type="1"> <li><t>A DMARC failure report includes the followingARFAbuse Reporting Format (ARF) header fields, with the indicated normative requirement levels:</t> <ul> <li><t>Identity-Alignment (<bcp14>REQUIRED</bcp14>; defined below)</t> </li> <li><t>Delivery-Result (<bcp14>OPTIONAL</bcp14>)</t> </li> <li><t>DKIM-Domain, DKIM-Identity, DKIM-Selector (<bcp14>REQUIRED</bcp14> for DKIM failures of an aligned identifier)</t> </li> <li><t>DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (<bcp14>OPTIONAL</bcp14> if reporting a DKIM failure)</t> </li> <li><t>SPF-DNS (<bcp14>REQUIRED</bcp14> for SPF failure of an aligned identifier)</t> </li> </ul></li> <li><t>The"Identity-Alignment"Identity-Alignment field is defined to contain acomma-separatedcomma- separated list of authentication mechanism names that failed to authenticate an alignedidentity,identity or the keyword"none""none" if all of the attempted methods were successful at authenticating an aligned identity. Here is the ABNF(<xref target="RFC5234"></xref>, importing CFWS<xref target="RFC5234"/> (importing comments and/or folding white space (CFWS) from <xreftarget="RFC5322"></xref>):</t> </li> </ol>target="RFC5322"/>):</t> <!--[rfced] This line within the ABNF in Section 4 exceeds the 72-character limit by 3 characters. Please let us know how it can be modified. Original: dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) ) --> <sourcecodetype="ABNF">id-aligntype="abnf"><![CDATA[ id-align ="Identity-Alignment:""Identity-Alignment:" [CFWS] ("none""none" / dmarc-method *( [CFWS]",""," [CFWS] dmarc-method ) ) [CFWS] dmarc-method = ("dkim""dkim" /"spf""spf" ) ; each may appear at most once in anid-align </sourcecode> <ol spacing="compact" start="3">id-align]]></sourcecode></li> <li>Authentication Failure Type"dmarc""dmarc" is defined for the Auth-Failure field, which is to be used when a failure report is generated because some or all of the authentication mechanisms failed to produce aligned identifiers. Note that a failure report generator <bcp14>MAY</bcp14> also independently produce an ARF message for any or all of the underlying authentication methods.</li> </ol> </section> <section anchor="verifying-external-destinations"><name>Verifying External Destinations</name> <t>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""external destinations" and may represent a different domain controlled by the same organization, a contracted report processing service, or some other arrangement.</t> <t>In case of external destinations, a Mail Receiver who generates failure reports <bcp14>MUST</bcp14> use the Verifying External Destinations procedure described in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"target="RFC9990" sectionFormat="of"relative="#" section="4"></xref>,section="4"/>, substituting the"ruf""ruf" tag where the"rua""rua" tag appears in that procedure.</t> <t>This prevents a bad actor from publishing a DMARC Policy Record requesting failure reports to an externaldestination,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.</t> <section anchor="transport"><name>Transport</name> <t>Email streams carrying DMARC failure reports <bcp14>SHOULD</bcp14> be DMARC-aligned.</t> <t>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.</t> </section> </section> <section anchor="iana-considerations"><name>IANA Considerations</name> <section anchor="feedback-report-header-fields-registry-update"><name>Feedback Report Header Fields Registry Update</name> <t>IANAis requested to changehas updated the"Identity-Alignment"reference and description for the "Identity-Alignment" entry in the"Feedback"Feedback Report HeaderFields" registry, which is part ofFields" registry within the"Messaging"Messaging Abuse Reporting Format (MARF)Parameters"Parameters" registry group, as follows:</t><ul> <li><t>"Reference" should change to this document</t> </li> <li><t>"Description" should change to "a<dl spacing="compact"> <dt>Field Name:</dt><dd>Identity-Alignment</dd> <dt>Description:</dt><dd>a list of authentication mechanism names that failed to authenticate an aligned identity, or'none'"none" if all weresuccessful".</t> </li> </ul>successful</dd> <dt>Multiple Appearances:</dt><dd>No</dd> <dt>Related "Feedback-Type":</dt><dd>auth-failure</dd> <dt>Reference:</dt><dd>RFC 9991</dd> <dt>Status:</dt><dd>current</dd> </dl> </section> </section> <section anchor="privacy-considerations"><name>Privacy Considerations</name> <t>The generation and transmission of DMARC failure reports raise significant privacy concerns that must be carefully considered before deployment.</t> <t>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:</t> <ulspacing="compact">spacing="normal"> <li>Limit the scope and duration of use to targeted diagnosticactivities.</li>activities;</li> <li>Ensure that reporting URIs are carefully controlled andvalidated.</li>validated;</li> <li>Apply minimization techniques, such as redaction of message bodies and header fields, to reduce sensitive dataexposure.</li>exposure; </li> <li>Always transmit reports over secure channels.</li> </ul> <t>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.</t> <t>Particular privacy-specific issues are explored below.</t> <section anchor="data-exposure-considerations"><name>Data Exposure Considerations</name> <t>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 <xreftarget="RFC5965"></xref>target="RFC5965"/> format used for failed-message reporting supports redaction(<xref target="RFC6590"></xref>),<xref target="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""broken" calendar invitations) can result in the leakage of private communications.</t> <t>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.</t> <t>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 themessage,message or their delegated Report Consumer(s).</t> <t>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.</t> </section> <section anchor="report-recipients"><name>Report Recipients</name> <t>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,et cetera.etc. Domain Owners and Mail Receivers should both review and understand whether their own internal policies constrain the use and transmission of DMARC reporting.</t> <t>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.</t> </section> <section anchor="additional-damage"><name>Additional Damage</name> <t>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""ruf" reportingURIs,URIs and the suggestions for redaction in this document, forexampleexample, using the method described in <xreftarget="RFC6590"></xref>.target="RFC6590"/>. All of these concerns are heightened for high-volume domains. To mitigate such concerns, the following steps should be considered:</t> <t>By report generators:</t> <ulspacing="compact">spacing="normal"> <li>Help prevent accidental access topotentially-maliciouspotentially malicious URIs by substituting hxxp for http;</li><li>remove<li>Remove attachmentswhichthat could embed malicious payload.</li> </ul> <t>By report consumers:</t> <ulspacing="compact"> <li>isolatespacing="normal"> <li>Isolate report streams from other mail streams;</li><li>use<li>Use sandboxes in evaluating failure reports;</li><li>use<li>Use network segmentation;</li><li>limit<li>Limit access to failure reports to authorized individuals with appropriate security training.</li> </ul> </section> </section> <section anchor="security-considerations"><name>Security Considerations</name> <t>While reviewing this document and itsSecurity Considerations,security considerations, the reader should also review thePrivacy Considerationsprivacy considerations above, as well as thePrivacy Considerationsprivacy considerations andSecurity Considerationssecurity considerations insectionsSections <xreftarget="I-D.ietf-dmarc-dmarcbis"target="RFC9989" sectionFormat="bare"relative="#" section="10"></xref>section="10"/> and <xreftarget="I-D.ietf-dmarc-dmarcbis"target="RFC9989" sectionFormat="bare"relative="#" section="11"></xref>section="11"/> of <xreftarget="I-D.ietf-dmarc-dmarcbis"></xref>;target="RFC9989"/> and insectionsSections <xreftarget="I-D.ietf-dmarc-aggregate-reporting"target="RFC9990" sectionFormat="bare"relative="#" section="7"></xref>section="7"/> and <xreftarget="I-D.ietf-dmarc-aggregate-reporting"target="RFC9990" sectionFormat="bare"relative="#" section="8"></xref>section="8"/> of <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> <section anchor="dos-attacks"><name>Denial of Service</name> <t>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 theAbuse Reporting FormatARF <xreftarget="RFC5965"></xref>.target="RFC5965"/>. Indeed, the aim is not to count each and everyfailure,failure but rather to report different failure conditions. Various pruning techniques are possible, including the following:</t> <ul><li><t>store<li><t>Store reports for a period of time before sending them, allowing detection, collection, and consolidation of like incidents;</t> </li><li><t>apply rate limiting,<li><t>Apply rate-limiting, such as a maximum number of reports per minute that will be generated (and the remainderdiscarded.)</t>discarded).</t> </li> </ul> </section> </section> </middle> <back> <references><name>References</name> <references><name>Normative References</name> <!-- [RFCYYY1] draft-ietf-dmarc-aggregate-reporting-32 companion doc RFC 9990 in AUTH48 as of 5/13/26 --> <reference anchor="RFC9990" target="https://www.rfc-editor.org/info/rfc9990"> <front> <title>Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting</title> <author initials="A." surname="Brotman" fullname="Alex Brotman" role="editor"> <organization>Comcast, Inc.</organization> </author> <date month='May' year='2026'/> </front> <seriesInfo name="RFC" value="9990"/> <seriesInfo name="DOI" value="10.17487/RFC9990"/> </reference> <!-- [RFCYYY2] draft-ietf-dmarc-dmarcbis-41 companion doc RFC 9989 in AUTH48 as of 5/13/26 --> <reference anchor="RFC9989" target="https://www.rfc-editor.org/info/rfc9989"> <front> <title>Domain-Based Message Authentication, Reporting, and Conformance (DMARC)</title> <author initials="T." surname="Herr" fullname="Todd Herr" role="editor"> <organization>Valimail</organization> </author> <author initials="J. R." surname="Levine" fullname="John R. Levine" role="editor"> <organization>Standcore LLC</organization> </author> <date month='May' year='2026'/> </front> <seriesInfo name="RFC" value="9989"/> <seriesInfo name="DOI" value="10.17487/RFC9989"/> </reference> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-dmarc-aggregate-reporting.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-dmarc-dmarcbis.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5965.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5965.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6590.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6590.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6591.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6591.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6692.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6692.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references><name>Informative References</name> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6651.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6651.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6652.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6652.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml"/> </references> </references> <section anchor="report-format-example"><name>Example Failure Report</name> <t>This is the full content of a sample failure message, including the message header.</t> <sourcecodetype="RFC5322">Received:type="message/rfc822"><![CDATA[ Received: from gen.example (gen.example [192.0.2.1]) (TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by mail.consumer.example with ESMTPS id 00000000005DC0DD.0000442E; Tue, 19 Jul 2022 07:57:50 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gen.example; s=mail; t=1658210268; bh=rCrh1aFDE8d/Fltt8wbcu48bLOu4OM23QXqphUZPAIM=; h=From:To:Date:Subject:From; b=IND9JkuwF9/5841kzxMbPeej0VYimVzNKozR2R89M8eYO2zOlCBblx507Gz0YK7mE /h6pslWm0ODBVFzLlwY9CXv4Vu62QsN0RBIXHPjEXOkoM2VCD5zCd+5i5dtCFX7Mxh LThb2ZJ3efklbSB9RQRwxcmRvCPV7z6lt/Ds9sucVE1RDODYHjx+iWnAUQrlos6ZQb u/YOUGjf60LPpyljfPu3EpFwo80mSHyQlP/4S5KEykgPQMgCqLPPKvJwu1aAIDj+jG q2ylO3fmc/ERDeDWACtR67YNabEKBWtjqCRLNxKttazViJTZ5drcLfpX0853KoougX Rltp7zdoLdy4A== From: DMARC Filter<DMARC@gen.example>;<DMARC@gen.example>; To: dmarcfail@consumer.example Date: Tue, 19 Jul 2022 00:57:48 -0500 (CDT) Subject: FW: This is the original subject Mime-Version: 1.0 Content-Type: multipart/report; report-type=feedback-report;boundary="=_mime_boundary_"boundary="=_mime_boundary_" Message-Id:<20220719055748.4AE9D403CC@gen.example>;<20220719055748.4AE9D403CC@gen.example>; This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_mime_boundary_ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 7bit This is an authentication failure report for an email message received from IP 192.0.2.2 on Tue, 19 Jul 2022 00:57:48 -0500. --=_mime_boundary_ Content-Type: message/feedback-report Content-Transfer-Encoding: 7bit Feedback-Type: auth-failure Version: 1 User-Agent: DMARC-Filter/1.2.3 Auth-Failure: dmarc Authentication-Results: gen.example; dmarc=fail header.from=consumer.example Identity-Alignment: dkim DKIM-Domain: consumer.example DKIM-Identity: @consumer.example DKIM-Selector: epsilon Original-Envelope-Id: 65E1A3F0A0 Original-Mail-From: author=gen.example@forwarder.example Source-IP: 192.0.2.2 Source-Port: 12345 Reported-Domain: consumer.example --=_mime_boundary_ Content-Type: message/rfc822; charset=utf-8 Content-Transfer-Encoding: 7bit Authentication-Results: gen.example; dkim=permerror header.d=forwarder.exampleheader.b="EjCbN/c3";header.b="EjCbN/c3"; dkim=temperror header.d=forwarder.exampleheader.b="mQ8GEWPc";header.b="mQ8GEWPc"; dkim=permerror header.d=consumer.exampleheader.b="hETrymCb";header.b="hETrymCb"; dkim=neutral header.d=consumer.exampleheader.b="C2nsAp3A";header.b="C2nsAp3A"; Received: from mail.forwarder.example (mail.forwarder.example [IPv6:2001:db8::23ac]) by mail.gen.example (Postfix) with ESMTP id 5E8B0C159826 for<x@gen.example>;<x@gen.example>; Sun, 14 Aug 2022 07:58:29 -0700 (PDT) Received: from mail.forwarder.example (localhost [127.0.0.1]) by mail.forwarder.example (Postfix) with ESMTP id 4Ln7Qw4fnvz6Bq for<x@gen.example>;<x@gen.example>; Tue, 19 Jul 2022 07:57:44 +0200 DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=forwarder.example; s=ed25519-59hs; t=1658210264; x=1663210264; bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=; h=Message-ID:Date:List-Id:List-Archive:List-Post:List-Help: List-Subscribe:List-Unsubscribe:List-Owner:MIME-Version:Subject: To:References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:autocrypt:cc:content-transfer-encoding: content-type:date:from:in-reply-to:message-id:mime-version: openpgp:references:subject:to; b=EjCbN/c3bTU4QkZH/zwTbYxBDp0k8kpmWSXh5h1M7T8J4vtRo+hvafJazT3ZRgq+7 +4dzEQwUhl+NOJYXXNUAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forwarder.example; s=rsa-wgJg; t=1658210264; x=1663210264; bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=; h=Message-ID:Date:List-Id:List-Archive:List-Post:List-Help: List-Subscribe:List-Unsubscribe:List-Owner:MIME-Version:Subject: To:References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:autocrypt:cc:content-transfer-encoding: content-type:date:from:in-reply-to:message-id:mime-version: openpgp:references:subject:to; b=mQ8GEWPcVpBpeqQ88pcbXpGHBT0J/Rwi8Zd2WZTXWWneQGRCOJLRcbBJpjqnrwtqd 76IqawH86tihz4Z/12J1GBCdNx1gfazsoI3yaqfooRDYg0mSyZHrYhQBmodnPcqZj4 /25L5278sc/UNrYO9az2n7R/skbVZ0bvSo2eEiGU8fcpO8+a5SKNYskhaviAI4eGIB iRMdEP7gP8dESdnZguNbY5HI32UMDpPPNqajzd/BgcqbveYpRrWCDOhcY47POV7GHM i/KLHiZXtJsL3/Pr/4TL+HTjdX8EDSsy1K5/JCvJCFsJHnSvkEaJQGLn/2m03eW9r8 9w1bQ90aY+VCQ== X-Original-To: users@forwarder.example Received: from mail.consumer.example (mail.consumer.example [192.0.2.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) by mail.forwarder.example (Postfix) with ESMTPS id 4Ln7Qs55xmz4nP for<users@forwarder.example>;<users@forwarder.example>; Tue, 19 Jul 2022 07:57:41 +0200 (CEST) Authentication-Results: mail.forwarder.example; arc=none smtp.remote-ip=192.0.2.4 Authentication-Results: mail.forwarder.example; dkim=pass (512-bit key; secure) header.d=consumer.example header.i=@consumer.example header.a=ed25519-sha256 header.s=epsilon header.b=hETrymCb; dkim=pass (1152-bit key; secure) header.d=consumer.example header.i=@consumer.example header.a=rsa-sha256 header.s=delta header.b=C2nsAp3A DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=consumer.example; s=epsilon; t=1658210255; bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=; h=Date:Subject:To:References:From:In-Reply-To; b=hETrymCbz6T1Dyo5dCG9dk8rPykKLdhJCPFeJ9TiiP/kaoN2afpUYtj+SrI+I83lp p1F/FfYSGy7zz3Q3OdxBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=consumer.example; s=delta; t=1658210255; bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=; h=Date:To:References:From:In-Reply-To; b=C2nsAp3AMNX33Nq7nN/StPo921xE3XGF8Ju3iAKdYB3EKhsril0N5IjWGlglJECst jLNKSo7KWZZ2lkH/dVZ9Rs1GHT2uaKy1sc/xmNIC5rHdhrxammiwpTSo4PsT8disfc 3DVF6Q62n0EsdLFqcw1KY8A9inFqYKY2tqoo+y4zMtItqCYx3xjsj3I0IFLuX Author: Message Author<author@consumer.example><author@consumer.example> Received: from [192.0.2.8] (host-8-2-0-192.isp.example [192.0.2.8]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3,128bits, ECDHE_RSA_AES_128_GCM_SHA256) by mail.consumer.example with ESMTPSA id 00000000005DC076.00004417; Tue, 19 Jul 2022 07:57:35 +0200 Message-ID:<2431dc66-b010-c9cc-4f2b-a1f889f8bdb4@consumer.example><2431dc66-b010-c9cc-4f2b-a1f889f8bdb4@consumer.example> Date: Tue, 19 Jul 2022 07:57:33 +0200 List-Id:<users.forwarder.example><users.forwarder.example> List-Post:<mailto:users@forwarder.example><mailto:users@forwarder.example> List-Help:<mailto:users+help@forwarder.example><mailto:users+help@forwarder.example> List-Subscribe:<mailto:users+subscribe@forwarder.example><mailto:users+subscribe@forwarder.example> List-Unsubscribe:<mailto:users+unsubscribe@forwarder.example><mailto:users+unsubscribe@forwarder.example> List-Owner:<mailto:users+owner@forwarder.example><mailto:users+owner@forwarder.example> Precedence: list MIME-Version: 1.0 Subject: This is the original subject Content-Language: en-US To: users@forwarder.example Authentication-Results: consumer.example; auth=pass (details omitted) From: Message Author<author@consumer.example><author@consumer.example> In-Reply-To:<20220718102753.0f6d9dde.cel@example.com><20220718102753.0f6d9dde.cel@example.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit [ Message body was here ]--=_mime_boundary_-- </sourcecode>--=_mime_boundary_--]]></sourcecode> <t>The Source-Port field definition is given by <xreftarget="RFC6692"></xref></t>target="RFC6692"/>.</t> <t>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""users" with"lRLxexey""lRLxexey" and"author""author" with"RT47aVey""RT47aVey" throughout the entity.</t> <t>If the body of the message is not included, the last MIME entity would have"Content-Type: text/rfc822-headers""Content-Type: text/rfc822-headers" instead ofmessage/rfc822.</t>"message/rfc822".</t> </section><section anchor="change-log-change-log"><name>Change Log {change-log}</name> <t>[RFC Editor: Please remove this section prior to publication.]</t> <section anchor="s00"><name>00 to 01</name> <ul> <li><t>Replace references to RFC7489 with references to I-D.ietf-dmarc-dmarcbis.</t> </li> <li><t>Replace the 2nd paragraph in the Introduction with the text proposed by Ned for Ticket #55, which enjoys some consensus:<br /> <eref target="https://mailarchive.ietf.org/arch/msg/dmarc/HptVyJ9SgrfxWRbeGwORagPrhCw">https://mailarchive.ietf.org/arch/msg/dmarc/HptVyJ9SgrfxWRbeGwORagPrhCw</eref></t> </li> <li><t>Strike a spurious sentence about criticality of feedback, which was meant<!-- [rfced] FYI - We have added expansions forfeedback in general, not failure reports. In fact, failure reports are not critical to establishing and maintaining accurate authentication deployments. Still attributable to Ticket #55.</t> </li> <li><t>Remove the content of section "Verifying External Destinations" and refer to I-D.ietf-dmarc-aggregate-reporting.</t> </li> <li><t>Remove the content of section "Security Considerations" and refer to I-D.ietf-dmarc-dmarcbis.</t> </li> <li><t>Slightly tweakthewordingfollowing abbreviations per Section 3.6 ofthe example in Appendix A.1 so that it makes sense standing alone.</t> </li> <li><t>Remove the sentence containing "must include any URI(s)", as the issue arose <eref target="https://mailarchive.ietf.org/arch/msg/dmarc/mFk0qiTCy8tzghRvcxus01W_Blw"/>.</t> </li> <li><t>Add paragraphRFC 7322 ("RFC Style Guide"). Please review each expansion inSecurity Considerations, noting that note that Organizational Domains are only an approximation...</t> </li> <li><t>Add a Transport section, mentioning DMARC conformance and failure report mail loops (Ticket #28).</t> </li> </ul> </section> <section anchor="s01"><name>01 to 02</name> <ul spacing="compact"> <li>Add a sentence to make clear that counting failures is not the aim.</li> </ul> </section> <section anchor="s02"><name>02 to 03</name> <ul spacing="compact"> <li>Updated references.</li> </ul> </section> <section anchor="s03"><name>03 to 04</name> <ul> <li><t>Add an example report.</t> </li> <li><t>Removetheold Acknowledgements section.</t> </li> <li><t>Add a IANA Consideration section</t> </li> </ul> </section> <section anchor="s04"><name>04 to 05</name> <ul> <li><t>Convert to markdown</t> </li> <li><t>Remove irrelevant material.</t> </li> </ul> </section> <section anchor="s05"><name>05 to 06</name> <ul> <li><t>A Vesely was incorrectly removed from list ofdocumenteditors. Corrected.</t> </li> <li><t>Added Terminology section with recoomended boilerplate re: RFC2119.</t> </li> </ul> </section> <section anchor="s06"><name>06 to 07</name> <ul> <li><t>Reduce Terminology section</t> </li> <li><t>minor nits</t> </li> </ul> </section> <section anchor="s07"><name>07carefully to08</name> <ul> <li><t>Specify what detailed information a report contains, inensure correctness. comments and/or folding white space (CFWS) DomainKeys Identified Mail (DKIM) Sender Policy Framework (SPF) --> <!-- [rfced] Please review the1st paragraph"Inclusive Language" portion ofSection 2</t> </li> <li><t>A couple of typos</t> </li> </ul> </section> <section anchor="s08"><name>08 to 09</name> <ul spacing="compact"> <li>Replace &lt; with < and &gt; with > in Appendix B</li> </ul> </section> <section anchor="s09"><name>09 to 10</name> <ul spacing="compact"> <li>Add an informative section about other failure reports (DKIM, SPF)</li> </ul> </section> <section anchor="s10"><name>10 to 11</name> <ul spacing="compact"> <li>Remove appendix with redundant examples - pull request by Daniel K.</li> </ul> </section> <section anchor="s11"><name>11 to 12</name> <ul spacing="compact"> <li>Reference Terminology in <xref target="I-D.ietf-dmarc-dmarcbis"></xref></li> <li>ExpandtheVerifying External Destinations section and reference <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref></li> </ul> </section> <section anchor="s12"><name>12 to 13</name> <ul spacing="compact"> <li>Update references to numbered sections of <xref target="I-D.ietf-dmarc-dmarcbis"></xref>online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref></li> <li>Clarify potential information disclosures when failure reportslet us know if any changes aresent</li> <li>Minor edits for readability and clarity</li> </ul> </section> <section anchor="s13"><name>13 to 14</name> <ul spacing="compact"> <li>In the introduction (last paragraph) mention that the purpose is twofold, debug and anti-abuse.</li> <li>In Section 2 (2nd paragraph) clarify that failure reports allow better determining the failure reason.</li> </ul> </section> <section anchor="s14"><name>14 to 15</name> <ul spacing="compact"> <li>Expanded Privacy Considerations section as discussed on list.</li> <li>Add tentative IANA Consideration subsections.</li> </ul> </section> <section anchor="s15"><name>15 to 16</name> <ul spacing="compact"> <li>Qualification of RFCs 6651/2 in Section 3.</li> <li>Spell "Auth-Failure" at bullet 3 of Section 4.</li> <li>Cite RFC 6590 when mentioning redaction.</li> <li>s/using the wrong sending path/failing authentication/.</li> <li>Remove unnecessary IANA Considerations.</li> </ul> </section> <section anchor="s16"><name>16 to 17</name> <ul spacing="compact"> <li>Remove the last paragraphneeded. Updates ofSecority Considerations.</li> </ul> </section> <section anchor="s17"><name>17 to 18</name> <ul spacing="compact"> <li>Reword the first purpose (Intro) and cite aggregate-reporting.</li> <li>Forward reference to Privacy Consideration.</li> <li>s/fo=/"fo"/, /ruf=/ruf/, /urls/URIs/.</li> <li>Specify parent registrythis nature typically result inIANA Considerations.</li> </ul> </section> <section anchor="s18"><name>18 to 19</name> <ul spacing="compact"> <li>Remove the term "scalable" from Abstract and Introduction.</li> <li>s/Sender Domain/Domain Owner/.</li> <li>Reference to dmarcbis, section 3.2 on its own line.</li> <li>Remove the phrase (sometimes referred to as "forensic reports").</li> <li>Notemore precise language, which is helpful for readers. Note thatDomain Owner can use dot-forward toour script did notdecalre consumer.</li> <li>Mention we could have encrypted the example.</li> <li>Don't mention MX.</li> </ul> </section> <section anchor="s19"><name>19 to 20</name> <ul spacing="compact"> <li>Replace "dot-forward" with a periphrasis to downplay final destination.</li> </ul> </section> <section anchor="s20"><name>20 to 21</name> <ul spacing="compact"> <li>Move the last paragraph of Section 2 to Security Considerations.</li> <li>Explicitly say we obsolete 7489 and update 6591flag any words inthe abstract.</li> <li>Reword "Withoutparticular, but thischeck,should still be reviewed as abad actor ..." in Section 5.</li> <li>Fix IANA request.</li> <li>Mention RFC 6591 in Terminology (Section 1.1).</li> </ul> </section> <section anchor="s21"><name>21 to 22</name> <ul spacing="compact"> <li>Reword obsoleting sentence in the abstract and move it to Section 1.2.</li> </ul> </section> <section anchor="s22"><name>22 to 23</name> <ul spacing="compact"> <li>Merge Med's pull request</li> </ul> </section> <section anchor="s23"><name>23 to 24</name> <ul spacing="compact"> <li>"Defang" issue.</li> <li>Avoid using "defined by" twice (Section 2, paragraph 5).</li> <li>Fix the normative part of rate-limiting (Section 2, paragraph 6).</li> <li>Recommend (non-2119) to rate limit (Section 5.1, paragraph 2).</li> <li>Reference RFC 5322 (Section 4, bullet 2).</li> </ul> </section> </section>best practice. --> </back> </rfc>