rfc9991.original.xml   rfc9991.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version='1.0' encoding='utf-8'?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
or - mmark.miek.nl" --> cName="draft-ietf-dmarc-failure-reporting-25" number="9991" submissionType="IETF
<rfc version="3" ipr="trust200902" docName="draft-ietf-dmarc-failure-reporting-2 " category="std" xml:lang="en" updates="6591" obsoletes="7489" tocInclude="true"
5" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.or consensus="true" symRefs="true" sortRefs="true" prepTime="2026-05-19T20:41:17"
g/2001/XInclude" updates="6591" obsoletes="7489" indexInclude="true" consensus=" indexInclude="true" scripts="Common,Latin" tocDepth="3">
true"> <link href="https://datatracker.ietf.org/doc/draft-ietf-dmarc-failure-reportin
g-25" rel="prev"/>
<front> <link href="https://dx.doi.org/10.17487/rfc9991" rel="alternate"/>
<title abbrev="DMARC Failure Reporting">Domain-based Message Authentication, Rep <link href="urn:issn:2070-1721" rel="alternate"/>
orting, and Conformance (DMARC) Failure Reporting</title><seriesInfo value="draf <front>
t-ietf-dmarc-failure-reporting-25" stream="IETF" status="standard" name="Interne <title abbrev="DMARC Failure Reporting">Domain-Based Message Authentication,
t-Draft"></seriesInfo> Reporting, and Conformance (DMARC) Failure Reporting</title>
<author initials="S." surname="Jones (ed)" fullname="Steven M Jones"><organizati <seriesInfo name="RFC" value="9991" stream="IETF"/>
on>DMARC.org</organization><address><postal><street></street> <author initials="S." surname="Jones" fullname="Steven M. Jones" role="edito
</postal><email>smj@dmarc.org</email> r">
</address></author><author initials="A." surname="Vesely (ed)" fullname="Alessan <organization showOnFrontPage="true">DMARC.org</organization>
dro Vesely"><organization>Tana</organization><address><postal><street></street> <address>
</postal><email>vesely@tana.it</email> <email>smj@dmarc.org</email>
</address></author><date/> </address>
<area>Application</area> </author>
<workgroup>DMARC</workgroup> <author initials="A." surname="Vesely" fullname="Alessandro Vesely" role="ed
itor">
<abstract> <organization showOnFrontPage="true">Tana</organization>
<t>Domain-based Message Authentication, Reporting, and Conformance <address>
<email>vesely@tana.it</email>
</address>
</author>
<date month="05" year="2026"/>
<area>ART</area>
<workgroup>dmarc</workgroup>
<keyword>DMARC</keyword>
<keyword>DKIM</keyword>
<keyword>SPF</keyword>
<keyword>feedback</keyword>
<keyword>Email Authentication</keyword>
<keyword>Failure report</keyword>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">Domain-based Message Authentication,
Reporting, and Conformance
(DMARC) is a mechanism by which a Domain Owner can request (DMARC) is a mechanism by which a Domain Owner can request
feedback about email messages using their domain in the From: address feedback about email messages using their domain in the From: address
field. This document describes &quot;failure reports&quot;, or &quot;failed mes field. This document describes "failure reports", or "failed message
sage reports", which provide details about individual messages that failed
reports&quot;, which provide details about individual messages that failed
to authenticate according to the DMARC mechanism.</t> to authenticate according to the DMARC mechanism.</t>
<t>This document updates RFC 6591 and obsoletes RFC 7489.</t> <t indent="0" pn="section-abstract-2">This document updates RFC 6591 and o
</abstract> bsoletes RFC 7489.</t>
</abstract>
</front> <boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<middle> "exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
<section anchor="introduction"><name>Introduction</name> >
<t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: <t indent="0" pn="section-boilerplate.1-1">
The source for this draft is maintained in GitHub at: This is an Internet Standards Track document.
<eref target="https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reportin </t>
g">https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting</eref></t <t indent="0" pn="section-boilerplate.1-2">
> This document is a product of the Internet Engineering Task Force
<t>Domain-based Message Authentication, Reporting, and Conformance (DMARC) (IETF). It represents the consensus of the IETF community. It has
<xref target="I-D.ietf-dmarc-dmarcbis"></xref> is a mechanism by which a mail-or received public review and has been approved for publication by
iginating the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9991" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) 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.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-te
rminology">Terminology</xref></t>
</li>
<li pn="section-toc.1-1.1.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><
xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.
2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-do
cument-status">Document Status</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-dmarc-failure-reports">DMARC Failu
re Reports</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-other-failure-reports">Other Failu
re Reports</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-reporting-format-update">Reporting
Format Update</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-verifying-external-destinat">Verif
ying External Destinations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-transport">Transport</
xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-feedback-report-header
-fiel">Feedback Report Header Fields Registry Update</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-privacy-considerations">Privacy Co
nsiderations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-data-exposure-consider
ation">Data Exposure Considerations</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-report-recipients">Rep
ort Recipients</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent=
"7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-additional-damage">Add
itional Damage</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-denial-of-service">Den
ial of Service</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-example-failure
-report">Example Failure Report</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="introduction" numbered="true" removeInRFC="false" toc="incl
ude" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">Domain-based Message Authentication, Report
ing, and Conformance (DMARC)
<xref target="RFC9989" format="default" sectionFormat="of" derivedContent="RFC99
89"/> is a mechanism by which a mail-originating
organization can express domain-level policies and preferences for organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that can be used by a message validation, disposition, and reporting that can be used by a
mail-receiving organization to improve mail handling. This document mail-receiving organization to improve mail handling. This document
focuses on one type of reporting that can be requested under DMARC.</t> focuses on one type of reporting that can be requested under DMARC.</t>
<t>Failure reports provide detailed information about the failure of a <t indent="0" pn="section-1-2">Failure reports provide detailed informatio
single message, or a group of similar messages failing for the same n about the failure of a
reason. Their purpose is twofold. On the one hand they are meant to 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 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
<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>). On the other hand, they can <xref target="RFC9990" format="default" sectionFormat="of" derivedContent="RFC99 90"/>). On the other hand, they can
allow the Domain Owner to quickly identify and address harmful allow the Domain Owner to quickly identify and address harmful
messages involving direct domain abuse. It is important to note that messages involving direct domain abuse. It is important to note that
these reports can contain the header fields or sometimes the entire these reports can contain the header fields or sometimes the entire
content of a failed message, which may contain personally identifiable content of a failed message, which may contain Personally Identifiable
information (PII). The potential disclosure of PII should be considered Information (PII). The potential disclosure of PII should be considered
when deciding whether to request failure reports as a Domain Owner, or when deciding whether to request failure reports as a Domain Owner, or
what information to include or redact in failure reports when creating what information to include or redact in failure reports when creating
them as a Mail Receiver, or whether to create failure reports at all. them as a Mail Receiver, or whether to create failure reports at all.
Refer to <xref target="privacy-considerations"></xref> for more discussion on pr Refer to <xref target="privacy-considerations" format="default" sectionFormat="o
ivacy considerations.</t> f" derivedContent="Section 7"/> for more discussion on privacy considerations.</
t>
<section anchor="terminology"><name>Terminology</name> <section anchor="terminology" numbered="true" removeInRFC="false" toc="inc
<t>There are a number of terms defined in lude" pn="section-1.1">
<xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="of" relative="#" section=" <name slugifiedName="name-terminology">Terminology</name>
3.2"></xref> <t indent="0" pn="section-1.1-1">There are a number of terms defined in
<xref target="RFC9989" sectionFormat="of" section="3.2" format="default" derived
Link="https://rfc-editor.org/rfc/rfc9989#section-3.2" derivedContent="RFC9989"/>
that are used within this document. Understanding those that are used within this document. Understanding those
definitions will aid in reading this document.</t> definitions will aid in reading this document.</t>
<t>The format of DMARC failure reports is derived from Authentication <t indent="0" pn="section-1.1-2">The format of DMARC failure reports is
Failure Reporting Using the Abuse Reporting Format (<xref target="RFC6591"></xre derived from "Authentication
f>) and Failure Reporting Using the Abuse Reporting Format" <xref target="RFC6591" forma
t="default" sectionFormat="of" derivedContent="RFC6591"/>, and
the terms defined there are used here.</t> the terms defined there are used here.</t>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, & <t indent="0" pn="section-1.1-3">
quot;SHALL&quot;, &quot;SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
&quot;NOT RECOMMENDED&quot;, D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
&quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted OT RECOMMENDED</bcp14>",
as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref be interpreted as
> when, and only when, they described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
appear in all capitals, as shown here.</t> f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
</section> mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
<section anchor="document-status"><name>Document Status</name> </t>
<t>This document, in part, along with DMARCbis <xref target="I-D.ietf-dmarc-dmar </section>
cbis"></xref> <section anchor="document-status" numbered="true" removeInRFC="false" toc=
DMARCbis Aggregate Reporting <xref target="I-D.ietf-dmarc-aggregate-reporting">< "include" pn="section-1.2">
/xref>, <name slugifiedName="name-document-status">Document Status</name>
obsoletes and replaces <xref target="RFC7489"></xref>.</t> <t indent="0" pn="section-1.2-1">This document, in part, along with <xre
</section> f target="RFC9989" format="default" sectionFormat="of" derivedContent="RFC9989"/
</section> > and <xref target="RFC9990" format="default" sectionFormat="of" derivedContent=
"RFC9990"/>,
<section anchor="failure-reports"><name>DMARC Failure Reports</name> obsoletes and replaces <xref target="RFC7489" format="default" sectionFormat="of
<t>Besides the header fields or the entire contents of a failed message, failure " derivedContent="RFC7489"/>.</t>
</section>
</section>
<section anchor="failure-reports" numbered="true" removeInRFC="false" toc="i
nclude" pn="section-2">
<name slugifiedName="name-dmarc-failure-reports">DMARC Failure Reports</na
me>
<t indent="0" pn="section-2-1">Besides the header fields or the entire con
tents of a failed message, failure
reports supply details about transmission and DMARC authentication, reports supply details about transmission and DMARC authentication,
which may aid a Domain Owner in determining the cause of an authentication failu re.</t> which may aid a Domain Owner in determining the cause of an authentication failu re.</t>
<t>Failure reports are normally generated and sent almost immediately <t indent="0" pn="section-2-2">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 notifying for an aggregate report, these reports are useful for quickly notifying
the Domain Owners when there is an authentication failure. Failure the Domain Owners when there is an authentication failure. Failure
reports also provide more information about the failed message than is reports also provide more information about the failed message than is
available in an aggregate report. This allows the failure report available in an aggregate report. This allows the failure report
consumer to better determine whether the failure is of a message that 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 the Domain Owner intended to authenticate or one for which use of its
domain was not authorized.</t> domain was not authorized.</t>
<t>These reports should include as much of the message header fields and body as <t indent="0" pn="section-2-3">These reports should include as much of the message header fields and body as
possible, consistent with the reporting party's privacy policies, to possible, consistent with the reporting party's privacy policies, to
enable the Domain Owner to diagnose the authentication failure.</t> enable the Domain Owner to diagnose the authentication failure.</t>
<t>When a Domain Owner requests failure reports for the purpose of <t indent="0" pn="section-2-4">When a Domain Owner requests failure report s 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 <xref target="RFC6591"></xref>; this document updates that r format described in <xref target="RFC6591" format="default" sectionFormat="of" d
eporting erivedContent="RFC6591"/>; this document updates that reporting
format, as described in <xref target="reporting-format-update"></xref>.</t> format, as described in <xref target="reporting-format-update" format="default"
<t>The destination(s) to which failure reports are sent, and options for when sectionFormat="of" derivedContent="Section 4"/>.</t>
they will be sent, are defined by the &quot;ruf&quot; and &quot;fo&quot; tags as <t indent="0" pn="section-2-5">The destination(s) to which failure reports
provided are sent, and options for when
in <xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="of" relative="#" sectio they will be sent, are defined by the "ruf" and "fo" tags as provided
n="4.7"></xref>.</t> in <xref target="RFC9989" sectionFormat="of" section="4.7" format="default" deri
<t>When multiple URIs are provided to receive failure reports, the vedLink="https://rfc-editor.org/rfc/rfc9989#section-4.7" derivedContent="RFC9989
"/>.</t>
<t indent="0" pn="section-2-6">When multiple Uniform Resource Identifiers
(URIs) are provided to receive failure reports, the
report generator <bcp14>MUST</bcp14> make an attempt to deliver to each of them. report generator <bcp14>MUST</bcp14> make an attempt to deliver to each of them.
External destinations <bcp14>MUST</bcp14> be verified, see <xref target="verifyi External destinations <bcp14>MUST</bcp14> be verified (see <xref target="verifyi
ng-external-destinations"></xref>. ng-external-destinations" format="default" sectionFormat="of" derivedContent="Se
Report generators <bcp14>MUST NOT</bcp14> consider &quot;ruf&quot; tags in DMARC ction 5"/>).
Policy Records having a &quot;psd=y&quot; Report generators <bcp14>MUST NOT</bcp14> consider "ruf" tags in DMARC Policy Re
cords that have a "psd=y"
tag, unless there are specific agreements between the interested parties.</t> tag, unless there are specific agreements between the interested parties.</t>
<t>Report generators <bcp14>MUST</bcp14> implement a rate-limit on outgoing repo <t indent="0" pn="section-2-7">Report generators <bcp14>MUST</bcp14> imple
rts ment a rate-limit on outgoing reports
so as not to flood report consumers with excessive reports, which would so as not to flood Report Consumers with excessive reports, which would
allow denial-of-service; see <xref target="dos-attacks"></xref>.</t> allow denial of service (see <xref target="dos-attacks" format="default" section
</section> Format="of" derivedContent="Section 8.1"/>).</t>
</section>
<section anchor="other-reports"><name>Other Failure Reports</name> <section anchor="other-reports" numbered="true" removeInRFC="false" toc="inc
<t>This document describes only DMARC failure reports. DKIM failure lude" pn="section-3">
reports and SPF failure reports are described in <xref target="RFC6591"></xref>. <name slugifiedName="name-other-failure-reports">Other Failure Reports</na
A Mail me>
Receiver generating DMARC failure reports <bcp14>MAY</bcp14> issue failure repor <t indent="0" pn="section-3-1">This document only describes DMARC failure
ts reports. DomainKeys Identified Mail (DKIM) failure
specific to the failed authentication mechanism instead of, or in reports and Sender Policy Framework (SPF) failure reports are described in <xref
addition to, DMARC failure reports, based on its own policy, the target="RFC6591" format="default" sectionFormat="of" derivedContent="RFC6591"/>
failure in question, and the content of the &quot;fo&quot; tag in the retrieved . A Mail
Receiver that generates DMARC failure reports <bcp14>MAY</bcp14> choose to issue
failure reports
of the type specific to the authentication mechanism that failed instead of, or
in
addition to, the DMARC failure report type described here. The Receiver <bcp14>S
HALL</bcp14> determine which
failure report types, if any, to transmit based on its own policy, the failure i
n question, and the content of the "fo" tag in the retrieved
DMARC Policy Record.</t> DMARC Policy Record.</t>
<t>Note that DKIM failure reports and SPF failure reports can also be <t indent="0" pn="section-3-2">Note that DKIM failure reports and SPF fail
requested using the methods described in <xref target="RFC6651"></xref> and <xre ure reports can also be
f target="RFC6652"></xref>, requested using the methods described in <xref target="RFC6651" format="default"
respectively. Report Generators are free to follow any of the sectionFormat="of" derivedContent="RFC6651"/> and <xref target="RFC6652" format
="default" sectionFormat="of" derivedContent="RFC6652"/>,
respectively. Report generators are free to follow any of the
specifications.</t> specifications.</t>
</section> </section>
<section anchor="reporting-format-update" numbered="true" removeInRFC="false
<section anchor="reporting-format-update"><name>Reporting Format Update</name> " toc="include" pn="section-4">
<t>Operators implementing this specification also implement an augmented <name slugifiedName="name-reporting-format-update">Reporting Format Update
version of <xref target="RFC6591"></xref> as follows:</t> </name>
<t indent="0" pn="section-4-1">Operators implementing this specification a
<ol> lso implement an augmented
<li><t>A DMARC failure report includes the following ARF header fields, version of failure reporting described in <xref target="RFC6591" format="default
" sectionFormat="of" derivedContent="RFC6591"/> as follows:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4-2"
>
<li pn="section-4-2.1" derivedCounter="1.">
<t indent="0" pn="section-4-2.1.1">A DMARC failure report includes the
following Abuse Reporting Format (ARF) header fields,
with the indicated normative requirement levels:</t> with the indicated normative requirement levels:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section
<ul> -4-2.1.2">
<li><t>Identity-Alignment (<bcp14>REQUIRED</bcp14>; defined below)</t> <li pn="section-4-2.1.2.1">
</li> <t indent="0" pn="section-4-2.1.2.1.1">Identity-Alignment (<bcp14>
<li><t>Delivery-Result (<bcp14>OPTIONAL</bcp14>)</t> REQUIRED</bcp14>; defined below)</t>
</li> </li>
<li><t>DKIM-Domain, DKIM-Identity, DKIM-Selector (<bcp14>REQUIRED</bcp14> for DK <li pn="section-4-2.1.2.2">
IM failures of an aligned identifier)</t> <t indent="0" pn="section-4-2.1.2.2.1">Delivery-Result (<bcp14>OPT
</li> IONAL</bcp14>)</t>
<li><t>DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (<bcp14>OPTIONAL</bcp1 </li>
4> if reporting a DKIM failure)</t> <li pn="section-4-2.1.2.3">
</li> <t indent="0" pn="section-4-2.1.2.3.1">DKIM-Domain, DKIM-Identity,
<li><t>SPF-DNS (<bcp14>REQUIRED</bcp14> for SPF failure of an aligned identifier DKIM-Selector (<bcp14>REQUIRED</bcp14> for DKIM failures of an aligned identifi
)</t> er)</t>
</li> </li>
</ul></li> <li pn="section-4-2.1.2.4">
<li><t>The &quot;Identity-Alignment&quot; field is defined to contain a <t indent="0" pn="section-4-2.1.2.4.1">DKIM-Canonicalized-Header,
comma-separated list of authentication mechanism names that failed to DKIM-Canonicalized-Body (<bcp14>OPTIONAL</bcp14> if reporting a DKIM failure)</t
authenticate an aligned identity, or the keyword &quot;none&quot; if all of the >
attempted methods were successful at authenticating an aligned </li>
identity. ABNF (<xref target="RFC5234"></xref>, importing CFWS from <xref targe <li pn="section-4-2.1.2.5">
t="RFC5322"></xref>):</t> <t indent="0" pn="section-4-2.1.2.5.1">SPF-DNS (<bcp14>REQUIRED</b
</li> cp14> for SPF failure of an aligned identifier)</t>
</ol> </li>
</ul>
<sourcecode type="ABNF">id-align = &quot;Identity-Alignment:&quot; [CFWS] </li>
( &quot;none&quot; / <li pn="section-4-2.2" derivedCounter="2.">
dmarc-method *( [CFWS] &quot;,&quot; [CFWS] dmarc-method ) ) <t indent="0" pn="section-4-2.2.1">The Identity-Alignment field is def
ined 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 succ
essful at authenticating an aligned identity. Here is the ABNF <xref target="RF
C5234" format="default" sectionFormat="of" derivedContent="RFC5234"/> (importing
comments and/or folding white space (CFWS) from <xref target="RFC5322" format="
default" sectionFormat="of" derivedContent="RFC5322"/>):</t>
<sourcecode type="abnf" markers="false" pn="section-4-2.2.2">
id-align = "Identity-Alignment:" [CFWS]
( "none" /
dmarc-method
*( [CFWS] "," [CFWS] dmarc-method ) )
[CFWS] [CFWS]
dmarc-method = ( &quot;dkim&quot; / &quot;spf&quot; ) dmarc-method = ( "dkim" / "spf" )
; each may appear at most once in an id-align ; each may appear at most once in an id-align</sourcecode>
</sourcecode> </li>
<li pn="section-4-2.3" derivedCounter="3.">Authentication Failure Type "
<ol spacing="compact" start="3"> dmarc" is defined for the Auth-Failure
<li>Authentication Failure Type &quot;dmarc&quot; is defined for the Auth-Failur
e
field, which is to be used when a failure report is generated because field, which is to be used when a failure report is generated because
some or all of the authentication mechanisms failed to produce aligned some or all of the authentication mechanisms failed to produce aligned
identifiers. Note that a failure report generator <bcp14>MAY</bcp14> also identifiers. Note that a failure report generator <bcp14>MAY</bcp14> also
independently produce an ARF message for any or all of the underlying independently produce an ARF message for any or all of the underlying
authentication methods.</li> authentication methods.</li>
</ol> </ol>
</section> </section>
<section anchor="verifying-external-destinations" numbered="true" removeInRF
<section anchor="verifying-external-destinations"><name>Verifying External Desti C="false" toc="include" pn="section-5">
nations</name> <name slugifiedName="name-verifying-external-destinat">Verifying External
<t>It is possible to specify destinations for failure reports that are Destinations</name>
<t indent="0" pn="section-5-1">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 was requesting the reports. These destinations are
commonly referred to as &quot;external destinations&quot; and may represent a commonly referred to as "external destinations" and may represent a
different domain controlled by the same organization, a contracted different domain controlled by the same organization, a contracted
report processing service, or some other arrangement.</t> report processing service, or some other arrangement.</t>
<t>In case of external destinations, a Mail Receiver who <t indent="0" pn="section-5-2">In case of external destinations, a Mail Re ceiver who
generates failure reports <bcp14>MUST</bcp14> use the Verifying External Destina tions generates failure reports <bcp14>MUST</bcp14> use the Verifying External Destina tions
procedure described in <xref target="I-D.ietf-dmarc-aggregate-reporting" section procedure described in <xref target="RFC9990" sectionFormat="of" section="4" for
Format="of" relative="#" section="4"></xref>, mat="default" derivedLink="https://rfc-editor.org/rfc/rfc9990#section-4" derived
substituting the &quot;ruf&quot; tag where the &quot;rua&quot; tag appears in th Content="RFC9990"/>,
at procedure.</t> substituting the "ruf" tag where the "rua" tag appears in that procedure.</t>
<t>This prevents a bad actor from publishing a DMARC Policy Record <t indent="0" pn="section-5-3">This prevents a bad actor from publishing a
requesting failure reports to an external destination, and DMARC Policy Record
requesting failure reports to an external destination and
then deliberately sending messages that will generate failure reports then deliberately sending messages that will generate failure reports
as a form of abuse. It also prevents a Domain Owner from unilaterally as a 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 unwanted failure reports, forcing the external destination to deal with unwanted
messages and potential privacy issues.</t> messages and potential privacy issues.</t>
<section anchor="transport" numbered="true" removeInRFC="false" toc="inclu
<section anchor="transport"><name>Transport</name> de" pn="section-5.1">
<t>Email streams carrying DMARC failure reports <bcp14>SHOULD</bcp14> be DMARC-a <name slugifiedName="name-transport">Transport</name>
ligned.</t> <t indent="0" pn="section-5.1-1">Email streams carrying DMARC failure re
<t>We recommend that reporters set a reasonable rate-limit for the number ports <bcp14>SHOULD</bcp14> be DMARC-aligned.</t>
<t indent="0" pn="section-5.1-2">We recommend that reporters set a reaso
nable rate-limit for the number
of failure reports sent of failure reports sent
to any recipient to avoid overloading recipient systems. to any recipient to avoid overloading recipient systems.
Unaligned reports may in turn produce subsequent failure reports that could Unaligned reports may in turn produce subsequent failure reports that could
cause mail loops.</t> cause mail loops.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations" numbered="true" removeInRFC="false" to
<section anchor="iana-considerations"><name>IANA Considerations</name> c="include" pn="section-6">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<section anchor="feedback-report-header-fields-registry-update"><name>Feedback R <section anchor="feedback-report-header-fields-registry-update" numbered="
eport Header Fields Registry Update</name> true" removeInRFC="false" toc="include" pn="section-6.1">
<t>IANA is requested to change the &quot;Identity-Alignment&quot; entry in the <name slugifiedName="name-feedback-report-header-fiel">Feedback Report H
&quot;Feedback Report Header Fields&quot; registry, which is part of the eader Fields Registry Update</name>
&quot;Messaging Abuse Reporting Format (MARF) Parameters&quot; registry group, a <t indent="0" pn="section-6.1-1">IANA has updated the reference and desc
s ription for the "Identity-Alignment" entry in the
follows:</t> "Feedback Report Header Fields" registry within the
"Messaging Abuse Reporting Format (MARF) Parameters" registry group, as follows:
<ul> </t>
<li><t>&quot;Reference&quot; should change to this document</t> <dl spacing="compact" indent="3" newline="false" pn="section-6.1-2">
</li> <dt pn="section-6.1-2.1">Field Name:</dt>
<li><t>&quot;Description&quot; should change to &quot;a list of authentication m <dd pn="section-6.1-2.2">Identity-Alignment</dd>
echanism <dt pn="section-6.1-2.3">Description:</dt>
names that failed to authenticate an aligned identity, or 'none' if all <dd pn="section-6.1-2.4">a list of authentication mechanism names that
were successful&quot;.</t> failed to authenticate an aligned identity, or "none" if all were successful</d
</li> d>
</ul> <dt pn="section-6.1-2.5">Multiple Appearances:</dt>
</section> <dd pn="section-6.1-2.6">No</dd>
</section> <dt pn="section-6.1-2.7">Related "Feedback-Type":</dt>
<dd pn="section-6.1-2.8">auth-failure</dd>
<section anchor="privacy-considerations"><name>Privacy Considerations</name> <dt pn="section-6.1-2.9">Reference:</dt>
<t>The generation and transmission of DMARC failure reports raise <dd pn="section-6.1-2.10">RFC 9991</dd>
<dt pn="section-6.1-2.11">Status:</dt>
<dd pn="section-6.1-2.12">current</dd>
</dl>
</section>
</section>
<section anchor="privacy-considerations" numbered="true" removeInRFC="false"
toc="include" pn="section-7">
<name slugifiedName="name-privacy-considerations">Privacy Considerations</
name>
<t indent="0" pn="section-7-1">The generation and transmission of DMARC fa
ilure reports raise
significant privacy concerns that must be carefully considered before significant privacy concerns that must be carefully considered before
deployment.</t> deployment.</t>
<t>Given these factors, many large-scale providers limit or entirely <t indent="0" pn="section-7-2">Given these factors, many large-scale provi ders 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:</t> reporting are strongly encouraged to:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-3
<ul spacing="compact"> ">
<li>Limit the scope and duration of use to targeted diagnostic activities.</li> <li pn="section-7-3.1">Limit the scope and duration of use to targeted d
<li>Ensure that reporting URIs are carefully controlled and validated.</li> iagnostic activities;</li>
<li>Apply minimization techniques, such as redaction of message bodies <li pn="section-7-3.2">Ensure that reporting URIs are carefully controll
and header fields, to reduce sensitive data exposure.</li> ed and validated;</li>
<li>Always transmit reports over secure channels.</li> <li pn="section-7-3.3">Apply minimization techniques, such as redaction
</ul> of message bodies
<t>In summary, while DMARC failure reports can offer diagnostic value, the and header fields, to reduce sensitive data exposure; </li>
<li pn="section-7-3.4">Always transmit reports over secure channels.</li
>
</ul>
<t indent="0" pn="section-7-4">In summary, while DMARC failure reports can
offer diagnostic value, the
associated privacy concerns have led many operators to restrict their associated privacy concerns have led many operators to restrict their
use. Aggregate reports remain the recommended mechanism for gaining use. Aggregate reports remain the recommended mechanism for gaining
visibility into authentication results while preserving the visibility into authentication results while preserving the
confidentiality of end-user communications.</t> confidentiality of end-user communications.</t>
<t>Particular privacy-specific issues are explored below.</t> <t indent="0" pn="section-7-5">Particular privacy-specific issues are expl
ored below.</t>
<section anchor="data-exposure-considerations"><name>Data Exposure Consideration <section anchor="data-exposure-considerations" numbered="true" removeInRFC
s</name> ="false" toc="include" pn="section-7.1">
<t>Failure reports may include PII and non-public information (NPI) from <name slugifiedName="name-data-exposure-consideration">Data Exposure Con
siderations</name>
<t indent="0" pn="section-7.1-1">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 addresses), expose sender and recipient identifiers (e.g., RFC5322.From addresses),
and although the <xref target="RFC5965"></xref> format used for failed-message r and although the <xref target="RFC5965" format="default" sectionFormat="of" deri
eporting vedContent="RFC5965"/> format used for failed-message reporting
supports redaction (<xref target="RFC6590"></xref>), failed-message reporting is supports redaction <xref target="RFC6590" format="default" sectionFormat="of" de
capable of rivedContent="RFC6590"/>, failed-message reporting is capable of
exposing the entire message to the Report Consumer. They may also exposing the entire message to the Report Consumer. They may also
expose PII, sensitive business data, or other confidential 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 for receivers. Examples include product launches, termination notices for
employees, or calendar data. Even innocuous-seeming failures (such as employees, or calendar data. Even innocuous-seeming failures (such as
malformed or &quot;broken&quot; calendar invitations) can result in the leakage malformed or "broken" calendar invitations) can result in the leakage
of private communications.</t> of private communications.</t>
<t>Domain Owners requesting reports will receive information about mail <t indent="0" pn="section-7.1-2">Domain Owners requesting reports will r eceive information about mail
using their domain, but which they did not actually cause to be sent. using their domain, but which they did not actually cause to be sent.
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 messages, but it might also expose PII or NPI from legitimate messages
mistakenly or accidentally failing authentication.</t> mistakenly or accidentally failing authentication.</t>
<t>Information about the final destination of mail, where it might <t indent="0" pn="section-7.1-3">Information about the final destination of mail, where it might
otherwise be obscured by intermediate systems, may be exposed through a otherwise be obscured by intermediate systems, may be exposed through a
failure report. A commonly cited example is exposure of members of 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 Owner list members. Those failure reports would be sent to the Domain Owner
of the list member posting the message, or their delegated Report of the list member posting the message or their delegated Report
Consumer(s).</t> Consumer(s).</t>
<t>Similarly, when message forwarding arrangements exist, Domain Owners <t indent="0" pn="section-7.1-4">Similarly, when message forwarding arra ngements 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.</t> Owner may now become visible.</t>
</section> </section>
<section anchor="report-recipients" numbered="true" removeInRFC="false" to
<section anchor="report-recipients"><name>Report Recipients</name> c="include" pn="section-7.2">
<t>A DMARC Policy Record can specify that reports should be sent to a <name slugifiedName="name-report-recipients">Report Recipients</name>
<t indent="0" pn="section-7.2-1">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 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 done when the Domain Owner sends reports to an entity to monitor mail
streams for deliverability, performance issues, or abuse. Receipt of streams for deliverability, performance issues, or abuse. Receipt of
such data by third parties may or may not be permitted by the Mail such data by third parties may or may not be permitted by the Mail
Receiver's privacy policy, terms of use, et cetera. Domain Owners and Receiver's privacy policy, terms of use, etc. Domain Owners and
Mail Receivers should both review and understand whether their own Mail Receivers should both review and understand whether their own
internal policies constrain the use and transmission of DMARC internal policies constrain the use and transmission of DMARC
reporting.</t> reporting.</t>
<t>Some potential exists for Report Consumers to perform traffic analysis, <t indent="0" pn="section-7.2-2">Some potential exists for Report Consum ers to perform traffic analysis,
making it possible to obtain metadata about the Mail Receiver's making it possible to obtain metadata about the Mail Receiver's
traffic. In addition to verifying compliance with policies, Mail traffic. In addition to verifying compliance with policies, Mail
Receivers need to consider that before sending reports to a third Receivers need to consider that before sending reports to a third
party. On the other hand, a Domain Owner may publish a destination party. On the other hand, a Domain Owner may publish a destination
address that appears to be an Internal Report Consumer but is actually address that appears to be an Internal Report Consumer but is actually
a forwarding address; in this case, the final destination of a report a forwarding address; in this case, the final destination of a report
is not guaranteed.</t> is not guaranteed.</t>
</section> </section>
<section anchor="additional-damage" numbered="true" removeInRFC="false" to
<section anchor="additional-damage"><name>Additional Damage</name> c="include" pn="section-7.3">
<t>The risks associated with failure reports are compounded by volume and <name slugifiedName="name-additional-damage">Additional Damage</name>
<t indent="0" pn="section-7.3-1">The risks associated with failure repor
ts are compounded by volume and
content distribution concerns. Partially or unredacted reports may content distribution concerns. Partially or unredacted reports may
propagate large amounts of spam, phishing, or malware content, all of propagate large amounts of spam, phishing, or malware content, all of
which may require special handling by Report Consumers or other which may require special handling by Report Consumers or other
recipients to avoid incidents. This underscores the need to avoid recipients to avoid incidents. This underscores the need to avoid
misconfiguration of the destinations in the &quot;ruf&quot; reporting URIs, and misconfiguration of the destinations in the "ruf" reporting URIs and
the suggestions for redaction in this document, for example using the the suggestions for redaction in this document, for example, using the
method described in <xref target="RFC6590"></xref>. All of these concerns are method described in <xref target="RFC6590" format="default" sectionFormat="of" d
erivedContent="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:</t> following steps should be considered:</t>
<t>By report generators:</t> <t indent="0" pn="section-7.3-2">By report generators:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7
<ul spacing="compact"> .3-3">
<li>Help prevent accidental access to potentially-malicious URIs by substituting <li pn="section-7.3-3.1">Help prevent accidental access to potentially
hxxp for http;</li> malicious URIs by substituting hxxp for http;</li>
<li>remove attachments which could embed malicious payload.</li> <li pn="section-7.3-3.2">Remove attachments that could embed malicious
</ul> payload.</li>
<t>By report consumers:</t> </ul>
<t indent="0" pn="section-7.3-4">By report consumers:</t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7
<li>isolate report streams from other mail streams;</li> .3-5">
<li>use sandboxes in evaluating failure reports;</li> <li pn="section-7.3-5.1">Isolate report streams from other mail stream
<li>use network segmentation;</li> s;</li>
<li>limit access to failure reports to authorized individuals with <li pn="section-7.3-5.2">Use sandboxes in evaluating failure reports;<
/li>
<li pn="section-7.3-5.3">Use network segmentation;</li>
<li pn="section-7.3-5.4">Limit access to failure reports to authorized
individuals with
appropriate security training.</li> appropriate security training.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="security-considerations" numbered="true" removeInRFC="false
<section anchor="security-considerations"><name>Security Considerations</name> " toc="include" pn="section-8">
<t>While reviewing this document and its Security Considerations, the <name slugifiedName="name-security-considerations">Security Considerations
reader should also review the Privacy Considerations above, as well as </name>
the Privacy Considerations and Security Considerations in sections <t indent="0" pn="section-8-1">While reviewing this document and its secur
<xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="bare" relative="#" section ity considerations, the
="10"></xref> and <xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="bare" re reader should also review the privacy considerations above, as well as
lative="#" section="11"></xref> of the privacy considerations and security considerations in Sections
<xref target="I-D.ietf-dmarc-dmarcbis"></xref>; and in sections <xref target="RFC9989" sectionFormat="bare" section="10" format="default" derive
<xref target="I-D.ietf-dmarc-aggregate-reporting" sectionFormat="bare" relative= dLink="https://rfc-editor.org/rfc/rfc9989#section-10" derivedContent="RFC9989"/>
"#" section="7"></xref> and and <xref target="RFC9989" sectionFormat="bare" section="11" format="default" d
<xref target="I-D.ietf-dmarc-aggregate-reporting" sectionFormat="bare" relative= erivedLink="https://rfc-editor.org/rfc/rfc9989#section-11" derivedContent="RFC99
"#" section="8"></xref> of 89"/> of
<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t> <xref target="RFC9989" format="default" sectionFormat="of" derivedContent="RFC99
89"/> and in Sections
<section anchor="dos-attacks"><name>Denial of Service</name> <xref target="RFC9990" sectionFormat="bare" section="7" format="default" derived
<t>Failure reports represent a possible denial-of-service attack that could be Link="https://rfc-editor.org/rfc/rfc9990#section-7" derivedContent="RFC9990"/> a
nd
<xref target="RFC9990" sectionFormat="bare" section="8" format="default" derived
Link="https://rfc-editor.org/rfc/rfc9990#section-8" derivedContent="RFC9990"/> o
f
<xref target="RFC9990" format="default" sectionFormat="of" derivedContent="RFC99
90"/>.</t>
<section anchor="dos-attacks" numbered="true" removeInRFC="false" toc="inc
lude" pn="section-8.1">
<name slugifiedName="name-denial-of-service">Denial of Service</name>
<t indent="0" pn="section-8.1-1">Failure reports represent a possible de
nial-of-service attack that could be
perpetrated by an attacker who sends numerous messages purporting to perpetrated by an attacker who sends numerous messages purporting to
be from the intended victim Domain Owner but which fail both SPF and be from the intended victim Domain Owner but which fail both SPF and
DKIM; this would cause participating Mail Receivers to send failure DKIM; this would cause participating Mail Receivers to send failure
reports to the Domain Owner or its delegate(s), potentially in large reports to the Domain Owner or its delegate(s), potentially in large
numbers. numbers.
Accordingly, participating Mail Receivers are encouraged to Accordingly, participating Mail Receivers are encouraged to
aggregate these reports as much as is practical, using the Incidents aggregate these reports as much as is practical, using the Incidents
field of the Abuse Reporting Format <xref target="RFC5965"></xref>. field of the ARF <xref target="RFC5965" format="default" sectionFormat="of" deri
Indeed, the aim is not to count each and every failure, but rather to vedContent="RFC5965"/>.
Indeed, the aim is not to count each and every failure but rather to
report different failure conditions. report different failure conditions.
Various pruning techniques are possible, including the following:</t> Various pruning techniques are possible, including the following:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-8
<ul> .1-2">
<li><t>store reports for a period of time before sending them, allowing <li pn="section-8.1-2.1">
<t indent="0" pn="section-8.1-2.1.1">Store reports for a period of t
ime before sending them, allowing
detection, collection, and consolidation of like incidents;</t> detection, collection, and consolidation of like incidents;</t>
</li> </li>
<li><t>apply rate limiting, such as a maximum number of reports per <li pn="section-8.1-2.2">
minute that will be generated (and the remainder discarded.)</t> <t indent="0" pn="section-8.1-2.2.1">Apply rate-limiting, such as a
</li> maximum number of reports per
</ul> minute that will be generated (and the remainder discarded).</t>
</section> </li>
</section> </ul>
</section>
</middle> </section>
</middle>
<back> <back>
<references><name>Normative References</name> <references pn="section-9">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i <name slugifiedName="name-references">References</name>
etf-dmarc-aggregate-reporting.xml"/> <references pn="section-9.1">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i <name slugifiedName="name-normative-references">Normative References</na
etf-dmarc-dmarcbis.xml"/> me>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
xml"/> 119" quoteTitle="true" derivedAnchor="RFC2119">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234. <front>
xml"/> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322. le>
xml"/> <author fullname="S. Bradner" initials="S." surname="Bradner"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5965. <date month="March" year="1997"/>
xml"/> <abstract>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6590. <t indent="0">In many standards track documents several words are
xml"/> used to signify the requirements in the specification. These words are often cap
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6591. italized. This document defines these words as they should be interpreted in IET
xml"/> F documents. This document specifies an Internet Best Current Practices for the
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6692. Internet Community, and requests discussion and suggestions for improvements.</t
xml"/> >
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. </abstract>
xml"/> </front>
</references> <seriesInfo name="BCP" value="14"/>
<references><name>Informative References</name> <seriesInfo name="RFC" value="2119"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6651. <seriesInfo name="DOI" value="10.17487/RFC2119"/>
xml"/> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6652. <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5
xml"/> 234" quoteTitle="true" derivedAnchor="RFC5234">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7489. <front>
xml"/> <title>Augmented BNF for Syntax Specifications: ABNF</title>
</references> <author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker"/>
<section anchor="report-format-example"><name>Example Failure Report</name> <author fullname="P. Overell" initials="P." surname="Overell"/>
<t>This is the full content of a sample failure message, including the message h <date month="January" year="2008"/>
eader.</t> <abstract>
<t indent="0">Internet technical specifications often need to defi
<sourcecode type="RFC5322">Received: from gen.example (gen.example [192.0.2.1]) ne a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF)
, called Augmented BNF (ABNF), has been popular among many Internet specificatio
ns. The current specification documents ABNF. It balances compactness and simpli
city with reasonable representational power. The differences between standard BN
F and ABNF involve naming rules, repetition, alternatives, order-independence, a
nd value ranges. This specification also supplies additional rule definitions an
d encoding for a core lexical analyzer of the type common to several Internet sp
ecifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC5322" target="https://www.rfc-editor.org/info/rfc5
322" quoteTitle="true" derivedAnchor="RFC5322">
<front>
<title>Internet Message Format</title>
<author fullname="P. Resnick" initials="P." role="editor" surname="R
esnick"/>
<date month="October" year="2008"/>
<abstract>
<t indent="0">This document specifies the Internet Message Format
(IMF), a syntax for text messages that are sent between computer users, within t
he framework of "electronic mail" messages. This specification is a revision of
Request For Comments (RFC) 2822, which itself superseded Request For Comments (R
FC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it t
o reflect current practice and incorporating incremental changes that were speci
fied in other RFCs. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5322"/>
<seriesInfo name="DOI" value="10.17487/RFC5322"/>
</reference>
<reference anchor="RFC5965" target="https://www.rfc-editor.org/info/rfc5
965" quoteTitle="true" derivedAnchor="RFC5965">
<front>
<title>An Extensible Format for Email Feedback Reports</title>
<author fullname="Y. Shafranovich" initials="Y." surname="Shafranovi
ch"/>
<author fullname="J. Levine" initials="J." surname="Levine"/>
<author fullname="M. Kucherawy" initials="M." surname="Kucherawy"/>
<date month="August" year="2010"/>
<abstract>
<t indent="0">This document defines an extensible format and MIME
type that may be used by mail operators to report feedback about received email
to other parties. This format is intended as a machine-readable replacement for
various existing report formats currently used in Internet email. [STANDARDS-TRA
CK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5965"/>
<seriesInfo name="DOI" value="10.17487/RFC5965"/>
</reference>
<reference anchor="RFC6590" target="https://www.rfc-editor.org/info/rfc6
590" quoteTitle="true" derivedAnchor="RFC6590">
<front>
<title>Redaction of Potentially Sensitive Data from Mail Abuse Repor
ts</title>
<author fullname="J. Falk" initials="J." role="editor" surname="Falk
"/>
<author fullname="M. Kucherawy" initials="M." role="editor" surname=
"Kucherawy"/>
<date month="April" year="2012"/>
<abstract>
<t indent="0">Email messages often contain information that might
be considered private or sensitive, per either regulation or social norms. When
such a message becomes the subject of a report intended to be shared with other
entities, the report generator may wish to redact or elide the sensitive portion
s of the message. This memo suggests one method for doing so effectively. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6590"/>
<seriesInfo name="DOI" value="10.17487/RFC6590"/>
</reference>
<reference anchor="RFC6591" target="https://www.rfc-editor.org/info/rfc6
591" quoteTitle="true" derivedAnchor="RFC6591">
<front>
<title>Authentication Failure Reporting Using the Abuse Reporting Fo
rmat</title>
<author fullname="H. Fontana" initials="H." surname="Fontana"/>
<date month="April" year="2012"/>
<abstract>
<t indent="0">This memo registers an extension report type for the
Abuse Reporting Format (ARF), affecting multiple registries, for use in generat
ing receipt-time reports about messages that fail one or more email message auth
entication checks. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6591"/>
<seriesInfo name="DOI" value="10.17487/RFC6591"/>
</reference>
<reference anchor="RFC6692" target="https://www.rfc-editor.org/info/rfc6
692" quoteTitle="true" derivedAnchor="RFC6692">
<front>
<title>Source Ports in Abuse Reporting Format (ARF) Reports</title>
<author fullname="R. Clayton" initials="R." surname="Clayton"/>
<author fullname="M. Kucherawy" initials="M." surname="Kucherawy"/>
<date month="July" year="2012"/>
<abstract>
<t indent="0">This document defines an additional header field for
use in Abuse Reporting Format (ARF) reports to permit the identification of the
source port of the connection involved in an abuse incident.</t>
<t indent="0">This document updates RFC 6591. [STANDARDS-TRACK]</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="6692"/>
<seriesInfo name="DOI" value="10.17487/RFC6692"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by clari
fying that only UPPERCASE usage of the key words have the defined special meanin
gs.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC9989" target="https://www.rfc-editor.org/info/rfc9
989" quoteTitle="true" derivedAnchor="RFC9989">
<front>
<title>Domain-Based Message Authentication, Reporting, and Conforman
ce (DMARC)</title>
<author initials="T." surname="Herr" fullname="Todd Herr" role="edit
or">
<organization showOnFrontPage="true">Valimail</organization>
</author>
<author initials="J." surname="Levine" fullname="John R. Levine" rol
e="editor">
<organization showOnFrontPage="true">Standcore LLC</organization>
</author>
<date month="May" year="2026"/>
</front>
<seriesInfo name="RFC" value="9989"/>
<seriesInfo name="DOI" value="10.17487/RFC9989"/>
</reference>
<reference anchor="RFC9990" target="https://www.rfc-editor.org/info/rfc9
990" quoteTitle="true" derivedAnchor="RFC9990">
<front>
<title>Domain-Based Message Authentication, Reporting, and Conforman
ce (DMARC) Aggregate Reporting</title>
<author initials="A." surname="Brotman" fullname="Alex Brotman" role
="editor">
<organization showOnFrontPage="true">Comcast, Inc.</organization>
</author>
<date month="May" year="2026"/>
</front>
<seriesInfo name="RFC" value="9990"/>
<seriesInfo name="DOI" value="10.17487/RFC9990"/>
</reference>
</references>
<references pn="section-9.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="RFC6651" target="https://www.rfc-editor.org/info/rfc6
651" quoteTitle="true" derivedAnchor="RFC6651">
<front>
<title>Extensions to DomainKeys Identified Mail (DKIM) for Failure R
eporting</title>
<author fullname="M. Kucherawy" initials="M." surname="Kucherawy"/>
<date month="June" year="2012"/>
<abstract>
<t indent="0">This document presents extensions to the DomainKeys
Identified Mail (DKIM) specification to allow for detailed reporting of message
authentication failures in an on-demand fashion. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6651"/>
<seriesInfo name="DOI" value="10.17487/RFC6651"/>
</reference>
<reference anchor="RFC6652" target="https://www.rfc-editor.org/info/rfc6
652" quoteTitle="true" derivedAnchor="RFC6652">
<front>
<title>Sender Policy Framework (SPF) Authentication Failure Reportin
g Using the Abuse Reporting Format</title>
<author fullname="S. Kitterman" initials="S." surname="Kitterman"/>
<date month="June" year="2012"/>
<abstract>
<t indent="0">This memo presents extensions to the Abuse Reporting
Format (ARF) and Sender Policy Framework (SPF) specifications to allow for deta
iled reporting of message authentication failures in an on-demand fashion.</t>
<t indent="0">This memo updates RFC 4408 by providing an IANA regi
stry for SPF modifiers. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6652"/>
<seriesInfo name="DOI" value="10.17487/RFC6652"/>
</reference>
<reference anchor="RFC7489" target="https://www.rfc-editor.org/info/rfc7
489" quoteTitle="true" derivedAnchor="RFC7489">
<front>
<title>Domain-based Message Authentication, Reporting, and Conforman
ce (DMARC)</title>
<author fullname="M. Kucherawy" initials="M." role="editor" surname=
"Kucherawy"/>
<author fullname="E. Zwicky" initials="E." role="editor" surname="Zw
icky"/>
<date month="March" year="2015"/>
<abstract>
<t indent="0">Domain-based Message Authentication, Reporting, and
Conformance (DMARC) is a scalable mechanism by which a mail-originating organiza
tion can express domain-level policies and preferences for message validation, d
isposition, and reporting, that a mail-receiving organization can use to improve
mail handling.</t>
<t indent="0">Originators of Internet Mail need to be able to asso
ciate reliable and authenticated domain identifiers with messages, communicate p
olicies about messages that use those identifiers, and report about mail using t
hose identifiers. These abilities have several benefits: Receivers can provide f
eedback to Domain Owners about the use of their domains; this feedback can provi
de valuable insight about the management of internal operations and the presence
of external domain name abuse.</t>
<t indent="0">DMARC does not produce or encourage elevated deliver
y privilege of authenticated email. DMARC is a mechanism for policy distribution
that enables increasingly strict handling of messages that fail authentication
checks, ranging from no action, through altered delivery, up to message rejectio
n.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7489"/>
<seriesInfo name="DOI" value="10.17487/RFC7489"/>
</reference>
</references>
</references>
<section anchor="report-format-example" numbered="true" removeInRFC="false"
toc="include" pn="section-appendix.a">
<name slugifiedName="name-example-failure-report">Example Failure Report</
name>
<t indent="0" pn="section-appendix.a-1">This is the full content of a samp
le failure message, including the message header.</t>
<sourcecode type="message/rfc822" markers="false" pn="section-appendix.a-2
">
Received: from gen.example (gen.example [192.0.2.1])
(TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) (TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
by mail.consumer.example with ESMTPS by mail.consumer.example with ESMTPS
id 00000000005DC0DD.0000442E; Tue, 19 Jul 2022 07:57:50 +0200 id 00000000005DC0DD.0000442E; Tue, 19 Jul 2022 07:57:50 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=gen.example; s=mail; t=1658210268; d=gen.example; s=mail; t=1658210268;
bh=rCrh1aFDE8d/Fltt8wbcu48bLOu4OM23QXqphUZPAIM=; bh=rCrh1aFDE8d/Fltt8wbcu48bLOu4OM23QXqphUZPAIM=;
h=From:To:Date:Subject:From; h=From:To:Date:Subject:From;
b=IND9JkuwF9/5841kzxMbPeej0VYimVzNKozR2R89M8eYO2zOlCBblx507Gz0YK7mE b=IND9JkuwF9/5841kzxMbPeej0VYimVzNKozR2R89M8eYO2zOlCBblx507Gz0YK7mE
/h6pslWm0ODBVFzLlwY9CXv4Vu62QsN0RBIXHPjEXOkoM2VCD5zCd+5i5dtCFX7Mxh /h6pslWm0ODBVFzLlwY9CXv4Vu62QsN0RBIXHPjEXOkoM2VCD5zCd+5i5dtCFX7Mxh
LThb2ZJ3efklbSB9RQRwxcmRvCPV7z6lt/Ds9sucVE1RDODYHjx+iWnAUQrlos6ZQb LThb2ZJ3efklbSB9RQRwxcmRvCPV7z6lt/Ds9sucVE1RDODYHjx+iWnAUQrlos6ZQb
u/YOUGjf60LPpyljfPu3EpFwo80mSHyQlP/4S5KEykgPQMgCqLPPKvJwu1aAIDj+jG u/YOUGjf60LPpyljfPu3EpFwo80mSHyQlP/4S5KEykgPQMgCqLPPKvJwu1aAIDj+jG
q2ylO3fmc/ERDeDWACtR67YNabEKBWtjqCRLNxKttazViJTZ5drcLfpX0853KoougX q2ylO3fmc/ERDeDWACtR67YNabEKBWtjqCRLNxKttazViJTZ5drcLfpX0853KoougX
Rltp7zdoLdy4A== Rltp7zdoLdy4A==
From: DMARC Filter &lt;DMARC@gen.example&gt;; From: DMARC Filter &lt;DMARC@gen.example&gt;;
To: dmarcfail@consumer.example To: dmarcfail@consumer.example
Date: Tue, 19 Jul 2022 00:57:48 -0500 (CDT) Date: Tue, 19 Jul 2022 00:57:48 -0500 (CDT)
Subject: FW: This is the original subject Subject: FW: This is the original subject
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report; Content-Type: multipart/report; report-type=feedback-report;
boundary=&quot;=_mime_boundary_&quot; boundary="=_mime_boundary_"
Message-Id: &lt;20220719055748.4AE9D403CC@gen.example&gt;; Message-Id: &lt;20220719055748.4AE9D403CC@gen.example&gt;;
This is a MIME-formatted message. If you see this text it means that This is a MIME-formatted message. If you see this text it means that
your E-mail software does not support MIME-formatted messages. your E-mail software does not support MIME-formatted messages.
--=_mime_boundary_ --=_mime_boundary_
Content-Type: text/plain; charset=utf-8 Content-Type: text/plain; charset=utf-8
Content-Disposition: inline Content-Disposition: inline
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
skipping to change at line 446 skipping to change at line 740
Original-Mail-From: author=gen.example@forwarder.example Original-Mail-From: author=gen.example@forwarder.example
Source-IP: 192.0.2.2 Source-IP: 192.0.2.2
Source-Port: 12345 Source-Port: 12345
Reported-Domain: consumer.example Reported-Domain: consumer.example
--=_mime_boundary_ --=_mime_boundary_
Content-Type: message/rfc822; charset=utf-8 Content-Type: message/rfc822; charset=utf-8
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Authentication-Results: gen.example; Authentication-Results: gen.example;
dkim=permerror header.d=forwarder.example header.b=&quot;EjCbN/c3&quot;; dkim=permerror header.d=forwarder.example header.b="EjCbN/c3";
dkim=temperror header.d=forwarder.example header.b=&quot;mQ8GEWPc&quot;; dkim=temperror header.d=forwarder.example header.b="mQ8GEWPc";
dkim=permerror header.d=consumer.example header.b=&quot;hETrymCb&quot;; dkim=permerror header.d=consumer.example header.b="hETrymCb";
dkim=neutral header.d=consumer.example header.b=&quot;C2nsAp3A&quot;; dkim=neutral header.d=consumer.example header.b="C2nsAp3A";
Received: from mail.forwarder.example Received: from mail.forwarder.example
(mail.forwarder.example [IPv6:2001:db8::23ac]) (mail.forwarder.example [IPv6:2001:db8::23ac])
by mail.gen.example (Postfix) with ESMTP id 5E8B0C159826 by mail.gen.example (Postfix) with ESMTP id 5E8B0C159826
for &lt;x@gen.example&gt;; Sun, 14 Aug 2022 07:58:29 -0700 (PDT) for &lt;x@gen.example&gt;; Sun, 14 Aug 2022 07:58:29 -0700 (PDT)
Received: from mail.forwarder.example (localhost [127.0.0.1]) Received: from mail.forwarder.example (localhost [127.0.0.1])
by mail.forwarder.example (Postfix) with ESMTP id 4Ln7Qw4fnvz6Bq by mail.forwarder.example (Postfix) with ESMTP id 4Ln7Qw4fnvz6Bq
for &lt;x@gen.example&gt;; Tue, 19 Jul 2022 07:57:44 +0200 for &lt;x@gen.example&gt;; Tue, 19 Jul 2022 07:57:44 +0200
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;
d=forwarder.example; s=ed25519-59hs; t=1658210264; d=forwarder.example; s=ed25519-59hs; t=1658210264;
x=1663210264; bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=; x=1663210264; bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;
skipping to change at line 541 skipping to change at line 835
Subject: This is the original subject Subject: This is the original subject
Content-Language: en-US Content-Language: en-US
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 &lt;author@consumer.example&gt; From: Message Author &lt;author@consumer.example&gt;
In-Reply-To: &lt;20220718102753.0f6d9dde.cel@example.com&gt; In-Reply-To: &lt;20220718102753.0f6d9dde.cel@example.com&gt;
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 ]
</sourcecode> --=_mime_boundary_--</sourcecode>
<t>The Source-Port field definition is given by <xref target="RFC6692"></xref></ <t indent="0" pn="section-appendix.a-3">The Source-Port field definition i
t> s given by <xref target="RFC6692" format="default" sectionFormat="of" derivedCon
<t>In the final MIME entity, the local-parts of To and From addresses are tent="RFC6692"/>.</t>
<t indent="0" pn="section-appendix.a-4">In the final MIME entity, the loca
l-parts of To and From addresses are
reported unredacted. Since we know that the local parts are PII, we reported unredacted. Since we know that the local parts are PII, we
can reduce the privacy risk by redacting them. In the example, the can reduce the privacy risk by redacting them. In the example, the
report generator could have replaced &quot;users&quot; with &quot;lRLxexey&quot; report generator could have replaced "users" with "lRLxexey" and
and "author" with "RT47aVey" throughout the entity.</t>
&quot;author&quot; with &quot;RT47aVey&quot; throughout the entity.</t> <t indent="0" pn="section-appendix.a-5">If the body of the message is not
<t>If the body of the message is not included, the last MIME entity included, the last MIME entity
would have &quot;Content-Type: text/rfc822-headers&quot; instead of message/rfc8 would have "Content-Type: text/rfc822-headers" instead of "message/rfc822".</t>
22.</t> </section>
</section> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<section anchor="change-log-change-log"><name>Change Log {change-log}</name> <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<t>[RFC Editor: Please remove this section prior to publication.]</t> <author initials="S." surname="Jones" fullname="Steven M. Jones" role="edi
tor">
<section anchor="s00"><name>00 to 01</name> <organization showOnFrontPage="true">DMARC.org</organization>
<address>
<ul> <email>smj@dmarc.org</email>
<li><t>Replace references to RFC7489 with references to I-D.ietf-dmarc-dmarcbis. </address>
</t> </author>
</li> <author initials="A." surname="Vesely" fullname="Alessandro Vesely" role="
<li><t>Replace the 2nd paragraph in the Introduction with the text proposed by N editor">
ed <organization showOnFrontPage="true">Tana</organization>
for Ticket #55, which enjoys some consensus:<br /> <address>
<email>vesely@tana.it</email>
<eref target="https://mailarchive.ietf.org/arch/msg/dmarc </address>
/HptVyJ9SgrfxWRbeGwORagPrhCw">https://mailarchive.ietf.org/arch/msg/dmarc/HptVyJ </author>
9SgrfxWRbeGwORagPrhCw</eref></t> </section>
</li> </back>
<li><t>Strike a spurious sentence about criticality of feedback, which was
meant for feedback in general, not failure reports. In f
act, 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 &quot;Verifying External Destinations&quot;
and refer to I-D.ietf-dmarc-aggregate-reporting.</t>
</li>
<li><t>Remove the content of section &quot;Security Considerations&quot;
and refer to I-D.ietf-dmarc-dmarcbis.</t>
</li>
<li><t>Slightly tweak the wording of the example in Appendix A.1
so that it makes sense standing alone.</t>
</li>
<li><t>Remove the sentence containing &quot;must include any URI(s)&quot;,
as the issue arose &lt;eref target=&quot;https://mailarchive.ietf.org/arch/msg/d
marc/mFk0qiTCy8tzghRvcxus01W_Blw&quot;/&gt;.</t>
</li>
<li><t>Add paragraph in Security 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>Remove the old 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 of document editors.
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>07 to 08</name>
<ul>
<li><t>Specify what detailed information a report contains, in the 1st paragraph
of Section 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 &amp;lt; with &lt; and &amp;gt; with &gt; 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>Expand the Verifying External Destinations section and reference <xref targe
t="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-dmarc
bis"></xref> and <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref></li>
<li>Clarify potential information disclosures when failure reports are sent</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, de
bug and anti-abuse.</li>
<li>In Section 2 (2nd paragraph) clarify that failure reports allow better deter
mining 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 &quot;Auth-Failure&quot; 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 paragraph of Secority 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=/&quot;fo&quot;/, /ruf=/ruf/, /urls/URIs/.</li>
<li>Specify parent registry in IANA Considerations.</li>
</ul>
</section>
<section anchor="s18"><name>18 to 19</name>
<ul spacing="compact">
<li>Remove the term &quot;scalable&quot; 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 &quot;forensic reports&quot;).</
li>
<li>Note that Domain Owner can use dot-forward to not decalre 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 &quot;dot-forward&quot; with a periphrasis to downplay final destina
tion.</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 6591 in the abstract.</li>
<li>Reword &quot;Without this check, a bad actor ...&quot; 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>&quot;Defang&quot; issue.</li>
<li>Avoid using &quot;defined by&quot; 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>
</back>
</rfc> </rfc>
 End of changes. 50 change blocks. 
610 lines changed or deleted 904 lines changed or added

This html diff was produced by rfcdiff 1.48.