rfc9990.original.xml   rfc9990.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-aggregate-reporting-32" number="9990" submissionType="IE
<rfc version="3" ipr="trust200902" docName="draft-ietf-dmarc-aggregate-reporting TF" category="std" xml:lang="en" obsoletes="7489" updates="" consensus="true" sy
-32" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3. mRefs="true" sortRefs="true" tocInclude="true" prepTime="2026-05-19T20:27:32" in
org/2001/XInclude" obsoletes="7489" indexInclude="true" consensus="true"> dexInclude="true" scripts="Common,Latin" tocDepth="3">
<link href="https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-report
<front> ing-32" rel="prev"/>
<title abbrev="DMARC Aggregate Reporting">Domain-based Message Authentication, R <link href="https://dx.doi.org/10.17487/rfc9990" rel="alternate"/>
eporting, and Conformance (DMARC) Aggregate Reporting</title><seriesInfo value=" <link href="urn:issn:2070-1721" rel="alternate"/>
draft-ietf-dmarc-aggregate-reporting-32" stream="IETF" status="standard" name="I <front>
nternet-Draft"></seriesInfo> <title abbrev="DMARC Aggregate Reporting">Domain-Based Message Authenticatio
<author initials="A." surname="Brotman (ed)" fullname="Alex Brotman"><organizati n, Reporting, and Conformance (DMARC) Aggregate Reporting</title>
on>Comcast, Inc.</organization><address><postal><street></street> <seriesInfo name="RFC" value="9990" stream="IETF"/>
</postal><email>alex_brotman@comcast.com</email> <author initials="A." surname="Brotman" fullname="Alex Brotman" role="editor
</address></author><date year="2025" month="March" day="17"></date> ">
<area>Application</area> <organization showOnFrontPage="true">Comcast, Inc.</organization>
<workgroup>DMARC</workgroup> <address>
<email>alex_brotman@comcast.com</email>
<abstract> </address>
<t>Domain-based Message Authentication, Reporting, and Conformance </author>
<date month="05" year="2026"/>
<area>ART</area>
<workgroup>dmarc</workgroup>
<keyword>domain</keyword>
<keyword>email</keyword>
<keyword>security</keyword>
<keyword>messaging</keyword>
<keyword>dkim</keyword>
<keyword>spf</keyword>
<keyword>authentication</keyword>
<keyword>reporting</keyword>
<keyword>conformance</keyword>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">Domain-based Message Authentication,
Reporting, and Conformance
(DMARC) allows for Domain Owners to request aggregate reports from receivers. (DMARC) allows for Domain Owners to request aggregate reports from receivers.
This report is an XML document, and contains extensible elements that allow for This report is an XML document and contains extensible elements that allow for
other types of data to be specified later. The aggregate reports can be other types of data to be specified later. The aggregate reports can be
submitted by the receiver to the Domain Owner's specified destination as submitted by the receiver to the Domain Owner's specified destination as
declared in the associated DNS record.</t> declared in the associated DNS record.</t>
</abstract> <t indent="0" pn="section-abstract-2">This document obsoletes RFC 7489.</t
>
</front> </abstract>
<boilerplate>
<middle> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<section anchor="introduction"><name>Introduction</name> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
<t>A key component of DMARC <xref target="I-D.ietf-dmarc-dmarcbis"></xref> (Doma >
in-based Message <t indent="0" pn="section-boilerplate.1-1">
Authentication, Reporting, and Conformance) is the ability for Domain Owners to This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</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/rfc9990" 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" pn="section-toc.1-1.1.1"><xref derivedContent="1" form
at="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" f
ormat="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>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.1.2.1.2">
<li pn="section-toc.1-1.1.2.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.
2.1.1"><xref derivedContent="1.1.1" format="counter" sectionFormat="of" target="
section-1.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" tar
get="name-notation">Notation</xref></t>
</li>
<li pn="section-toc.1-1.1.2.1.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.
2.2.1"><xref derivedContent="1.1.2" format="counter" sectionFormat="of" target="
section-1.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" tar
get="name-dmarc-terminology">DMARC Terminology</xref></t>
</li>
</ul>
</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-document-status">Document Status</
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-dmarc-feedback">DMARC Feedback</xr
ef></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-aggregate-reports">Agg
regate Reports</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.1.2">
<li pn="section-toc.1-1.3.2.1.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.2.1.1"><xref derived
Content="3.1.1" format="counter" sectionFormat="of" target="section-3.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-descriptio
n-of-the-content-">Description of the Content of the XML File</xref></t>
</li>
<li pn="section-toc.1-1.3.2.1.2.2">
<t indent="0" pn="section-toc.1-1.3.2.1.2.2.1"><xref derived
Content="3.1.2" format="counter" sectionFormat="of" target="section-3.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-handling-d
omains-in-reports">Handling Domains in Reports</xref></t>
</li>
<li pn="section-toc.1-1.3.2.1.2.3">
<t indent="0" pn="section-toc.1-1.3.2.1.2.3.1"><xref derived
Content="3.1.3" format="counter" sectionFormat="of" target="section-3.1.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-dkim-signa
tures-in-aggregat">DKIM Signatures in Aggregate Reports</xref></t>
</li>
<li pn="section-toc.1-1.3.2.1.2.4">
<t indent="0" pn="section-toc.1-1.3.2.1.2.4.1"><xref derived
Content="3.1.4" format="counter" sectionFormat="of" target="section-3.1.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-unique-ide
ntifiers-in-aggre">Unique Identifiers in Aggregate Reporting</xref></t>
</li>
<li pn="section-toc.1-1.3.2.1.2.5">
<t indent="0" pn="section-toc.1-1.3.2.1.2.5.1"><xref derived
Content="3.1.5" format="counter" sectionFormat="of" target="section-3.1.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-error-elem
ent">Error Element</xref></t>
</li>
<li pn="section-toc.1-1.3.2.1.2.6">
<t indent="0" pn="section-toc.1-1.3.2.1.2.6.1"><xref derived
Content="3.1.6" format="counter" sectionFormat="of" target="section-3.1.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-policy-ove
rride-reason">Policy Override Reason</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-extensions">Extensions
</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
"3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-changes-in-policy-duri
ng-a-">Changes in Policy During a Reporting Period</xref></t>
</li>
<li pn="section-toc.1-1.3.2.4">
<t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent=
"3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-report-request-discove
ry">Report Request Discovery</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5">
<t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent=
"3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-report-delivery">Repor
t Delivery</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.5.2">
<li pn="section-toc.1-1.3.2.5.2.1">
<t indent="0" pn="section-toc.1-1.3.2.5.2.1.1"><xref derived
Content="3.5.1" format="counter" sectionFormat="of" target="section-3.5.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-definition
-of-report-id">Definition of Report-ID</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5.2.2">
<t indent="0" pn="section-toc.1-1.3.2.5.2.2.1"><xref derived
Content="3.5.2" format="counter" sectionFormat="of" target="section-3.5.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-email">Ema
il</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5.2.3">
<t indent="0" pn="section-toc.1-1.3.2.5.2.3.1"><xref derived
Content="3.5.3" format="counter" sectionFormat="of" target="section-3.5.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-other-meth
ods">Other Methods</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5.2.4">
<t indent="0" pn="section-toc.1-1.3.2.5.2.4.1"><xref derived
Content="3.5.4" format="counter" sectionFormat="of" target="section-3.5.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-handling-o
f-duplicates">Handling of Duplicates</xref></t>
</li>
</ul>
</li>
</ul>
</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-verifying-external-destinat">Verif
ying External Destinations</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-extensible-reporting">Extensible R
eporting</xref></t>
</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-registration-for-the-d
marc-">Registration for the DMARC Namespace</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-registration-for-the-d
marc-x">Registration for the DMARC XML Schema</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-report-recipients">Rep
ort Recipients</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-data-contained-within-
repor">Data Contained Within Reports</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-feedback-leakage">Feed
back Leakage</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-report-content-as-an-a
ttack">Report Content as an Attack</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-false-information">Fal
se Information</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3">
<t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent=
"8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-disclosure-of-filterin
g-inf">Disclosure of Filtering Information</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-operational-considerations">Operat
ional Considerations</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-report-generation">Rep
ort Generation</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-report-evaluation">Rep
ort Evaluation</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3">
<t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent=
"9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-report-storage">Report
Storage</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent
="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2">
<t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent
="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-dmarc-xml-schem
a">DMARC XML Schema</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="Append
ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-sample-report">
Sample Report</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Append
ix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-differences-fro
m-rfc-7489">Differences from RFC 7489</xref></t>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-address">Author's Addre
ss</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">A key component of Domain-based Message
Authentication, Reporting, and Conformance (DMARC) <xref target="RFC9989" format
="default" sectionFormat="of" derivedContent="RFC9989"/> is the ability for Doma
in Owners to
request that Mail Receivers provide various types of reports. These reports all ow request that Mail Receivers provide various types of reports. These reports all ow
Domain Owners to have insight into which IP addresses are sending on their Domain Owners to have insight into which IP addresses are sending on their
behalf, and some insight into whether or not the volume may be legitimate.<br /> behalf and some insight into whether or not the volume may be legitimate.</t>
These reports expose information relating to the DMARC policy, as well as <t indent="0" pn="section-1-2">These reports expose information relating t
the outcome of SPF (Sender Policy Framework) <xref target="RFC7208"></xref> &amp o the DMARC policy, as well as
; DKIM the outcome of Sender Policy Framework (SPF) <xref target="RFC7208" format="defa
(DomainKeys Identified Mail) <xref target="RFC6376"></xref> validation.</t> ult" sectionFormat="of" derivedContent="RFC7208"/> and
DomainKeys Identified Mail (DKIM) <xref target="RFC6376" format="default" sectio
<section anchor="terminology"><name>Terminology</name> nFormat="of" derivedContent="RFC6376"/> validation.</t>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, & <section anchor="terminology" numbered="true" removeInRFC="false" toc="inc
quot;SHALL&quot;, &quot;SHALL lude" pn="section-1.1">
NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, <name slugifiedName="name-terminology">Terminology</name>
&quot;NOT RECOMMENDED&quot;, <t indent="0" pn="section-1.1-1">
&quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
> when, and only when, they OT RECOMMENDED</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
<section anchor="notation"><name>Notation</name> described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
<t>Certain properties of mail messages described in this document are f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
referenced using notation found in <xref target="RFC5598"></xref> (e.g., &quot;R mat="of" derivedContent="RFC8174"/>
FC5322.From&quot;).</t> when, and only when, they appear in all capitals, as shown here.
<t>This specification uses the Augmented Backus-Naur Form (ABNF) </t>
notation of <xref target="RFC5234"></xref> and <xref target="RFC7405"></xref>.</ <section anchor="notation" numbered="true" removeInRFC="false" toc="incl
t> ude" pn="section-1.1.1">
</section> <name slugifiedName="name-notation">Notation</name>
<t indent="0" pn="section-1.1.1-1">Certain properties of mail messages
<section anchor="dmarc-terminology"><name>DMARC Terminology</name> described in this document are
<t>There are a number of terms defined in <xref target="I-D.ietf-dmarc-dmarcbis" referenced using notation found in <xref target="RFC5598" format="default" secti
></xref> that are used onFormat="of" derivedContent="RFC5598"/> (e.g., "RFC5322.From").</t>
<t indent="0" pn="section-1.1.1-2">This specification uses the Augment
ed Backus-Naur Form (ABNF)
notation of <xref target="RFC5234" format="default" sectionFormat="of" derivedCo
ntent="RFC5234"/> and <xref target="RFC7405" format="default" sectionFormat="of"
derivedContent="RFC7405"/>.</t>
</section>
<section anchor="dmarc-terminology" numbered="true" removeInRFC="false"
toc="include" pn="section-1.1.2">
<name slugifiedName="name-dmarc-terminology">DMARC Terminology</name>
<t indent="0" pn="section-1.1.2-1">There are a number of terms defined
in <xref target="RFC9989" format="default" sectionFormat="of" derivedContent="R
FC9989"/> that are used
within this document. Understanding those definitions will aid in reading within this document. Understanding those definitions will aid in reading
this document. The terms below are of noted interest:</t> this document. The terms below are of noted interest:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<ul spacing="compact"> -1.1.2-2">
<li>Author Domain</li> <li pn="section-1.1.2-2.1">Author Domain</li>
<li>DMARC Policy Record</li> <li pn="section-1.1.2-2.2">DMARC Policy Record</li>
<li>Domain Owner</li> <li pn="section-1.1.2-2.3">Domain Owner</li>
<li>Mail Receiver</li> <li pn="section-1.1.2-2.4">Mail Receiver</li>
<li>Organizational Domain</li> <li pn="section-1.1.2-2.5">Organizational Domain</li>
<li>Report Consumer</li> <li pn="section-1.1.2-2.6">Report Consumer</li>
</ul> </ul>
</section> </section>
</section> </section>
</section> </section>
<section anchor="document-status" numbered="true" removeInRFC="false" toc="i
<section anchor="document-status"><name>Document Status</name> nclude" pn="section-2">
<t>This document, in part, along with DMARCbis <xref target="I-D.ietf-dmarc-dmar <name slugifiedName="name-document-status">Document Status</name>
cbis"></xref> DMARCbis <t indent="0" pn="section-2-1">This document, in part, along with <xref ta
Failure Reporting <xref target="I-D.ietf-dmarc-failure-reporting"></xref>, obsol rget="RFC9989" format="default" sectionFormat="of" derivedContent="RFC9989"/> an
etes and replaces d <xref target="RFC9991" format="default" sectionFormat="of" derivedContent="RFC
DMARC <xref target="RFC7489"></xref>.</t> 9991"/>, obsoletes and replaces DMARC <xref target="RFC7489" format="default" se
</section> ctionFormat="of" derivedContent="RFC7489"/>. Note that errata for this document
has been addressed as described in <xref target="RFC9989" format=
<section anchor="dmarc-feedback"><name>DMARC Feedback</name> "default" sectionFormat="of" derivedContent="RFC9989"/>.</t>
<t>Providing Domain Owners with visibility into how Mail Receivers implement </section>
<section anchor="dmarc-feedback" numbered="true" removeInRFC="false" toc="in
clude" pn="section-3">
<name slugifiedName="name-dmarc-feedback">DMARC Feedback</name>
<t indent="0" pn="section-3-1">Providing Domain Owners with visibility int
o how Mail Receivers implement
and enforce the DMARC mechanism in the form of feedback is critical to and enforce the DMARC mechanism in the form of feedback is critical to
establishing and maintaining accurate authentication deployments. When establishing and maintaining accurate authentication deployments. When
Domain Owners can see what effect their policies and practices are having, Domain Owners can see what effect their policies and practices are having,
they are better willing and able to use quarantine and reject policies.</t> they are better willing and able to use quarantine and reject policies.</t>
<section anchor="aggregate-reports" numbered="true" removeInRFC="false" to
<section anchor="aggregate-reports"><name>Aggregate Reports</name> c="include" pn="section-3.1">
<t>The DMARC aggregate feedback report is designed to provide Domain <name slugifiedName="name-aggregate-reports">Aggregate Reports</name>
<t indent="0" pn="section-3.1-1">The DMARC aggregate feedback report is
designed to provide Domain
Owners with precise insight into:</t> Owners with precise insight into:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
<ul spacing="compact"> .1-2">
<li>authentication results,</li> <li pn="section-3.1-2.1">authentication results,</li>
<li>corrective action that needs to be taken by Domain Owners, and</li> <li pn="section-3.1-2.2">corrective action that needs to be taken by D
<li>the effect of Domain Owner DMARC policy on mail streams processed omain Owners, and</li>
<li pn="section-3.1-2.3">the effect of Domain Owner DMARC policy on ma
il streams processed
by Mail Receivers.</li> by Mail Receivers.</li>
</ul> </ul>
<t>Aggregate DMARC feedback provides visibility into real-world mail <t indent="0" pn="section-3.1-3">Aggregate DMARC feedback provides visib
ility into real-world mail
streams that Domain Owners need in order to make informed decisions streams that Domain Owners need in order to make informed decisions
regarding the publication of a DMARC policy. When Domain Owners know what regarding the publication of a DMARC policy. When Domain Owners know what
legitimate mail they are sending, what the authentication results are legitimate mail they are sending, what the authentication results are
on that mail, and what forged mail receivers are getting, they can on that mail, and what forged Mail Receivers are getting, they can
make better decisions about the policies they need and the steps they make better decisions about the policies they need and the steps they
need to take to enable those policies. When Domain Owners set need to take to enable those policies. When Domain Owners set
policies appropriately and understand their effects, Mail Receivers policies appropriately and understand their effects, Mail Receivers
can act on them confidently.</t> can act on them confidently.</t>
<t>Visibility comes in the form of daily (or more frequent) Mail <t indent="0" pn="section-3.1-4">Visibility comes in the form of daily (
Receiver-originated feedback reports that contain aggregate data on or more frequent)
feedback reports that are originated from Mail Receivers and that contain aggreg
ate data on
message streams relevant to the Domain Owner. This information message streams relevant to the Domain Owner. This information
includes data about messages that passed DMARC authentication as well includes data about messages that passed DMARC authentication as well
as those that did not.</t> as those that did not.</t>
<t>A separate report <bcp14>MUST</bcp14> be generated for each DMARC Policy Doma in encountered <t indent="0" pn="section-3.1-5">A separate report <bcp14>MUST</bcp14> b e generated for each DMARC Policy Domain encountered
during the reporting period. See below for further explanation in during the reporting period. See below for further explanation in
<xref target="handling"></xref>, &quot;Handling Domains in Reports&quot;.</t> <xref target="handling" format="default" sectionFormat="of" derivedContent="Sect
<t>The report may include the following data:</t> ion 3.1.2"/> ("Handling Domains in Reports").</t>
<t indent="0" pn="section-3.1-6">The report may include the following da
<ul spacing="compact"> ta:</t>
<li>The DMARC policy discovered and applied, if any</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
<li>The selected message disposition</li> .1-7">
<li>The identifier evaluated by SPF and the SPF result, if any</li> <li pn="section-3.1-7.1">The DMARC policy discovered and applied, if a
<li>The identifier evaluated by DKIM and the DKIM result, if any</li> ny</li>
<li>For both DKIM and SPF, an indication of whether the identifier was <li pn="section-3.1-7.2">The selected message disposition</li>
in DMARC alignment (see <xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="of <li pn="section-3.1-7.3">The identifier evaluated by SPF and the SPF r
" relative="#" section="3.2.10"></xref>)</li> esult, if any</li>
<li>Sending and receiving domains</li> <li pn="section-3.1-7.4">The identifier evaluated by DKIM and the DKIM
<li>The number of successful authentications</li> result, if any</li>
<li>The counts of messages based on all messages received, even if <li pn="section-3.1-7.5">For both DKIM and SPF, an indication of wheth
er the identifier was
in DMARC alignment (see <xref target="RFC9989" sectionFormat="of" section="3.2.1
0" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9989#section-3.2.
10" derivedContent="RFC9989"/>)</li>
<li pn="section-3.1-7.6">Sending and receiving domains</li>
<li pn="section-3.1-7.7">The number of successful authentications</li>
<li pn="section-3.1-7.8">The counts of messages based on all messages
received, even if
their delivery is ultimately blocked by other filtering agents.</li> their delivery is ultimately blocked by other filtering agents.</li>
</ul> </ul>
<t>Each report <bcp14>MUST</bcp14> contain data for only one DMARC Policy Domain <t indent="0" pn="section-3.1-8">Each report <bcp14>MUST</bcp14> contain
. A single data for only one DMARC Policy Domain. A single
report <bcp14>MUST</bcp14> contain data for one policy configuration. If multip le report <bcp14>MUST</bcp14> contain data for one policy configuration. If multip le
configurations were observed during a single reporting period, a configurations were observed during a single reporting period, a
reporting entity MAY choose to send multiple reports, otherwise the reporting entity <bcp14>MAY</bcp14> choose to send multiple reports; otherwise,
reporting entity SHOULD note only the final configuration observed the
reporting entity <bcp14>SHOULD</bcp14> note only the final configuration observe
d
during the period. See below for further information.</t> during the period. See below for further information.</t>
<section anchor="description-of-the-content-xml-file" numbered="true" re
<section anchor="description-of-the-content-xml-file"><name>Description of the c moveInRFC="false" toc="include" pn="section-3.1.1">
ontent XML file</name> <name slugifiedName="name-description-of-the-content-">Description of
<t>NOTE TO RFC EDITOR: We tried a few various formats for these tables. If you the Content of the XML File</name>
would like to see those other formats, we can send over those attempts at <t indent="0" pn="section-3.1.1-1">The format for these reports is def
your request. Please remove this comment before publishing.</t> ined in the XML Schema Definition
<t>The format for these reports is defined in the XML Schema Definition (XSD) in <xref target="xsd" format="default" sectionFormat="of" derivedContent="
(XSD) in <xref target="xsd"></xref>. The XSD includes the possible Appendix A"/>. The XSD includes the possible
values for some of the elements below. Most of these values have a definition values for some of the elements below. Most of these values have a definition
tied to <xref target="I-D.ietf-dmarc-dmarcbis"></xref>.</t> tied to <xref target="RFC9989" format="default" sectionFormat="of" derivedConten
<t>The format is also described in the following sections. Each section t="RFC9989"/>.</t>
<t indent="0" pn="section-3.1.1-2">The format is also described in the
following sections. Each section
describes a collection of sibling elements in the XML hierarchy. describes a collection of sibling elements in the XML hierarchy.
There are pointers to where in the hierarchy each table fits.</t> There are pointers to where in the hierarchy each table fits.</t>
<t>If a document does not match the the specified format, the document <t indent="0" pn="section-3.1.1-3">If a document does not match the sp
evaluator SHOULD discard the report. The evaluator MAY choose to try to utilize ecified format, the document
some of the data, though if the format is in question, so may be the data. The evaluator <bcp14>SHOULD</bcp14> discard the report. The evaluator <bcp14>MAY</bc
report evaluator MAY choose to contact the report generator so p14> choose to try to utilize
some of the data; however, if the format is in question, the data may be as well
. The
report evaluator <bcp14>MAY</bcp14> choose to contact the report generator so
that they may be alerted to an issue with the report format.</t> that they may be alerted to an issue with the report format.</t>
<t>The column &quot;#&quot; specifies how many times an element may appear, this <t indent="0" pn="section-3.1.1-4">The column "#" specifies how many t imes an element may appear -- this
is sometimes referred to as multiplicity. The possible values are:</t> is sometimes referred to as multiplicity. The possible values are:</t>
<dl spacing="normal" indent="3" newline="false" pn="section-3.1.1-5">
<dl spacing="compact"> <dt pn="section-3.1.1-5.1">O:</dt>
<dt>O:</dt> <dd pn="section-3.1.1-5.2">
<dd><bcp14>OPTIONAL</bcp14>, zero or one element</dd> <bcp14>OPTIONAL</bcp14>, zero or one element</dd>
<dt>R:</dt> <dt pn="section-3.1.1-5.3">R:</dt>
<dd><bcp14>REQUIRED</bcp14>, exactly one element</dd> <dd pn="section-3.1.1-5.4">
<dt>*:</dt> <bcp14>REQUIRED</bcp14>, exactly one element</dd>
<dd><bcp14>OPTIONAL</bcp14>, zero or more elements</dd> <dt pn="section-3.1.1-5.5">*:</dt>
<dt>+:</dt> <dd pn="section-3.1.1-5.6">
<dd><bcp14>REQUIRED</bcp14>, one or more elements</dd> <bcp14>OPTIONAL</bcp14>, zero or more elements</dd>
</dl> <dt pn="section-3.1.1-5.7">+:</dt>
<t>Some elements contain text meant for humans and support an optional <dd pn="section-3.1.1-5.8">
&quot;lang&quot; attribute whose value indicate the language of its contents. <bcp14>REQUIRED</bcp14>, one or more elements</dd>
The default value is &quot;en&quot;. </dl>
Elements supporting this optional attribute is marked with &quot;[@lang]&quot; <t indent="0" pn="section-3.1.1-6">Some elements contain text meant fo
r humans and support an optional
"lang" attribute whose value indicates the language of its contents.
The default value is "en".
Elements supporting this optional attribute are marked with "[@lang]"
at the start of their content description in the following tables.</t> at the start of their content description in the following tables.</t>
<section anchor="xml-root-element" numbered="true" removeInRFC="false"
<section anchor="xml-root-element"><name>XML root element</name> toc="exclude" pn="section-3.1.1.1">
<t>DMARC aggregate feedback reports have the root element &quot;feedback&quot; <name slugifiedName="name-xml-root-element">XML Root Element</name>
<t indent="0" pn="section-3.1.1.1-1">DMARC aggregate feedback report
s have the root element "feedback"
with its XML namespace set to the DMARC namespace.</t> with its XML namespace set to the DMARC namespace.</t>
<table align="left"><name>The XML root element. <table align="center" pn="table-1">
</name> <name slugifiedName="name-the-xml-root-element">The XML Root Eleme
<thead> nt</name>
<tr> <thead>
<th>Element name</th> <tr>
<th>#</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">#</th>
</tr> <th align="left" colspan="1" rowspan="1">Content</th>
</thead> </tr>
</thead>
<tbody> <tbody>
<tr> <tr>
<td>feedback</td> <td align="left" colspan="1" rowspan="1">feedback</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>First level elements, see <xref target="xml-first-level"></xref></td> <td align="left" colspan="1" rowspan="1">First level elements;
</tr> see <xref target="xml-first-level" format="default" sectionFormat="of" derivedC
</tbody> ontent="Section 3.1.1.2"/></td>
</table></section> </tr>
</tbody>
<section anchor="xml-first-level"><name>First Level Elements</name> </table>
<t>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t </section>
> <section anchor="xml-first-level" numbered="true" removeInRFC="false"
<table align="left"><name>First level elements of the Aggregate Feedback Report. toc="exclude" pn="section-3.1.1.2">
<name slugifiedName="name-first-level-elements">First Level Elements
</name>
<t indent="0" pn="section-3.1.1.2-1">The elements in this table <bcp
14>MUST</bcp14> appear in the order listed.</t>
<table align="center" pn="table-2">
<name slugifiedName="name-first-level-elements-of-the">First Level
Elements of the Aggregate Feedback Report
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">version</td>
<td>version</td> <td align="left" colspan="1" rowspan="1">O</td>
<td>O</td> <td align="left" colspan="1" rowspan="1">
<td><bcp14>MUST</bcp14> have the value 1.0.</td> <bcp14>MUST</bcp14> have the value 1.0.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">report_metadata</td>
<td>report_metadata</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">Report generator meta
<td>Report generator metadata, see <xref target="xml-report-metadata"></xref>.</ data; see <xref target="xml-report-metadata" format="default" sectionFormat="of"
td> derivedContent="Section 3.1.1.3"/>.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">policy_published</td>
<td>policy_published</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">The DMARC policy conf
<td>The DMARC policy configuration observed by the receiving system, see <xref t iguration observed by the receiving system; see <xref target="xml-policy-publish
arget="xml-policy-published"></xref>.</td> ed" format="default" sectionFormat="of" derivedContent="Section 3.1.1.5"/>.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">extension</td>
<td>extension</td> <td align="left" colspan="1" rowspan="1">O</td>
<td>O</td> <td align="left" colspan="1" rowspan="1">Allows for future ext
<td>Allows for future extensibility, see <xref target="xml-extension"></xref></t ensibility; see <xref target="xml-extension" format="default" sectionFormat="of"
d> derivedContent="Section 3.1.1.6"/>.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">record</td>
<td>record</td> <td align="left" colspan="1" rowspan="1">+</td>
<td>+</td> <td align="left" colspan="1" rowspan="1">Record(s) of the feed
<td>Record(s) of the feedback from the report generator, see <xref target="xml-r back from the report generator; see <xref target="xml-record" format="default" s
ecord"></xref>.</td> ectionFormat="of" derivedContent="Section 3.1.1.7"/>.</td>
</tr> </tr>
</tbody> </tbody>
</table><t>There <bcp14>MUST</bcp14> be at least one &quot;record&quot; element, </table>
they contain data <t indent="0" pn="section-3.1.1.2-3">There <bcp14>MUST</bcp14> be at
stating which IP addresses were seen to have delivered messages for least one "record" element; these elements contain data
stating that IP addresses were seen to have delivered messages for
the Author Domain to the receiving system. For each IP address that the Author Domain to the receiving system. For each IP address that
is being reported, there will be at least one &quot;record&quot; element.</t> is being reported, there will be at least one "record" element.</t>
</section> </section>
<section anchor="xml-report-metadata" numbered="true" removeInRFC="fal
<section anchor="xml-report-metadata"><name>Report generator metadata</name> se" toc="exclude" pn="section-3.1.1.3">
<table align="left"><name>Report generator metadata <name slugifiedName="name-report-generator-metadata">Report Generato
r Metadata</name>
<table align="center" pn="table-3">
<name slugifiedName="name-report-generator-metadata-2">Report Gene
rator Metadata
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">org_name</td>
<td>org_name</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">Name of the Reporting
<td>Name of the Reporting Organization.</td> Organization.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">email</td>
<td>email</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">Contact to use when c
<td>Contact to use when contacting the Reporting Organization.</td> ontacting the Reporting Organization.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">extra_contact_info</t
<td>extra_contact_info</td> d>
<td>O</td> <td align="left" colspan="1" rowspan="1">O</td>
<td>[@lang] Additional contact details.</td> <td align="left" colspan="1" rowspan="1">[@lang] Additional co
</tr> ntact details.</td>
</tr>
<tr> <tr>
<td>report_id</td> <td align="left" colspan="1" rowspan="1">report_id</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>Unique Report-ID, see <xref target="report-id"></xref>.</td> <td align="left" colspan="1" rowspan="1">Unique Report-ID; see
</tr> <xref target="report-id" format="default" sectionFormat="of" derivedContent="Se
ction 3.5.1"/>.</td>
<tr> </tr>
<td>date_range</td> <tr>
<td>R</td> <td align="left" colspan="1" rowspan="1">date_range</td>
<td>The reporting period, see <xref target="xml-date-range"></xref>.</td> <td align="left" colspan="1" rowspan="1">R</td>
</tr> <td align="left" colspan="1" rowspan="1">The reporting period;
see <xref target="xml-date-range" format="default" sectionFormat="of" derivedCo
<tr> ntent="Section 3.1.1.4"/>.</td>
<td>error</td> </tr>
<td>O</td> <tr>
<td>[@lang] Error messages encountered when processing the DMARC Policy Record, <td align="left" colspan="1" rowspan="1">error</td>
see <xref target="error"></xref>.</td> <td align="left" colspan="1" rowspan="1">O</td>
</tr> <td align="left" colspan="1" rowspan="1">[@lang] Error message
s encountered when processing the DMARC Policy Record; see <xref target="error"
<tr> format="default" sectionFormat="of" derivedContent="Section 3.1.5"/>.</td>
<td>generator</td> </tr>
<td>O</td> <tr>
<td>The name and version of the report generator; this can help the Report Consu <td align="left" colspan="1" rowspan="1">generator</td>
mer find out where to report bugs.</td> <td align="left" colspan="1" rowspan="1">O</td>
</tr> <td align="left" colspan="1" rowspan="1">The name and version
</tbody> of the report generator; this can help the Report Consumer find out where to rep
</table></section> ort bugs.</td>
</tr>
<section anchor="xml-date-range"><name>Contents of the &quot;date_range&quot; el </tbody>
ement</name> </table>
<t>The time range in UTC defining the reporting period of this report.</t> </section>
<table align="left"><name>Contents of the &quot;date_range&quot; element <section anchor="xml-date-range" numbered="true" removeInRFC="false" t
oc="exclude" pn="section-3.1.1.4">
<name slugifiedName="name-contents-of-the-date_range-">Contents of t
he "date_range" Element</name>
<t indent="0" pn="section-3.1.1.4-1">This element describes the time
range in UTC defining the reporting period of this report.</t>
<table align="center" pn="table-4">
<name slugifiedName="name-contents-of-the-date_range-e">Contents o
f the "date_range" Element
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">begin</td>
<td>begin</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">Start of the reportin
<td>Start of the reporting period.</td> g period.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">end</td>
<td>end</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">End of the reporting
<td>End of the reporting period.</td> period.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>&quot;begin&quot; and &quot;end&quot; contain the number of seconds since ep on-3.1.1.4-3">
och.</li> <li pn="section-3.1.1.4-3.1">"begin" and "end" contain the number
</ul> of seconds since the epoch.</li>
<t>The &quot;begin&quot; and &quot;end&quot; are meant to denote the reporting p </ul>
eriod, and not <t indent="0" pn="section-3.1.1.4-4">The "begin" and "end" elements
are meant to denote the reporting period and not
the first/last observed message from the reporting period. When generating the first/last observed message from the reporting period. When generating
reports, these reporting periods SHOULD NOT overlap. Typically, the reports, these reporting periods <bcp14>SHOULD NOT</bcp14> overlap. Typically, the
reporting period will encompass a single UTC day, beginning at 0000UTC.</t> reporting period will encompass a single UTC day, beginning at 0000UTC.</t>
</section> </section>
<section anchor="xml-policy-published" numbered="true" removeInRFC="fa
<section anchor="xml-policy-published"><name>Contents of the &quot;policy_publis lse" toc="exclude" pn="section-3.1.1.5">
hed&quot; element</name> <name slugifiedName="name-contents-of-the-policy_publ">Contents of t
<t>Information on the DMARC Policy Record published for the Author Domain. he "policy_published" Element</name>
The elements from &quot;p&quot; and onwards contain the discovered or default <t indent="0" pn="section-3.1.1.5-1">This element provides informati
on on the DMARC Policy Record published for the Author Domain.
The elements from "p" and onwards contain the discovered or default
value for the DMARC policy applied.</t> value for the DMARC policy applied.</t>
<t>Unspecified tags have their default values.</t> <t indent="0" pn="section-3.1.1.5-2">Unspecified tags have their def
<table align="left"><name>Contents of the &quot;policy_published&quot; element ault values.</t>
<table align="center" pn="table-5">
<name slugifiedName="name-contents-of-the-policy_publi">Contents o
f the "policy_published" Element
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">domain</td>
<td>domain</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">The DMARC Policy Doma
<td>The DMARC Policy Domain.</td> in.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">discovery_method</td>
<td>discovery_method</td> <td align="left" colspan="1" rowspan="1">O</td>
<td>O</td> <td align="left" colspan="1" rowspan="1">The method used to di
<td>The method used to discover the DMARC Policy Record used during evaluation.< scover the DMARC Policy Record used during evaluation.</td>
/td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">p</td>
<tr> <td align="left" colspan="1" rowspan="1">R</td>
<td>p</td> <td align="left" colspan="1" rowspan="1">A Domain Owner Assess
<td>R</td> ment Policy.</td>
<td>A Domain Owner Assessment Policy.</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">sp</td>
<tr> <td align="left" colspan="1" rowspan="1">O</td>
<td>sp</td> <td align="left" colspan="1" rowspan="1">A Domain Owner Assess
<td>O</td> ment Policy.</td>
<td>A Domain Owner Assessment Policy.</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">np</td>
<tr> <td align="left" colspan="1" rowspan="1">O</td>
<td>np</td> <td align="left" colspan="1" rowspan="1">A Domain Owner Assess
<td>O</td> ment Policy.</td>
<td>A Domain Owner Assessment Policy.</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">fo</td>
<tr> <td align="left" colspan="1" rowspan="1">O</td>
<td>fo</td> <td align="left" colspan="1" rowspan="1">The value for the fai
<td>O</td> lure reporting options.</td>
<td>The value for the failure reporting options.</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">adkim</td>
<tr> <td align="left" colspan="1" rowspan="1">O</td>
<td>adkim</td> <td align="left" colspan="1" rowspan="1">The DKIM Identifier A
<td>O</td> lignment mode.</td>
<td>The DKIM Identifier Alignment mode.</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">aspf</td>
<tr> <td align="left" colspan="1" rowspan="1">O</td>
<td>aspf</td> <td align="left" colspan="1" rowspan="1">The SPF Identifier Al
<td>O</td> ignment mode.</td>
<td>The SPF Identifier Alignment mode.</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">testing</td>
<tr> <td align="left" colspan="1" rowspan="1">O</td>
<td>testing</td> <td align="left" colspan="1" rowspan="1">The value of the "t"
<td>O</td> tag.</td>
<td>The value of the &quot;t&quot; tag.</td> </tr>
</tr> </tbody>
</tbody> </table>
</table> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<ul> on-3.1.1.5-4">
<li><t>&quot;discovery_method&quot; can have the value &quot;psl&quot; or &quot; <li pn="section-3.1.1.5-4.1">
treewalk&quot;, where <t indent="0" pn="section-3.1.1.5-4.1.1">"discovery_method" can
&quot;psl&quot; is the method from <xref target="RFC7489"></xref> and &quot;tree have the value "psl" or "treewalk", where
walk&quot; is described "psl" is the method from <xref target="RFC7489" format="default" sectionFormat="
in <xref target="I-D.ietf-dmarc-dmarcbis"></xref>.</t> of" derivedContent="RFC7489"/> and "treewalk" is described
</li> in <xref target="RFC9989" format="default" sectionFormat="of" derivedContent="RF
<li><t>Many of the items above (p, sp, etc.) are defined in C9989"/>.</t>
the <xref target="I-D.ietf-dmarc-dmarcbis"></xref> document.</t> </li>
</li> <li pn="section-3.1.1.5-4.2">
</ul> <t indent="0" pn="section-3.1.1.5-4.2.1">Many of the items above
</section> (p, sp, etc.) are defined in
<xref target="RFC9989" format="default" sectionFormat="of" derivedContent="RFC99
<section anchor="xml-extension"><name>Contents of the &quot;extension&quot; elem 89"/>.</t>
ent</name> </li>
<t>Use of extensions may cause elements to be added here. </ul>
</section>
<section anchor="xml-extension" numbered="true" removeInRFC="false" to
c="exclude" pn="section-3.1.1.6">
<name slugifiedName="name-contents-of-the-extension-e">Contents of t
he "extension" Element</name>
<t indent="0" pn="section-3.1.1.6-1">Use of extensions may cause ele
ments to be added here.
These elements <bcp14>MUST</bcp14> be namespaced.</t> These elements <bcp14>MUST</bcp14> be namespaced.</t>
<table align="left"><name>Contents of the &quot;extension&quot; element <table align="center" pn="table-6">
<name slugifiedName="name-contents-of-the-extension-el">Contents o
f the "extension" Element
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">&lt;any namespaced el
<td>&lt;any namespaced element&gt;</td> ement&gt;</td>
<td>*</td> <td align="left" colspan="1" rowspan="1">*</td>
<td>File level elements defined by an extension.</td> <td align="left" colspan="1" rowspan="1">File level elements d
</tr> efined by an extension.</td>
</tbody> </tr>
</table> </tbody>
<ul> </table>
<li><t>&quot;&lt;any namespaced element&gt;&quot;</t> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<t>Zero or more elements in the namespace of the related on-3.1.1.6-3">
extension declared in the XML root element.</t> <li pn="section-3.1.1.6-3.1">"&lt;any namespaced element&gt;": Zer
</li> o or more elements in the namespace of the related
</ul> extension declared in the XML root element.</li>
</section> </ul>
</section>
<section anchor="xml-record"><name>Contents of the &quot;record&quot; element</n <section anchor="xml-record" numbered="true" removeInRFC="false" toc="
ame> exclude" pn="section-3.1.1.7">
<t>The report <bcp14>MUST</bcp14> contain record(s) stating which IP addresses w <name slugifiedName="name-contents-of-the-record-elem">Contents of t
ere he "record" Element</name>
<t indent="0" pn="section-3.1.1.7-1">The report <bcp14>MUST</bcp14>
contain one or more records stating which IP addresses were
seen to have delivered messages for the Author Domain to the seen to have delivered messages for the Author Domain to the
receiving system. For each IP address that is being reported, receiving system. For each IP address that is being reported,
there will be at least one &quot;record&quot; element.</t> there will be at least one "record" element.</t>
<t>This element contains all the authentication results that were <t indent="0" pn="section-3.1.1.7-2">This element contains all the a
uthentication results that were
evaluated by the receiving system for the given set of messages.</t> evaluated by the receiving system for the given set of messages.</t>
<t>An unlimited number of &quot;record&quot; elements may be specified.</t> <t indent="0" pn="section-3.1.1.7-3">An unlimited number of "record"
<t>Use of extensions may cause other elements to be added to the end of elements may be specified.</t>
the record, such elements <bcp14>MUST</bcp14> be namespaced.</t> <t indent="0" pn="section-3.1.1.7-4">Use of extensions may cause oth
<t>One record per (IP, result, authenitication identifiers) tuples.</t> er elements to be added to the end of
<t>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t the record; such elements <bcp14>MUST</bcp14> be namespaced.</t>
> <t indent="0" pn="section-3.1.1.7-5">One record (IP, result, authent
<table align="left"><name>Contents of the &quot;record&quot; element ication identifiers) per tuple.</t>
<t indent="0" pn="section-3.1.1.7-6">The elements in this table <bcp
14>MUST</bcp14> appear in the order listed.</t>
<table align="center" pn="table-7">
<name slugifiedName="name-contents-of-the-record-eleme">Contents o
f the "record" Element
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">row</td>
<td>row</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">See <xref target="xml
<td>See <xref target="xml-row"></xref>.</td> -row" format="default" sectionFormat="of" derivedContent="Section 3.1.1.8"/>.</t
</tr> d>
</tr>
<tr> <tr>
<td>identifiers</td> <td align="left" colspan="1" rowspan="1">identifiers</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>The data that was used to apply policy for the given &quot;row&quot;, see <x <td align="left" colspan="1" rowspan="1">The data that was use
ref target="xml-identifiers"></xref>.</td> d to apply policy for the given "row"; see <xref target="xml-identifiers" format
</tr> ="default" sectionFormat="of" derivedContent="Section 3.1.1.10"/>.</td>
</tr>
<tr> <tr>
<td>auth_results</td> <td align="left" colspan="1" rowspan="1">auth_results</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>The data related to authenticating the messages associated with this sending <td align="left" colspan="1" rowspan="1">The data related to a
IP address, see <xref target="xml-auth-results"></xref>.</td> uthenticating the messages associated with this sending IP address; see <xref ta
</tr> rget="xml-auth-results" format="default" sectionFormat="of" derivedContent="Sect
ion 3.1.1.11"/>.</td>
<tr> </tr>
<td>&lt;any namespaced element&gt;</td> <tr>
<td>*</td> <td align="left" colspan="1" rowspan="1">&lt;any namespaced el
<td>Record level elements defined by an extension.</td> ement&gt;</td>
</tr> <td align="left" colspan="1" rowspan="1">*</td>
</tbody> <td align="left" colspan="1" rowspan="1">Record level elements
</table> defined by an extension.</td>
<ul> </tr>
<li><t>&quot;&lt;any namespaced element&gt;&quot;</t> </tbody>
<t>Zero or more elements in the namespace of the related </table>
extension declared in the XML root element.</t> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
</li> on-3.1.1.7-8">
</ul> <li pn="section-3.1.1.7-8.1">"&lt;any namespaced element&gt;": Zer
</section> o or more elements in the namespace of the related
extension declared in the XML root element.</li>
<section anchor="xml-row"><name>Contents of the &quot;row&quot; element</name> </ul>
<t>A &quot;row&quot; element contains the details of the connecting system, and </section>
how many mails were received from it, for the particular combination <section anchor="xml-row" numbered="true" removeInRFC="false" toc="exc
lude" pn="section-3.1.1.8">
<name slugifiedName="name-contents-of-the-row-element">Contents of t
he "row" Element</name>
<t indent="0" pn="section-3.1.1.8-1">A "row" element contains the de
tails of the connecting system, and
how many mail messages were received from it, for the particular combination
of the policy evaluated.</t> of the policy evaluated.</t>
<table align="left"><name>Contents of the &quot;row&quot; element <table align="center" pn="table-8">
<name slugifiedName="name-contents-of-the-row-element-2">Contents
of the "row" Element
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">source_ip</td>
<td>source_ip</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">The connecting IP add
<td>The connecting IP address. IPv4address or IPv6address as defined in <xref ta ress. IPv4address or IPv6address as defined in <xref target="RFC3986" sectionFor
rget="RFC3986" sectionFormat="of" relative="#" section="3.2.2"></xref></td> mat="of" section="3.2.2" format="default" derivedLink="https://rfc-editor.org/rf
</tr> c/rfc3986#section-3.2.2" derivedContent="RFC3986"/>.</td>
</tr>
<tr> <tr>
<td>count</td> <td align="left" colspan="1" rowspan="1">count</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>Number of messages for which the &quot;policy_evaluated&quot; was applied.</ <td align="left" colspan="1" rowspan="1">Number of messages fo
td> r which the "policy_evaluated" was applied.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">policy_evaluated</td>
<td>policy_evaluated</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">The DMARC disposition
<td>The DMARC disposition applied to matching messages, see <xref target="xml-po applied to matching messages; see <xref target="xml-policy-evaluated" format="d
licy-evaluated"></xref>.</td> efault" sectionFormat="of" derivedContent="Section 3.1.1.9"/>.</td>
</tr> </tr>
</tbody> </tbody>
</table></section> </table>
</section>
<section anchor="xml-policy-evaluated"><name>Contents of the &quot;policy_evalua <section anchor="xml-policy-evaluated" numbered="true" removeInRFC="fa
ted&quot; element</name> lse" toc="exclude" pn="section-3.1.1.9">
<t>The results of applying the DMARC policy. If alignment fails and the <name slugifiedName="name-contents-of-the-policy_eval">Contents of t
he "policy_evaluated" Element</name>
<t indent="0" pn="section-3.1.1.9-1">This element describes the resu
lts of applying the DMARC policy. If alignment fails and the
policy applied does not match the DMARC Policy Domain's configured policy, policy applied does not match the DMARC Policy Domain's configured policy,
the &quot;reason&quot; element <bcp14>MUST</bcp14> be included.</t> the "reason" element <bcp14>MUST</bcp14> be included.</t>
<t>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t <t indent="0" pn="section-3.1.1.9-2">The elements in this table <bcp
> 14>MUST</bcp14> appear in the order listed.</t>
<table align="left"><name>Contents of the &quot;policy_evaluated&quot; element <table align="center" pn="table-9">
<name slugifiedName="name-contents-of-the-policy_evalu">Contents o
f the "policy_evaluated" Element
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">disposition</td>
<td>disposition</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">The result of applyin
<td>The result of applying the DMARC policy.</td> g the DMARC policy.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">dkim</td>
<td>dkim</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">The result of the DKI
<td>The result of the DKIM DMARC Identifier alignment test.</td> M DMARC Identifier Alignment test.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">spf</td>
<td>spf</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">The result of the SPF
<td>The result of the SPF DMARC Identifier alignment test.</td> DMARC Identifier Alignment test.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">reason</td>
<td>reason</td> <td align="left" colspan="1" rowspan="1">*</td>
<td>*</td> <td align="left" colspan="1" rowspan="1">Policy override reaso
<td>Policy override reason, see <xref target="xml-reason"></xref>.</td> n; see <xref target="xml-reason" format="default" sectionFormat="of" derivedCont
</tr> ent="Section 3.1.1.14"/>.</td>
</tbody> </tr>
</table> </tbody>
<ul> </table>
<li><t>&quot;spf&quot; and &quot;dkim&quot; <bcp14>MUST</bcp14> be the evaluated <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
values as they relate to on-3.1.1.9-4">
<li pn="section-3.1.1.9-4.1">
<t indent="0" pn="section-3.1.1.9-4.1.1">"spf" and "dkim" <bcp14
>MUST</bcp14> be the evaluated values as they relate to
DMARC, not the values the receiver may have used when overriding the DMARC, not the values the receiver may have used when overriding the
policy.</t> policy.</t>
</li> </li>
<li><t>&quot;reason&quot; elements are meant to include any notes the reporter m <li pn="section-3.1.1.9-4.2">
ight <t indent="0" pn="section-3.1.1.9-4.2.1">"reason" elements are m
want to include as to why the &quot;disposition&quot; policy does not match the eant to contain any notes the reporter might
&quot;policy_published&quot;, such as a local policy override.</t> want to include as to why the "disposition" policy does not match the
</li> "policy_published", such as a local policy override.</t>
</ul> </li>
</section> </ul>
</section>
<section anchor="xml-identifiers"><name>Contents of the &quot;identifiers&quot; <section anchor="xml-identifiers" numbered="true" removeInRFC="false"
element</name> toc="exclude" pn="section-3.1.1.10">
<table align="left"><name>Contents of the &quot;identifiers&quot; element <name slugifiedName="name-contents-of-the-identifiers">Contents of t
he "identifiers" Element</name>
<table align="center" pn="table-10">
<name slugifiedName="name-contents-of-the-identifiers-">Contents o
f the "identifiers" Element
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">header_from</td>
<td>header_from</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">The RFC5322.From doma
<td>The RFC5322.From domain from the message.</td> in from the message.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">envelope_from</td>
<td>envelope_from</td> <td align="left" colspan="1" rowspan="1">O</td>
<td>O</td> <td align="left" colspan="1" rowspan="1">The RFC5321.MailFrom
<td>The RFC5321.MailFrom domain that the SPF check has been applied to.</td> domain that the SPF check has been applied to.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">envelope_to</td>
<td>envelope_to</td> <td align="left" colspan="1" rowspan="1">O</td>
<td>O</td> <td align="left" colspan="1" rowspan="1">The RFC5321.RcptTo do
<td>The RFC5321.RcptTo domain from the message.</td> main from the message.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>&quot;envelope_from&quot; <bcp14>MAY</bcp14> be existing but empty if the me on-3.1.1.10-2">
ssage had a <li pn="section-3.1.1.10-2.1">"envelope_from" <bcp14>MAY</bcp14> e
null reverse-path (see <xref target="RFC5321" sectionFormat="of" relative="#" se xist but be empty if the message had a
ction="4.5.5"></xref>).</li> null reverse-path (see <xref target="RFC5321" sectionFormat="of" section="4.5.5"
</ul> format="default" derivedLink="https://rfc-editor.org/rfc/rfc5321#section-4.5.5"
</section> derivedContent="RFC5321"/>).</li>
</ul>
<section anchor="xml-auth-results"><name>Contents of the &quot;auth_results&quot </section>
; element</name> <section anchor="xml-auth-results" numbered="true" removeInRFC="false"
<t>Contains DKIM and SPF results, uninterpreted with respect to DMARC.</t> toc="exclude" pn="section-3.1.1.11">
<t>If validation is attempted for any DKIM signature, the results <name slugifiedName="name-contents-of-the-auth_result">Contents of t
<bcp14>MUST</bcp14> be included in the report (within reason, see he "auth_results" Element</name>
<xref target="dkim-signatures"></xref>, &quot;DKIM Signatures in Aggregate Repor <t indent="0" pn="section-3.1.1.11-1">This element contains DKIM and
ts&quot;, below for SPF results, uninterpreted with respect to DMARC.</t>
<t indent="0" pn="section-3.1.1.11-2">If validation is attempted for
any DKIM signature, the results
<bcp14>MUST</bcp14> be included in the report (within reason; see
<xref target="dkim-signatures" format="default" sectionFormat="of" derivedConten
t="Section 3.1.3"/> ("DKIM Signatures in Aggregate Reports") below for
handling numerous signatures).</t> handling numerous signatures).</t>
<t>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t <t indent="0" pn="section-3.1.1.11-3">The elements in this table <bc
> p14>MUST</bcp14> appear in the order listed.</t>
<table align="left"><name>Contents of the &quot;auth_results&quot; element <table align="center" pn="table-11">
<name slugifiedName="name-contents-of-the-auth_results">Contents o
f the "auth_results" Element
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">dkim</td>
<td>dkim</td> <td align="left" colspan="1" rowspan="1">*</td>
<td>*</td> <td align="left" colspan="1" rowspan="1">DKIM authentication r
<td>DKIM authentication result, see <xref target="xml-dkim"></xref>.</td> esult; see <xref target="xml-dkim" format="default" sectionFormat="of" derivedCo
</tr> ntent="Section 3.1.1.12"/>.</td>
</tr>
<tr> <tr>
<td>spf</td> <td align="left" colspan="1" rowspan="1">spf</td>
<td>O</td> <td align="left" colspan="1" rowspan="1">O</td>
<td>SPF authentication result, see <xref target="xml-spf"></xref>.</td> <td align="left" colspan="1" rowspan="1">SPF authentication re
</tr> sult; see <xref target="xml-spf" format="default" sectionFormat="of" derivedCont
</tbody> ent="Section 3.1.1.13"/>.</td>
</table></section> </tr>
</tbody>
<section anchor="xml-dkim"><name>Contents of the &quot;dkim&quot; element</name> </table>
<table align="left"><name>Contents of the &quot;dkim&quot; element </section>
<section anchor="xml-dkim" numbered="true" removeInRFC="false" toc="ex
clude" pn="section-3.1.1.12">
<name slugifiedName="name-contents-of-the-dkim-elemen">Contents of t
he "dkim" Element</name>
<table align="center" pn="table-12">
<name slugifiedName="name-contents-of-the-dkim-element">Contents o
f the "dkim" Element
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">domain</td>
<td>domain</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">The domain that was u
<td>The domain that was used during validation (the &quot;d=&quot; tag in the si sed during validation (the "d=" tag in the signature).</td>
gnature).</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">selector</td>
<tr> <td align="left" colspan="1" rowspan="1">R</td>
<td>selector</td> <td align="left" colspan="1" rowspan="1">The selector that was
<td>R</td> used during validation (the "s=" tag in the signature).</td>
<td>The selector that was used during validation (the &quot;s=&quot; tag in the </tr>
signature).</td> <tr>
</tr> <td align="left" colspan="1" rowspan="1">result</td>
<td align="left" colspan="1" rowspan="1">R</td>
<tr> <td align="left" colspan="1" rowspan="1">DKIM verification res
<td>result</td> ult; see below.</td>
<td>R</td> </tr>
<td>DKIM verification result, see below.</td> <tr>
</tr> <td align="left" colspan="1" rowspan="1">human_result</td>
<td align="left" colspan="1" rowspan="1">O</td>
<tr> <td align="left" colspan="1" rowspan="1">[@lang] More descript
<td>human_result</td> ive information to the Domain Owner relating to evaluation failures.</td>
<td>O</td> </tr>
<td>[@lang] More descriptive information to the Domain Owner relating to evaluat </tbody>
ion failures.</td> </table>
</tr> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
</tbody> on-3.1.1.12-2">
</table> <li pn="section-3.1.1.12-2.1">"result" is a lowercase string where
<ul spacing="compact"> the value is one of the results
<li>&quot;result&quot; is a lower-case string where the value is one of the resu defined in <xref target="RFC8601" sectionFormat="of" section="2.7.1" format="def
lts ault" derivedLink="https://rfc-editor.org/rfc/rfc8601#section-2.7.1" derivedCont
defined in <xref target="RFC8601" sectionFormat="of" relative="#" section="2.7.1 ent="RFC8601"/>.</li>
"></xref>.</li> </ul>
</ul> </section>
</section> <section anchor="xml-spf" numbered="true" removeInRFC="false" toc="exc
lude" pn="section-3.1.1.13">
<section anchor="xml-spf"><name>Contents of the &quot;spf&quot; element</name> <name slugifiedName="name-contents-of-the-spf-element">Contents of t
<t>Only the &quot;MAIL FROM&quot; identity (see <xref target="RFC7208" sectionFo he "spf" Element</name>
rmat="of" relative="#" section="2.4"></xref>) <t indent="0" pn="section-3.1.1.13-1">Only the "MAIL FROM" identity
(see <xref target="RFC7208" sectionFormat="of" section="2.4" format="default" de
rivedLink="https://rfc-editor.org/rfc/rfc7208#section-2.4" derivedContent="RFC72
08"/>)
is used in DMARC.</t> is used in DMARC.</t>
<table align="left"><name>Contents of the &quot;spf&quot; element <table align="center" pn="table-13">
<name slugifiedName="name-contents-of-the-spf-element-2">Contents
of the "spf" Element
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">domain</td>
<td>domain</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">The domain that was u
<td>The domain that was used during validation.</td> sed during validation.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">scope</td>
<td>scope</td> <td align="left" colspan="1" rowspan="1">O</td>
<td>O</td> <td align="left" colspan="1" rowspan="1">The source of the dom
<td>The source of the domain used during validation.</td> ain used during validation.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">result</td>
<td>result</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">SPF verification resu
<td>SPF verification result, see below.</td> lt; see below.</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">human_result</td>
<td>human_result</td> <td align="left" colspan="1" rowspan="1">O</td>
<td>O</td> <td align="left" colspan="1" rowspan="1">[@lang] More descript
<td>[@lang] More descriptive information to the Domain Owner relating to evaluat ive information to the Domain Owner relating to evaluation failures.</td>
ion failures.</td> </tr>
</tr> </tbody>
</tbody> </table>
</table> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
<ul> on-3.1.1.13-3">
<li><t>The only valid value for the &quot;scope&quot; element is &quot;mfrom&quo <li pn="section-3.1.1.13-3.1">
t;.</t> <t indent="0" pn="section-3.1.1.13-3.1.1">The only valid value f
</li> or the "scope" element is "mfrom".</t>
<li><t>&quot;result&quot; is a lower-case string where the value is one of the r </li>
esults <li pn="section-3.1.1.13-3.2">
defined in <xref target="RFC8601" sectionFormat="of" relative="#" section="2.7.2 <t indent="0" pn="section-3.1.1.13-3.2.1">"result" is a lowercas
"></xref>.</t> e string where the value is one of the results
</li> defined in <xref target="RFC8601" sectionFormat="of" section="2.7.2" format="def
</ul> ault" derivedLink="https://rfc-editor.org/rfc/rfc8601#section-2.7.2" derivedCont
</section> ent="RFC8601"/>.</t>
</li>
<section anchor="xml-reason"><name>Contents of the &quot;reason&quot; element</n </ul>
ame> </section>
<t>The policy override reason consists of a pre-defined override type <section anchor="xml-reason" numbered="true" removeInRFC="false" toc="
and free-text comment, see <xref target="policy-override-reason"></xref></t> exclude" pn="section-3.1.1.14">
<table align="left"><name>Contents of the &quot;reason&quot; element <name slugifiedName="name-contents-of-the-reason-elem">Contents of t
he "reason" Element</name>
<t indent="0" pn="section-3.1.1.14-1">The policy override reason con
sists of a pre-defined override type
and free-text comment; see <xref target="policy-override-reason" format="default
" sectionFormat="of" derivedContent="Section 3.1.6"/>.</t>
<table align="center" pn="table-14">
<name slugifiedName="name-contents-of-the-reason-eleme">Contents o
f the "reason" Element
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Element name</th> <th align="left" colspan="1" rowspan="1">Element name</th>
<th>#</th> <th align="left" colspan="1" rowspan="1">#</th>
<th>Content</th> <th align="left" colspan="1" rowspan="1">Content</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">type</td>
<td>type</td> <td align="left" colspan="1" rowspan="1">R</td>
<td>R</td> <td align="left" colspan="1" rowspan="1">The reason the DMARC
<td>The reason the DMARC policy was overridden</td> policy was overridden</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">comment</td>
<td>comment</td> <td align="left" colspan="1" rowspan="1">O</td>
<td>O</td> <td align="left" colspan="1" rowspan="1">[@lang] Further detai
<td>[@lang] Further details, if available.</td> ls, if available.</td>
</tr> </tr>
</tbody> </tbody>
</table></section> </table>
</section> </section>
</section>
<section anchor="handling"><name>Handling Domains in Reports</name> <section anchor="handling" numbered="true" removeInRFC="false" toc="incl
<t>In the same report, there <bcp14>MUST</bcp14> be a single DMARC Policy Domain ude" pn="section-3.1.2">
, though there could be <name slugifiedName="name-handling-domains-in-reports">Handling Domain
multiple RFC5322.From Domains. Each RFC5322.From domain will create its own &qu s in Reports</name>
ot;record&quot; <t indent="0" pn="section-3.1.2-1">In the same report, there <bcp14>MU
ST</bcp14> be a single DMARC Policy Domain, though there could be
multiple RFC5322.From domains. Each RFC5322.From domain will create its own "re
cord"
within the report. Consider the case where there are three domains with traffic within the report. Consider the case where there are three domains with traffic
volume to report: example.com, foo.example.com, and bar.example.com. There will be volume to report: example.com, foo.example.com, and bar.example.com. There will be
explicit DMARC Policy Records for example.com and bar.example.com, with distinct policies. There explicit DMARC Policy Records for example.com and bar.example.com, with distinct policies. There
is no explicit DMARC Policy Record for foo.example.com, so it will be reliant on the is no explicit DMARC Policy Record for foo.example.com, so it will be reliant on the
policy described for example.com. For a report period, there would now be two r policy described for example.com. For a report period, there would now be two r
eports.<br /> eports.</t>
The first will be for bar.example.com, and contain only one &quot;record&quot;, <t indent="0" pn="section-3.1.2-2">The first report will be for bar.ex
for ample.com and contain only one "record", for
bar.example.com. The second report would be for example.com and contain multipl bar.example.com. The second report will be for example.com and will contain mul
e tiple
&quot;record&quot; elements, one for example.com and one for foo.example.com (an "record" elements, one for example.com and one for foo.example.com (and by exten
d extensibly, sion,
other &quot;record&quot; elements for subdomains which likewise did not have an other "record" elements for subdomains that likewise did not have an explicit
explicit
DMARC Policy Record).</t> DMARC Policy Record).</t>
</section> </section>
<section anchor="dkim-signatures" numbered="true" removeInRFC="false" to
<section anchor="dkim-signatures"><name>DKIM Signatures in Aggregate Reports</na c="include" pn="section-3.1.3">
me> <name slugifiedName="name-dkim-signatures-in-aggregat">DKIM Signatures
<t>Within a single message, the possibility exists that there could be multiple in Aggregate Reports</name>
DKIM <t indent="0" pn="section-3.1.3-1">Within a single message, the possib
ility exists that there could be multiple DKIM
signatures. When validation of the message occurs, some signatures may pass, signatures. When validation of the message occurs, some signatures may pass,
while some may not. As these pertain to DMARC, and especially to aggregate while some may not. As these pertain to DMARC, and especially to aggregate
reporting, reporters may not find it clear which DKIM signatures they should inc lude reporting, reporters may not find it clear which DKIM signatures they should inc lude
in a report. Signatures, regardless of outcome, could help the report ingester in a report. Signatures, regardless of outcome, could help the report ingester
determine the source of a message. However, there is a preference as to which determine the source of a message. However, there is a preference as to which
signatures are included.</t> signatures are included.</t>
<ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-
<ol spacing="compact"> 3.1.3-2">
<li>A signature that passes DKIM, in strict alignment with the RFC5322.From doma <li pn="section-3.1.3-2.1" derivedCounter="1.">A signature that passes DKIM, in
in</li> strict alignment with the RFC5322.From domain</li>
<li>A signature that passes DKIM, in relaxed alignment with the RFC5322.From dom <li pn="section-3.1.3-2.2" derivedCounter="2.">A signature that pass
ain</li> es DKIM, in relaxed alignment with the RFC5322.From domain</li>
<li>Any other DKIM signatures that pass</li> <li pn="section-3.1.3-2.3" derivedCounter="3.">Any other DKIM signat
<li>DKIM signatures that do not pass</li> ures that pass</li>
</ol> <li pn="section-3.1.3-2.4" derivedCounter="4.">DKIM signatures that
<t>A report <bcp14>SHOULD</bcp14> contain no more than 100 signatures for a give do not pass</li>
n &quot;row&quot;, in </ol>
<t indent="0" pn="section-3.1.3-3">A report <bcp14>SHOULD</bcp14> cont
ain no more than 100 signatures for a given "row", in
decreasing priority.</t> decreasing priority.</t>
</section> </section>
<section anchor="unique-identifiers-in-aggregate-reporting" numbered="tr
<section anchor="unique-identifiers-in-aggregate-reporting"><name>Unique Identif ue" removeInRFC="false" toc="include" pn="section-3.1.4">
iers in Aggregate Reporting</name> <name slugifiedName="name-unique-identifiers-in-aggre">Unique Identifi
<t>There are a few places where a unique identifier is specified as part of the ers in Aggregate Reporting</name>
<t indent="0" pn="section-3.1.4-1">There are a few places where a uniq
ue identifier is specified as part of the
body of the report, the subject, and so on. These unique identifiers should be body of the report, the subject, and so on. These unique identifiers should be
consistent per each report. Specified below, the reader will see a consistent per each report. Specified below, the reader will see a
&quot;Report-ID&quot; and &quot;unique-id&quot;. These are the fields that <bcp "Report-ID" and "unique-id". These are the fields that <bcp14>MUST</bcp14> be i
14>MUST</bcp14> be identical when used.</t> dentical when used.</t>
</section> </section>
<section anchor="error" numbered="true" removeInRFC="false" toc="include
<section anchor="error"><name>Error element</name> " pn="section-3.1.5">
<t>A few examples of information contained within the &quot;error&quot; element( <name slugifiedName="name-error-element">Error Element</name>
s):</t> <t indent="0" pn="section-3.1.5-1">Here are a few examples of informat
ion contained within the "error" element(s):</t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>DMARC Policy Record evaluation errors (invalid &quot;rua&quot; or &quot;sp&q -3.1.5-2">
uot;, etc.)</li> <li pn="section-3.1.5-2.1">DMARC Policy Record evaluation errors (in
<li>Multiple DMARC Policy Records at a given location</li> valid "rua", "sp", etc.)</li>
</ul> <li pn="section-3.1.5-2.2">Multiple DMARC Policy Records at a given
<t>Be mindful that the &quot;error&quot; element is an unbounded string, but sho location</li>
uld not contain </ul>
<t indent="0" pn="section-3.1.5-3">Be mindful that the "error" element
is an unbounded string but should not contain
an extremely large body. Provide enough information to assist the Domain Owner an extremely large body. Provide enough information to assist the Domain Owner
with understanding some issues with their authentication or DMARC Policy Record. </t> with understanding some issues with their authentication or DMARC Policy Record. </t>
</section> </section>
<section anchor="policy-override-reason" numbered="true" removeInRFC="fa
<section anchor="policy-override-reason"><name>Policy Override Reason</name> lse" toc="include" pn="section-3.1.6">
<t>The &quot;reason&quot; element, indicating an override of the DMARC policy, c <name slugifiedName="name-policy-override-reason">Policy Override Reas
onsists of a on</name>
mandatory &quot;type&quot; element and an optional &quot;comment&quot; element. <t indent="0" pn="section-3.1.6-1">The "reason" element, indicating an
The &quot;type&quot; element override of the DMARC policy, consists of a
<bcp14>MUST</bcp14> have one of the pre-defined values listed below. The &quot;c mandatory "type" element and an optional "comment" element. The "type" element
omment&quot; element <bcp14>MUST</bcp14> have one of the pre-defined values listed below. The "commen
t" element
is an unbounded string for providing further details.</t> is an unbounded string for providing further details.</t>
<t>Possible values for the policy override type:</t> <t indent="0" pn="section-3.1.6-2">Possible values for the policy over
<t>&quot;local_policy&quot;: The Mail Receiver's local policy exempted the messa ride type:</t>
ge <dl spacing="normal" newline="false" indent="3" pn="section-3.1.6-3">
<dt pn="section-3.1.6-3.1">"local_policy":</dt>
<dd pn="section-3.1.6-3.2">The Mail Receiver's local policy exempted
the message
from being subjected to the Domain Owner's requested policy from being subjected to the Domain Owner's requested policy
action.</t> action.</dd>
<t>&quot;mailing_list&quot;: Local heuristics determined that the message arrive <dt pn="section-3.1.6-3.3">"mailing_list":</dt>
d <dd pn="section-3.1.6-3.4">Local heuristics determined that the mess
age arrived
via a mailing list, and thus authentication of the original via a mailing list, and thus authentication of the original
message was not expected to succeed.</t> message was not expected to succeed.</dd>
<t>&quot;other&quot;: Some policy exception not covered by the other entries in <dt pn="section-3.1.6-3.5">"other":</dt>
this list occurred. Additional detail can be found in the <dd pn="section-3.1.6-3.6">Some policy exception not covered by the
&quot;comment&quot; element.</t> other entries in
<t>&quot;policy_test_mode&quot;: The message was exempted from application of po this list occurred. Additional details can be found in the
licy by "comment" element.</dd>
the testing mode (&quot;t&quot; tag) in the DMARC Policy Record.</t> <dt pn="section-3.1.6-3.7">"policy_test_mode":</dt>
<t>&quot;trusted_forwarder&quot;: Message authentication failure was anticipated <dd pn="section-3.1.6-3.8">The message was exempted from application
by of policy by
the testing mode ("t" tag) in the DMARC Policy Record.</dd>
<dt pn="section-3.1.6-3.9">"trusted_forwarder":</dt>
<dd pn="section-3.1.6-3.10">Message authentication failure was antic
ipated by
other evidence linking the message to a locally maintained list of other evidence linking the message to a locally maintained list of
known and trusted forwarders.</t> known and trusted forwarders.</dd>
</section> </dl>
</section> </section>
</section>
<section anchor="extensions"><name>Extensions</name> <section anchor="extensions" numbered="true" removeInRFC="false" toc="incl
<t>The document format supports optional elements for extensions. ude" pn="section-3.2">
<name slugifiedName="name-extensions">Extensions</name>
<t indent="0" pn="section-3.2-1">The document format supports optional e
lements for extensions.
The absence or existence of this section <bcp14>SHOULD NOT</bcp14> create an err or when The absence or existence of this section <bcp14>SHOULD NOT</bcp14> create an err or when
processing reports. This will be covered in a separate processing reports. This will be covered in
section, Extensible Reporting, <xref target="extensible"></xref>.</t> <xref target="extensible" format="default" sectionFormat="of" derivedContent="Se
</section> ction 5"/> ("Extensible Reporting").</t>
</section>
<section anchor="changes-in-policy-during-reporting-period"><name>Changes in Pol <section anchor="changes-in-policy-during-reporting-period" numbered="true
icy During Reporting Period</name> " removeInRFC="false" toc="include" pn="section-3.3">
<t>Note that Domain Owners or their agents may change the published <name slugifiedName="name-changes-in-policy-during-a-">Changes in Policy
During a Reporting Period</name>
<t indent="0" pn="section-3.3-1">Note that Domain Owners or their agents
may change the published
DMARC Policy Record for a domain or subdomain at any time. From a Mail DMARC Policy Record for a domain or subdomain at any time. From a Mail
Receiver's perspective, this will occur during a reporting period and Receiver's perspective, this will occur during a reporting period and
may be noticed during that period, at the end of that period when may be noticed during that period, at the end of that period when
reports are generated, or during a subsequent reporting period, all reports are generated, or during a subsequent reporting period, all
depending on the Mail Receiver's implementation. Under these depending on the Mail Receiver's implementation. Under these
conditions, it is possible that a Mail Receiver could do any of the conditions, it is possible that a Mail Receiver could do any of the
following:</t> following:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
<ul spacing="compact"> .3-2">
<li>generate for such a reporting period a single aggregate report <li pn="section-3.3-2.1">generate for such a reporting period a single
aggregate report
that includes message dispositions based on the old policy, or a that includes message dispositions based on the old policy, or a
mix of the two policies, even though the report only contains a mix of the two policies, even though the report only contains a
single &quot;policy_published&quot; element;</li> single "policy_published" element</li>
<li>generate multiple reports for the same period, one for each <li pn="section-3.3-2.2">generate multiple reports for the same period
published policy occurring during the reporting period;</li> , one for each
</ul> published policy occurring during the reporting period</li>
<t>Such policy changes are expected to be infrequent for any given </ul>
<t indent="0" pn="section-3.3-3">Such policy changes are expected to be
infrequent for any given
domain, whereas more stringent policy monitoring requirements on the domain, whereas more stringent policy monitoring requirements on the
Mail Receiver would produce a very large burden at Internet scale. Mail Receiver would produce a very large burden at Internet scale.
Therefore, it is the responsibility of Report Consumers (i.e., vendors) Therefore, it is the responsibility of Report Consumers (i.e., vendors)
and Domain Owners to be aware of this situation and expect such mixed and Domain Owners to be aware of this situation and expect such mixed
reports during the propagation of the new policy to Mail Receivers.</t> reports during the propagation of the new policy to Mail Receivers.</t>
</section> </section>
<section anchor="report-request-discovery" numbered="true" removeInRFC="fa
<section anchor="report-request-discovery"><name>Report Request Discovery</name> lse" toc="include" pn="section-3.4">
<t>A Mail Receiver discovers reporting requests when it looks up a DMARC <name slugifiedName="name-report-request-discovery">Report Request Disco
very</name>
<t indent="0" pn="section-3.4-1">A Mail Receiver discovers reporting req
uests when it looks up a DMARC
Policy Record that corresponds to an RFC5322.From domain on received Policy Record that corresponds to an RFC5322.From domain on received
mail. The presence of the &quot;rua&quot; tag specifies where to send mail. The presence of the "rua" tag specifies where to send
feedback.</t> feedback.</t>
</section> </section>
<section anchor="report-delivery" numbered="true" removeInRFC="false" toc=
<section anchor="report-delivery"><name>Report Delivery</name> "include" pn="section-3.5">
<t>The Mail Receiver, after preparing a report, <bcp14>MUST</bcp14> evaluate the <name slugifiedName="name-report-delivery">Report Delivery</name>
provided reporting URIs (See <xref target="I-D.ietf-dmarc-dmarcbis"></xref>) in <t indent="0" pn="section-3.5-1">The Mail Receiver, after preparing a re
the order port, <bcp14>MUST</bcp14> evaluate the
given. If any of the URIs are malformed, they SHOULD be ignored. An provided reporting URIs (see <xref target="RFC9989" format="default" sectionForm
at="of" derivedContent="RFC9989"/>) in the order
given. If any of the URIs are malformed, they <bcp14>SHOULD</bcp14> be ignored.
An
attempt <bcp14>MUST</bcp14> be made to deliver an aggregate report to attempt <bcp14>MUST</bcp14> be made to deliver an aggregate report to
every remaining URI, up to the Receiver's limits on supported URIs.</t> every remaining URI, up to the Receiver's limits on supported URIs.</t>
<t>If delivery is not possible because the services advertised by the <t indent="0" pn="section-3.5-2">If delivery is not possible because the services advertised by the
published URIs are not able to accept reports (e.g., the URI refers published URIs are not able to accept reports (e.g., the URI refers
to a service that is unreachable), the Mail Receiver <bcp14>MAY</bcp14> to a service that is unreachable), the Mail Receiver <bcp14>MAY</bcp14>
cache that data and try again later, or <bcp14>MAY</bcp14> discard data that cache that data and try again later or <bcp14>MAY</bcp14> discard data that
could not be sent.</t> could not be sent.</t>
<t>Where the URI specified in a &quot;rua&quot; tag does not specify otherwise, a <t indent="0" pn="section-3.5-3">Where the URI specified in a "rua" tag does not specify otherwise, a
Mail Receiver generating a feedback report <bcp14>SHOULD</bcp14> employ a secure Mail Receiver generating a feedback report <bcp14>SHOULD</bcp14> employ a secure
transport mechanism, meaning the report should be delivered over a channel transport mechanism, meaning the report should be delivered over a channel
employing TLS (SMTP+STARTTLS).</t> employing TLS (SMTP+STARTTLS).</t>
<section anchor="report-id" numbered="true" removeInRFC="false" toc="inc
<section anchor="report-id"><name>Definition of Report-ID</name> lude" pn="section-3.5.1">
<t>This identifier <bcp14>MUST</bcp14> be unique among reports to the same domai <name slugifiedName="name-definition-of-report-id">Definition of Repor
n to t-ID</name>
<t indent="0" pn="section-3.5.1-1">This identifier <bcp14>MUST</bcp14>
be unique among reports to the same domain to
aid receivers in identifying duplicate reports should they happen. aid receivers in identifying duplicate reports should they happen.
The Report-ID value should be constructed using the following ABNF:</t> The Report-ID value should be constructed using the following ABNF:</t>
<sourcecode type="abnf" markers="false" pn="section-3.5.1-2">
ridfmt = (dot-atom-text ["@" dot-atom-text]) ; from RFC 5322
<artwork> ridfmt = (dot-atom-text [&quot;@&quot; dot-atom-text]) ; from RFC 53 ridtxt = ("&lt;" ridfmt "&gt;") / ridfmt</sourcecode>
22 <t indent="0" pn="section-3.5.1-3">The format specified here is not ve
ry strict, as the key goal is uniqueness. In
ridtxt = (&quot;&lt;&quot; ridfmt &quot;&gt;&quot;) / ridfmt
</artwork>
<t>The format specified here is not very strict as the key goal is uniqueness. I
n
order to create this uniqueness, the Mail Receiver may wish to use elements order to create this uniqueness, the Mail Receiver may wish to use elements
such as the receiving domain, sending domain, and a timestamp in combination. such as the receiving domain, the sending domain, and a timestamp in combination
An example string might be &quot;1721054318-example.com@example.org&quot;. An al .
ternate An example string might be "1721054318-example.com@example.org". An alternate
could use a date string such as &quot;2024-03-27_example.com@example.org&quot;.< could use a date string such as "2024-03-27_example.com@example.org".</t>
/t> </section>
</section> <section anchor="email" numbered="true" removeInRFC="false" toc="include
" pn="section-3.5.2">
<section anchor="email"><name>Email</name> <name slugifiedName="name-email">Email</name>
<t>The message generated by the Mail Receiver <bcp14>MUST</bcp14> be a <xref tar <t indent="0" pn="section-3.5.2-1">The message generated by the Mail R
get="RFC5322"></xref> message eceiver <bcp14>MUST</bcp14> be as described in <xref target="RFC5322" format="de
formatted per <xref target="RFC2045"></xref>. The aggregate report itself <bcp1 fault" sectionFormat="of" derivedContent="RFC5322"/> and
4>MUST</bcp14> be included formatted per <xref target="RFC2045" format="default" sectionFormat="of" derived
Content="RFC2045"/>. The aggregate report itself <bcp14>MUST</bcp14> be include
d
in one of the parts of the message, as an attachment with a corresponding in one of the parts of the message, as an attachment with a corresponding
media type from below. A human-readable annotation <bcp14>MAY</bcp14> be includ ed as a body media type from below. A human-readable annotation <bcp14>MAY</bcp14> be includ ed as a body
part (with a human-friendly content-type, such as &quot;text/plain&quot; or part (with a human-friendly content-type, such as "text/plain" or
&quot;text/html&quot;).</t> "text/html").</t>
<t>The aggregate data <bcp14>MUST</bcp14> be an XML file that <bcp14>SHOULD</bcp <t indent="0" pn="section-3.5.2-2">The aggregate data <bcp14>MUST</bcp
14> be subjected to 14> be an XML file that <bcp14>SHOULD</bcp14> be subjected to
GZIP <xref target="RFC1952"></xref> compression. Declining to apply compression GZIP <xref target="RFC1952" format="default" sectionFormat="of" derivedContent="
can cause the RFC1952"/> compression. Declining to apply compression can cause the
report to be too large for a receiver to process (the total message size report to be too large for a receiver to process (the total message size
could exceed the receiver SMTP size limit); doing the compression increases could exceed the receiver SMTP size limit); doing the compression increases
the chances of acceptance of the report at some compute cost. The the chances of acceptance of the report at some compute cost. The
aggregate data <bcp14>MUST</bcp14> be present using the media type &quot;applica aggregate data <bcp14>MUST</bcp14> be present using the media type "application/
tion/gzip&quot; if gzip" if
compressed (see <xref target="RFC6713"></xref>), and &quot;text/xml&quot; otherw compressed (see <xref target="RFC6713" format="default" sectionFormat="of" deriv
ise. The attachment edContent="RFC6713"/>) and "text/xml" otherwise. The attachment
filename <bcp14>MUST</bcp14> be constructed using the following ABNF:</t> filename <bcp14>MUST</bcp14> be constructed using the following ABNF:</t>
<sourcecode type="abnf" markers="false" pn="section-3.5.2-3">
filename = receiver "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension
<artwork> filename = receiver &quot;!&quot; policy-domain &quot;!&quot; begin-t receiver = domain-name
imestamp ; imported from RFC 6376
&quot;!&quot; end-timestamp [ &quot;!&quot; unique-id ] &quot;.&quo
t; extension
receiver = domain-name
; imported from RFC 6376
policy-domain = domain-name
begin-timestamp = 1*DIGIT policy-domain = domain-name
; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained
; in the report
end-timestamp = 1*DIGIT begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970 ; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained ; indicating start of the time range contained
; in the report ; in the report
unique-id = 1*(ALPHA / DIGIT) end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained
; in the report
extension = &quot;xml&quot; / &quot;xml.gz&quot; unique-id = 1*(ALPHA / DIGIT)
</artwork>
<t>The following primitive tokens that are used but otherwise unspecified extension = "xml" / "xml.gz"</sourcecode>
are taken from the &quot;Core Rules&quot; of <xref target="RFC5234"></xref>: DIG <t indent="0" pn="section-3.5.2-4">The following primitive tokens that
IT, ALPHA.</t> are used but otherwise unspecified
<t>The extension <bcp14>MUST</bcp14> be &quot;xml&quot; for a plain XML file, or are taken from "Core Rules" (<xref target="RFC5234" sectionFormat="of" section="
&quot;xml.gz&quot; for an B.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5234#appendix-B
.1" derivedContent="RFC5234"/>): DIGIT, ALPHA.</t>
<t indent="0" pn="section-3.5.2-5">The extension <bcp14>MUST</bcp14> b
e "xml" for a plain XML file or "xml.gz" for an
XML file compressed using GZIP.</t> XML file compressed using GZIP.</t>
<t>&quot;unique-id&quot; allows an optional unique ID generated by the Mail <t indent="0" pn="section-3.5.2-6">"unique-id" allows an optional uniq ue ID generated by the Mail
Receiver to distinguish among multiple reports generated Receiver to distinguish among multiple reports generated
simultaneously by different sources within the same Domain Owner. A simultaneously by different sources within the same Domain Owner. A
viable option may be to explore UUIDs <xref target="RFC9562"></xref>.</t> viable option may be to explore Universally Unique Identifiers (UUIDs) <xref tar
<t>If a report generator needs to re-send a report, the system <bcp14>MUST</bcp1 get="RFC9562" format="default" sectionFormat="of" derivedContent="RFC9562"/>.</t
4> >
<t indent="0" pn="section-3.5.2-7">If a report generator needs to re-s
end a report, the system <bcp14>MUST</bcp14>
use the same filename as the original report. This would use the same filename as the original report. This would
allow the receiver to overwrite the data from the original, or discard allow the receiver to overwrite the data from the original or discard
second instance of the report.</t> the second instance of the report.</t>
<t>For example, this is a sample filename for the gzip file of a <t indent="0" pn="section-3.5.2-8">For example, this is a sample filen
report to the Domain Owner &quot;example.com&quot; from the Mail Receiver ame for the gzip file of a
&quot;mail.receiver.example&quot;:</t> report to the Domain Owner "example.com" from the Mail Receiver
<t>mail.receiver.example!example.com!1013662812!1013749130.xml.gz</t> "mail.receiver.example":</t>
<t>No specific MIME message structure is required for the message body. It <t indent="3" pn="section-3.5.2-9">mail.receiver.example!example.com!1
013662812!1013749130.xml.gz</t>
<t indent="0" pn="section-3.5.2-10">No specific MIME message structure
is required for the message body. It
is presumed that the aggregate reporting address will be equipped to extract is presumed that the aggregate reporting address will be equipped to extract
body parts with the prescribed media type and filename and ignore the rest.</t> body parts with the prescribed media type and filename and ignore the rest.</t>
<t>Mail streams carrying DMARC feedback data <bcp14>MUST</bcp14> conform to the <t indent="0" pn="section-3.5.2-11">Mail streams carrying DMARC feedba
DMARC ck data <bcp14>MUST</bcp14> conform to the DMARC
mechanism, thereby resulting in an aligned &quot;pass&quot; (see mechanism, thereby resulting in an aligned "pass" (see
<xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="of" relative="#" section=" <xref target="RFC9989" sectionFormat="of" section="4.4" format="default" derived
4.4"></xref>). Link="https://rfc-editor.org/rfc/rfc9989#section-4.4" derivedContent="RFC9989"/>
).
This practice minimizes the risk of Report Consumers processing This practice minimizes the risk of Report Consumers processing
fraudulent reports.</t> fraudulent reports.</t>
<t>The RFC5322.Subject field for individual report submissions <bcp14>MUST</bcp1 4> <t indent="0" pn="section-3.5.2-12">The RFC5322.Subject field for indi vidual report submissions <bcp14>MUST</bcp14>
conform to the following ABNF:</t> conform to the following ABNF:</t>
<sourcecode type="abnf" markers="false" pn="section-3.5.2-13">
<artwork> ; FWS is imported from RFC 5322 ; FWS is imported from RFC 5322
dmarc-subject = %s&quot;Report&quot; 1*FWS %s&quot;Domain:&quot; dmarc-subject = %s"Report" 1*FWS %s"Domain:"
1*FWS domain-name 1*FWS ; policy domain 1*FWS domain-name 1*FWS ; policy domain
%s&quot;Submitter:&quot; 1*FWS %s"Submitter:" 1*FWS
domain-name 1*FWS ; report generator domain-name 1*FWS ; report generator
[ %s&quot;Report-ID:&quot; 1*FWS ridtxt ] ; defined above [ %s"Report-ID:" 1*FWS ridtxt ] ; defined above
</artwork> </sourcecode>
<t>The first domain-name indicates the DNS domain name about which the <t indent="0" pn="section-3.5.2-14">The first domain-name indicates th
e DNS domain name about which the
report was generated. The second domain-name indicates the DNS report was generated. The second domain-name indicates the DNS
domain name representing the Mail Receiver generating the report. domain name representing the Mail Receiver generating the report.
The purpose of the Report-ID: portion of the field is to enable the The purpose of the Report-ID: portion of the field is to enable the
Domain Owner to identify and ignore duplicate reports that might be Domain Owner to identify and ignore duplicate reports that might be
sent by a Mail Receiver.</t> sent by a Mail Receiver.</t>
<t>For instance, this is a possible Subject field for a report to the <t indent="0" pn="section-3.5.2-15">For instance, this is a possible S
Domain Owner &quot;example.com&quot; from the Mail Receiver ubject field for a report to the
&quot;mail.receiver.example&quot;. It is folded as allowed by <xref target="RFC Domain Owner "example.com" from the Mail Receiver
5322"></xref>:</t> "mail.receiver.example". It is folded as allowed by <xref target="RFC5322" form
at="default" sectionFormat="of" derivedContent="RFC5322"/>:</t>
<artwork> Subject: Report Domain: example.com <artwork align="left" pn="section-3.5.2-16">
Subject: Report Domain: example.com
Submitter: mail.receiver.example Submitter: mail.receiver.example
Report-ID: &lt;sample-ridtxt@example.com&gt; Report-ID: &lt;sample-ridtxt@example.com&gt;</artwork>
</artwork> <t indent="0" pn="section-3.5.2-17">This transport mechanism potential
<t>This transport mechanism potentially encounters a problem when ly encounters a problem when
feedback data size exceeds maximum allowable attachment sizes for feedback data size exceeds maximum allowable attachment sizes for
either the generator or the consumer.</t> either the generator or the consumer.</t>
<t>Optionally, the report sender <bcp14>MAY</bcp14> choose to use the same &quot ;ridtxt&quot; <t indent="0" pn="section-3.5.2-18">Optionally, the report sender <bcp 14>MAY</bcp14> choose to use the same "ridtxt"
as a part or whole of the RFC5322.Message-Id header included with the report. as a part or whole of the RFC5322.Message-Id header included with the report.
Doing so may help receivers distinguish when a message is a re-transmission Doing so may help receivers distinguish when a message is a re-transmission
or duplicate report.</t> or duplicate report.</t>
</section> </section>
<section anchor="other-methods" numbered="true" removeInRFC="false" toc=
<section anchor="other-methods"><name>Other Methods</name> "include" pn="section-3.5.3">
<t>The specification as written allows for the addition of other <name slugifiedName="name-other-methods">Other Methods</name>
<t indent="0" pn="section-3.5.3-1">The specification as written allows
for the addition of other
registered URI schemes to be supported in later versions.</t> registered URI schemes to be supported in later versions.</t>
</section> </section>
<section anchor="handling-of-duplicates" numbered="true" removeInRFC="fa
<section anchor="handling-of-duplicates"><name>Handling of Duplicates</name> lse" toc="include" pn="section-3.5.4">
<t>There may be a situation where the report generator attempts to deliver <name slugifiedName="name-handling-of-duplicates">Handling of Duplicat
es</name>
<t indent="0" pn="section-3.5.4-1">There may be a situation where the
report generator attempts to deliver
duplicate information to the receiver. This may manifest as an exact duplicate information to the receiver. This may manifest as an exact
duplicate of the report, or as duplicate information between two reports. duplicate of the report or as duplicate information between two reports.
In these situations, the decision of how to handle the duplicate data In these situations, the decision of how to handle the duplicate data
lies with the receiver. As noted above, the sender <bcp14>MUST</bcp14> use the same lies with the receiver. As noted above, the sender <bcp14>MUST</bcp14> use the same
unique identifiers when sending the report. This allows the receiver to unique identifiers when sending the report. This allows the receiver to
better understand when duplicates happen. A few options on how to better understand when duplicates happen. Here are a few options on how to
handle that duplicate information:</t> handle that duplicate information:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<ul spacing="compact"> -3.5.4-2">
<li>Reject back to sender, ideally with a permfail error noting <li pn="section-3.5.4-2.1">Reject back to sender, ideally with a per
mfail error noting
the duplicate receipt</li> the duplicate receipt</li>
<li>Discard upon receipt</li> <li pn="section-3.5.4-2.2">Discard upon receipt</li>
<li>Inspect the contents to evaluate the timestamps and reported data, <li pn="section-3.5.4-2.3">Inspect the contents to evaluate the time
stamps and reported data,
act as appropriate</li> act as appropriate</li>
<li>Accept the duplicate data</li> <li pn="section-3.5.4-2.4">Accept the duplicate data</li>
</ul> </ul>
<t>When accepting the data, that's likely in a situation where it's not <t indent="0" pn="section-3.5.4-3">When accepting the data, it's likel
yet noticed, or a one-off experience. Long term, duplicate data y that the duplicate data has not
yet been noticed and is a one-off experience. Long-term duplicate data
is not ideal. In the situation of a partial time frame overlap, there is is not ideal. In the situation of a partial time frame overlap, there is
no clear way to distinguish the impact of the overlap. The receiver would no clear way to distinguish the impact of the overlap. The receiver would
need to accept or reject the duplicate data in whole.</t> need to accept or reject the duplicate data in whole.</t>
</section> </section>
</section> </section>
</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-4">
nations</name> <name slugifiedName="name-verifying-external-destinat">Verifying External
<t>It is possible to specify destinations for the different reports that Destinations</name>
<t indent="0" pn="section-4-1">It is possible to specify destinations for
the different reports that
are outside the authority of the Domain Owner making the request. are outside the authority of the Domain Owner making the request.
This allows domains that do not operate mail servers to request This allows domains that do not operate mail servers to request
reports and have them go someplace that is able to receive and reports and have them go someplace that is able to receive and
process them.</t> process them.</t>
<t>Without checks, this would allow a bad actor to publish a DMARC <t indent="0" pn="section-4-2">Without checks, this would allow a bad acto
Policy Record that requests that reports be sent to a victim address, r to publish a DMARC
Policy Record that requests that reports be sent to a victim address
and then send a large volume of mail that will fail both DKIM and SPF and then send a large volume of mail that will fail both DKIM and SPF
checks to a wide variety of destinations; the victim will in turn be checks to a wide variety of destinations; the victim will in turn be
flooded with unwanted reports. Therefore, a verification mechanism flooded with unwanted reports. Therefore, a verification mechanism
is included.</t> is included.</t>
<t>When a Mail Receiver discovers a DMARC Policy Record in the DNS, and the <t indent="0" pn="section-4-3">When a Mail Receiver discovers a DMARC Poli cy Record in the DNS, and the
Organizational Domain at which that record was discovered is not Organizational Domain at which that record was discovered is not
identical to the Organizational Domain of the host part of the identical to the Organizational Domain of the host part of the
authority component of a <xref target="RFC3986"></xref> specified in the &quot;r ua&quot; tag, authority component of a <xref target="RFC3986" format="default" sectionFormat=" of" derivedContent="RFC3986"/> specified in the "rua" tag,
the following verification steps <bcp14>MUST</bcp14> be taken:</t> the following verification steps <bcp14>MUST</bcp14> be taken:</t>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4-4"
<ol> >
<li><t>Extract the host portion of the authority component of the URI. <li pn="section-4-4.1" derivedCounter="1.">
Call this the &quot;destination host&quot;, as it refers to a Report <t indent="0" pn="section-4-4.1.1">Extract the host portion of the aut
hority component of the URI.
Call this the "destination host", as it refers to a Report
Receiver.</t> Receiver.</t>
</li> </li>
<li><t>Prepend the string &quot;_report._dmarc&quot;.</t> <li pn="section-4-4.2" derivedCounter="2.">
</li> <t indent="0" pn="section-4-4.2.1">Prepend the string "_report._dmarc"
<li><t>Prepend the domain name from which the policy was retrieved, .</t>
after conversion to an A-label <xref target="RFC5890"></xref> if needed.</t> </li>
</li> <li pn="section-4-4.3" derivedCounter="3.">
<li><t>If the length of the constructed name exceed DNS limits, <t indent="0" pn="section-4-4.3.1">Prepend the domain name from which
the policy was retrieved,
after conversion to an A-label <xref target="RFC5890" format="default" sectionFo
rmat="of" derivedContent="RFC5890"/> if needed.</t>
</li>
<li pn="section-4-4.4" derivedCounter="4.">
<t indent="0" pn="section-4-4.4.1">If the length of the constructed na
me exceed DNS limits,
a positive determination of the external reporting a positive determination of the external reporting
relationship cannot be made; stop.</t> relationship cannot be made; stop.</t>
</li> </li>
<li><t>Query the DNS for a TXT record at the constructed name. If the <li pn="section-4-4.5" derivedCounter="5.">
<t indent="0" pn="section-4-4.5.1">Query the DNS for a TXT record at t
he constructed name. If the
result of this request is a temporary DNS error of some kind result of this request is a temporary DNS error of some kind
(e.g., a timeout), the Mail Receiver <bcp14>MAY</bcp14> elect to temporarily (e.g., a timeout), the Mail Receiver <bcp14>MAY</bcp14> elect to temporarily
fail the delivery so the verification test can be repeated later.</t> fail the delivery so the verification test can be repeated later.</t>
</li> </li>
<li><t>For each record returned, parse the result as a series of <li pn="section-4-4.6" derivedCounter="6.">
&quot;tag=value&quot; pairs, i.e., the same overall format as the DMARC Policy <t indent="0" pn="section-4-4.6.1">For each record returned, parse the
Record (see <xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="of" relative=" result as a series of
#" section="4.7"></xref>). In "tag=value" pairs, i.e., the same overall format as the DMARC Policy
particular, the &quot;v=DMARC1&quot; tag is mandatory and <bcp14>MUST</bcp14> ap Record (see <xref target="RFC9989" sectionFormat="of" section="4.7" format="defa
pear ult" derivedLink="https://rfc-editor.org/rfc/rfc9989#section-4.7" derivedContent
="RFC9989"/>). In
particular, the "v=DMARC1" tag is mandatory and <bcp14>MUST</bcp14> appear
first in the list. Discard any that do not pass this test. A first in the list. Discard any that do not pass this test. A
trailing &quot;;&quot; is optional.</t> trailing ";" is optional.</t>
</li> </li>
<li><t>If the result includes no TXT resource records that pass basic <li pn="section-4-4.7" derivedCounter="7.">
<t indent="0" pn="section-4-4.7.1">If the result includes no TXT resou
rce records that pass basic
parsing, a positive determination of the external reporting parsing, a positive determination of the external reporting
relationship cannot be made; stop.</t> relationship cannot be made; stop.</t>
</li> </li>
<li><t>If at least one TXT resource record remains in the set after <li pn="section-4-4.8" derivedCounter="8.">
<t indent="0" pn="section-4-4.8.1">If at least one TXT resource record
remains in the set after
parsing, then the external reporting arrangement was authorized parsing, then the external reporting arrangement was authorized
by the Report Consumer.</t> by the Report Consumer.</t>
</li> </li>
<li><t>If a &quot;rua&quot; tag is thus discovered, replace the <li pn="section-4-4.9" derivedCounter="9.">
<t indent="0" pn="section-4-4.9.1">If a "rua" tag is thus discovered,
replace the
corresponding value extracted from the domain's DMARC Policy corresponding value extracted from the domain's DMARC Policy
Record with the one found in this record. This permits the Record with the one found in this record. This permits the
Report Consumer to override the report destination. However, to Report Consumer to override the report destination. However, to
prevent loops or indirect abuse, the overriding URI <bcp14>MUST</bcp14> use the prevent loops or indirect abuse, the overriding URI <bcp14>MUST</bcp14> use the
same destination host from the first step.</t> same destination host from the first step.</t>
</li> </li>
</ol> </ol>
<t>For example, if the DMARC Policy Record for &quot;blue.example.com&quot; cont <t indent="0" pn="section-4-5">For example, if the DMARC Policy Record for
ained "blue.example.com" contained
<tt>&quot;rua=mailto:reports@red.example.net&quot;</tt>, the Organizational Doma <tt>"rua=mailto:reports@red.example.net"</tt>, the Organizational Domain host
in host extracted from the latter ("red.example.net") does not match
extracted from the latter (&quot;red.example.net&quot;) does not match "blue.example.com", so this procedure is enacted. A TXT query for
&quot;blue.example.com&quot;, so this procedure is enacted. A TXT query for "blue.example.com._report._dmarc.red.example.net" is issued. If a
&quot;blue.example.com._report._dmarc.red.example.net&quot; is issued. If a single reply comes back containing a tag of "v=DMARC1", then the
single reply comes back containing a tag of &quot;v=DMARC1&quot;, then the
relationship between the two is confirmed. Moreover, relationship between the two is confirmed. Moreover,
&quot;red.example.net&quot; has the opportunity to override the report "red.example.net" has the opportunity to override the report
destination requested by &quot;blue.example.com&quot; if needed.</t> destination requested by "blue.example.com" if needed.</t>
<t>Where the above algorithm fails to confirm that the external <t indent="0" pn="section-4-6">Where the above algorithm fails to confirm
that the external
reporting was authorized by the Report Consumer, the URI <bcp14>MUST</bcp14> be reporting was authorized by the Report Consumer, the URI <bcp14>MUST</bcp14> be
ignored by the Mail Receiver generating the report. Further, if the ignored by the Mail Receiver generating the report. Further, if the
confirming record includes a URI whose host is again different than confirming record includes a URI whose host is again different than
the domain publishing that override, the Mail Receiver generating the the domain publishing that override, the Mail Receiver generating the
report <bcp14>MUST NOT</bcp14> generate a report to either the original or the report <bcp14>MUST NOT</bcp14> generate a report to either the original or the
override URI. override URI.
A Report Consumer publishes such a record in its DNS if it wishes to A Report Consumer publishes such a record in its DNS if it wishes to
receive reports for other domains.</t> receive reports for other domains.</t>
<t>A Report Consumer that is willing to receive reports for any domain <t indent="0" pn="section-4-7">A Report Consumer that is willing to receiv e reports for any domain
can use a wildcard DNS record. For example, a TXT resource record at can use a wildcard DNS record. For example, a TXT resource record at
&quot;*._report._dmarc.example.com&quot; containing at least &quot;v=DMARC1&quot ; "*._report._dmarc.example.com" containing at least "v=DMARC1"
confirms that example.com is willing to receive DMARC reports for any confirms that example.com is willing to receive DMARC reports for any
domain.</t> domain.</t>
<t>If the Report Consumer is overcome by volume, it can simply remove <t indent="0" pn="section-4-8">If the Report Consumer is overcome by volum e, it can simply remove
the confirming DNS record. However, due to positive caching, the the confirming DNS record. However, due to positive caching, the
change could take as long as the time-to-live (TTL) on the record to change could take as long as the Time to Live (TTL) on the record to
go into effect.</t> go into effect.</t>
<t>If the length of the DNS query is excessively long (Step 4 above), the <t indent="0" pn="section-4-9">If the DNS query length is excessively long
Domain Owner may need to reconsider the domain being used to be shorter, (Step 4 above), the
or reach out to another party that may allow for a shorter DNS label.</t> Domain Owner may need to consider using a shorter domain name
</section> or coordinate with another party that may allow for a shorter DNS label.</t>
</section>
<section anchor="extensible"><name>Extensible Reporting</name> <section anchor="extensible" numbered="true" removeInRFC="false" toc="includ
<t>DMARC reports allow for some extensibility, as defined by future e" pn="section-5">
<name slugifiedName="name-extensible-reporting">Extensible Reporting</name
>
<t indent="0" pn="section-5-1">DMARC reports allow for some extensibility,
as defined by future
documents that utilize DMARC as a foundation. These extensions documents that utilize DMARC as a foundation. These extensions
<bcp14>MUST</bcp14> be properly formatted XML and meant to exist within the stru cture <bcp14>MUST</bcp14> be properly formatted XML and meant to exist within the stru cture
of a DMARC report. Two positions of type &quot;&lt;any&gt;&quot; are provided i of a DMARC report. Two positions of type "&lt;any&gt;" are provided in the
n the existing DMARC structure: one at file level in an "&lt;extension&gt;" element
existing DMARC structure, one at file level, in an &quot;&lt;extension&gt;&quot; after "&lt;policy_published&gt;" and one at record level after "&lt;auth_results
element &gt;".
after &quot;&lt;policy_published&gt;&quot; and one at record level, after &quot;
&lt;auth_results&gt;&quot;.
In either case, the extensions <bcp14>MUST</bcp14> contain a URI to the definiti on of In either case, the extensions <bcp14>MUST</bcp14> contain a URI to the definiti on of
the extension so that the receiver understands how to interpret the data.</t> the extension so that the receiver understands how to interpret the data.</t>
<t>At file level:</t> <t indent="0" pn="section-5-2">At file level:</t>
<sourcecode type="xml" markers="false" pn="section-5-3">
<sourcecode type="xml">&lt;feedback xmlns=&quot;urn:ietf:params:xml:ns:dmarc-2.0 &lt;feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
&quot; xmlns:ext="URI for an extension-supplied name space"&gt;
xmlns:ext=&quot;URI for an extension-supplied name space&quot;&gt;
... ...
&lt;policy_published&gt; &lt;policy_published&gt;
&lt;domain&gt;example.com&lt;/domain&gt; &lt;domain&gt;example.com&lt;/domain&gt;
&lt;p&gt;quarantine&lt;/p&gt; &lt;p&gt;quarantine&lt;/p&gt;
&lt;sp&gt;none&lt;/sp&gt; &lt;sp&gt;none&lt;/sp&gt;
&lt;testing&gt;n&lt;/testing&gt; &lt;testing&gt;n&lt;/testing&gt;
&lt;/policy_published&gt; &lt;/policy_published&gt;
&lt;extension&gt; &lt;extension&gt;
&lt;ext:arc-override&gt;never&lt;/ext:arc-override&gt; &lt;ext:arc-override&gt;never&lt;/ext:arc-override&gt;
&lt;/extension&gt; &lt;/extension&gt;</sourcecode>
</sourcecode> <t indent="0" pn="section-5-4">Within the "record" element:</t>
<t>Within the &quot;record&quot; element:</t> <sourcecode type="xml" markers="false" pn="section-5-5">
...
<sourcecode type="xml"> &lt;record&gt; &lt;record&gt;
&lt;row&gt; &lt;row&gt;
... ...
&lt;/row&gt; &lt;/row&gt;
&lt;identifiers&gt; &lt;identifiers&gt;
... ...
&lt;/identifiers&gt; &lt;/identifiers&gt;
&lt;auth_results&gt; &lt;auth_results&gt;
... ...
&lt;/auth_results&gt; &lt;/auth_results&gt;
&lt;ext:arc-results&gt; &lt;ext:arc-results&gt;
... ...
&lt;/ext:arc-results&gt; &lt;/ext:arc-results&gt;
&lt;/record&gt; &lt;/record&gt;
&lt;record&gt; &lt;record&gt;
... ...</sourcecode>
</sourcecode> <t indent="0" pn="section-5-6">Here "arc-override" and "arc-results" are h
<t>Here &quot;arc-override&quot; and &quot;arc-results&quot; are hypothetical el ypothetical element names
ement names defined in the extension's namespace.</t>
defined in the extension's name space.</t> <t indent="0" pn="section-5-7">Extension elements are optional. Any numbe
<t>Extension elements are optional. Any number of extensions is allowed. r of extensions is allowed.
If a processor is unable to handle an extension in a report, it <bcp14>SHOULD</b cp14> If a processor is unable to handle an extension in a report, it <bcp14>SHOULD</b cp14>
ignore the data and continue to the next extension.</t> ignore the data and continue to the next extension.</t>
</section> </section>
<section anchor="iana-considerations" numbered="true" removeInRFC="false" to
<section anchor="iana-considerations"><name>IANA Considerations</name> c="include" pn="section-6">
<t>This document uses URNs to describe XML namespaces and XML schemas <name slugifiedName="name-iana-considerations">IANA Considerations</name>
conforming to a registry mechanism described in <xref target="RFC3688"></xref>. <t indent="0" pn="section-6-1">This document uses URNs to describe XML nam
Two URI espaces and XML schemas
assignments will be registered by the IANA.</t> conforming to a registry mechanism described in <xref target="RFC3688" format="d
efault" sectionFormat="of" derivedContent="RFC3688"/>. Two URI
<section anchor="registration-request-for-the-dmarc-namespace"><name>Registratio assignments have been registered by the IANA.
n request for the DMARC namespace:</name> </t>
<t>URI: urn:ietf:params:xml:ns:dmarc-2.0</t> <section anchor="registration-request-for-the-dmarc-namespace" numbered="t
<t>Registrant Contact: Internet Engineering Task Force (iesg@ietf.org)</t> rue" removeInRFC="false" toc="include" pn="section-6.1">
<t>XML: None. Namespace URIs do not represent an XML specification.</t> <name slugifiedName="name-registration-for-the-dmarc-">Registration for
</section> the DMARC Namespace</name>
<t indent="0" pn="section-6.1-1">
<section anchor="registration-request-for-the-dmarc-xml-schema"><name>Registrati IANA has registered the following URI in the "ns" registry within the "IETF XML
on request for the DMARC XML schema:</name> Registry" group:
<t>URI: urn:ietf:params:xml:schema:dmarc-2.0</t> </t>
<t>Registrant Contact: Internet Engineering Task Force (iesg@ietf.org)</t> <dl spacing="compact" newline="false" indent="3" pn="section-6.1-2">
<t>XML: See Appendix A. DMARC XML Schema (<xref target="W3C.REC-xmlschema-1"></x <dt pn="section-6.1-2.1">URI:</dt>
ref> and <dd pn="section-6.1-2.2">urn:ietf:params:xml:ns:dmarc-2.0</dd>
<xref target="W3C.REC-xmlschema-2"></xref>) in this document.</t> <dt pn="section-6.1-2.3">Registrant Contact:</dt>
</section> <dd pn="section-6.1-2.4">The IESG (iesg@ietf.org)</dd>
</section> <dt pn="section-6.1-2.5">XML:</dt>
<dd pn="section-6.1-2.6">N/A; the requested URI is an XML namespace.</
<section anchor="privacy-considerations"><name>Privacy Considerations</name> dd>
<t>This section will discuss exposure related to DMARC aggregate reporting.</t> </dl>
</section>
<section anchor="report-recipients"><name>Report Recipients</name> <section anchor="registration-request-for-the-dmarc-xml-schema" numbered="
<t>A DMARC Policy Record can specify that reports should be sent to an true" removeInRFC="false" toc="include" pn="section-6.2">
<name slugifiedName="name-registration-for-the-dmarc-x">Registration for
the DMARC XML Schema</name>
<t indent="0" pn="section-6.2-1">
IANA has registered the following URI in the "schema" registry within the "IETF
XML Registry" group:
</t>
<dl spacing="compact" newline="false" indent="3" pn="section-6.2-2">
<dt pn="section-6.2-2.1">URI:</dt>
<dd pn="section-6.2-2.2">urn:ietf:params:xml:schema:dmarc-2.0</dd>
<dt pn="section-6.2-2.3">Registrant Contact:</dt>
<dd pn="section-6.2-2.4">The IESG (iesg@ietf.org)</dd>
<dt pn="section-6.2-2.5">XML:</dt>
<dd pn="section-6.2-2.6">See the DMARC XML schema <xref target="W3C.RE
C-xmlschema-1" format="default" sectionFormat="of" derivedContent="W3C.REC-xmlsc
hema-1"/>
<xref target="W3C.REC-xmlschema-2" format="default" sectionFormat="o
f" derivedContent="W3C.REC-xmlschema-2"/> in <xref target="xsd" format="default"
sectionFormat="of" derivedContent="Appendix A"/> of this document.</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">This section discusses exposure related to
DMARC aggregate reporting.</t>
<section anchor="report-recipients" numbered="true" removeInRFC="false" to
c="include" pn="section-7.1">
<name slugifiedName="name-report-recipients">Report Recipients</name>
<t indent="0" pn="section-7.1-1">A DMARC Policy Record can specify that
reports should be sent to an
intermediary operating on behalf of the Domain Owner. This is done intermediary operating on behalf of the Domain Owner. This is done
when the Domain Owner contracts with an entity to monitor mail when the Domain Owner contracts with an entity to monitor mail
streams for abuse and performance issues. Receipt by third parties streams for abuse and performance issues. Receipt by third parties
of such data may or may not be permitted by the Mail Receiver's of such data may or may not be permitted by the Mail Receiver's
privacy policy, terms of use, or other similar governing document. privacy policy, terms of use, or other similar governing document.
Domain Owners and Mail Receivers should both review and understand if Domain Owners and Mail Receivers should both review and understand if
their own internal policies constrain the use and transmission of their own internal policies constrain the use and transmission of
DMARC reporting.</t> DMARC reporting.</t>
<t>Some potential exists for report recipients to perform traffic <t indent="0" pn="section-7.1-2">Some potential exists for report recipi ents to perform traffic
analysis, making it possible to obtain metadata about the Receiver's analysis, making it possible to obtain metadata about the Receiver's
traffic. In addition to verifying compliance with policies, traffic. In addition to verifying compliance with policies,
Receivers need to consider that before sending reports to a third Receivers need to consider that before sending reports to a third
party.</t> party.</t>
</section> </section>
<section anchor="data-contained-within-reports" numbered="true" removeInRF
<section anchor="data-contained-within-reports"><name>Data Contained Within Repo C="false" toc="include" pn="section-7.2">
rts</name> <name slugifiedName="name-data-contained-within-repor">Data Contained Wi
<t>Aggregate feedback reports contain aggregated data relating to thin Reports</name>
<t indent="0" pn="section-7.2-1">Aggregate feedback reports contain aggr
egated data relating to
messages purportedly originating from the Domain Owner. The data messages purportedly originating from the Domain Owner. The data
does not contain any identifying characteristics about individual does not contain any identifying characteristics about individual
users. No personal information such as individual mail addresses, users. No personal information such as individual mail addresses,
IP addresses of individuals, or the content of any messages, is IP addresses of individuals, or the content of any messages is
included in reports.</t> included in reports.</t>
<t>Mail Receivers should have no concerns in sending reports as they <t indent="0" pn="section-7.2-2">Mail Receivers should have no concerns in sending reports, as they
do not contain personal information. In all cases, the data within do not contain personal information. In all cases, the data within
the reports relates to the domain-level authentication information the reports relates to the domain-level authentication information
provided by mail servers sending messages on behalf of the Domain provided by mail servers sending messages on behalf of the Domain
Owner. This information is necessary to assist Domain Owners in Owner. This information is necessary to assist Domain Owners in
implementing and maintaining DMARC.</t> implementing and maintaining DMARC.</t>
<t>Domain Owners should have no concerns in receiving reports as <t indent="0" pn="section-7.2-3">Domain Owners should have no concerns i n receiving reports, as
they do not contain personal information. The reports only contain they do not contain personal information. The reports only contain
aggregated data related to the domain-level authentication details aggregated data related to the domain-level authentication details
of messages claiming to originate from their domain. This information of messages claiming to originate from their domain. This information
is essential for the proper implementation and operation of DMARC. is essential for the proper implementation and operation of DMARC.
Domain Owners who are unable to receive reports for organizational Domain Owners who are unable to receive reports for organizational
reasons, can choose to exclusively direct the reports to an reasons can choose to exclusively direct the reports to an
external processor.</t> external processor.</t>
</section> </section>
<section anchor="leakage" numbered="true" removeInRFC="false" toc="include
<section anchor="leakage"><name>Feedback Leakage</name> " pn="section-7.3">
<t>Providing feedback reporting to PSOs (Public Suffix Operator) for a <name slugifiedName="name-feedback-leakage">Feedback Leakage</name>
PSD (Public Suffix Domain) <xref target="I-D.ietf-dmarc-dmarcbis"></xref> can, i <t indent="0" pn="section-7.3-1">Providing feedback reporting to Public
n some Suffix Operators (PSOs) for a
Public Suffix Domain (PSD) <xref target="RFC9989" format="default" sectionFormat
="of" derivedContent="RFC9989"/> can, in some
cases, cause information to leak out of an organization to the PSO. This cases, cause information to leak out of an organization to the PSO. This
leakage could potentially be utilized as part of a program of pervasive leakage could potentially be utilized as part of a program of pervasive
surveillance (see <xref target="RFC7624"></xref>). There are roughly three case surveillance (see <xref target="RFC7624" format="default" sectionFormat="of" der
s to consider:</t> ivedContent="RFC7624"/>). There are roughly three cases to consider:</t>
<dl spacing="normal" newline="true" indent="3" pn="section-7.3-2">
<ul> <dt pn="section-7.3-2.1">Single Organization PSDs (e.g., ".mil"):</dt>
<li><t>Single Organization PSDs (e.g., &quot;.mil&quot;)</t> <dd pn="section-7.3-2.2">Aggregate reports based on PSD DMARC have the
<t>Aggregate reports based on PSD DMARC have the potential to potential to contain
contain information about mails related to entities managed by information about mail related to entities managed by the organization.
the organization. Since both the PSO and the Organizational Since both the PSO and the Organizational Domain Owners are common, there is
Domain Owners are common, there is no additional privacy risk for no additional privacy risk for either normal or non-existent domain
either normal or non-existent domain reporting due to PSD DMARC.</t> reporting due to PSD DMARC.</dd>
</li> <dt pn="section-7.3-2.3">Multi-organization PSDs requiring DMARC usage
<li><t>Multi-organization PSDs requiring DMARC usage (e.g., &quot;.bank&quot;)</ (e.g., ".bank"):</dt>
t> <dd pn="section-7.3-2.4">Aggregate reports based on PSD DMARC will onl
<t>Aggregate reports based on PSD DMARC will only be generated for domains that y be generated for domains
do not publish a DMARC Policy Record at the Organizational Domain or host level. that do not publish a DMARC Policy Record at the Organizational Domain or
For domains that do publish the required DMARC Policy Records, the host level. For domains that do publish the required DMARC Policy Records,
feedback reporting addresses of the Organizational Domain (or the feedback reporting addresses of the Organizational Domain (or hosts)
hosts) will be used. The only direct risk of feedback leakage for will be used. The only direct risk of feedback leakage for these PSDs are
these PSDs are for Organizational Domains that are out of for Organizational Domains that are out of compliance with PSD policy. Data
compliance with PSD policy. Data on non-existent domains on non-existent domains would be sent to the PSO.</dd>
would be sent to the PSO.</t> <dt pn="section-7.3-2.5">Multi-organization PSDs not requiring DMARC u
</li> sage (e.g., ".com"):</dt>
<li><t>Multi-organization PSDs not requiring DMARC usage (e.g., &quot;.com&quot; <dd pn="section-7.3-2.6">Privacy risks for Organizational Domains that
)</t> have not deployed DMARC
<t>Privacy risks for Organizational Domains that have not deployed DMARC within such PSDs can be significant. For non-DMARC Organizational Domains,
within such PSDs can be significant. For non-DMARC Organizational all DMARC feedback will be directed to the PSO if that PSO itself has a
Domains, all DMARC feedback will be directed to the PSO if that PSO DMARC Policy Record that specifies a "rua" tag. Any non-DMARC
itself has a DMARC Policy Record that specifies a &quot;rua&quot; tag. Any non- Organizational Domain would have its feedback reports redirected to the PSO.
DMARC The content of such reports, particularly for existing domains, is privacy
Organizational Domain would have its Feedback Reports redirected to sensitive.</dd>
the PSO. The content of such reports, particularly for existing </dl>
domains, is privacy sensitive.</t> <t indent="0" pn="section-7.3-3">PSOs will receive feedback on non-exist
</li> ent domains, which may be
</ul>
<t>PSOs will receive feedback on non-existent domains, which may be
similar to existing Organizational Domains. Feedback related to such similar to existing Organizational Domains. Feedback related to such
domains have a small risk of carrying information related to domains have a small risk of carrying information related to
an actual Organizational Domain. To minimize this potential concern, an actual Organizational Domain. To minimize this potential concern,
PSD DMARC feedback <bcp14>MUST</bcp14> be limited to aggregate reports. Failure PSD DMARC feedback <bcp14>MUST</bcp14> be limited to aggregate reports. Failure
reports carry more detailed information and present a greater risk.</t> reports carry more detailed information and present a greater risk.</t>
</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, it is ideal <name slugifiedName="name-security-considerations">Security Considerations
that the reader would also review Privacy Considerations above, as well as </name>
the Privacy Considerations and Security Considerations in section <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, it is ideal
="9"></xref> and <xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="bare" rel that the reader also review the Privacy Considerations section above, as well as
ative="#" section="10"></xref> of the privacy considerations and security considerations in Sections
<xref target="I-D.ietf-dmarc-dmarcbis"></xref>.</t> <xref target="RFC9989" sectionFormat="bare" section="10" format="default" derive
dLink="https://rfc-editor.org/rfc/rfc9989#section-10" derivedContent="RFC9989"/>
<section anchor="report-contents-as-an-attack"><name>Report Contents as an Attac and <xref target="RFC9989" sectionFormat="bare" section="11" format="default" d
k</name> erivedLink="https://rfc-editor.org/rfc/rfc9989#section-11" derivedContent="RFC99
<t>Aggregate reports are supposed to be processed automatically. An attacker 89"/> of
<xref target="RFC9989" format="default" sectionFormat="of" derivedContent="RFC99
89"/>.</t>
<section anchor="report-contents-as-an-attack" numbered="true" removeInRFC
="false" toc="include" pn="section-8.1">
<name slugifiedName="name-report-content-as-an-attack">Report Content as
an Attack</name>
<t indent="0" pn="section-8.1-1">Aggregate reports are supposed to be pr
ocessed automatically. An attacker
might attempt to compromise the integrity or availability of the report might attempt to compromise the integrity or availability of the report
processor by sending malformed reports. In particular, the archive processor by sending malformed reports. In particular, the archive
decompressor and XML parser are at risk to resource exhaustion decompressor and XML parser are at risk to resource exhaustion
attacks (zip bomb or XML bomb).</t> attacks (zip bomb or XML bomb).</t>
</section> </section>
<section anchor="false-information" numbered="true" removeInRFC="false" to
<section anchor="false-information"><name>False Information</name> c="include" pn="section-8.2">
<t>The data contained within aggregate reports may be forged. An attacker might <name slugifiedName="name-false-information">False Information</name>
<t indent="0" pn="section-8.2-1">The data contained within aggregate rep
orts may be forged. An attacker might
attempt to interfere with or influence policy decisions by submitting false attempt to interfere with or influence policy decisions by submitting false
reports in large volume. The attacker could also be attempting to influence reports in large volume. The attacker could also be attempting to influence
platform architecture decisions. A volume-based attack may also impact the platform architecture decisions. A volume-based attack may also impact the
ability for a report receiver to accept reports from other entities.</t> ability for a Report Receiver to accept reports from other entities.</t>
</section> </section>
<section anchor="disclosure-of-filtering-information" numbered="true" remo
<section anchor="disclosure-of-filtering-information"><name>Disclosure of Filter veInRFC="false" toc="include" pn="section-8.3">
ing Information</name> <name slugifiedName="name-disclosure-of-filtering-inf">Disclosure of Fil
<t>While not specified in this document itself, the availability of extensions tering Information</name>
<t indent="0" pn="section-8.3-1">While not specified in this document it
self, the availability of extensions
could enable the report generator to disclose information about message could enable the report generator to disclose information about message
placement (Inbox/Spam/etc). This is very much discouraged as it could placement (Inbox/Spam/etc.). This is very much discouraged as it could
relay this information to a malicious party, allowing them to understand relay this information to a malicious party, allowing them to understand
more about filtering methodologies at a receiving entity.</t> more about filtering methodologies at a receiving entity.</t>
</section> </section>
</section> </section>
<section anchor="operational-considerations" numbered="true" removeInRFC="fa
<section anchor="operational-considerations"><name>Operational Considerations</n lse" toc="include" pn="section-9">
ame> <name slugifiedName="name-operational-considerations">Operational Consider
ations</name>
<section anchor="report-generation"><name>Report Generation</name> <section anchor="report-generation" numbered="true" removeInRFC="false" to
c="include" pn="section-9.1">
<ul spacing="compact"> <name slugifiedName="name-report-generation">Report Generation</name>
<li>The error fields should be reasonably terse and usable.</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9
<li>If reports cannot be generator, the system should ideally log a useful error .1-1">
<li pn="section-9.1-1.1">The error fields should be reasonably terse a
nd usable.</li>
<li pn="section-9.1-1.2">If reports cannot be generated, the system sh
ould ideally log a useful error
that helps troubleshoot the issue.</li> that helps troubleshoot the issue.</li>
</ul> </ul>
</section> </section>
<section anchor="report-evaluation" numbered="true" removeInRFC="false" to
<section anchor="report-evaluation"><name>Report Evaluation</name> c="include" pn="section-9.2">
<t>As noted above, if a report does not match the specified format, the <name slugifiedName="name-report-evaluation">Report Evaluation</name>
<t indent="0" pn="section-9.2-1">As noted above, if a report does not ma
tch the specified format, the
evaluator will likely find the contents to be in question. Alternately, evaluator will likely find the contents to be in question. Alternately,
the evaluator may decide to sideline those reports so they can more easily the evaluator may decide to sideline those reports so they can more easily
collaborate with the report generator to identify where the issues are collaborate with the report generator to identify where the issues are
happening.</t> happening.</t>
<t>It's quite likely that the data contained within the reports will be extracte d and <t indent="0" pn="section-9.2-2">It's quite likely that the data contain ed within the reports will be extracted and
stored in a system that allows for easy reporting, dashboarding, and/or stored in a system that allows for easy reporting, dashboarding, and/or
monitoring. The XML reports themselves are not human readable in bulk, and a monitoring. The XML reports themselves are not human readable in bulk, and a
system such as the above may aid the Domain Owner with identifying issues.</t> system such as the above may aid the Domain Owner with identifying issues.</t>
</section> </section>
<section anchor="report-storage" numbered="true" removeInRFC="false" toc="
<section anchor="report-storage"><name>Report Storage</name> include" pn="section-9.3">
<t>Once a report is accepted and properly parsed by the report evaluator, it is <name slugifiedName="name-report-storage">Report Storage</name>
entirely up to that evaluator what they wish to do with the XML documents. For <t indent="0" pn="section-9.3-1">Once a report is accepted and properly
parsed by the report evaluator, it is
entirely up to that evaluator as to what they wish to do with the XML documents.
For
some domains, the quantity of reports could be fairly high, or the size of the some domains, the quantity of reports could be fairly high, or the size of the
reports themselves could be large. Once the data from the reports has been reports themselves could be large. Once the data from the reports has been
extracted and indexed, the reports seemingly have little value in most extracted and indexed, the reports seemingly have little value in most
situations.</t> situations.</t>
</section> </section>
</section> </section>
</middle>
</middle> <back>
<references pn="section-10">
<back> <name slugifiedName="name-references">References</name>
<references><name>Normative References</name> <references pn="section-10.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.1952. <reference anchor="RFC1952" target="https://www.rfc-editor.org/info/rfc1
xml"/> 952" quoteTitle="true" derivedAnchor="RFC1952">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2045. <front>
xml"/> <title>GZIP file format specification version 4.3</title>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. <author fullname="P. Deutsch" initials="P." surname="Deutsch"/>
xml"/> <date month="May" year="1996"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688. <abstract>
xml"/> <t indent="0">This specification defines a lossless compressed dat
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986. a format that is compatible with the widely used GZIP utility. This memo provide
xml"/> s information for the Internet community. This memo does not specify an Internet
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234. standard of any kind.</t>
xml"/> </abstract>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321. </front>
xml"/> <seriesInfo name="RFC" value="1952"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322. <seriesInfo name="DOI" value="10.17487/RFC1952"/>
xml"/> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5890. <reference anchor="RFC2045" target="https://www.rfc-editor.org/info/rfc2
xml"/> 045" quoteTitle="true" derivedAnchor="RFC2045">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6376. <front>
xml"/> <title>Multipurpose Internet Mail Extensions (MIME) Part One: Format
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6713. of Internet Message Bodies</title>
xml"/> <author fullname="N. Freed" initials="N." surname="Freed"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7208. <author fullname="N. Borenstein" initials="N." surname="Borenstein"/
xml"/> >
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7405. <date month="November" year="1996"/>
xml"/> <abstract>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7489. <t indent="0">This initial document specifies the various headers
xml"/> used to describe the structure of MIME messages. [STANDARDS-TRACK]</t>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. </abstract>
xml"/> </front>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8601. <seriesInfo name="RFC" value="2045"/>
xml"/> <seriesInfo name="DOI" value="10.17487/RFC2045"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-w3c/reference.W3C.R </reference>
EC-xmlschema-1.xml"/> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-w3c/reference.W3C.R 119" quoteTitle="true" derivedAnchor="RFC2119">
EC-xmlschema-2.xml"/> <front>
</references> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
<references><name>Informative References</name> le>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i <author fullname="S. Bradner" initials="S." surname="Bradner"/>
etf-dmarc-failure-reporting.xml"/> <date month="March" year="1997"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5598. <abstract>
xml"/> <t indent="0">In many standards track documents several words are
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7624. used to signify the requirements in the specification. These words are often cap
xml"/> italized. This document defines these words as they should be interpreted in IET
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9562. F documents. This document specifies an Internet Best Current Practices for the
xml"/> Internet Community, and requests discussion and suggestions for improvements.</t
</references> >
</abstract>
<section anchor="xsd"><name>DMARC XML Schema</name> </front>
<seriesInfo name="BCP" value="14"/>
<sourcecode type="xsd">&lt;?xml version=&quot;1.0&quot;?&gt; <seriesInfo name="RFC" value="2119"/>
&lt;xs:schema xmlns:xs=&quot;http://www.w3.org/2001/XMLSchema&quot; <seriesInfo name="DOI" value="10.17487/RFC2119"/>
targetNamespace=&quot;urn:ietf:params:xml:ns:dmarc-2.0&quot; </reference>
xmlns=&quot;urn:ietf:params:xml:ns:dmarc-2.0&quot; <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3
elementFormDefault=&quot;qualified&quot;&gt; 688" quoteTitle="true" derivedAnchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author fullname="M. Mealling" initials="M." surname="Mealling"/>
<date month="January" year="2004"/>
<abstract>
<t indent="0">This document describes an IANA maintained registry
for IETF standards which use Extensible Markup Language (XML) related items such
as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Descrip
tion Framework (RDF) Schemas.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference>
<reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3
986" quoteTitle="true" derivedAnchor="RFC3986">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"/>
<author fullname="L. Masinter" initials="L." surname="Masinter"/>
<date month="January" year="2005"/>
<abstract>
<t indent="0">A Uniform Resource Identifier (URI) is a compact seq
uence of characters that identifies an abstract or physical resource. This speci
fication defines the generic URI syntax and a process for resolving URI referenc
es that might be in relative form, along with guidelines and security considerat
ions for the use of URIs on the Internet. The URI syntax defines a grammar that
is a superset of all valid URIs, allowing an implementation to parse the common
components of a URI reference without knowing the scheme-specific requirements o
f every possible identifier. This specification does not define a generative gra
mmar for URIs; that task is performed by the individual specifications of each U
RI scheme. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5
234" quoteTitle="true" derivedAnchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker"/>
<author fullname="P. Overell" initials="P." surname="Overell"/>
<date month="January" year="2008"/>
<abstract>
<t indent="0">Internet technical specifications often need to defi
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="RFC5321" target="https://www.rfc-editor.org/info/rfc5
321" quoteTitle="true" derivedAnchor="RFC5321">
<front>
<title>Simple Mail Transfer Protocol</title>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<date month="October" year="2008"/>
<abstract>
<t indent="0">This document is a specification of the basic protoc
ol for Internet electronic mail transport. It consolidates, updates, and clarifi
es several previous documents, making all or parts of most of them obsolete. It
covers the SMTP extension mechanisms and best practices for the contemporary Int
ernet, but does not provide details about particular extensions. Although SMTP w
as designed as a mail transport and delivery protocol, this specification also c
ontains information that is important to its use as a "mail submission" protocol
for "split-UA" (User Agent) mail reading systems and mobile environments. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5321"/>
<seriesInfo name="DOI" value="10.17487/RFC5321"/>
</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="RFC5890" target="https://www.rfc-editor.org/info/rfc5
890" quoteTitle="true" derivedAnchor="RFC5890">
<front>
<title>Internationalized Domain Names for Applications (IDNA): Defin
itions and Document Framework</title>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<date month="August" year="2010"/>
<abstract>
<t indent="0">This document is one of a collection that, together,
describe the protocol and usage context for a revision of Internationalized Dom
ain Names for Applications (IDNA), superseding the earlier version. It describes
the document collection and provides definitions and other material that are co
mmon to the set. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5890"/>
<seriesInfo name="DOI" value="10.17487/RFC5890"/>
</reference>
<reference anchor="RFC6376" target="https://www.rfc-editor.org/info/rfc6
376" quoteTitle="true" derivedAnchor="RFC6376">
<front>
<title>DomainKeys Identified Mail (DKIM) Signatures</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker"/>
<author fullname="T. Hansen" initials="T." role="editor" surname="Ha
nsen"/>
<author fullname="M. Kucherawy" initials="M." role="editor" surname=
"Kucherawy"/>
<date month="September" year="2011"/>
<abstract>
<t indent="0">DomainKeys Identified Mail (DKIM) permits a person,
role, or organization that owns the signing domain to claim some responsibility
for a message by associating the domain with the message. This can be an author'
s organization, an operational relay, or one of their agents. DKIM separates the
question of the identity of the Signer of the message from the purported author
of the message. Assertion of responsibility is validated through a cryptographi
c signature and by querying the Signer's domain directly to retrieve the appropr
iate public key. Message transit from author to recipient is through relays that
typically make no substantive change to the message content and thus preserve t
he DKIM signature.</t>
<t indent="0">This memo obsoletes RFC 4871 and RFC 5672. [STANDARD
S-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="76"/>
<seriesInfo name="RFC" value="6376"/>
<seriesInfo name="DOI" value="10.17487/RFC6376"/>
</reference>
<reference anchor="RFC6713" target="https://www.rfc-editor.org/info/rfc6
713" quoteTitle="true" derivedAnchor="RFC6713">
<front>
<title>The 'application/zlib' and 'application/gzip' Media Types</ti
tle>
<author fullname="J. Levine" initials="J." surname="Levine"/>
<date month="August" year="2012"/>
<abstract>
<t indent="0">This document defines the 'application/gzip' and 'ap
plication/zlib' media types for compressed data using the gzip and zlib compress
ion formats. This document is not an Internet Standards Track specification; it
is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6713"/>
<seriesInfo name="DOI" value="10.17487/RFC6713"/>
</reference>
<reference anchor="RFC7208" target="https://www.rfc-editor.org/info/rfc7
208" quoteTitle="true" derivedAnchor="RFC7208">
<front>
<title>Sender Policy Framework (SPF) for Authorizing Use of Domains
in Email, Version 1</title>
<author fullname="S. Kitterman" initials="S." surname="Kitterman"/>
<date month="April" year="2014"/>
<abstract>
<t indent="0">Email on the Internet can be forged in a number of w
ays. In particular, existing protocols place no restriction on what a sending ho
st can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/
EHLO commands. This document describes version 1 of the Sender Policy Framework
(SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly
authorize the hosts that are allowed to use their domain names, and a receiving
host can check such authorization.</t>
<t indent="0">This document obsoletes RFC 4408.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7208"/>
<seriesInfo name="DOI" value="10.17487/RFC7208"/>
</reference>
<reference anchor="RFC7405" target="https://www.rfc-editor.org/info/rfc7
405" quoteTitle="true" derivedAnchor="RFC7405">
<front>
<title>Case-Sensitive String Support in ABNF</title>
<author fullname="P. Kyzivat" initials="P." surname="Kyzivat"/>
<date month="December" year="2014"/>
<abstract>
<t indent="0">This document extends the base definition of ABNF (A
ugmented Backus-Naur Form) to include a way to specify US-ASCII string literals
that are matched in a case-sensitive manner.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7405"/>
<seriesInfo name="DOI" value="10.17487/RFC7405"/>
</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>
<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="RFC8601" target="https://www.rfc-editor.org/info/rfc8
601" quoteTitle="true" derivedAnchor="RFC8601">
<front>
<title>Message Header Field for Indicating Message Authentication St
atus</title>
<author fullname="M. Kucherawy" initials="M." surname="Kucherawy"/>
<date month="May" year="2019"/>
<abstract>
<t indent="0">This document specifies a message header field calle
d "Authentication-Results" for use with electronic mail messages to indicate the
results of message authentication efforts. Any receiver-side software, such as
mail filters or Mail User Agents (MUAs), can use this header field to relay that
information in a convenient and meaningful way to users or to make sorting and
filtering decisions.</t>
<t indent="0">This document obsoletes RFC 7601.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8601"/>
<seriesInfo name="DOI" value="10.17487/RFC8601"/>
</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="W3C.REC-xmlschema-1" target="https://www.w3.org/TR/20
04/REC-xmlschema-1-20041028/" quoteTitle="true" derivedAnchor="W3C.REC-xmlschema
-1">
<front>
<title>XML Schema Part 1: Structures Second Edition</title>
<author fullname="Henry S. Thompson" role="editor"/>
<author fullname="David Beech" role="editor"/>
<author fullname="Murray Maloney" role="editor"/>
<author fullname="Noah Mendelsohn" role="editor"/>
<date day="28" month="October" year="2004"/>
</front>
<refcontent>W3C Recommendation</refcontent>
<annotation>Latest version available at <eref target="https://www.w3.o
rg/TR/xmlschema-1/"/>.</annotation>
</reference>
<reference anchor="W3C.REC-xmlschema-2" target="https://www.w3.org/TR/20
04/REC-xmlschema-2-20041028/" quoteTitle="true" derivedAnchor="W3C.REC-xmlschema
-2">
<front>
<title>XML Schema Part 2: Datatypes Second Edition</title>
<author fullname="Paul V. Biron" role="editor"/>
<author fullname="Ashok Malhotra" role="editor"/>
<date day="28" month="October" year="2004"/>
</front>
<refcontent>W3C Recommendation</refcontent>
<annotation>Latest version available at <eref target="https://www.w3.o
rg/TR/xmlschema-2/"/>.</annotation>
</reference>
</references>
<references pn="section-10.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="RFC5598" target="https://www.rfc-editor.org/info/rfc5
598" quoteTitle="true" derivedAnchor="RFC5598">
<front>
<title>Internet Mail Architecture</title>
<author fullname="D. Crocker" initials="D." surname="Crocker"/>
<date month="July" year="2009"/>
<abstract>
<t indent="0">Over its thirty-five-year history, Internet Mail has
changed significantly in scale and complexity, as it has become a global infras
tructure service. These changes have been evolutionary, rather than revolutionar
y, reflecting a strong desire to preserve both its installed base and its useful
ness. To collaborate productively on this large and complex system, all particip
ants need to work from a common view of it and use a common language to describe
its components and the interactions among them. But the many differences in per
spective currently make it difficult to know exactly what another participant me
ans. To serve as the necessary common frame of reference, this document describe
s the enhanced Internet Mail architecture, reflecting the current service. This
memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5598"/>
<seriesInfo name="DOI" value="10.17487/RFC5598"/>
</reference>
<reference anchor="RFC7624" target="https://www.rfc-editor.org/info/rfc7
624" quoteTitle="true" derivedAnchor="RFC7624">
<front>
<title>Confidentiality in the Face of Pervasive Surveillance: A Thre
at Model and Problem Statement</title>
<author fullname="R. Barnes" initials="R." surname="Barnes"/>
<author fullname="B. Schneier" initials="B." surname="Schneier"/>
<author fullname="C. Jennings" initials="C." surname="Jennings"/>
<author fullname="T. Hardie" initials="T." surname="Hardie"/>
<author fullname="B. Trammell" initials="B." surname="Trammell"/>
<author fullname="C. Huitema" initials="C." surname="Huitema"/>
<author fullname="D. Borkmann" initials="D." surname="Borkmann"/>
<date month="August" year="2015"/>
<abstract>
<t indent="0">Since the initial revelations of pervasive surveilla
nce in 2013, several classes of attacks on Internet communications have been dis
covered. In this document, we develop a threat model that describes these attack
s on Internet confidentiality. We assume an attacker that is interested in undet
ected, indiscriminate eavesdropping. The threat model is based on published, ver
ified attacks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7624"/>
<seriesInfo name="DOI" value="10.17487/RFC7624"/>
</reference>
<reference anchor="RFC9562" target="https://www.rfc-editor.org/info/rfc9
562" quoteTitle="true" derivedAnchor="RFC9562">
<front>
<title>Universally Unique IDentifiers (UUIDs)</title>
<author fullname="K. Davis" initials="K." surname="Davis"/>
<author fullname="B. Peabody" initials="B." surname="Peabody"/>
<author fullname="P. Leach" initials="P." surname="Leach"/>
<date month="May" year="2024"/>
<abstract>
<t indent="0">This specification defines UUIDs (Universally Unique
IDentifiers) --
also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform
Resource Name namespace for UUIDs. A UUID is 128 bits long and is
intended to guarantee uniqueness across space and time. UUIDs were
originally used in the Apollo Network Computing System (NCS), later
in the Open Software Foundation's (OSF's) Distributed Computing
Environment (DCE), and then in Microsoft Windows platforms.</t>
<t indent="0">This specification is derived from the OSF DCE speci
fication with the
kind permission of the OSF (now known as "The Open Group"). Information from ear
lier versions of the OSF DCE specification have
been incorporated into this document. This document obsoletes RFC
4122.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9562"/>
<seriesInfo name="DOI" value="10.17487/RFC9562"/>
</reference>
<reference anchor="RFC9991" target="https://www.rfc-editor.org/info/rfc9
991" quoteTitle="true" derivedAnchor="RFC9991">
<front>
<title>Domain-Based Message Authentication, Reporting, and Conforman
ce (DMARC) Failure Reporting</title>
<author initials="S." surname="Jones" fullname="Steven M. Jones" rol
e="editor">
<organization showOnFrontPage="true">DMARC.org</organization>
</author>
<author initials="A." surname="Vesely" fullname="Alessandro Vesely"
role="editor">
<organization showOnFrontPage="true">Tana</organization>
</author>
<date month="May" year="2026"/>
</front>
<seriesInfo name="RFC" value="9991"/>
<seriesInfo name="DOI" value="10.17487/RFC9991"/>
</reference>
</references>
</references>
<section anchor="xsd" numbered="true" removeInRFC="false" toc="include" pn="
section-appendix.a">
<name slugifiedName="name-dmarc-xml-schema">DMARC XML Schema</name>
<sourcecode type="xml" markers="false" pn="section-appendix.a-1">
&lt;?xml version="1.0"?&gt;
&lt;xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:dmarc-2.0"
xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
elementFormDefault="qualified"&gt;
&lt;!-- Elements with an optional &quot;lang&quot; attribute. --&gt; &lt;!-- Elements with an optional "lang" attribute. --&gt;
&lt;xs:complexType name=&quot;langAttrString&quot;&gt; &lt;xs:complexType name="langAttrString"&gt;
&lt;xs:simpleContent&gt; &lt;xs:simpleContent&gt;
&lt;xs:extension base=&quot;xs:string&quot;&gt; &lt;xs:extension base="xs:string"&gt;
&lt;xs:attribute name=&quot;lang&quot; type=&quot;xs:language&quot; &lt;xs:attribute name="lang" type="xs:language"
use=&quot;optional&quot; default=&quot;en&quot;/&gt; use="optional" default="en"/&gt;
&lt;/xs:extension&gt; &lt;/xs:extension&gt;
&lt;/xs:simpleContent&gt; &lt;/xs:simpleContent&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;!-- The time range in UTC defining the reporting period of &lt;!-- The time range in UTC defining the reporting period of
this report, specified in seconds since epoch. --&gt; this report, specified in seconds since epoch. --&gt;
&lt;xs:complexType name=&quot;DateRangeType&quot;&gt; &lt;xs:complexType name="DateRangeType"&gt;
&lt;xs:all&gt; &lt;xs:all&gt;
&lt;xs:element name=&quot;begin&quot; type=&quot;xs:integer&quot; &lt;xs:element name="begin" type="xs:integer"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;xs:element name=&quot;end&quot; type=&quot;xs:integer&quot; &lt;xs:element name="end" type="xs:integer"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;/xs:all&gt; &lt;/xs:all&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;!-- Report generator metadata. --&gt; &lt;!-- Report generator metadata. --&gt;
&lt;xs:complexType name=&quot;ReportMetadataType&quot;&gt; &lt;xs:complexType name="ReportMetadataType"&gt;
&lt;xs:all&gt; &lt;xs:all&gt;
&lt;!-- Reporting Organization --&gt; &lt;!-- Reporting Organization --&gt;
&lt;xs:element name=&quot;org_name&quot; type=&quot;xs:string&quot; &lt;xs:element name="org_name" type="xs:string"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- Contact to use when contacting the Reporting Organization --&gt; &lt;!-- Contact to use when contacting the Reporting Organization --&gt;
&lt;xs:element name=&quot;email&quot; type=&quot;xs:string&quot; &lt;xs:element name="email" type="xs:string"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- Additional contact details --&gt; &lt;!-- Additional contact details --&gt;
&lt;xs:element name=&quot;extra_contact_info&quot; type=&quot;langAttrString&q &lt;xs:element name="extra_contact_info" type="langAttrString"
uot; minOccurs="0" maxOccurs="1"/&gt;
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
&lt;!-- Unique Report-ID --&gt; &lt;!-- Unique Report-ID --&gt;
&lt;xs:element name=&quot;report_id&quot; type=&quot;xs:string&quot; &lt;xs:element name="report_id" type="xs:string"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- Timestamps used when forming report data --&gt; &lt;!-- Timestamps used when forming report data --&gt;
&lt;xs:element name=&quot;date_range&quot; type=&quot;DateRangeType&quot; &lt;xs:element name="date_range" type="DateRangeType"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- Optional error messages when processing DMARC policy --&gt; &lt;!-- Optional error messages when processing DMARC policy --&gt;
&lt;xs:element name=&quot;error&quot; type=&quot;langAttrString&quot; &lt;xs:element name="error" type="langAttrString"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;!-- Optional information about the generating software --&gt; &lt;!-- Optional information about the generating software --&gt;
&lt;xs:element name=&quot;generator&quot; type=&quot;xs:string&quot; &lt;xs:element name="generator" type="xs:string"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;/xs:all&gt; &lt;/xs:all&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;!-- Alignment mode (relaxed or strict) for DKIM and SPF. --&gt; &lt;!-- Alignment mode (relaxed or strict) for DKIM and SPF. --&gt;
&lt;xs:simpleType name=&quot;AlignmentType&quot;&gt; &lt;xs:simpleType name="AlignmentType"&gt;
&lt;xs:restriction base=&quot;xs:string&quot;&gt; &lt;xs:restriction base="xs:string"&gt;
&lt;xs:enumeration value=&quot;r&quot;/&gt; &lt;xs:enumeration value="r"/&gt;
&lt;xs:enumeration value=&quot;s&quot;/&gt; &lt;xs:enumeration value="s"/&gt;
&lt;/xs:restriction&gt; &lt;/xs:restriction&gt;
&lt;/xs:simpleType&gt; &lt;/xs:simpleType&gt;
&lt;!-- The policy actions specified by p, sp and np in the &lt;!-- The policy actions specified by p, sp, and np in the
DMARC Policy Record. --&gt; DMARC Policy Record. --&gt;
&lt;xs:simpleType name=&quot;DispositionType&quot;&gt; &lt;xs:simpleType name="DispositionType"&gt;
&lt;xs:restriction base=&quot;xs:string&quot;&gt; &lt;xs:restriction base="xs:string"&gt;
&lt;xs:enumeration value=&quot;none&quot;/&gt; &lt;xs:enumeration value="none"/&gt;
&lt;xs:enumeration value=&quot;quarantine&quot;/&gt; &lt;xs:enumeration value="quarantine"/&gt;
&lt;xs:enumeration value=&quot;reject&quot;/&gt; &lt;xs:enumeration value="reject"/&gt;
&lt;/xs:restriction&gt; &lt;/xs:restriction&gt;
&lt;/xs:simpleType&gt; &lt;/xs:simpleType&gt;
&lt;!-- The policy actions utilized on messages for this record. --&gt; &lt;!-- The policy actions utilized on messages for this record. --&gt;
&lt;!-- &lt;!--
&quot;none&quot;: No action taken "none": No action taken
&quot;pass&quot;: No action, passing DMARC w/enforcing policy "pass": No action, passing DMARC w/enforcing policy
&quot;quarantine&quot;: Failed DMARC, message marked for quarantine "quarantine": Failed DMARC, message marked for quarantine
&quot;reject&quot;: Failed DMARC, marked as reject "reject": Failed DMARC, marked as reject
--&gt; --&gt;
&lt;xs:simpleType name=&quot;ActionDispositionType&quot;&gt; &lt;xs:simpleType name="ActionDispositionType"&gt;
&lt;xs:restriction base=&quot;xs:string&quot;&gt; &lt;xs:restriction base="xs:string"&gt;
&lt;xs:enumeration value=&quot;none&quot;/&gt; &lt;xs:enumeration value="none"/&gt;
&lt;xs:enumeration value=&quot;pass&quot;/&gt; &lt;xs:enumeration value="pass"/&gt;
&lt;xs:enumeration value=&quot;quarantine&quot;/&gt; &lt;xs:enumeration value="quarantine"/&gt;
&lt;xs:enumeration value=&quot;reject&quot;/&gt; &lt;xs:enumeration value="reject"/&gt;
&lt;/xs:restriction&gt; &lt;/xs:restriction&gt;
&lt;/xs:simpleType&gt; &lt;/xs:simpleType&gt;
&lt;!-- The method used to discover the DMARC Policy Record used during &lt;!-- The method used to discover the DMARC Policy Record used during
evaluation. The available values are &quot;psl&quot; and &quot;treewalk&qu evaluation. The available values are "psl" and "treewalk",
ot;, where "psl" is the method from RFC 7489 and "treewalk" is
where &quot;psl&quot; is the method from [@?RFC7489] and the &quot;treewalk described in RFC 9989. --&gt;
&quot; &lt;xs:simpleType name="DiscoveryType"&gt;
is described in [@I-D.ietf-dmarc-dmarcbis]. --&gt; &lt;xs:restriction base="xs:string"&gt;
&lt;xs:simpleType name=&quot;DiscoveryType&quot;&gt; &lt;xs:enumeration value="psl"/&gt;
&lt;xs:restriction base=&quot;xs:string&quot;&gt; &lt;xs:enumeration value="treewalk"/&gt;
&lt;xs:enumeration value=&quot;psl&quot;/&gt;
&lt;xs:enumeration value=&quot;treewalk&quot;/&gt;
&lt;/xs:restriction&gt; &lt;/xs:restriction&gt;
&lt;/xs:simpleType&gt; &lt;/xs:simpleType&gt;
&lt;!-- The published DMARC policy. Unspecified tags have their &lt;!-- The published DMARC policy. Unspecified tags have their
default values. --&gt; default values. --&gt;
&lt;xs:complexType name=&quot;PolicyPublishedType&quot;&gt; &lt;xs:complexType name="PolicyPublishedType"&gt;
&lt;xs:all&gt; &lt;xs:all&gt;
&lt;!-- The domain at which the DMARC record was found. --&gt; &lt;!-- The domain at which the DMARC record was found. --&gt;
&lt;xs:element name=&quot;domain&quot; type=&quot;xs:string&quot; &lt;xs:element name="domain" type="xs:string"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- The policy published for messages from: --&gt; &lt;!-- The policy published for messages from: --&gt;
&lt;!-- * the domain. --&gt; &lt;!-- * the domain. --&gt;
&lt;xs:element name=&quot;p&quot; type=&quot;DispositionType&quot; &lt;xs:element name="p" type="DispositionType"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- * subdomains. --&gt; &lt;!-- * subdomains. --&gt;
&lt;xs:element name=&quot;sp&quot; type=&quot;DispositionType&quot; &lt;xs:element name="sp" type="DispositionType"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;!-- * non-existent subdomains. --&gt; &lt;!-- * non-existent subdomains. --&gt;
&lt;xs:element name=&quot;np&quot; type=&quot;DispositionType&quot; &lt;xs:element name="np" type="DispositionType"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;!-- The DKIM alignment mode. --&gt; &lt;!-- The DKIM alignment mode. --&gt;
&lt;xs:element name=&quot;adkim&quot; type=&quot;AlignmentType&quot; &lt;xs:element name="adkim" type="AlignmentType"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;!-- The SPF alignment mode. --&gt; &lt;!-- The SPF alignment mode. --&gt;
&lt;xs:element name=&quot;aspf&quot; type=&quot;AlignmentType&quot; &lt;xs:element name="aspf" type="AlignmentType"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;!-- Method used to find/obtain DMARC policy --&gt; &lt;!-- Method used to find/obtain DMARC policy. --&gt;
&lt;xs:element name=&quot;discovery_method&quot; type=&quot;DiscoveryType&quot &lt;xs:element name="discovery_method" type="DiscoveryType"
; minOccurs="0" maxOccurs="1"/&gt;
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt;
&lt;!-- Failure reporting options in effect. --&gt; &lt;!-- Failure reporting options in effect. --&gt;
&lt;xs:element name=&quot;fo&quot; type=&quot;xs:string&quot; &lt;xs:element name="fo" type="xs:string"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;!-- Whether testing mode was declared in the DMARC Record --&gt; &lt;!-- Whether testing mode was declared in the DMARC Record. --&gt;
&lt;xs:element name=&quot;testing&quot; type=&quot;TestingType&quot; &lt;xs:element name="testing" type="TestingType"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;/xs:all&gt; &lt;/xs:all&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;!-- Values for Testing mode attached to policy --&gt; &lt;!-- Values for Testing mode attached to policy. --&gt;
&lt;xs:simpleType name=&quot;TestingType&quot;&gt; &lt;xs:simpleType name="TestingType"&gt;
&lt;xs:restriction base=&quot;xs:string&quot;&gt; &lt;xs:restriction base="xs:string"&gt;
&lt;xs:enumeration value=&quot;n&quot;/&gt; &lt;xs:enumeration value="n"/&gt;
&lt;xs:enumeration value=&quot;y&quot;/&gt; &lt;xs:enumeration value="y"/&gt;
&lt;/xs:restriction&gt; &lt;/xs:restriction&gt;
&lt;/xs:simpleType&gt; &lt;/xs:simpleType&gt;
&lt;!-- The DMARC-aligned authentication result. --&gt; &lt;!-- The DMARC-aligned authentication result. --&gt;
&lt;xs:simpleType name=&quot;DMARCResultType&quot;&gt; &lt;xs:simpleType name="DMARCResultType"&gt;
&lt;xs:restriction base=&quot;xs:string&quot;&gt; &lt;xs:restriction base="xs:string"&gt;
&lt;xs:enumeration value=&quot;pass&quot;/&gt; &lt;xs:enumeration value="pass"/&gt;
&lt;xs:enumeration value=&quot;fail&quot;/&gt; &lt;xs:enumeration value="fail"/&gt;
&lt;/xs:restriction&gt; &lt;/xs:restriction&gt;
&lt;/xs:simpleType&gt; &lt;/xs:simpleType&gt;
&lt;!-- Reasons that may affect DMARC disposition or execution. --&gt; &lt;!-- Reasons that may affect DMARC disposition or execution. --&gt;
&lt;xs:simpleType name=&quot;PolicyOverrideType&quot;&gt; &lt;xs:simpleType name="PolicyOverrideType"&gt;
&lt;xs:restriction base=&quot;xs:string&quot;&gt; &lt;xs:restriction base="xs:string"&gt;
&lt;xs:enumeration value=&quot;local_policy&quot;/&gt; &lt;xs:enumeration value="local_policy"/&gt;
&lt;xs:enumeration value=&quot;mailing_list&quot;/&gt; &lt;xs:enumeration value="mailing_list"/&gt;
&lt;xs:enumeration value=&quot;other&quot;/&gt; &lt;xs:enumeration value="other"/&gt;
&lt;xs:enumeration value=&quot;policy_test_mode&quot;/&gt; &lt;xs:enumeration value="policy_test_mode"/&gt;
&lt;xs:enumeration value=&quot;trusted_forwarder&quot;/&gt; &lt;xs:enumeration value="trusted_forwarder"/&gt;
&lt;/xs:restriction&gt; &lt;/xs:restriction&gt;
&lt;/xs:simpleType&gt; &lt;/xs:simpleType&gt;
&lt;!-- Override reason consists of pre-defined override type and &lt;!-- Override reason consists of pre-defined override type and
free-text comment. --&gt; free-text comment. --&gt;
&lt;xs:complexType name=&quot;PolicyOverrideReason&quot;&gt; &lt;xs:complexType name="PolicyOverrideReason"&gt;
&lt;xs:all&gt; &lt;xs:all&gt;
&lt;xs:element name=&quot;type&quot; type=&quot;PolicyOverrideType&quot; &lt;xs:element name="type" type="PolicyOverrideType"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;xs:element name=&quot;comment&quot; type=&quot;langAttrString&quot; &lt;xs:element name="comment" type="langAttrString"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;/xs:all&gt; &lt;/xs:all&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;!-- Taking into account everything else in the record, &lt;!-- Taking into account everything else in the record,
the results of applying DMARC. If alignment fails the results of applying DMARC. If alignment fails
and the policy applied does not match the domain's and the policy applied does not match the domain's
configured policy, the reason element MUST be specified --&gt; configured policy, the reason element MUST be specified. --&gt;
&lt;xs:complexType name=&quot;PolicyEvaluatedType&quot;&gt; &lt;xs:complexType name="PolicyEvaluatedType"&gt;
&lt;xs:sequence&gt; &lt;xs:sequence&gt;
&lt;xs:element name=&quot;disposition&quot; type=&quot;ActionDispositionType&q &lt;xs:element name="disposition" type="ActionDispositionType"
uot; minOccurs="1" maxOccurs="1"/&gt;
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; &lt;xs:element name="dkim" type="DMARCResultType"
&lt;xs:element name=&quot;dkim&quot; type=&quot;DMARCResultType&quot; minOccurs="1" maxOccurs="1"/&gt;
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; &lt;xs:element name="spf" type="DMARCResultType"
&lt;xs:element name=&quot;spf&quot; type=&quot;DMARCResultType&quot; minOccurs="1" maxOccurs="1"/&gt;
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; &lt;xs:element name="reason" type="PolicyOverrideReason"
&lt;xs:element name=&quot;reason&quot; type=&quot;PolicyOverrideReason&quot; minOccurs="0" maxOccurs="unbounded"/&gt;
minOccurs=&quot;0&quot; maxOccurs=&quot;unbounded&quot;/&gt;
&lt;/xs:sequence&gt; &lt;/xs:sequence&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;xs:complexType name=&quot;RowType&quot;&gt; &lt;xs:complexType name="RowType"&gt;
&lt;xs:all&gt; &lt;xs:all&gt;
&lt;!-- The connecting IP. IPv4address or IPv6address &lt;!-- The connecting IP. IPv4address or IPv6address
as defined in RFC 3986 section 3.2.2 --&gt; as defined in RFC 3986, Section 3.2.2. --&gt;
&lt;xs:element name=&quot;source_ip&quot; type=&quot;xs:string&quot; &lt;xs:element name="source_ip" type="xs:string"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- The number of messages for which the &lt;!-- The number of messages for which the
PolicyEvaluatedType was applied. --&gt; PolicyEvaluatedType was applied. --&gt;
&lt;xs:element name=&quot;count&quot; type=&quot;xs:integer&quot; &lt;xs:element name="count" type="xs:integer"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- The DMARC disposition applied to matching messages. --&gt; &lt;!-- The DMARC disposition applied to matching messages. --&gt;
&lt;xs:element name=&quot;policy_evaluated&quot; type=&quot;PolicyEvaluatedTyp &lt;xs:element name="policy_evaluated" type="PolicyEvaluatedType"
e&quot; minOccurs="1" maxOccurs="1"/&gt;
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt;
&lt;/xs:all&gt; &lt;/xs:all&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;xs:complexType name=&quot;IdentifierType&quot;&gt; &lt;xs:complexType name="IdentifierType"&gt;
&lt;xs:all&gt; &lt;xs:all&gt;
&lt;!-- The RFC5322.From domain. --&gt; &lt;!-- The RFC5322.From domain. --&gt;
&lt;xs:element name=&quot;header_from&quot; type=&quot;xs:string&quot; &lt;xs:element name="header_from" type="xs:string"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- The RFC5321.MailFrom domain --&gt; &lt;!-- The RFC5321.MailFrom domain. --&gt;
&lt;xs:element name=&quot;envelope_from&quot; type=&quot;xs:string&quot; &lt;xs:element name="envelope_from" type="xs:string"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;!-- The envelope recipient domain. --&gt; &lt;!-- The envelope recipient domain. --&gt;
&lt;xs:element name=&quot;envelope_to&quot; type=&quot;xs:string&quot; &lt;xs:element name="envelope_to" type="xs:string"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;/xs:all&gt; &lt;/xs:all&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;!-- DKIM verification result, see RFC 8601 Section 2.7.1. --&gt; &lt;!-- DKIM verification result; see RFC 8601, Section 2.7.1. --&gt;
&lt;xs:simpleType name=&quot;DKIMResultType&quot;&gt; &lt;xs:simpleType name="DKIMResultType"&gt;
&lt;xs:restriction base=&quot;xs:string&quot;&gt; &lt;xs:restriction base="xs:string"&gt;
&lt;xs:enumeration value=&quot;none&quot;/&gt; &lt;xs:enumeration value="none"/&gt;
&lt;xs:enumeration value=&quot;pass&quot;/&gt; &lt;xs:enumeration value="pass"/&gt;
&lt;xs:enumeration value=&quot;fail&quot;/&gt; &lt;xs:enumeration value="fail"/&gt;
&lt;xs:enumeration value=&quot;policy&quot;/&gt; &lt;xs:enumeration value="policy"/&gt;
&lt;xs:enumeration value=&quot;neutral&quot;/&gt; &lt;xs:enumeration value="neutral"/&gt;
&lt;xs:enumeration value=&quot;temperror&quot;/&gt; &lt;xs:enumeration value="temperror"/&gt;
&lt;xs:enumeration value=&quot;permerror&quot;/&gt; &lt;xs:enumeration value="permerror"/&gt;
&lt;/xs:restriction&gt; &lt;/xs:restriction&gt;
&lt;/xs:simpleType&gt; &lt;/xs:simpleType&gt;
&lt;xs:complexType name=&quot;DKIMAuthResultType&quot;&gt; &lt;xs:complexType name="DKIMAuthResultType"&gt;
&lt;xs:all&gt; &lt;xs:all&gt;
&lt;!-- The &quot;d=&quot; tag in the signature. --&gt; &lt;!-- The "d=" tag in the signature. --&gt;
&lt;xs:element name=&quot;domain&quot; type=&quot;xs:string&quot; &lt;xs:element name="domain" type="xs:string"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- The &quot;s=&quot; tag in the signature. --&gt; &lt;!-- The "s=" tag in the signature. --&gt;
&lt;xs:element name=&quot;selector&quot; type=&quot;xs:string&quot; &lt;xs:element name="selector" type="xs:string"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- The DKIM verification result. --&gt; &lt;!-- The DKIM verification result. --&gt;
&lt;xs:element name=&quot;result&quot; type=&quot;DKIMResultType&quot; &lt;xs:element name="result" type="DKIMResultType"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- Any extra information (e.g., from Authentication-Results). --&gt; &lt;!-- Any extra information (e.g., from Authentication-Results). --&gt;
&lt;xs:element name=&quot;human_result&quot; type=&quot;langAttrString&quot; &lt;xs:element name="human_result" type="langAttrString"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;/xs:all&gt; &lt;/xs:all&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;!-- SPF domain scope. --&gt; &lt;!-- SPF domain scope. --&gt;
&lt;xs:simpleType name=&quot;SPFDomainScope&quot;&gt; &lt;xs:simpleType name="SPFDomainScope"&gt;
&lt;xs:restriction base=&quot;xs:string&quot;&gt; &lt;xs:restriction base="xs:string"&gt;
&lt;xs:enumeration value=&quot;mfrom&quot;/&gt; &lt;xs:enumeration value="mfrom"/&gt;
&lt;/xs:restriction&gt; &lt;/xs:restriction&gt;
&lt;/xs:simpleType&gt; &lt;/xs:simpleType&gt;
&lt;!-- SPF verification result, see RFC 8601 Section 2.7.2. --&gt; &lt;!-- SPF verification result; see RFC 8601, Section 2.7.2. --&gt;
&lt;xs:simpleType name=&quot;SPFResultType&quot;&gt; &lt;xs:simpleType name="SPFResultType"&gt;
&lt;xs:restriction base=&quot;xs:string&quot;&gt; &lt;xs:restriction base="xs:string"&gt;
&lt;xs:enumeration value=&quot;none&quot;/&gt; &lt;xs:enumeration value="none"/&gt;
&lt;xs:enumeration value=&quot;pass&quot;/&gt; &lt;xs:enumeration value="pass"/&gt;
&lt;xs:enumeration value=&quot;fail&quot;/&gt; &lt;xs:enumeration value="fail"/&gt;
&lt;xs:enumeration value=&quot;softfail&quot;/&gt; &lt;xs:enumeration value="softfail"/&gt;
&lt;xs:enumeration value=&quot;policy&quot;/&gt; &lt;xs:enumeration value="policy"/&gt;
&lt;xs:enumeration value=&quot;neutral&quot;/&gt; &lt;xs:enumeration value="neutral"/&gt;
&lt;xs:enumeration value=&quot;temperror&quot;/&gt; &lt;xs:enumeration value="temperror"/&gt;
&lt;xs:enumeration value=&quot;permerror&quot;/&gt; &lt;xs:enumeration value="permerror"/&gt;
&lt;/xs:restriction&gt; &lt;/xs:restriction&gt;
&lt;/xs:simpleType&gt; &lt;/xs:simpleType&gt;
&lt;xs:complexType name=&quot;SPFAuthResultType&quot;&gt; &lt;xs:complexType name="SPFAuthResultType"&gt;
&lt;xs:all&gt; &lt;xs:all&gt;
&lt;!-- The checked domain. --&gt; &lt;!-- The checked domain. --&gt;
&lt;xs:element name=&quot;domain&quot; type=&quot;xs:string&quot; &lt;xs:element name="domain" type="xs:string"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- The scope of the checked domain. --&gt; &lt;!-- The scope of the checked domain. --&gt;
&lt;xs:element name=&quot;scope&quot; type=&quot;SPFDomainScope&quot; &lt;xs:element name="scope" type="SPFDomainScope"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;!-- The SPF verification result. --&gt; &lt;!-- The SPF verification result. --&gt;
&lt;xs:element name=&quot;result&quot; type=&quot;SPFResultType&quot; &lt;xs:element name="result" type="SPFResultType"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- Any extra information (e.g., from Authentication-Results). &lt;!-- Any extra information (e.g., from Authentication-Results).
The information in the field below should be for a The information in the field below should be for a
person to be provided with additional information person to be provided with additional information
that may be useful when debugging SPF authentication that may be useful when debugging SPF authentication
issues. This could include broken records, invalid issues. This could include broken records, invalid
DNS responses, etc. --&gt; DNS responses, etc. --&gt;
&lt;xs:element name=&quot;human_result&quot; type=&quot;langAttrString&quot; &lt;xs:element name="human_result" type="langAttrString"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;/xs:all&gt; &lt;/xs:all&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;!-- This element contains DKIM and SPF results, uninterpreted &lt;!-- This element contains DKIM and SPF results, uninterpreted
with respect to DMARC. --&gt; with respect to DMARC. --&gt;
&lt;xs:complexType name=&quot;AuthResultType&quot;&gt; &lt;xs:complexType name="AuthResultType"&gt;
&lt;xs:sequence&gt; &lt;xs:sequence&gt;
&lt;!-- There may be zero or more DKIM signatures. --&gt; &lt;!-- There may be zero or more DKIM signatures. --&gt;
&lt;xs:element name=&quot;dkim&quot; type=&quot;DKIMAuthResultType&quot; &lt;xs:element name="dkim" type="DKIMAuthResultType"
minOccurs=&quot;0&quot; maxOccurs=&quot;unbounded&quot;/&gt; minOccurs="0" maxOccurs="unbounded"/&gt;
&lt;!-- There may be zero or one SPF result. --&gt; &lt;!-- There may be zero or one SPF result. --&gt;
&lt;xs:element name=&quot;spf&quot; type=&quot;SPFAuthResultType&quot; &lt;xs:element name="spf" type="SPFAuthResultType"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;/xs:sequence&gt; &lt;/xs:sequence&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;!-- This element contains all the authentication results that &lt;!-- This element contains all the authentication results that
were evaluated by the receiving system for the given set of were evaluated by the receiving system for the given set of
messages. --&gt; messages. --&gt;
&lt;xs:complexType name=&quot;RecordType&quot;&gt; &lt;xs:complexType name="RecordType"&gt;
&lt;xs:sequence&gt; &lt;xs:sequence&gt;
&lt;xs:element name=&quot;row&quot; type=&quot;RowType&quot; &lt;xs:element name="row" type="RowType"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;xs:element name=&quot;identifiers&quot; type=&quot;IdentifierType&quot; &lt;xs:element name="identifiers" type="IdentifierType"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;xs:element name=&quot;auth_results&quot; type=&quot;AuthResultType&quot; &lt;xs:element name="auth_results" type="AuthResultType"
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="1" maxOccurs="1"/&gt;
&lt;!-- Extension at record level --&gt; &lt;!-- Extension at record level --&gt;
&lt;xs:any processContents=&quot;lax&quot; &lt;xs:any processContents="lax"
minOccurs=&quot;0&quot; maxOccurs=&quot;unbounded&quot;/&gt; minOccurs="0" maxOccurs="unbounded"/&gt;
&lt;/xs:sequence&gt; &lt;/xs:sequence&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;xs:complexType name=&quot;ExtensionType&quot;&gt; &lt;xs:complexType name="ExtensionType"&gt;
&lt;xs:sequence&gt; &lt;xs:sequence&gt;
&lt;xs:any processContents=&quot;lax&quot; &lt;xs:any processContents="lax"
minOccurs=&quot;0&quot; maxOccurs=&quot;unbounded&quot;/&gt; minOccurs="0" maxOccurs="unbounded"/&gt;
&lt;/xs:sequence&gt; &lt;/xs:sequence&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;!-- Parent --&gt; &lt;!-- Parent --&gt;
&lt;xs:element name=&quot;feedback&quot;&gt; &lt;xs:element name="feedback"&gt;
&lt;xs:complexType&gt; &lt;xs:complexType&gt;
&lt;xs:sequence&gt; &lt;xs:sequence&gt;
&lt;xs:element name=&quot;version&quot; type=&quot;xs:decimal&quot; &lt;xs:element name="version" type="xs:decimal"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;xs:element name=&quot;report_metadata&quot; type=&quot;ReportMetadataType &lt;xs:element name="report_metadata" type="ReportMetadataType"
&quot; minOccurs="1" maxOccurs="1"/&gt;
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt; &lt;xs:element name="policy_published" type="PolicyPublishedType"
&lt;xs:element name=&quot;policy_published&quot; type=&quot;PolicyPublishedTy minOccurs="1" maxOccurs="1"/&gt;
pe&quot;
minOccurs=&quot;1&quot; maxOccurs=&quot;1&quot;/&gt;
&lt;!-- Extension at top level --&gt; &lt;!-- Extension at top level --&gt;
&lt;xs:element name=&quot;extension&quot; type=&quot;ExtensionType&quot; &lt;xs:element name="extension" type="ExtensionType"
minOccurs=&quot;0&quot; maxOccurs=&quot;1&quot;/&gt; minOccurs="0" maxOccurs="1"/&gt;
&lt;!-- One record per (IP, result, IDs Auths) tuples --&gt; &lt;!-- One record (IP, result, IDs Auths) per tuple --&gt;
&lt;xs:element name=&quot;record&quot; type=&quot;RecordType&quot; &lt;xs:element name="record" type="RecordType"
minOccurs=&quot;1&quot; maxOccurs=&quot;unbounded&quot;/&gt; minOccurs="1" maxOccurs="unbounded"/&gt;
&lt;/xs:sequence&gt; &lt;/xs:sequence&gt;
&lt;/xs:complexType&gt; &lt;/xs:complexType&gt;
&lt;/xs:element&gt; &lt;/xs:element&gt;
&lt;/xs:schema&gt; &lt;/xs:schema&gt;</sourcecode>
</sourcecode> </section>
</section> <section anchor="sample-report" numbered="true" removeInRFC="false" toc="inc
lude" pn="section-appendix.b">
<section anchor="sample-report"><name>Sample Report</name> <name slugifiedName="name-sample-report">Sample Report</name>
<sourcecode type="xml" markers="false" pn="section-appendix.b-1">
<sourcecode type="xml">&lt;feedback xmlns=&quot;urn:ietf:params:xml:ns:dmarc-2.0 &lt;feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"&gt;
&quot;&gt;
&lt;version&gt;1.0&lt;/version&gt; &lt;version&gt;1.0&lt;/version&gt;
&lt;report_metadata&gt; &lt;report_metadata&gt;
&lt;org_name&gt;Sample Reporter&lt;/org_name&gt; &lt;org_name&gt;Sample Reporter&lt;/org_name&gt;
&lt;email&gt;report_sender@example-reporter.com&lt;/email&gt; &lt;email&gt;report_sender@example-reporter.com&lt;/email&gt;
&lt;extra_contact_info&gt;...&lt;/extra_contact_info&gt; &lt;extra_contact_info&gt;...&lt;/extra_contact_info&gt;
&lt;report_id&gt;3v98abbp8ya9n3va8yr8oa3ya&lt;/report_id&gt; &lt;report_id&gt;3v98abbp8ya9n3va8yr8oa3ya&lt;/report_id&gt;
&lt;date_range&gt; &lt;date_range&gt;
&lt;begin&gt;302832000&lt;/begin&gt; &lt;begin&gt;302832000&lt;/begin&gt;
&lt;end&gt;302918399&lt;/end&gt; &lt;end&gt;302918399&lt;/end&gt;
&lt;/date_range&gt; &lt;/date_range&gt;
skipping to change at line 1791 skipping to change at line 2287
&lt;domain&gt;example.com&lt;/domain&gt; &lt;domain&gt;example.com&lt;/domain&gt;
&lt;result&gt;pass&lt;/result&gt; &lt;result&gt;pass&lt;/result&gt;
&lt;selector&gt;abc123&lt;/selector&gt; &lt;selector&gt;abc123&lt;/selector&gt;
&lt;/dkim&gt; &lt;/dkim&gt;
&lt;spf&gt; &lt;spf&gt;
&lt;domain&gt;example.com&lt;/domain&gt; &lt;domain&gt;example.com&lt;/domain&gt;
&lt;result&gt;fail&lt;/result&gt; &lt;result&gt;fail&lt;/result&gt;
&lt;/spf&gt; &lt;/spf&gt;
&lt;/auth_results&gt; &lt;/auth_results&gt;
&lt;/record&gt; &lt;/record&gt;
&lt;/feedback&gt; &lt;/feedback&gt;</sourcecode>
</sourcecode> </section>
</section> <section anchor="differences-from-rfc7489" numbered="true" removeInRFC="fals
e" toc="include" pn="section-appendix.c">
<section anchor="differences-from-rfc7489"><name>Differences from RFC7489</name> <name slugifiedName="name-differences-from-rfc-7489">Differences from RFC
<t>A bulleted list of some of the more noticeable/important differences 7489</name>
between DMARC <xref target="RFC7489"></xref> and this document:</t> <t indent="0" pn="section-appendix.c-1">Here is a bulleted list of some of
the more noticeable/important differences
<ul spacing="compact"> between DMARC <xref target="RFC7489" format="default" sectionFormat="of" derived
<li>Many elements of the defining XSD have been clarified, which means the Content="RFC7489"/> and this document:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-app
endix.c-2">
<li pn="section-appendix.c-2.1">Many elements of the defining XSD have b
een clarified, which means the
structure of the report should be more consistent</li> structure of the report should be more consistent</li>
<li>The report identifier has more structure</li> <li pn="section-appendix.c-2.2">The report identifier has more structure
<li>Clarification about the number of domains to be addressed per report</li> </li>
<li>The addition of extensions as part of the report structure</li> <li pn="section-appendix.c-2.3">Clarification provided about the number
<li>PSD is now included as part of the specification</li> of domains to be addressed per report</li>
<li>Selector is now required when reporting a DKIM signature</li> <li pn="section-appendix.c-2.4">The addition of extensions as part of th
</ul> e report structure</li>
<t>Furthermore, the original DMARC specification was contained within a single <li pn="section-appendix.c-2.5">PSD is now included as part of the speci
document, <xref target="RFC7489"></xref>. The original document has fication</li>
been split into three documents, DMARCbis <xref target="I-D.ietf-dmarc-dmarcbis" <li pn="section-appendix.c-2.6">Selector is now required when reporting
></xref>, this a DKIM signature</li>
document, and DMARCbis Failure </ul>
Reporting <xref target="I-D.ietf-dmarc-failure-reporting"></xref>. This allows <t indent="0" pn="section-appendix.c-3">Furthermore, the original DMARC sp
these pieces to ecification was contained within a single
document: <xref target="RFC7489" format="default" sectionFormat="of" derivedCont
ent="RFC7489"/>. The original document has
been split into three documents: <xref target="RFC9989" format="default" section
Format="of" derivedContent="RFC9989"/>, this
document, and <xref target="RFC9991" format="default" sectionFormat="of" derived
Content="RFC9991"/>. This allows these pieces to
potentially be altered in the future without re-opening the entire document, potentially be altered in the future without re-opening the entire document,
as well as allowing them to move through the IETF process independently.</t> as well as allowing them to move through the IETF process independently.</t>
<t>Acknowledgements</t> </section>
<t>Many thanks are deserved to those that helped create this document. Much of <section numbered="false" removeInRFC="false" toc="include" pn="section-appe
the content was created from the original <xref target="RFC7489"></xref>, and ha ndix.d">
s now been <name slugifiedName="name-acknowledgements">Acknowledgements</name>
updated to be more clear and correct some outstanding issues. The IETF <t indent="0" pn="section-appendix.d-1">Many thanks are deserved to those
DMARC Working Group has spent much time working to finalize this effort, that helped create this document. Much
and significant contributions were made by Seth Blank, Todd Herr, Steve Jones, of the content was created from <xref target="RFC7489" format="default" sectionF
Murray S. Kucherawy, Barry Leiba, John Levine, Scott Kitterman, Daniel Kvål, ormat="of" derivedContent="RFC7489"/> and has
Martijn van der Lee, Alessandro Veseley, and Matthäus Wander.</t> now been updated to be more clear and correct some outstanding issues. The
</section> IETF DMARC Working Group has spent much time working to finalize this effort,
and significant contributions were made by <contact fullname="Seth Blank"/>,
</back> <contact fullname="Todd Herr"/>, <contact fullname="Steve Jones"/>, <contact ful
lname="Scott Kitterman"/>, <contact fullname="Murray S. Kucherawy"/>, <contact f
ullname="Daniel Kvål"/>, <contact fullname="Barry Leiba"/>, <contact fullname="J
ohn Levine"/>, <contact fullname="Martijn van der Lee"/>, <contact fullname="Ale
ssandro Veseley"/>, and <contact fullname="Matthäus Wander"/>.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.e">
<name slugifiedName="name-authors-address">Author's Address</name>
<author initials="A." surname="Brotman" fullname="Alex Brotman" role="edit
or">
<organization showOnFrontPage="true">Comcast, Inc.</organization>
<address>
<email>alex_brotman@comcast.com</email>
</address>
</author>
</section>
</back>
</rfc> </rfc>
 End of changes. 201 change blocks. 
1516 lines changed or deleted 2605 lines changed or added

This html diff was produced by rfcdiff 1.48.