Diff: rfc9990.original.xml

	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
	or - mmark.miek.nl" -->
	<rfc version="3" ipr="trust200902" docName="draft-ietf-dmarc-aggregate-reporting
	-32" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.
	org/2001/XInclude" obsoletes="7489" indexInclude="true" consensus="true">


	<front>	<!DOCTYPE rfc [
	<title abbrev="DMARC Aggregate Reporting">Domain-based Message Authentication, R	<!ENTITY nbsp " ">
	eporting, and Conformance (DMARC) Aggregate Reporting</title><seriesInfo value="	<!ENTITY zwsp "">
	draft-ietf-dmarc-aggregate-reporting-32" stream="IETF" status="standard" name="I	<!ENTITY nbhy "‑">
	nternet-Draft"></seriesInfo>	<!ENTITY wj "⁠">
	<author initials="A." surname="Brotman (ed)" fullname="Alex Brotman"><organizati	]>
	on>Comcast, Inc.</organization><address><postal><street></street>
	</postal><email>alex_brotman@comcast.com</email>	<rfc version="3" ipr="trust200902" docName="draft-ietf-dmarc-aggregate-reporting
	</address></author><date year="2025" month="March" day="17"></date>	-32" number="9990" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="
	<area>Application</area>	http://www.w3.org/2001/XInclude" obsoletes="7489" updates="" consensus="true" sy
	<workgroup>DMARC</workgroup>	mRefs="true" sortRefs="true" tocInclude="true">

		<front>
		<title abbrev="DMARC Aggregate Reporting">Domain-Based Message
		Authentication, Reporting, and Conformance (DMARC) Aggregate
		Reporting</title>
		<seriesInfo name="RFC" value="9990"/>
		<author initials="A." surname="Brotman" fullname="Alex Brotman" role="editor
		">
		<organization>Comcast, Inc.</organization>
		<address>
		<email>alex_brotman@comcast.com</email>
		</address>
		</author>

		<date year="2026" month="May"/>

		<area>ART</area>
		<workgroup>dmarc</workgroup>
		<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->

		<keyword>example</keyword>

		<!--[rfced] FYI: We added the following sentence to the end of the
		Abstract as the Obsolete status was absent (this is now
		consistent with the companion documents).


		Current:
		This document obsoletes RFC 7489.
		-->
	<abstract>	<abstract>
	<t>Domain-based Message Authentication, Reporting, and Conformance	<t>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>


		<t>This document obsoletes RFC 7489.</t>

	</abstract>	</abstract>

	</front>	</front>

	<middle>	<middle>

	<section anchor="introduction"><name>Introduction</name>	<section anchor="introduction"><name>Introduction</name>

	<t>A key component of DMARC <xref target="I-D.ietf-dmarc-dmarcbis"></xref> (Doma	<t>A key component of Domain-based Message
	in-based Message	Authentication, Reporting, and Conformance (DMARC) <xref target="RFC9989"/> is t
	Authentication, Reporting, and Conformance) is the ability for Domain Owners to	he ability for Domain 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>These reports expose information relating to the DMARC policy, as well as
	the outcome of SPF (Sender Policy Framework) <xref target="RFC7208"></xref> &amp	the outcome of Sender Policy Framework (SPF) <xref target="RFC7208"/> and
	; DKIM	DomainKeys Identified Mail (DKIM) <xref target="RFC6376"/> validation.</t>
	(DomainKeys Identified Mail) <xref target="RFC6376"></xref> validation.</t>

	<section anchor="terminology"><name>Terminology</name>	<section anchor="terminology"><name>Terminology</name>

	<t>The key words "MUST", "MUST NOT", "REQUIRED", &	<t>
	quot;SHALL", "SHALL	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"NOT RECOMMENDED",	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	"MAY", and "OPTIONAL" in this document are to be interpreted	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	as	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref	be interpreted as
	> when, and only when, they	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	appear in all capitals, as shown here.</t>	when, and only when, they appear in all capitals, as shown here.
		</t>

	<section anchor="notation"><name>Notation</name>	<section anchor="notation"><name>Notation</name>
	<t>Certain properties of mail messages described in this document are	<t>Certain properties of mail messages described in this document are

	referenced using notation found in <xref target="RFC5598"></xref> (e.g., "R FC5322.From").</t>	referenced using notation found in <xref target="RFC5598"/> (e.g., "RFC5322 .From").</t>
	<t>This specification uses the Augmented Backus-Naur Form (ABNF)	<t>This specification uses the Augmented Backus-Naur Form (ABNF)

	notation of <xref target="RFC5234"></xref> and <xref target="RFC7405"></xref>.</ t>	notation of <xref target="RFC5234"/> and <xref target="RFC7405"/>.</t>
	</section>	</section>

	<section anchor="dmarc-terminology"><name>DMARC Terminology</name>	<section anchor="dmarc-terminology"><name>DMARC Terminology</name>

	<t>There are a number of terms defined in <xref target="I-D.ietf-dmarc-dmarcbis" ></xref> that are used	<t>There are a number of terms defined in <xref target="RFC9989"/> 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="compact">	<ul spacing="normal">
	<li>Author Domain</li>	<li>Author Domain</li>
	<li>DMARC Policy Record</li>	<li>DMARC Policy Record</li>
	<li>Domain Owner</li>	<li>Domain Owner</li>
	<li>Mail Receiver</li>	<li>Mail Receiver</li>
	<li>Organizational Domain</li>	<li>Organizational Domain</li>
	<li>Report Consumer</li>	<li>Report Consumer</li>
	</ul>	</ul>
	</section>	</section>
	</section>	</section>
	</section>	</section>


		<!--[rfced] We note that the errata for this document is addressed in
		RFC-to-be 9989. May we add a sentence in Section 2 ("Document
		Status") that mentions the errata has been addressed in the
		companion document?

		Original:
		This document, in part, along with RFCs 9989 and 9991, obsoletes
		and replaces DMARC [RFC7489].

		Perhaps:
		This document, in part, along with [RFC9989] and [RFC9991], obsoletes
		and replaces DMARC [RFC7489]. Note that errata for this document
		has been addressed as described in [RFC9989].
		-->

	<section anchor="document-status"><name>Document Status</name>	<section anchor="document-status"><name>Document Status</name>

	<t>This document, in part, along with DMARCbis <xref target="I-D.ietf-dmarc-dmar	<t>This document, in part, along with <xref target="RFC9989"/> and <xref target=
	cbis"></xref> DMARCbis	"RFC9991"/>, obsoletes and replaces DMARC <xref target="RFC7489"/>.</t>
	Failure Reporting <xref target="I-D.ietf-dmarc-failure-reporting"></xref>, obsol
	etes and replaces
	DMARC <xref target="RFC7489"></xref>.</t>
	</section>	</section>

	<section anchor="dmarc-feedback"><name>DMARC Feedback</name>	<section anchor="dmarc-feedback"><name>DMARC Feedback</name>
	<t>Providing Domain Owners with visibility into how Mail Receivers implement	<t>Providing Domain Owners with visibility into 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"><name>Aggregate Reports</name>	<section anchor="aggregate-reports"><name>Aggregate Reports</name>
	<t>The DMARC aggregate feedback report is designed to provide Domain	<t>The DMARC aggregate feedback report is designed to provide Domain
	Owners with precise insight into:</t>	Owners with precise insight into:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>authentication results,</li>	<li>authentication results,</li>
	<li>corrective action that needs to be taken by Domain Owners, and</li>	<li>corrective action that needs to be taken by Domain Owners, and</li>
	<li>the effect of Domain Owner DMARC policy on mail streams processed	<li>the effect of Domain Owner DMARC policy on mail streams processed
	by Mail Receivers.</li>	by Mail Receivers.</li>
	</ul>	</ul>
	<t>Aggregate DMARC feedback provides visibility into real-world mail	<t>Aggregate DMARC feedback provides visibility 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>Visibility comes in the form of daily (or more frequent)
	Receiver-originated feedback reports that contain aggregate data on	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>A separate report <bcp14>MUST</bcp14> be generated for each DMARC Policy Doma in 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>, "Handling Domains in Reports".</t>	<xref target="handling"/> ("Handling Domains in Reports").</t>
	<t>The report may include the following data:</t>	<t>The report may include the following data:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>The DMARC policy discovered and applied, if any</li>	<li>The DMARC policy discovered and applied, if any</li>
	<li>The selected message disposition</li>	<li>The selected message disposition</li>
	<li>The identifier evaluated by SPF and the SPF result, if any</li>	<li>The identifier evaluated by SPF and the SPF result, if any</li>
	<li>The identifier evaluated by DKIM and the DKIM result, if any</li>	<li>The identifier evaluated by DKIM and the DKIM result, if any</li>
	<li>For both DKIM and SPF, an indication of whether the identifier was	<li>For both DKIM and SPF, an indication of whether the identifier was

	in DMARC alignment (see <xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="of " relative="#" section="3.2.10"></xref>)</li>	in DMARC alignment (see <xref target="RFC9989" sectionFormat="of" section="3.2.1 0"/>)</li>
	<li>Sending and receiving domains</li>	<li>Sending and receiving domains</li>
	<li>The number of successful authentications</li>	<li>The number of successful authentications</li>
	<li>The counts of messages based on all messages received, even if	<li>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 . A single	<t>Each report <bcp14>MUST</bcp14> contain 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"><name>Description of the c	<section anchor="description-of-the-content-xml-file"><name>Description of the C
	ontent XML file</name>	ontent of the XML File</name>
	<t>NOTE TO RFC EDITOR: We tried a few various formats for these tables. If you
	would like to see those other formats, we can send over those attempts at
	your request. Please remove this comment before publishing.</t>
	<t>The format for these reports is defined in the XML Schema Definition	<t>The format for these reports is defined in the XML Schema Definition

	(XSD) in <xref target="xsd"></xref>. The XSD includes the possible	(XSD) in <xref target="xsd"/>. 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"/>.</t>
	<t>The format is also described in the following sections. Each section	<t>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>If a document does not match the specified format, the document
	evaluator SHOULD discard the report. The evaluator MAY choose to try to utilize	evaluator <bcp14>SHOULD</bcp14> discard the report. The evaluator <bcp14>MAY</bc
	some of the data, though if the format is in question, so may be the data. The	p14> choose to try to utilize
	report evaluator MAY choose to contact the report generator so	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 "#" specifies how many times an element may appear, this	<t>The column "#" specifies how many times an element may appear -- th is
	is sometimes referred to as multiplicity. The possible values are:</t>	is sometimes referred to as multiplicity. The possible values are:</t>


	<dl spacing="compact">	<dl spacing="normal">
	<dt>O:</dt>	<dt>O:</dt>
	<dd><bcp14>OPTIONAL</bcp14>, zero or one element</dd>	<dd><bcp14>OPTIONAL</bcp14>, zero or one element</dd>
	<dt>R:</dt>	<dt>R:</dt>
	<dd><bcp14>REQUIRED</bcp14>, exactly one element</dd>	<dd><bcp14>REQUIRED</bcp14>, exactly one element</dd>
	<dt>*:</dt>	<dt>*:</dt>
	<dd><bcp14>OPTIONAL</bcp14>, zero or more elements</dd>	<dd><bcp14>OPTIONAL</bcp14>, zero or more elements</dd>
	<dt>+:</dt>	<dt>+:</dt>
	<dd><bcp14>REQUIRED</bcp14>, one or more elements</dd>	<dd><bcp14>REQUIRED</bcp14>, one or more elements</dd>
	</dl>	</dl>


	<t>Some elements contain text meant for humans and support an optional	<t>Some elements contain text meant for humans and support an optional

	"lang" attribute whose value indicate the language of its contents.	"lang" attribute whose value indicates the language of its contents.
	The default value is "en".	The default value is "en".

	Elements supporting this optional attribute is marked with "[@lang]"	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"><name>XML root element</name>	<section anchor="xml-root-element"><name>XML Root Element</name>
	<t>DMARC aggregate feedback reports have the root element "feedback"	<t>DMARC aggregate feedback reports 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.
	</name>	<table align="center">
		<name>The XML Root Element</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>


	<tbody>	<tbody>
	<tr>	<tr>
	<td>feedback</td>	<td>feedback</td>
	<td>R</td>	<td>R</td>

	<td>First level elements, see <xref target="xml-first-level"></xref></td>	<td>First level elements; see <xref target="xml-first-level"/></td>
	</tr>	</tr>
	</tbody>	</tbody>

	</table></section>	</table>
		</section>

	<section anchor="xml-first-level"><name>First Level Elements</name>	<section anchor="xml-first-level"><name>First Level Elements</name>
	<t>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t >	<t>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t >

	<table align="left"><name>First level elements of the Aggregate Feedback Report.	<table align="center"><name>First Level Elements of the Aggregate Feedback Repor t
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td>version</td>	<td>version</td>
	<td>O</td>	<td>O</td>
	<td><bcp14>MUST</bcp14> have the value 1.0.</td>	<td><bcp14>MUST</bcp14> have the value 1.0.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>report_metadata</td>	<td>report_metadata</td>
	<td>R</td>	<td>R</td>

	<td>Report generator metadata, see <xref target="xml-report-metadata"></xref>.</ td>	<td>Report generator metadata; see <xref target="xml-report-metadata"/>.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>policy_published</td>	<td>policy_published</td>
	<td>R</td>	<td>R</td>

	<td>The DMARC policy configuration observed by the receiving system, see <xref t arget="xml-policy-published"></xref>.</td>	<td>The DMARC policy configuration observed by the receiving system; see <xref t arget="xml-policy-published"/>.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>extension</td>	<td>extension</td>
	<td>O</td>	<td>O</td>

	<td>Allows for future extensibility, see <xref target="xml-extension"></xref></t d>	<td>Allows for future extensibility; see <xref target="xml-extension"/>.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>record</td>	<td>record</td>
	<td>+</td>	<td>+</td>

	<td>Record(s) of the feedback from the report generator, see <xref target="xml-r ecord"></xref>.</td>	<td>Record(s) of the feedback from the report generator; see <xref target="xml-r ecord"/>.</td>
	</tr>	</tr>
	</tbody>	</tbody>

	</table><t>There <bcp14>MUST</bcp14> be at least one "record" element,	</table>
	they contain data
	stating which IP addresses were seen to have delivered messages for	<t>There <bcp14>MUST</bcp14> be at least one "record" element; these e
		lements 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 "record" element.</t>	is being reported, there will be at least one "record" element.</t>
	</section>	</section>


	<section anchor="xml-report-metadata"><name>Report generator metadata</name>	<section anchor="xml-report-metadata"><name>Report Generator Metadata</name>
	<table align="left"><name>Report generator metadata	<table align="center"><name>Report Generator Metadata
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>

	skipping to change at line 267 ¶	skipping to change at line 313 ¶

	<tr>	<tr>
	<td>extra_contact_info</td>	<td>extra_contact_info</td>
	<td>O</td>	<td>O</td>
	<td>[@lang] Additional contact details.</td>	<td>[@lang] Additional contact details.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>report_id</td>	<td>report_id</td>
	<td>R</td>	<td>R</td>

	<td>Unique Report-ID, see <xref target="report-id"></xref>.</td>	<td>Unique Report-ID; see <xref target="report-id"/>.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>date_range</td>	<td>date_range</td>
	<td>R</td>	<td>R</td>

	<td>The reporting period, see <xref target="xml-date-range"></xref>.</td>	<td>The reporting period; see <xref target="xml-date-range"/>.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>error</td>	<td>error</td>
	<td>O</td>	<td>O</td>

	<td>[@lang] Error messages encountered when processing the DMARC Policy Record, see <xref target="error"></xref>.</td>	<td>[@lang] Error messages encountered when processing the DMARC Policy Record; see <xref target="error"/>.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>generator</td>	<td>generator</td>
	<td>O</td>	<td>O</td>
	<td>The name and version of the report generator; this can help the Report Consu mer find out where to report bugs.</td>	<td>The name and version of the report generator; this can help the Report Consu mer find out where to report bugs.</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table></section>	</table></section>


	<section anchor="xml-date-range"><name>Contents of the "date_range" el	<section anchor="xml-date-range"><name>Contents of the "date_range" El
	ement</name>	ement</name>
	<t>The time range in UTC defining the reporting period of this report.</t>	<t>This element describes the time range in UTC defining the reporting period of
	<table align="left"><name>Contents of the "date_range" element	this report.</t>
		<table align="center"><name>Contents of the "date_range" Element
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>

	skipping to change at line 316 ¶	skipping to change at line 362 ¶
	<td>Start of the reporting period.</td>	<td>Start of the reporting period.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>end</td>	<td>end</td>
	<td>R</td>	<td>R</td>
	<td>End of the reporting period.</td>	<td>End of the reporting period.</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

	<ul spacing="compact">	<ul spacing="normal">
	<li>"begin" and "end" contain the number of seconds since ep	<li>"begin" and "end" contain the number of seconds since th
	och.</li>	e epoch.</li>
	</ul>	</ul>

	<t>The "begin" and "end" are meant to denote the reporting p eriod, and not	<t>The "begin" and "end" elements are meant to denote the re porting 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"><name>Contents of the "policy_publis	<section anchor="xml-policy-published"><name>Contents of the "policy_publis
	hed" element</name>	hed" Element</name>
	<t>Information on the DMARC Policy Record published for the Author Domain.	<t>This element provides information on the DMARC Policy Record published for th
		e Author Domain.
	The elements from "p" and onwards contain the discovered or default	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>Unspecified tags have their default values.</t>

	<table align="left"><name>Contents of the "policy_published" element	<table align="center"><name>Contents of the "policy_published" Element
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>

	skipping to change at line 396 ¶	skipping to change at line 442 ¶
	<td>The SPF Identifier Alignment mode.</td>	<td>The SPF Identifier Alignment mode.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>testing</td>	<td>testing</td>
	<td>O</td>	<td>O</td>
	<td>The value of the "t" tag.</td>	<td>The value of the "t" tag.</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>


		<!-- [rfced] We note that "psl" is not used in RFC 7489. Please review
		the citation below and let us know how it may be updated.

		Current:
		* "discovery_method" can have the value "psl" or "treewalk", where
		"psl" is the method from [RFC7489] and "treewalk" is described in
		[RFC9989].
		-->

	<ul>	<ul>
	<li><t>"discovery_method" can have the value "psl" or " treewalk", where	<li><t>"discovery_method" can have the value "psl" or " treewalk", where

	"psl" is the method from <xref target="RFC7489"></xref> and "tree	"psl" is the method from <xref target="RFC7489"/> and "treewalk&q
	walk" is described	uot; is described
	in <xref target="I-D.ietf-dmarc-dmarcbis"></xref>.</t>	in <xref target="RFC9989"/>.</t>
	</li>	</li>
	<li><t>Many of the items above (p, sp, etc.) are defined in	<li><t>Many of the items above (p, sp, etc.) are defined in

	the <xref target="I-D.ietf-dmarc-dmarcbis"></xref> document.</t>	<xref target="RFC9989"/>.</t>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>


	<section anchor="xml-extension"><name>Contents of the "extension" elem ent</name>	<section anchor="xml-extension"><name>Contents of the "extension" Elem ent</name>
	<t>Use of extensions may cause elements to be added here.	<t>Use of extensions may cause elements 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 "extension" element	<table align="center"><name>Contents of the "extension" Element
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td><any namespaced element></td>	<td><any namespaced element></td>
	<td>*</td>	<td>*</td>
	<td>File level elements defined by an extension.</td>	<td>File level elements defined by an extension.</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	<ul>	<ul>

	<li><t>"<any namespaced element>"</t>	<li>"<any namespaced element>": Zero or more elements in the nam
	<t>Zero or more elements in the namespace of the related	espace of the related
	extension declared in the XML root element.</t>	extension declared in the XML root element.</li>
	</li>
	</ul>	</ul>
	</section>	</section>


	<section anchor="xml-record"><name>Contents of the "record" element</n	<section anchor="xml-record"><name>Contents of the "record" Element</n
	ame>	ame>
	<t>The report <bcp14>MUST</bcp14> contain record(s) stating which IP addresses w	<t>The report <bcp14>MUST</bcp14> contain one or more records stating which IP a
	ere	ddresses 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 "record" element.</t>	there will be at least one "record" element.</t>
	<t>This element contains all the authentication results that were	<t>This element contains all the authentication 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 "record" elements may be specified.</t>	<t>An unlimited number of "record" elements may be specified.</t>
	<t>Use of extensions may cause other elements to be added to the end of	<t>Use of extensions may cause other elements to be added to the end of

	the record, such elements <bcp14>MUST</bcp14> be namespaced.</t>	the record; such elements <bcp14>MUST</bcp14> be namespaced.</t>
	<t>One record per (IP, result, authenitication identifiers) tuples.</t>
		<!--[rfced] The following text is not a complete sentence. Please review and
		let us know how it may be updated.

		Original:
		One record per (IP, result, authentication identifiers) tuples.

		Perhaps:
		There is one record (IP, result, authentication identifiers)
		per tuples.
		-->

		<t>One record per (IP, result, authentication identifiers) tuples.</t>
	<t>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t >	<t>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t >

	<table align="left"><name>Contents of the "record" element	<table align="center"><name>Contents of the "record" Element
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td>row</td>	<td>row</td>
	<td>R</td>	<td>R</td>

	<td>See <xref target="xml-row"></xref>.</td>	<td>See <xref target="xml-row"/>.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>identifiers</td>	<td>identifiers</td>
	<td>R</td>	<td>R</td>

	<td>The data that was used to apply policy for the given "row", see <x ref target="xml-identifiers"></xref>.</td>	<td>The data that was used to apply policy for the given "row"; see <x ref target="xml-identifiers"/>.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>auth_results</td>	<td>auth_results</td>
	<td>R</td>	<td>R</td>

	<td>The data related to authenticating the messages associated with this sending IP address, see <xref target="xml-auth-results"></xref>.</td>	<td>The data related to authenticating the messages associated with this sending IP address; see <xref target="xml-auth-results"/>.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td><any namespaced element></td>	<td><any namespaced element></td>
	<td>*</td>	<td>*</td>
	<td>Record level elements defined by an extension.</td>	<td>Record level elements defined by an extension.</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	<ul>	<ul>

	<li><t>"<any namespaced element>"</t>	<li>"<any namespaced element>": Zero or more elements in the nam
	<t>Zero or more elements in the namespace of the related	espace of the related
	extension declared in the XML root element.</t>	extension declared in the XML root element.</li>
	</li>
	</ul>	</ul>
	</section>	</section>


	<section anchor="xml-row"><name>Contents of the "row" element</name>	<section anchor="xml-row"><name>Contents of the "row" Element</name>
	<t>A "row" element contains the details of the connecting system, and	<t>A "row" element contains the details of the connecting system, and

	how many mails were received from it, for the particular combination	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 "row" element	<table align="center"><name>Contents of the "row" Element
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td>source_ip</td>	<td>source_ip</td>
	<td>R</td>	<td>R</td>

	<td>The connecting IP address. IPv4address or IPv6address as defined in <xref ta rget="RFC3986" sectionFormat="of" relative="#" section="3.2.2"></xref></td>	<td>The connecting IP address. IPv4address or IPv6address as defined in <xref ta rget="RFC3986" sectionFormat="of" section="3.2.2"/>.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>count</td>	<td>count</td>
	<td>R</td>	<td>R</td>
	<td>Number of messages for which the "policy_evaluated" was applied.</ td>	<td>Number of messages for which the "policy_evaluated" was applied.</ td>
	</tr>	</tr>

	<tr>	<tr>
	<td>policy_evaluated</td>	<td>policy_evaluated</td>
	<td>R</td>	<td>R</td>

	<td>The DMARC disposition applied to matching messages, see <xref target="xml-po licy-evaluated"></xref>.</td>	<td>The DMARC disposition applied to matching messages; see <xref target="xml-po licy-evaluated"/>.</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table></section>	</table></section>


	<section anchor="xml-policy-evaluated"><name>Contents of the "policy_evalua	<section anchor="xml-policy-evaluated"><name>Contents of the "policy_evalua
	ted" element</name>	ted" Element</name>
	<t>The results of applying the DMARC policy. If alignment fails and the	<t>This element describes the results of applying the DMARC policy. If alignmen
		t 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 "reason" 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>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t >

	<table align="left"><name>Contents of the "policy_evaluated" element	<table align="center"><name>Contents of the "policy_evaluated" Element
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td>disposition</td>	<td>disposition</td>
	<td>R</td>	<td>R</td>
	<td>The result of applying the DMARC policy.</td>	<td>The result of applying the DMARC policy.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>dkim</td>	<td>dkim</td>
	<td>R</td>	<td>R</td>

	<td>The result of the DKIM DMARC Identifier alignment test.</td>	<td>The result of the DKIM DMARC Identifier Alignment test.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>spf</td>	<td>spf</td>
	<td>R</td>	<td>R</td>

	<td>The result of the SPF DMARC Identifier alignment test.</td>	<td>The result of the SPF DMARC Identifier Alignment test.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>reason</td>	<td>reason</td>
	<td>*</td>	<td>*</td>

	<td>Policy override reason, see <xref target="xml-reason"></xref>.</td>	<td>Policy override reason; see <xref target="xml-reason"/>.</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	<ul>	<ul>
	<li><t>"spf" and "dkim" <bcp14>MUST</bcp14> be the evaluated values as they relate to	<li><t>"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>"reason" elements are meant to include any notes the reporter m ight	<li><t>"reason" elements are meant to contain any notes the reporter m ight
	want to include as to why the "disposition" policy does not match the	want to include as to why the "disposition" policy does not match the
	"policy_published", such as a local policy override.</t>	"policy_published", such as a local policy override.</t>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>


	<section anchor="xml-identifiers"><name>Contents of the "identifiers"	<section anchor="xml-identifiers"><name>Contents of the "identifiers"
	element</name>	Element</name>
	<table align="left"><name>Contents of the "identifiers" element	<table align="center"><name>Contents of the "identifiers" Element
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>

	skipping to change at line 611 ¶	skipping to change at line 675 ¶
	<td>The RFC5321.MailFrom domain that the SPF check has been applied to.</td>	<td>The RFC5321.MailFrom domain that the SPF check has been applied to.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>envelope_to</td>	<td>envelope_to</td>
	<td>O</td>	<td>O</td>
	<td>The RFC5321.RcptTo domain from the message.</td>	<td>The RFC5321.RcptTo domain from the message.</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

	<ul spacing="compact">	<ul spacing="normal">
	<li>"envelope_from" <bcp14>MAY</bcp14> be existing but empty if the me	<li>"envelope_from" <bcp14>MAY</bcp14> exist but be empty if the messa
	ssage had a	ge had a
	null reverse-path (see <xref target="RFC5321" sectionFormat="of" relative="#" se	null reverse-path (see <xref target="RFC5321" sectionFormat="of" section="4.5.5"
	ction="4.5.5"></xref>).</li>	/>).</li>
	</ul>	</ul>
	</section>	</section>


	<section anchor="xml-auth-results"><name>Contents of the "auth_results&quot	<section anchor="xml-auth-results"><name>Contents of the "auth_results&quot
	; element</name>	; Element</name>
	<t>Contains DKIM and SPF results, uninterpreted with respect to DMARC.</t>	<t>This element contains DKIM and SPF results, uninterpreted with respect to DMA
		RC.</t>
	<t>If validation is attempted for any DKIM signature, the results	<t>If validation is attempted for any DKIM signature, the results

	<bcp14>MUST</bcp14> be included in the report (within reason, see	<bcp14>MUST</bcp14> be included in the report (within reason; see
	<xref target="dkim-signatures"></xref>, "DKIM Signatures in Aggregate Repor	<xref target="dkim-signatures"/> ("DKIM Signatures in Aggregate Reports&quo
	ts", below for	t;) 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>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t >

	<table align="left"><name>Contents of the "auth_results" element	<table align="center"><name>Contents of the "auth_results" Element
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td>dkim</td>	<td>dkim</td>
	<td>*</td>	<td>*</td>

	<td>DKIM authentication result, see <xref target="xml-dkim"></xref>.</td>	<td>DKIM authentication result; see <xref target="xml-dkim"/>.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>spf</td>	<td>spf</td>
	<td>O</td>	<td>O</td>

	<td>SPF authentication result, see <xref target="xml-spf"></xref>.</td>	<td>SPF authentication result; see <xref target="xml-spf"/>.</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table></section>	</table></section>


	<section anchor="xml-dkim"><name>Contents of the "dkim" element</name>	<section anchor="xml-dkim"><name>Contents of the "dkim" Element</name>
	<table align="left"><name>Contents of the "dkim" element	<table align="center"><name>Contents of the "dkim" Element
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>

	skipping to change at line 676 ¶	skipping to change at line 740 ¶

	<tr>	<tr>
	<td>selector</td>	<td>selector</td>
	<td>R</td>	<td>R</td>
	<td>The selector that was used during validation (the "s=" tag in the signature).</td>	<td>The selector that was used during validation (the "s=" tag in the signature).</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>result</td>	<td>result</td>
	<td>R</td>	<td>R</td>

	<td>DKIM verification result, see below.</td>	<td>DKIM verification result; see below.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>human_result</td>	<td>human_result</td>
	<td>O</td>	<td>O</td>
	<td>[@lang] More descriptive information to the Domain Owner relating to evaluat ion failures.</td>	<td>[@lang] More descriptive information to the Domain Owner relating to evaluat ion failures.</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

	<ul spacing="compact">	<ul spacing="normal">
	<li>"result" is a lower-case string where the value is one of the resu	<li>"result" is a lowercase string where the value is one of the resul
	lts	ts
	defined in <xref target="RFC8601" sectionFormat="of" relative="#" section="2.7.1	defined in <xref target="RFC8601" sectionFormat="of" section="2.7.1"/>.</li>
	"></xref>.</li>
	</ul>	</ul>
	</section>	</section>


	<section anchor="xml-spf"><name>Contents of the "spf" element</name>	<section anchor="xml-spf"><name>Contents of the "spf" Element</name>
	<t>Only the "MAIL FROM" identity (see <xref target="RFC7208" sectionFo	<t>Only the "MAIL FROM" identity (see <xref target="RFC7208" sectionFo
	rmat="of" relative="#" section="2.4"></xref>)	rmat="of" section="2.4"/>)
	is used in DMARC.</t>	is used in DMARC.</t>

	<table align="left"><name>Contents of the "spf" element	<table align="center"><name>Contents of the "spf" Element
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>

	skipping to change at line 721 ¶	skipping to change at line 785 ¶

	<tr>	<tr>
	<td>scope</td>	<td>scope</td>
	<td>O</td>	<td>O</td>
	<td>The source of the domain used during validation.</td>	<td>The source of the domain used during validation.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>result</td>	<td>result</td>
	<td>R</td>	<td>R</td>

	<td>SPF verification result, see below.</td>	<td>SPF verification result; see below.</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>human_result</td>	<td>human_result</td>
	<td>O</td>	<td>O</td>
	<td>[@lang] More descriptive information to the Domain Owner relating to evaluat ion failures.</td>	<td>[@lang] More descriptive information to the Domain Owner relating to evaluat ion failures.</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>
	<ul>	<ul>
	<li><t>The only valid value for the "scope" element is "mfrom&quo t;.</t>	<li><t>The only valid value for the "scope" element is "mfrom&quo t;.</t>
	</li>	</li>

	<li><t>"result" is a lower-case string where the value is one of the r	<li><t>"result" is a lowercase string where the value is one of the re
	esults	sults
	defined in <xref target="RFC8601" sectionFormat="of" relative="#" section="2.7.2	defined in <xref target="RFC8601" sectionFormat="of" section="2.7.2"/>.</t>
	"></xref>.</t>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>


	<section anchor="xml-reason"><name>Contents of the "reason" element</n ame>	<section anchor="xml-reason"><name>Contents of the "reason" Element</n ame>
	<t>The policy override reason consists of a pre-defined override type	<t>The policy override reason consists of a pre-defined override type

	and free-text comment, see <xref target="policy-override-reason"></xref></t>	and free-text comment; see <xref target="policy-override-reason"/>.</t>
	<table align="left"><name>Contents of the "reason" element	<table align="center"><name>Contents of the "reason" Element
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Element name</th>	<th>Element name</th>
	<th>#</th>	<th>#</th>
	<th>Content</th>	<th>Content</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>

	skipping to change at line 771 ¶	skipping to change at line 835 ¶
	<td>comment</td>	<td>comment</td>
	<td>O</td>	<td>O</td>
	<td>[@lang] Further details, if available.</td>	<td>[@lang] Further details, 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"><name>Handling Domains in Reports</name>
	<t>In the same report, there <bcp14>MUST</bcp14> be a single DMARC Policy Domain , though there could be	<t>In the same report, there <bcp14>MUST</bcp14> be a single DMARC Policy Domain , though there could be

	multiple RFC5322.From Domains. Each RFC5322.From domain will create its own &qu ot;record"	multiple RFC5322.From domains. Each RFC5322.From domain will create its own &qu ot;record"
	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 "record",
	for	<!--[rfced] Please clarify the use of "extensibly". Is the intended
	bar.example.com. The second report would be for example.com and contain multipl	meaning perhaps "potentially" or "by extension"?
	e
		Current:
		The second report will be for example.com and contain multiple
		"record" elements, one for example.com and one for foo.example.com
		(and extensibly, other "record" elements for subdomains that
		likewise did not have an explicit DMARC Policy Record).
		-->

		<t>The first report will be for bar.example.com and contain only one "recor
		d", for
		bar.example.com. The second report will be for example.com and will contain mul
		tiple
	"record" elements, one for example.com and one for foo.example.com (an d extensibly,	"record" elements, one for example.com and one for foo.example.com (an d extensibly,

	other "record" elements for subdomains which likewise did not have an explicit	other "record" elements for subdomains that likewise did not have an e xplicit
	DMARC Policy Record).</t>	DMARC Policy Record).</t>
	</section>	</section>

	<section anchor="dkim-signatures"><name>DKIM Signatures in Aggregate Reports</na me>	<section anchor="dkim-signatures"><name>DKIM Signatures in Aggregate Reports</na me>
	<t>Within a single message, the possibility exists that there could be multiple DKIM	<t>Within a single message, the possibility 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="compact">	<ol spacing="normal">
	<li>A signature that passes DKIM, in strict alignment with the RFC5322.From doma in</li>	<li>A signature that passes DKIM, in strict alignment with the RFC5322.From doma in</li>
	<li>A signature that passes DKIM, in relaxed alignment with the RFC5322.From dom ain</li>	<li>A signature that passes DKIM, in relaxed alignment with the RFC5322.From dom ain</li>
	<li>Any other DKIM signatures that pass</li>	<li>Any other DKIM signatures that pass</li>
	<li>DKIM signatures that do not pass</li>	<li>DKIM signatures that do not pass</li>
	</ol>	</ol>
	<t>A report <bcp14>SHOULD</bcp14> contain no more than 100 signatures for a give n "row", in	<t>A report <bcp14>SHOULD</bcp14> contain no more than 100 signatures for a give n "row", in
	decreasing priority.</t>	decreasing priority.</t>
	</section>	</section>

	<section anchor="unique-identifiers-in-aggregate-reporting"><name>Unique Identif iers in Aggregate Reporting</name>	<section anchor="unique-identifiers-in-aggregate-reporting"><name>Unique Identif iers in Aggregate Reporting</name>
	<t>There are a few places where a unique identifier is specified as part of the	<t>There are a few places where a unique 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
	"Report-ID" and "unique-id". These are the fields that <bcp 14>MUST</bcp14> be identical when used.</t>	"Report-ID" and "unique-id". These are the fields that <bcp 14>MUST</bcp14> be identical when used.</t>
	</section>	</section>


	<section anchor="error"><name>Error element</name>	<section anchor="error"><name>Error Element</name>
	<t>A few examples of information contained within the "error" element(	<t>Here are a few examples of information contained within the "error"
	s):</t>	element(s):</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>DMARC Policy Record evaluation errors (invalid "rua" or "sp&q	<li>DMARC Policy Record evaluation errors (invalid "rua", "sp&quo
	uot;, etc.)</li>	t;, etc.)</li>
	<li>Multiple DMARC Policy Records at a given location</li>	<li>Multiple DMARC Policy Records at a given location</li>
	</ul>	</ul>

	<t>Be mindful that the "error" element is an unbounded string, but sho uld not contain	<t>Be mindful that the "error" element is an unbounded string but shou ld 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"><name>Policy Override Reason</name>	<section anchor="policy-override-reason"><name>Policy Override Reason</name>
	<t>The "reason" element, indicating an override of the DMARC policy, c onsists of a	<t>The "reason" element, indicating an override of the DMARC policy, c onsists of a
	mandatory "type" element and an optional "comment" element. The "type" element	mandatory "type" element and an optional "comment" element. The "type" element
	<bcp14>MUST</bcp14> have one of the pre-defined values listed below. The "c omment" element	<bcp14>MUST</bcp14> have one of the pre-defined values listed below. The "c omment" 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>Possible values for the policy override type:</t>

	<t>"local_policy": The Mail Receiver's local policy exempted the messa
	ge	<dl spacing="normal" newline="false">
		<dt>"local_policy":</dt><dd>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>"mailing_list": Local heuristics determined that the message arrive	<dt>"mailing_list":</dt><dd>Local heuristics determined that the messa
	d	ge 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>"other": Some policy exception not covered by the other entries in	<dt>"other":</dt><dd>Some policy exception not covered by the other en
	this list occurred. Additional detail can be found in the	tries in
	"comment" element.</t>	this list occurred. Additional details can be found in the
	<t>"policy_test_mode": The message was exempted from application of po	"comment" element.</dd>
	licy by	<dt>"policy_test_mode":</dt><dd>The message was exempted from applicat
	the testing mode ("t" tag) in the DMARC Policy Record.</t>	ion of policy by
	<t>"trusted_forwarder": Message authentication failure was anticipated	the testing mode ("t" tag) in the DMARC Policy Record.</dd>
	by	<dt>"trusted_forwarder":</dt><dd>Message authentication failure was an
		ticipated 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>
		</dl>
	</section>	</section>
	</section>	</section>

	<section anchor="extensions"><name>Extensions</name>	<section anchor="extensions"><name>Extensions</name>
	<t>The document format supports optional elements for extensions.	<t>The document format supports optional elements 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"/> ("Extensible Reporting").</t>
	</section>	</section>


	<section anchor="changes-in-policy-during-reporting-period"><name>Changes in Pol icy During Reporting Period</name>	<section anchor="changes-in-policy-during-reporting-period"><name>Changes in Pol icy During a Reporting Period</name>
	<t>Note that Domain Owners or their agents may change the published	<t>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="compact">	<ul spacing="normal">
	<li>generate for such a reporting period a single aggregate report	<li>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 "policy_published" element;</li>	single "policy_published" element</li>
	<li>generate multiple reports for the same period, one for each	<li>generate multiple reports for the same period, one for each

	published policy occurring during the reporting period;</li>	published policy occurring during the reporting period</li>
	</ul>	</ul>
	<t>Such policy changes are expected to be infrequent for any given	<t>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"><name>Report Request Discovery</name>	<section anchor="report-request-discovery"><name>Report Request Discovery</name>
	<t>A Mail Receiver discovers reporting requests when it looks up a DMARC	<t>A Mail Receiver discovers reporting requests 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 "rua" 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"><name>Report Delivery</name>	<section anchor="report-delivery"><name>Report Delivery</name>
	<t>The Mail Receiver, after preparing a report, <bcp14>MUST</bcp14> evaluate the	<t>The Mail Receiver, after preparing a report, <bcp14>MUST</bcp14> evaluate the

	provided reporting URIs (See <xref target="I-D.ietf-dmarc-dmarcbis"></xref>) in	provided reporting URIs (see <xref target="RFC9989"/>) in the order
	the order	given. If any of the URIs are malformed, they <bcp14>SHOULD</bcp14> be ignored.
	given. If any of the URIs are malformed, they SHOULD be ignored. An	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>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 "rua" tag does not specify otherwise, a	<t>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"><name>Definition of Report-ID</name>	<section anchor="report-id"><name>Definition of Report-ID</name>
	<t>This identifier <bcp14>MUST</bcp14> be unique among reports to the same domai n to	<t>This identifier <bcp14>MUST</bcp14> be unique among reports to the same domai n 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>


	<artwork> ridfmt = (dot-atom-text ["@" dot-atom-text]) ; from RFC 53	<sourcecode type="abnf"><![CDATA[
	22	ridfmt = (dot-atom-text ["@" dot-atom-text]) ; from RFC 5322


	ridtxt = ("<" ridfmt ">") / ridfmt	ridtxt = ("<" ridfmt ">") / ridfmt]]></sourcecode>
	</artwork>
	<t>The format specified here is not very strict as the key goal is uniqueness. I	<t>The format specified here is not very strict, as the key goal is uniqueness.
	n	In
	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 "1721054318-example.com@example.org". An al	.
	ternate	An example string might be "1721054318-example.com@example.org". An alternate
	could use a date string such as "2024-03-27_example.com@example.org".<	could use a date string such as "2024-03-27_example.com@example.org".</t>
	/t>
	</section>	</section>


		<!--[rfced] How may we rephrase "a [RFC5322] message" to avoid using
		RFC 5322 as an adjective?

		Original:
		The message generated by the Mail Receiver MUST be a [RFC5322]
		message formatted per [RFC2045].

		Perhaps A:
		The message generated by the Mail Receiver MUST be as
		described in [RFC5322] and formatted per [RFC2045].

		or
		Perhaps B:
		The message generated by the Mail Receiver MUST be a message that
		contains subaddressing [RFC5322] and is formatted per [RFC2045].
		-->

	<section anchor="email"><name>Email</name>	<section anchor="email"><name>Email</name>

	<t>The message generated by the Mail Receiver <bcp14>MUST</bcp14> be a <xref tar	<t>The message generated by the Mail Receiver <bcp14>MUST</bcp14> be a <xref tar
	get="RFC5322"></xref> message	get="RFC5322"/> message
	formatted per <xref target="RFC2045"></xref>. The aggregate report itself <bcp1	formatted per <xref target="RFC2045"/>. The aggregate report itself <bcp14>MUST
	4>MUST</bcp14> be included	</bcp14> be included
	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 "text/plain" or	part (with a human-friendly content-type, such as "text/plain" or
	"text/html").</t>	"text/html").</t>
	<t>The aggregate data <bcp14>MUST</bcp14> be an XML file that <bcp14>SHOULD</bcp 14> be subjected to	<t>The aggregate data <bcp14>MUST</bcp14> be an XML file that <bcp14>SHOULD</bcp 14> be subjected to

	GZIP <xref target="RFC1952"></xref> compression. Declining to apply compression can cause the	GZIP <xref target="RFC1952"/> compression. Declining to apply compression can c ause 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 "applica	aggregate data <bcp14>MUST</bcp14> be present using the media type "application/
	tion/gzip" if	gzip" if
	compressed (see <xref target="RFC6713"></xref>), and "text/xml" otherw	compressed (see <xref target="RFC6713"/>) and "text/xml" otherwise. The attachm
	ise. The attachment	ent
	filename <bcp14>MUST</bcp14> be constructed using the following ABNF:</t>	filename <bcp14>MUST</bcp14> be constructed using the following ABNF:</t>


	<artwork> filename = receiver "!" policy-domain "!" begin-t	<sourcecode type="abnf"><![CDATA[
	imestamp	filename = receiver "!" policy-domain "!" begin-timestamp
	"!" end-timestamp [ "!" unique-id ] ".&quo	"!" end-timestamp [ "!" unique-id ] "." extension
	t; extension

	receiver = domain-name
	; imported from RFC 6376


	policy-domain = domain-name	receiver = domain-name
		; imported from RFC 6376


	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

		unique-id = 1*(ALPHA / DIGIT)

		extension = "xml" / "xml.gz"]]></sourcecode>


	extension = "xml" / "xml.gz"
	</artwork>
	<t>The following primitive tokens that are used but otherwise unspecified	<t>The following primitive tokens that are used but otherwise unspecified

	are taken from the "Core Rules" of <xref target="RFC5234"></xref>: DIG	are taken from "Core Rules" (<xref target="RFC5234" sectionFormat="of" section="
	IT, ALPHA.</t>	B.1"/>): DIGIT, ALPHA.</t>
	<t>The extension <bcp14>MUST</bcp14> be "xml" for a plain XML file, or	<t>The extension <bcp14>MUST</bcp14> be "xml" for a plain XML file or "xml.gz" f
	"xml.gz" for an	or an
	XML file compressed using GZIP.</t>	XML file compressed using GZIP.</t>

	<t>"unique-id" allows an optional unique ID generated by the Mail	<t>"unique-id" allows an optional unique 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 get="RFC9562"/>.</t>
	<t>If a report generator needs to re-send a report, the system <bcp14>MUST</bcp1 4>	<t>If a report generator needs to re-send a report, the system <bcp14>MUST</bcp1 4>
	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>For example, this is a sample filename for the gzip file of a

	report to the Domain Owner "example.com" from the Mail Receiver	report to the Domain Owner "example.com" from the Mail Receiver
	"mail.receiver.example":</t>	"mail.receiver.example":</t>
	<t>mail.receiver.example!example.com!1013662812!1013749130.xml.gz</t>	<t indent="3">mail.receiver.example!example.com!1013662812!1013749130.xml.gz</t>
	<t>No specific MIME message structure is required for the message body. It	<t>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 DMARC	<t>Mail streams carrying DMARC feedback data <bcp14>MUST</bcp14> conform to the DMARC

	mechanism, thereby resulting in an aligned "pass" (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"/>).
	4.4"></xref>).
	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>The RFC5322.Subject field for individual report submissions <bcp14>MUST</bcp1 4>
	conform to the following ABNF:</t>	conform to the following ABNF:</t>


	<artwork> ; FWS is imported from RFC 5322	<sourcecode type="abnf"><![CDATA[
	dmarc-subject = %s"Report" 1*FWS %s"Domain:"	; FWS is imported from RFC 5322
	1FWS domain-name 1FWS ; policy domain	dmarc-subject = %s"Report" 1*FWS %s"Domain:"
	%s"Submitter:" 1*FWS	1FWS domain-name 1FWS ; policy domain
	domain-name 1*FWS ; report generator	%s"Submitter:" 1*FWS
	[ %s"Report-ID:" 1*FWS ridtxt ] ; defined above	domain-name 1*FWS ; report generator
	</artwork>	[ %s"Report-ID:" 1*FWS ridtxt ] ; defined above
		]]></sourcecode>

	<t>The first domain-name indicates the DNS domain name about which the	<t>The first domain-name indicates the 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>For instance, this is a possible Subject field for a report to the

	Domain Owner "example.com" from the Mail Receiver	Domain Owner "example.com" from the Mail Receiver
	"mail.receiver.example". It is folded as allowed by <xref target="RFC	"mail.receiver.example". It is folded as allowed by <xref target="RFC5322"/>:</
	5322"></xref>:</t>	t>


	<artwork> Subject: Report Domain: example.com	<artwork><![CDATA[
		Subject: Report Domain: example.com
	Submitter: mail.receiver.example	Submitter: mail.receiver.example

	Report-ID: <sample-ridtxt@example.com>	Report-ID: <sample-ridtxt@example.com>]]></artwork>
	</artwork>
	<t>This transport mechanism potentially encounters a problem when	<t>This transport mechanism potentially 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"	<t>Optionally, the report sender <bcp14>MAY</bcp14> choose to use the same "ridt xt"
	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"><name>Other Methods</name>	<section anchor="other-methods"><name>Other Methods</name>
	<t>The specification as written allows for the addition of other	<t>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"><name>Handling of Duplicates</name>	<section anchor="handling-of-duplicates"><name>Handling of Duplicates</name>
	<t>There may be a situation where the report generator attempts to deliver	<t>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="compact">	<ul spacing="normal">
	<li>Reject back to sender, ideally with a permfail error noting	<li>Reject back to sender, ideally with a permfail error noting
	the duplicate receipt</li>	the duplicate receipt</li>
	<li>Discard upon receipt</li>	<li>Discard upon receipt</li>
	<li>Inspect the contents to evaluate the timestamps and reported data,	<li>Inspect the contents to evaluate the timestamps and reported data,
	act as appropriate</li>	act as appropriate</li>
	<li>Accept the duplicate data</li>	<li>Accept the duplicate data</li>
	</ul>	</ul>


		<!--[rfced] To improve readability, may we update this sentence as follows?

		Original:
		When accepting the data, that's likely in a situation where it's not
		yet noticed, or a one-off experience.

		Perhaps:
		When accepting the data, it's likely that the duplicate data has not
		yet been noticed and is a one-off experience.
		-->

	<t>When accepting the data, that's likely in a situation where it's not	<t>When accepting the data, that's likely in a situation where it's not

	yet noticed, or a one-off experience. Long term, duplicate data	yet noticed or 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"><name>Verifying External Desti nations</name>	<section anchor="verifying-external-destinations"><name>Verifying External Desti nations</name>
	<t>It is possible to specify destinations for the different reports that	<t>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>Without checks, this would allow a bad actor to publish a DMARC

	Policy Record that requests that reports be sent to a victim address,	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>When a Mail Receiver discovers a DMARC Policy 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 "r ua" tag,	authority component of a <xref target="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>	<ol>
	<li><t>Extract the host portion of the authority component of the URI.	<li><t>Extract the host portion of the authority component of the URI.

	Call this the "destination host", as it refers to a Report	Call this the "destination host", as it refers to a Report
	Receiver.</t>	Receiver.</t>
	</li>	</li>

	<li><t>Prepend the string "_report._dmarc".</t>	<li><t>Prepend the string "_report._dmarc".</t>
	</li>	</li>
	<li><t>Prepend the domain name from which the policy was retrieved,	<li><t>Prepend the domain name from which the policy was retrieved,

	after conversion to an A-label <xref target="RFC5890"></xref> if needed.</t>	after conversion to an A-label <xref target="RFC5890"/> if needed.</t>
	</li>	</li>
	<li><t>If the length of the constructed name exceed DNS limits,	<li><t>If the length of the constructed name 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><t>Query the DNS for a TXT record at the 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><t>For each record returned, parse the result as a series of

	"tag=value" pairs, i.e., the same overall format as the DMARC Policy	"tag=value" pairs, i.e., the same overall format as the DMARC Policy
	Record (see <xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="of" relative="	Record (see <xref target="RFC9989" sectionFormat="of" section="4.7"/>). In
	#" section="4.7"></xref>). In	particular, the "v=DMARC1" tag is mandatory and <bcp14>MUST</bcp14> appear
	particular, the "v=DMARC1" tag is mandatory and <bcp14>MUST</bcp14> ap
	pear
	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 ";" is optional.</t>	trailing ";" is optional.</t>
	</li>	</li>
	<li><t>If the result includes no TXT resource records that pass basic	<li><t>If the result includes no TXT resource 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><t>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 "rua" tag is thus discovered, replace the	<li><t>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 "blue.example.com" cont	<t>For example, if the DMARC Policy Record for "blue.example.com" contained
	ained	<tt>"rua=mailto:reports@red.example.net"</tt>, the Organizational Domain host
	<tt>"rua=mailto:reports@red.example.net"</tt>, the Organizational Doma	extracted from the latter ("red.example.net") does not match
	in host	"blue.example.com", so this procedure is enacted. A TXT query for
	extracted from the latter ("red.example.net") does not match	"blue.example.com._report._dmarc.red.example.net" is issued. If a
	"blue.example.com", so this procedure is enacted. A TXT query for	single reply comes back containing a tag of "v=DMARC1", then the
	"blue.example.com._report._dmarc.red.example.net" is issued. If a
	single reply comes back containing a tag of "v=DMARC1", then the
	relationship between the two is confirmed. Moreover,	relationship between the two is confirmed. Moreover,

	"red.example.net" has the opportunity to override the report	"red.example.net" has the opportunity to override the report
	destination requested by "blue.example.com" if needed.</t>	destination requested by "blue.example.com" if needed.</t>
	<t>Where the above algorithm fails to confirm that the external	<t>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>A Report Consumer that is willing to receive 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

	"*._report._dmarc.example.com" containing at least "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>If the Report Consumer is overcome by volume, 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>


		<!--[rfced] Would it be correct to say that the Domain Owner should
		consider using a shorter "domain name" for clarity?

		Current:
		If the length of the DNS query is excessively long (Step 4 above),
		the Domain Owner may need to reconsider the domain being used to be
		shorter or reach out to another party that may allow for a
		shorter DNS label.

		Perhaps:
		If the DNS query length is excessively long (see Step 4), the
		Domain Owner may need to consider using a shorter domain name or
		coordinate with another party that may allow for a shorter DNS
		label.
		-->

	<t>If the length of the DNS query is excessively long (Step 4 above), the	<t>If the length of the DNS query is excessively long (Step 4 above), the

	Domain Owner may need to reconsider the domain being used to be shorter,	Domain Owner may need to reconsider the domain being used to be shorter
	or reach out to another party that may allow for a shorter DNS label.</t>	or reach out to another party that may allow for a shorter DNS label.</t>
	</section>	</section>

	<section anchor="extensible"><name>Extensible Reporting</name>	<section anchor="extensible"><name>Extensible Reporting</name>
	<t>DMARC reports allow for some extensibility, as defined by future	<t>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 "<any>" are provided i	of a DMARC report. Two positions of type "<any>" are provided in the
	n the	existing DMARC structure: one at file level in an "<extension>" element
	existing DMARC structure, one at file level, in an "<extension>"	after "<policy_published>" and one at record level after "<auth_results
	element	>".
	after "<policy_published>" and one at record level, after "
	<auth_results>".
	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>At file level:</t>


	<sourcecode type="xml"><feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0	<!--[rfced] XML snippets
	"
	xmlns:ext="URI for an extension-supplied name space">	a) Should the "</feedback>" closing tag be added after "</extension>"
		in the first XML example in Section 5 so that the XML parses, or is
		this meant to be a continuing example?

		Original:
		<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
		xmlns:ext="URI for an extension-supplied name space">
	...	...

	<policy_published>	<policy_published>
	<domain>example.com</domain>	<domain>example.com</domain>
	<p>quarantine</p>	<p>quarantine</p>
	<sp>none</sp>	<sp>none</sp>
	<testing>n</testing>	<testing>n</testing>
	</policy_published>	</policy_published>
	<extension>	<extension>
	<ext:arc-override>never</ext:arc-override>	<ext:arc-override>never</ext:arc-override>
	</extension>	</extension>
	</sourcecode>
	<t>Within the "record" element:</t>


	<sourcecode type="xml"> <record>	Perhaps:
	<row>	<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
		xmlns:ext="URI for an extension-supplied name space">
		...
		<policy_published>
		<domain>example.com</domain>
		<p>quarantine</p>
		<sp>none</sp>
		<testing>n</testing>
		</policy_published>
		<extension>
		<ext:arc-override>never</ext:arc-override>
		</extension>
		</feedback>

		b) Should "<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
		xmlns:ext="URI for an extension-supplied name space">" be added to the
		following XML snippet? Is a closing tag unnecessary because this is a
		continuing example, or should one be added?

		Current:
		<record>
		<row>
	...	...

	</row>	</row>
	<identifiers>	<identifiers>
	...	...

	</identifiers>	</identifiers>
	<auth_results>	<auth_results>
	...	...

	</auth_results>	</auth_results>
	<ext:arc-results>	<ext:arc-results>
	...	...

	</ext:arc-results>	</ext:arc-results>
	</record>	</record>
	<record>	<record>
	...	...

	</sourcecode>
	<t>Here "arc-override" and "arc-results" are hypothetical el	Perhaps:
	ement names	<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
	defined in the extension's name space.</t>	xmlns:ext="URI for an extension-supplied name space">
		...
		<record>
		<row>
		...
		</row>
		<identifiers>
		...
		</identifiers>
		<auth_results>
		...
		</auth_results>
		<ext:arc-results>
		...
		</ext:arc-results>
		</record>
		-->

		<sourcecode type="xml"><![CDATA[
		<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
		xmlns:ext="URI for an extension-supplied name space">
		...
		<policy_published>
		<domain>example.com</domain>
		<p>quarantine</p>
		<sp>none</sp>
		<testing>n</testing>
		</policy_published>
		<extension>
		<ext:arc-override>never</ext:arc-override>
		</extension>]]></sourcecode>

		<t>Within the "record" element:</t>

		<sourcecode type="xml"><![CDATA[
		<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
		xmlns:ext="URI for an extension-supplied name space">
		...
		<record>
		<row>
		...
		</row>
		<identifiers>
		...
		</identifiers>
		<auth_results>
		...
		</auth_results>
		<ext:arc-results>
		...
		</ext:arc-results>
		</record>
		<record>
		...]]></sourcecode>

		<t>Here "arc-override" and "arc-results" are hypothetical element names
		defined in the extension's namespace.</t>
	<t>Extension elements are optional. Any number of extensions is allowed.	<t>Extension elements are optional. Any number 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"><name>IANA Considerations</name>	<section anchor="iana-considerations"><name>IANA Considerations</name>


		<!--[rfced] FYI: Per IANA's note, we have updated the registrant contact
		from "IETF" to "IESG" in Sections 6.1 and 6.2.

		Original:
		Registrant Contact: Internet Engineering Task Force (iesg@ietf.org)

		Current:
		Registrant Contact: The IESG (iesg@ietf.org)
		-->

	<t>This document uses URNs to describe XML namespaces and XML schemas	<t>This document uses URNs to describe XML namespaces and XML schemas

	conforming to a registry mechanism described in <xref target="RFC3688"></xref>.	conforming to a registry mechanism described in <xref target="RFC3688"/>. Two UR
	Two URI	I
	assignments will be registered by the IANA.</t>	assignments have been registered by the IANA.
		</t>


	<section anchor="registration-request-for-the-dmarc-namespace"><name>Registratio	<section anchor="registration-request-for-the-dmarc-namespace"><name>Registratio
	n request for the DMARC namespace:</name>	n for the DMARC Namespace</name>
	<t>URI: urn:ietf:params:xml:ns:dmarc-2.0</t>	<t>
	<t>Registrant Contact: Internet Engineering Task Force (iesg@ietf.org)</t>	IANA has registered the following URI in the "ns" registry within the "IETF XML
	<t>XML: None. Namespace URIs do not represent an XML specification.</t>	Registry" group:
		</t>
		<dl spacing="compact" newline="false">
		<dt>URI:</dt><dd>urn:ietf:params:xml:ns:dmarc-2.0</dd>
		<dt>Registrant Contact:</dt><dd>The IESG (iesg@ietf.org)</dd>
		<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
		</dl>
	</section>	</section>


	<section anchor="registration-request-for-the-dmarc-xml-schema"><name>Registrati	<section anchor="registration-request-for-the-dmarc-xml-schema"><name>Registrati
	on request for the DMARC XML schema:</name>	on for the DMARC XML Schema</name>
	<t>URI: urn:ietf:params:xml:schema:dmarc-2.0</t>	<t>
	<t>Registrant Contact: Internet Engineering Task Force (iesg@ietf.org)</t>	IANA has registered the following URI in the "schema" registry within the "IETF
	<t>XML: See Appendix A. DMARC XML Schema (<xref target="W3C.REC-xmlschema-1"></x	XML Registry" group:
	ref> and	</t>
	<xref target="W3C.REC-xmlschema-2"></xref>) in this document.</t>	<dl spacing="compact" newline="false">
		<dt>URI:</dt><dd>urn:ietf:params:xml:schema:dmarc-2.0</dd>
		<dt>Registrant Contact:</dt><dd>The IESG (iesg@ietf.org)</dd>
		<dt>XML:</dt><dd>See the DMARC XML schema <xref target="W3C.REC-xmlschema-1"/>
		<xref target="W3C.REC-xmlschema-2"/> in <xref target="xsd"/> of this document.</
		dd>
		</dl>
	</section>	</section>
	</section>	</section>

	<section anchor="privacy-considerations"><name>Privacy Considerations</name>	<section anchor="privacy-considerations"><name>Privacy Considerations</name>

	<t>This section will discuss exposure related to DMARC aggregate reporting.</t>	<t>This section discusses exposure related to DMARC aggregate reporting.</t>

	<section anchor="report-recipients"><name>Report Recipients</name>	<section anchor="report-recipients"><name>Report Recipients</name>
	<t>A DMARC Policy Record can specify that reports should be sent to an	<t>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

	skipping to change at line 1230 ¶	skipping to change at line 1464 ¶
	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"><name>Data Contained Within Repo rts</name>	<section anchor="data-contained-within-reports"><name>Data Contained Within Repo rts</name>
	<t>Aggregate feedback reports contain aggregated data relating to	<t>Aggregate feedback reports contain aggregated 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>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>Domain Owners should have no concerns in 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"><name>Feedback Leakage</name>	<section anchor="leakage"><name>Feedback Leakage</name>

	<t>Providing feedback reporting to PSOs (Public Suffix Operator) for a	<t>Providing feedback reporting to Public Suffix Operators (PSOs) for a
	PSD (Public Suffix Domain) <xref target="I-D.ietf-dmarc-dmarcbis"></xref> can, i	Public Suffix Domain (PSD) <xref target="RFC9989"/> can, in some
	n 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 s to consider:</t>	surveillance (see <xref target="RFC7624"/>). There are roughly three cases to c onsider:</t>


	<ul>	<dl spacing="normal" newline="true">
	<li><t>Single Organization PSDs (e.g., ".mil")</t>	<dt>Single Organization PSDs (e.g., ".mil"):</dt>
	<t>Aggregate reports based on PSD DMARC have the potential to	<dd>Aggregate reports based on PSD DMARC have the 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>Multi-organization PSDs requiring DMARC usage (e.g., ".bank"):</dt>
	<li><t>Multi-organization PSDs requiring DMARC usage (e.g., ".bank")</	<dd>Aggregate reports based on PSD DMARC will only be generated for domains
	t>	that do not publish a DMARC Policy Record at the Organizational Domain or
	<t>Aggregate reports based on PSD DMARC will only be generated for domains that	host level. For domains that do publish the required DMARC Policy Records,
	do not publish a DMARC Policy Record at the Organizational Domain or host level.	the feedback reporting addresses of the Organizational Domain (or hosts)
	For domains that do publish the required DMARC Policy Records, the	will be used. The only direct risk of feedback leakage for these PSDs are
	feedback reporting addresses of the Organizational Domain (or	for Organizational Domains that are out of compliance with PSD policy. Data
	hosts) will be used. The only direct risk of feedback leakage for	on non-existent domains would be sent to the PSO.</dd>
	these PSDs are for Organizational Domains that are out of	<dt>Multi-organization PSDs not requiring DMARC usage (e.g., ".com"):</dt>
	compliance with PSD policy. Data on non-existent domains	<dd>Privacy risks for Organizational Domains that have not deployed DMARC
	would be sent to the PSO.</t>	within such PSDs can be significant. For non-DMARC Organizational Domains,
	</li>	all DMARC feedback will be directed to the PSO if that PSO itself has a
	<li><t>Multi-organization PSDs not requiring DMARC usage (e.g., ".com"	DMARC Policy Record that specifies a "rua" tag. Any non-DMARC
	)</t>	Organizational Domain would have its feedback reports redirected to the PSO.
	<t>Privacy risks for Organizational Domains that have not deployed DMARC	The content of such reports, particularly for existing domains, is privacy
	within such PSDs can be significant. For non-DMARC Organizational	sensitive.</dd>
	Domains, all DMARC feedback will be directed to the PSO if that PSO	</dl>
	itself has a DMARC Policy Record that specifies a "rua" tag. Any non-
	DMARC
	Organizational Domain would have its Feedback Reports redirected to
	the PSO. The content of such reports, particularly for existing
	domains, is privacy sensitive.</t>
	</li>
	</ul>
	<t>PSOs will receive feedback on non-existent domains, which may be	<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"><name>Security Considerations</name>	<section anchor="security-considerations"><name>Security Considerations</name>

	<t>While reviewing this document and its Security Considerations, it is ideal	<t>While reviewing this document and its security considerations, it is ideal
	that the reader would also review Privacy Considerations above, as well as	that the reader also review the Privacy Considerations section above, as well as
	the Privacy Considerations and Security Considerations in section	the privacy considerations and security considerations in Sections
	<xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="bare" relative="#" section	<xref target="RFC9989" sectionFormat="bare" section="10"/> and <xref target="RFC
	="9"></xref> and <xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="bare" rel	9989" sectionFormat="bare" section="11"/> of
	ative="#" section="10"></xref> of	<xref target="RFC9989"/>.</t>
	<xref target="I-D.ietf-dmarc-dmarcbis"></xref>.</t>


	<section anchor="report-contents-as-an-attack"><name>Report Contents as an Attac k</name>	<section anchor="report-contents-as-an-attack"><name>Report Content as an Attack </name>
	<t>Aggregate reports are supposed to be processed automatically. An attacker	<t>Aggregate reports are supposed to be processed 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"><name>False Information</name>	<section anchor="false-information"><name>False Information</name>
	<t>The data contained within aggregate reports may be forged. An attacker might	<t>The data contained within aggregate reports 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"><name>Disclosure of Filter ing Information</name>	<section anchor="disclosure-of-filtering-information"><name>Disclosure of Filter ing Information</name>
	<t>While not specified in this document itself, the availability of extensions	<t>While not specified in this document itself, 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"><name>Operational Considerations</n ame>	<section anchor="operational-considerations"><name>Operational Considerations</n ame>

	<section anchor="report-generation"><name>Report Generation</name>	<section anchor="report-generation"><name>Report Generation</name>


	<ul spacing="compact">	<ul spacing="normal">
	<li>The error fields should be reasonably terse and usable.</li>	<li>The error fields should be reasonably terse and usable.</li>

	<li>If reports cannot be generator, the system should ideally log a useful error	<li>If reports cannot be generated, the system should 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"><name>Report Evaluation</name>	<section anchor="report-evaluation"><name>Report Evaluation</name>
	<t>As noted above, if a report does not match the specified format, the	<t>As noted above, if a report does not match 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>It's quite likely that the data contained within the reports will be extracte d 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"><name>Report Storage</name>	<section anchor="report-storage"><name>Report Storage</name>
	<t>Once a report is accepted and properly parsed by the report evaluator, it is	<t>Once a report is accepted and properly parsed by the report evaluator, it is

	entirely up to that evaluator what they wish to do with the XML documents. For	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>	<back>

		<references><name>References</name>
	<references><name>Normative References</name>	<references><name>Normative References</name>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i	<!-- [RFCYYY1]
	etf-dmarc-dmarcbis.xml"/>	RFC 9989
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1952.	draft-ietf-dmarc-dmarcbis-41
	xml"/>	in RFC-EDITOR as of 05/11/26
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2045.	-->
	xml"/>	<reference anchor="RFC9989" target="https://www.rfc-editor.org/info/rfc9989">
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.	<front>
	xml"/>	<title>Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.	</title>
	xml"/>	<author initials="T." surname="Herr" fullname="Todd Herr" role="editor">
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.	<organization>Valimail</organization>
	xml"/>	</author>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.	<author initials="J. R." surname="Levine" fullname="John R. Levine" role="
	xml"/>	editor">
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321.	<organization>Standcore LLC</organization>
	xml"/>	</author>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.	<date month='May' year='2026'/>
	xml"/>	</front>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5890.	<seriesInfo name="RFC" value="9989"/>
	xml"/>	<seriesInfo name="DOI" value="10.17487/RFC9989"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6376.	</reference>
	xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6713.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1952.xml"
	xml"/>	/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7208.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2045.xml"
	xml"/>	/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7405.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
	xml"/>	/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7489.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"
	xml"/>	/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"
	xml"/>	/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8601.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
	xml"/>	/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-w3c/reference.W3C.R	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"
	EC-xmlschema-1.xml"/>	/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-w3c/reference.W3C.R	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"
	EC-xmlschema-2.xml"/>	/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6713.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7208.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8601.xml"
		/>

		<!-- [rfced] FYI: We updated the dates for the W3C reference entries
		from "2 May 2001" to "28 October 2004" to match the most current
		version of the two W3C Recommendations.
		-->

		<reference anchor="W3C.REC-xmlschema-1" target="https://www.w3.org/TR/2004/REC-x
		mlschema-1-20041028/">
		<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.org/TR
		/xmlschema-1/"/>.</annotation>
		</reference>

		<reference anchor="W3C.REC-xmlschema-2" target="https://www.w3.org/TR/2004/REC-x
		mlschema-2-20041028/">
		<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.org/TR
		/xmlschema-2/"/>.</annotation>
		</reference>

	</references>	</references>
	<references><name>Informative References</name>	<references><name>Informative References</name>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i	<!-- [RFCYYY2]
	etf-dmarc-failure-reporting.xml"/>	RFC 9991
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5598.	draft-ietf-dmarc-failure-reporting-25
	xml"/>	IESG State: in RFC-EDITOR as of 05/11/26
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7624.	-->
	xml"/>	<reference anchor="RFC9991" target="https://www.rfc-editor.org/info/rfc9991">
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9562.	<front>
	xml"/>	<title>Domain-Based Message Authentication, Reporting, and Conformance (DM
		ARC) Failure Reporting</title>
		<author initials="S. M." surname="Jones" fullname="Steven M Jones" role="e
		ditor">
		<organization>DMARC.org</organization>
		</author>
		<author initials="A." surname="Vesely" fullname="Alessandro Vesely" role="
		editor">
		<organization>Tana</organization>
		</author>
		<date month="May" year="2026" />
		</front>
		<seriesInfo name="RFC" value="9991"/>
		<seriesInfo name="DOI" value="10.17487/RFC9991"/>
		</reference>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5598.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7624.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9562.xml"
		/>
		</references>
	</references>	</references>

	<section anchor="xsd"><name>DMARC XML Schema</name>	<section anchor="xsd"><name>DMARC XML Schema</name>


	<sourcecode type="xsd"><?xml version="1.0"?>	<!--[rfced] In the XML schema in Appendix A, we updated "[@?RFC7489]"
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"	to "RFC 7489" and "[@I-D.ietf-dmarc-dmarcbis]" to "RFC 9989". We
	targetNamespace="urn:ietf:params:xml:ns:dmarc-2.0"	also made a few punctuation updates for consistency. Please let
	xmlns="urn:ietf:params:xml:ns:dmarc-2.0"	us know of any objections.
	elementFormDefault="qualified">	-->


	<!-- Elements with an optional "lang" attribute. -->	<sourcecode type="xml"><![CDATA[
	<xs:complexType name="langAttrString">	<?xml version="1.0"?>
	<xs:simpleContent>	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	<xs:extension base="xs:string">	targetNamespace="urn:ietf:params:xml:ns:dmarc-2.0"
	<xs:attribute name="lang" type="xs:language"	xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
	use="optional" default="en"/>	elementFormDefault="qualified">
	</xs:extension>
	</xs:simpleContent>
	</xs:complexType>


	<!-- The time range in UTC defining the reporting period of	<!-- Elements with an optional "lang" attribute. -->
	this report, specified in seconds since epoch. -->	<xs:complexType name="langAttrString">
	<xs:complexType name="DateRangeType">	<xs:simpleContent>
	<xs:all>	<xs:extension base="xs:string">
	<xs:element name="begin" type="xs:integer"	<xs:attribute name="lang" type="xs:language"
	minOccurs="1" maxOccurs="1"/>	use="optional" default="en"/>
	<xs:element name="end" type="xs:integer"	</xs:extension>
	minOccurs="1" maxOccurs="1"/>	</xs:simpleContent>
	</xs:all>	</xs:complexType>
	</xs:complexType>


	<!-- Report generator metadata. -->	<!-- The time range in UTC defining the reporting period of
	<xs:complexType name="ReportMetadataType">	this report, specified in seconds since epoch. -->
	<xs:all>	<xs:complexType name="DateRangeType">
	<!-- Reporting Organization -->	<xs:all>
	<xs:element name="org_name" type="xs:string"	<xs:element name="begin" type="xs:integer"
	minOccurs="1" maxOccurs="1"/>	minOccurs="1" maxOccurs="1"/>
	<!-- Contact to use when contacting the Reporting Organization -->	<xs:element name="end" type="xs:integer"
	<xs:element name="email" type="xs:string"	minOccurs="1" maxOccurs="1"/>
	minOccurs="1" maxOccurs="1"/>	</xs:all>
	<!-- Additional contact details -->	</xs:complexType>
	<xs:element name="extra_contact_info" type="langAttrString&q
	uot;
	minOccurs="0" maxOccurs="1"/>
	<!-- Unique Report-ID -->
	<xs:element name="report_id" type="xs:string"
	minOccurs="1" maxOccurs="1"/>
	<!-- Timestamps used when forming report data -->
	<xs:element name="date_range" type="DateRangeType"
	minOccurs="1" maxOccurs="1"/>
	<!-- Optional error messages when processing DMARC policy -->
	<xs:element name="error" type="langAttrString"
	minOccurs="0" maxOccurs="1"/>
	<!-- Optional information about the generating software -->
	<xs:element name="generator" type="xs:string"
	minOccurs="0" maxOccurs="1"/>
	</xs:all>
	</xs:complexType>


	<!-- Alignment mode (relaxed or strict) for DKIM and SPF. -->	<!-- Report generator metadata. -->
	<xs:simpleType name="AlignmentType">	<xs:complexType name="ReportMetadataType">
	<xs:restriction base="xs:string">	<xs:all>
	<xs:enumeration value="r"/>	<!-- Reporting Organization -->
	<xs:enumeration value="s"/>	<xs:element name="org_name" type="xs:string"
	</xs:restriction>	minOccurs="1" maxOccurs="1"/>
	</xs:simpleType>	<!-- Contact to use when contacting the Reporting Organization -->
		<xs:element name="email" type="xs:string"
		minOccurs="1" maxOccurs="1"/>
		<!-- Additional contact details -->
		<xs:element name="extra_contact_info" type="langAttrString"
		minOccurs="0" maxOccurs="1"/>
		<!-- Unique Report-ID -->
		<xs:element name="report_id" type="xs:string"
		minOccurs="1" maxOccurs="1"/>
		<!-- Timestamps used when forming report data -->
		<xs:element name="date_range" type="DateRangeType"
		minOccurs="1" maxOccurs="1"/>
		<!-- Optional error messages when processing DMARC policy -->
		<xs:element name="error" type="langAttrString"
		minOccurs="0" maxOccurs="1"/>
		<!-- Optional information about the generating software -->
		<xs:element name="generator" type="xs:string"
		minOccurs="0" maxOccurs="1"/>
		</xs:all>
		</xs:complexType>


	<!-- The policy actions specified by p, sp and np in the	<!-- Alignment mode (relaxed or strict) for DKIM and SPF. -->
	DMARC Policy Record. -->	<xs:simpleType name="AlignmentType">
	<xs:simpleType name="DispositionType">	<xs:restriction base="xs:string">
	<xs:restriction base="xs:string">	<xs:enumeration value="r"/>
	<xs:enumeration value="none"/>	<xs:enumeration value="s"/>
	<xs:enumeration value="quarantine"/>	</xs:restriction>
	<xs:enumeration value="reject"/>	</xs:simpleType>
	</xs:restriction>
	</xs:simpleType>


	<!-- The policy actions utilized on messages for this record. -->	<!-- The policy actions specified by p, sp, and np in the
	<!--	DMARC Policy Record. -->
	"none": No action taken	<xs:simpleType name="DispositionType">
	"pass": No action, passing DMARC w/enforcing policy	<xs:restriction base="xs:string">
	"quarantine": Failed DMARC, message marked for quarantine	<xs:enumeration value="none"/>
	"reject": Failed DMARC, marked as reject	<xs:enumeration value="quarantine"/>
	<xs:simpleType name="ActionDispositionType">	<xs:enumeration value="reject"/>
	<xs:restriction base="xs:string">	</xs:restriction>
	<xs:enumeration value="none"/>	</xs:simpleType>
	<xs:enumeration value="pass"/>
	<xs:enumeration value="quarantine"/>
	<xs:enumeration value="reject"/>
	</xs:restriction>
	</xs:simpleType>


	<!-- The method used to discover the DMARC Policy Record used during	<!-- The policy actions utilized on messages for this record. -->
	evaluation. The available values are "psl" and "treewalk&qu	<!--
	ot;,	"none": No action taken
	where "psl" is the method from [@?RFC7489] and the "treewalk	"pass": No action, passing DMARC w/enforcing policy
	"	"quarantine": Failed DMARC, message marked for quarantine
	is described in [@I-D.ietf-dmarc-dmarcbis]. -->	"reject": Failed DMARC, marked as reject
	<xs:simpleType name="DiscoveryType">	-->
	<xs:restriction base="xs:string">	<xs:simpleType name="ActionDispositionType">
	<xs:enumeration value="psl"/>	<xs:restriction base="xs:string">
	<xs:enumeration value="treewalk"/>	<xs:enumeration value="none"/>
	</xs:restriction>	<xs:enumeration value="pass"/>
	</xs:simpleType>	<xs:enumeration value="quarantine"/>
		<xs:enumeration value="reject"/>
		</xs:restriction>
		</xs:simpleType>


	<!-- The published DMARC policy. Unspecified tags have their	<!-- The method used to discover the DMARC Policy Record used during
	default values. -->	evaluation. The available values are "psl" and "treewalk",
	<xs:complexType name="PolicyPublishedType">	where "psl" is the method from RFC 7489 and "treewalk" is
	<xs:all>	described in RFC 9989. -->
	<!-- The domain at which the DMARC record was found. -->	<xs:simpleType name="DiscoveryType">
	<xs:element name="domain" type="xs:string"	<xs:restriction base="xs:string">
	minOccurs="1" maxOccurs="1"/>	<xs:enumeration value="psl"/>
	<!-- The policy published for messages from: -->	<xs:enumeration value="treewalk"/>
	<!-- * the domain. -->	</xs:restriction>
	<xs:element name="p" type="DispositionType"	</xs:simpleType>
	minOccurs="1" maxOccurs="1"/>
	<!-- * subdomains. -->
	<xs:element name="sp" type="DispositionType"
	minOccurs="0" maxOccurs="1"/>
	<!-- * non-existent subdomains. -->
	<xs:element name="np" type="DispositionType"
	minOccurs="0" maxOccurs="1"/>
	<!-- The DKIM alignment mode. -->
	<xs:element name="adkim" type="AlignmentType"
	minOccurs="0" maxOccurs="1"/>
	<!-- The SPF alignment mode. -->
	<xs:element name="aspf" type="AlignmentType"
	minOccurs="0" maxOccurs="1"/>
	<!-- Method used to find/obtain DMARC policy -->
	<xs:element name="discovery_method" type="DiscoveryType&quot
	;
	minOccurs="0" maxOccurs="1"/>
	<!-- Failure reporting options in effect. -->
	<xs:element name="fo" type="xs:string"
	minOccurs="0" maxOccurs="1"/>
	<!-- Whether testing mode was declared in the DMARC Record -->
	<xs:element name="testing" type="TestingType"
	minOccurs="0" maxOccurs="1"/>
	</xs:all>
	</xs:complexType>


	<!-- Values for Testing mode attached to policy -->	<!-- The published DMARC policy. Unspecified tags have their
	<xs:simpleType name="TestingType">	default values. -->
	<xs:restriction base="xs:string">	<xs:complexType name="PolicyPublishedType">
	<xs:enumeration value="n"/>	<xs:all>
	<xs:enumeration value="y"/>	<!-- The domain at which the DMARC record was found. -->
	</xs:restriction>	<xs:element name="domain" type="xs:string"
	</xs:simpleType>	minOccurs="1" maxOccurs="1"/>
		<!-- The policy published for messages from: -->
		<!-- * the domain. -->
		<xs:element name="p" type="DispositionType"
		minOccurs="1" maxOccurs="1"/>
		<!-- * subdomains. -->
		<xs:element name="sp" type="DispositionType"
		minOccurs="0" maxOccurs="1"/>
		<!-- * non-existent subdomains. -->
		<xs:element name="np" type="DispositionType"
		minOccurs="0" maxOccurs="1"/>
		<!-- The DKIM alignment mode. -->
		<xs:element name="adkim" type="AlignmentType"
		minOccurs="0" maxOccurs="1"/>
		<!-- The SPF alignment mode. -->
		<xs:element name="aspf" type="AlignmentType"
		minOccurs="0" maxOccurs="1"/>
		<!-- Method used to find/obtain DMARC policy. -->
		<xs:element name="discovery_method" type="DiscoveryType"
		minOccurs="0" maxOccurs="1"/>
		<!-- Failure reporting options in effect. -->
		<xs:element name="fo" type="xs:string"
		minOccurs="0" maxOccurs="1"/>
		<!-- Whether testing mode was declared in the DMARC Record. -->
		<xs:element name="testing" type="TestingType"
		minOccurs="0" maxOccurs="1"/>
		</xs:all>
		</xs:complexType>


	<!-- The DMARC-aligned authentication result. -->	<!-- Values for Testing mode attached to policy. -->
	<xs:simpleType name="DMARCResultType">	<xs:simpleType name="TestingType">
	<xs:restriction base="xs:string">	<xs:restriction base="xs:string">
	<xs:enumeration value="pass"/>	<xs:enumeration value="n"/>
	<xs:enumeration value="fail"/>	<xs:enumeration value="y"/>
	</xs:restriction>	</xs:restriction>
	</xs:simpleType>	</xs:simpleType>


	<!-- Reasons that may affect DMARC disposition or execution. -->	<!-- The DMARC-aligned authentication result. -->
	<xs:simpleType name="PolicyOverrideType">	<xs:simpleType name="DMARCResultType">
	<xs:restriction base="xs:string">	<xs:restriction base="xs:string">
	<xs:enumeration value="local_policy"/>	<xs:enumeration value="pass"/>
	<xs:enumeration value="mailing_list"/>	<xs:enumeration value="fail"/>
	<xs:enumeration value="other"/>	</xs:restriction>
	<xs:enumeration value="policy_test_mode"/>	</xs:simpleType>
	<xs:enumeration value="trusted_forwarder"/>
	</xs:restriction>
	</xs:simpleType>


	<!-- Override reason consists of pre-defined override type and	<!-- Reasons that may affect DMARC disposition or execution. -->
	free-text comment. -->	<xs:simpleType name="PolicyOverrideType">
	<xs:complexType name="PolicyOverrideReason">	<xs:restriction base="xs:string">
	<xs:all>	<xs:enumeration value="local_policy"/>
	<xs:element name="type" type="PolicyOverrideType"	<xs:enumeration value="mailing_list"/>
	minOccurs="1" maxOccurs="1"/>	<xs:enumeration value="other"/>
	<xs:element name="comment" type="langAttrString"	<xs:enumeration value="policy_test_mode"/>
	minOccurs="0" maxOccurs="1"/>	<xs:enumeration value="trusted_forwarder"/>
	</xs:all>	</xs:restriction>
	</xs:complexType>	</xs:simpleType>


	<!-- Taking into account everything else in the record,	<!-- Override reason consists of pre-defined override type and
		free-text comment. -->
		<xs:complexType name="PolicyOverrideReason">
		<xs:all>
		<xs:element name="type" type="PolicyOverrideType"
		minOccurs="1" maxOccurs="1"/>
		<xs:element name="comment" type="langAttrString"
		minOccurs="0" maxOccurs="1"/>
		</xs:all>
		</xs:complexType>

		<!-- 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 -->	configured policy, the reason element MUST be specified. -->
	<xs:complexType name="PolicyEvaluatedType">	<xs:complexType name="PolicyEvaluatedType">
	<xs:sequence>	<xs:sequence>
	<xs:element name="disposition" type="ActionDispositionType&q	<xs:element name="disposition" type="ActionDispositionType"
	uot;	minOccurs="1" maxOccurs="1"/>
	minOccurs="1" maxOccurs="1"/>	<xs:element name="dkim" type="DMARCResultType"
	<xs:element name="dkim" type="DMARCResultType"	minOccurs="1" maxOccurs="1"/>
	minOccurs="1" maxOccurs="1"/>	<xs:element name="spf" type="DMARCResultType"
	<xs:element name="spf" type="DMARCResultType"	minOccurs="1" maxOccurs="1"/>
	minOccurs="1" maxOccurs="1"/>	<xs:element name="reason" type="PolicyOverrideReason"
	<xs:element name="reason" type="PolicyOverrideReason"	minOccurs="0" maxOccurs="unbounded"/>
	minOccurs="0" maxOccurs="unbounded"/>	</xs:sequence>
	</xs:sequence>	</xs:complexType>
	</xs:complexType>


	<xs:complexType name="RowType">	<xs:complexType name="RowType">
	<xs:all>	<xs:all>
	<!-- The connecting IP. IPv4address or IPv6address	<!-- The connecting IP. IPv4address or IPv6address
	as defined in RFC 3986 section 3.2.2 -->	as defined in RFC 3986, Section 3.2.2. -->
	<xs:element name="source_ip" type="xs:string"	<xs:element name="source_ip" type="xs:string"
	minOccurs="1" maxOccurs="1"/>	minOccurs="1" maxOccurs="1"/>
	<!-- The number of messages for which the	<!-- The number of messages for which the
	PolicyEvaluatedType was applied. -->	PolicyEvaluatedType was applied. -->
	<xs:element name="count" type="xs:integer"	<xs:element name="count" type="xs:integer"
	minOccurs="1" maxOccurs="1"/>	minOccurs="1" maxOccurs="1"/>
	<!-- The DMARC disposition applied to matching messages. -->	<!-- The DMARC disposition applied to matching messages. -->
	<xs:element name="policy_evaluated" type="PolicyEvaluatedTyp	<xs:element name="policy_evaluated" type="PolicyEvaluatedType"
	e"	minOccurs="1" maxOccurs="1"/>
	minOccurs="1" maxOccurs="1"/>	</xs:all>
	</xs:all>	</xs:complexType>
	</xs:complexType>


	<xs:complexType name="IdentifierType">	<xs:complexType name="IdentifierType">
	<xs:all>	<xs:all>
	<!-- The RFC5322.From domain. -->	<!-- The RFC5322.From domain. -->
	<xs:element name="header_from" type="xs:string"	<xs:element name="header_from" type="xs:string"
	minOccurs="1" maxOccurs="1"/>	minOccurs="1" maxOccurs="1"/>
	<!-- The RFC5321.MailFrom domain -->	<!-- The RFC5321.MailFrom domain. -->
	<xs:element name="envelope_from" type="xs:string"	<xs:element name="envelope_from" type="xs:string"
	minOccurs="0" maxOccurs="1"/>	minOccurs="0" maxOccurs="1"/>
	<!-- The envelope recipient domain. -->	<!-- The envelope recipient domain. -->
	<xs:element name="envelope_to" type="xs:string"	<xs:element name="envelope_to" type="xs:string"
	minOccurs="0" maxOccurs="1"/>	minOccurs="0" maxOccurs="1"/>
	</xs:all>	</xs:all>
	</xs:complexType>	</xs:complexType>


	<!-- DKIM verification result, see RFC 8601 Section 2.7.1. -->	<!-- DKIM verification result; see RFC 8601, Section 2.7.1. -->
	<xs:simpleType name="DKIMResultType">	<xs:simpleType name="DKIMResultType">
	<xs:restriction base="xs:string">	<xs:restriction base="xs:string">
	<xs:enumeration value="none"/>	<xs:enumeration value="none"/>
	<xs:enumeration value="pass"/>	<xs:enumeration value="pass"/>
	<xs:enumeration value="fail"/>	<xs:enumeration value="fail"/>
	<xs:enumeration value="policy"/>	<xs:enumeration value="policy"/>
	<xs:enumeration value="neutral"/>	<xs:enumeration value="neutral"/>
	<xs:enumeration value="temperror"/>	<xs:enumeration value="temperror"/>
	<xs:enumeration value="permerror"/>	<xs:enumeration value="permerror"/>
	</xs:restriction>	</xs:restriction>
	</xs:simpleType>	</xs:simpleType>


	<xs:complexType name="DKIMAuthResultType">	<xs:complexType name="DKIMAuthResultType">
	<xs:all>	<xs:all>
	<!-- The "d=" tag in the signature. -->	<!-- The "d=" tag in the signature. -->
	<xs:element name="domain" type="xs:string"	<xs:element name="domain" type="xs:string"
	minOccurs="1" maxOccurs="1"/>	minOccurs="1" maxOccurs="1"/>
	<!-- The "s=" tag in the signature. -->	<!-- The "s=" tag in the signature. -->
	<xs:element name="selector" type="xs:string"	<xs:element name="selector" type="xs:string"
	minOccurs="1" maxOccurs="1"/>	minOccurs="1" maxOccurs="1"/>
	<!-- The DKIM verification result. -->	<!-- The DKIM verification result. -->
	<xs:element name="result" type="DKIMResultType"	<xs:element name="result" type="DKIMResultType"
	minOccurs="1" maxOccurs="1"/>	minOccurs="1" maxOccurs="1"/>
	<!-- Any extra information (e.g., from Authentication-Results). -->	<!-- Any extra information (e.g., from Authentication-Results). -->
	<xs:element name="human_result" type="langAttrString"	<xs:element name="human_result" type="langAttrString"
	minOccurs="0" maxOccurs="1"/>	minOccurs="0" maxOccurs="1"/>
	</xs:all>	</xs:all>
	</xs:complexType>	</xs:complexType>


	<!-- SPF domain scope. -->	<!-- SPF domain scope. -->
	<xs:simpleType name="SPFDomainScope">	<xs:simpleType name="SPFDomainScope">
	<xs:restriction base="xs:string">	<xs:restriction base="xs:string">
	<xs:enumeration value="mfrom"/>	<xs:enumeration value="mfrom"/>
	</xs:restriction>	</xs:restriction>
	</xs:simpleType>	</xs:simpleType>


	<!-- SPF verification result, see RFC 8601 Section 2.7.2. -->	<!-- SPF verification result; see RFC 8601, Section 2.7.2. -->
	<xs:simpleType name="SPFResultType">	<xs:simpleType name="SPFResultType">
	<xs:restriction base="xs:string">	<xs:restriction base="xs:string">
	<xs:enumeration value="none"/>	<xs:enumeration value="none"/>
	<xs:enumeration value="pass"/>	<xs:enumeration value="pass"/>
	<xs:enumeration value="fail"/>	<xs:enumeration value="fail"/>
	<xs:enumeration value="softfail"/>	<xs:enumeration value="softfail"/>
	<xs:enumeration value="policy"/>	<xs:enumeration value="policy"/>
	<xs:enumeration value="neutral"/>	<xs:enumeration value="neutral"/>
	<xs:enumeration value="temperror"/>	<xs:enumeration value="temperror"/>
	<xs:enumeration value="permerror"/>	<xs:enumeration value="permerror"/>
	</xs:restriction>	</xs:restriction>
	</xs:simpleType>	</xs:simpleType>


	<xs:complexType name="SPFAuthResultType">	<xs:complexType name="SPFAuthResultType">
	<xs:all>	<xs:all>
	<!-- The checked domain. -->	<!-- The checked domain. -->
	<xs:element name="domain" type="xs:string"	<xs:element name="domain" type="xs:string"
	minOccurs="1" maxOccurs="1"/>	minOccurs="1" maxOccurs="1"/>
	<!-- The scope of the checked domain. -->	<!-- The scope of the checked domain. -->
	<xs:element name="scope" type="SPFDomainScope"	<xs:element name="scope" type="SPFDomainScope"
	minOccurs="0" maxOccurs="1"/>	minOccurs="0" maxOccurs="1"/>
	<!-- The SPF verification result. -->	<!-- The SPF verification result. -->
	<xs:element name="result" type="SPFResultType"	<xs:element name="result" type="SPFResultType"
	minOccurs="1" maxOccurs="1"/>	minOccurs="1" maxOccurs="1"/>
	<!-- Any extra information (e.g., from Authentication-Results).	<!-- 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. -->	DNS responses, etc. -->
	<xs:element name="human_result" type="langAttrString"	<xs:element name="human_result" type="langAttrString"
	minOccurs="0" maxOccurs="1"/>	minOccurs="0" maxOccurs="1"/>
	</xs:all>	</xs:all>
	</xs:complexType>	</xs:complexType>


	<!-- This element contains DKIM and SPF results, uninterpreted	<!-- This element contains DKIM and SPF results, uninterpreted
	with respect to DMARC. -->	with respect to DMARC. -->
	<xs:complexType name="AuthResultType">	<xs:complexType name="AuthResultType">
	<xs:sequence>	<xs:sequence>
	<!-- There may be zero or more DKIM signatures. -->	<!-- There may be zero or more DKIM signatures. -->
	<xs:element name="dkim" type="DKIMAuthResultType"	<xs:element name="dkim" type="DKIMAuthResultType"
	minOccurs="0" maxOccurs="unbounded"/>	minOccurs="0" maxOccurs="unbounded"/>
	<!-- There may be zero or one SPF result. -->	<!-- There may be zero or one SPF result. -->
	<xs:element name="spf" type="SPFAuthResultType"	<xs:element name="spf" type="SPFAuthResultType"
	minOccurs="0" maxOccurs="1"/>	minOccurs="0" maxOccurs="1"/>
	</xs:sequence>	</xs:sequence>
	</xs:complexType>	</xs:complexType>


	<!-- This element contains all the authentication results that	<!-- 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. -->	messages. -->
	<xs:complexType name="RecordType">	<xs:complexType name="RecordType">
	<xs:sequence>	<xs:sequence>
	<xs:element name="row" type="RowType"	<xs:element name="row" type="RowType"
	minOccurs="1" maxOccurs="1"/>	minOccurs="1" maxOccurs="1"/>
	<xs:element name="identifiers" type="IdentifierType"	<xs:element name="identifiers" type="IdentifierType"
	minOccurs="1" maxOccurs="1"/>	minOccurs="1" maxOccurs="1"/>
	<xs:element name="auth_results" type="AuthResultType"	<xs:element name="auth_results" type="AuthResultType"
	minOccurs="1" maxOccurs="1"/>	minOccurs="1" maxOccurs="1"/>
	<!-- Extension at record level -->	<!-- Extension at record level -->
	<xs:any processContents="lax"	<xs:any processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>	</xs:sequence>
	</xs:complexType>	</xs:complexType>


	<xs:complexType name="ExtensionType">	<xs:complexType name="ExtensionType">
	<xs:sequence>	<xs:sequence>
	<xs:any processContents="lax"	<xs:any processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>	</xs:sequence>
	</xs:complexType>	</xs:complexType>

		<!-- Parent -->
		<xs:element name="feedback">
		<xs:complexType>
		<xs:sequence>
		<xs:element name="version" type="xs:decimal"
		minOccurs="0" maxOccurs="1"/>
		<xs:element name="report_metadata" type="ReportMetadataType"
		minOccurs="1" maxOccurs="1"/>
		<xs:element name="policy_published" type="PolicyPublishedType"
		minOccurs="1" maxOccurs="1"/>
		<!-- Extension at top level -->
		<xs:element name="extension" type="ExtensionType"
		minOccurs="0" maxOccurs="1"/>
		<!-- One record per (IP, result, IDs Auths) tuples -->
		<xs:element name="record" type="RecordType"
		minOccurs="1" maxOccurs="unbounded"/>
		</xs:sequence>
		</xs:complexType>
		</xs:element>
		</xs:schema>]]></sourcecode>


	<!-- Parent -->
	<xs:element name="feedback">
	<xs:complexType>
	<xs:sequence>
	<xs:element name="version" type="xs:decimal"
	minOccurs="0" maxOccurs="1"/>
	<xs:element name="report_metadata" type="ReportMetadataType
	"
	minOccurs="1" maxOccurs="1"/>
	<xs:element name="policy_published" type="PolicyPublishedTy
	pe"
	minOccurs="1" maxOccurs="1"/>
	<!-- Extension at top level -->
	<xs:element name="extension" type="ExtensionType"
	minOccurs="0" maxOccurs="1"/>
	<!-- One record per (IP, result, IDs Auths) tuples -->
	<xs:element name="record" type="RecordType"
	minOccurs="1" maxOccurs="unbounded"/>
	</xs:sequence>
	</xs:complexType>
	</xs:element>
	</xs:schema>
	</sourcecode>
	</section>	</section>

	<section anchor="sample-report"><name>Sample Report</name>	<section anchor="sample-report"><name>Sample Report</name>


	<sourcecode type="xml"><feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0	<sourcecode type="xml"><![CDATA[
	">	<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
	<version>1.0</version>	<version>1.0</version>
	<report_metadata>	<report_metadata>
	<org_name>Sample Reporter</org_name>	<org_name>Sample Reporter</org_name>
	<email>report_sender@example-reporter.com</email>	<email>report_sender@example-reporter.com</email>
	<extra_contact_info>...</extra_contact_info>	<extra_contact_info>...</extra_contact_info>
	<report_id>3v98abbp8ya9n3va8yr8oa3ya</report_id>	<report_id>3v98abbp8ya9n3va8yr8oa3ya</report_id>
	<date_range>	<date_range>
	<begin>302832000</begin>	<begin>302832000</begin>
	<end>302918399</end>	<end>302918399</end>
	</date_range>	</date_range>
	<generator>Example DMARC Aggregate Reporter v1.2</generator>	<generator>Example DMARC Aggregate Reporter v1.2</generator>
	</report_metadata>	</report_metadata>
	<policy_published>	<policy_published>
	<domain>example.com</domain>	<domain>example.com</domain>
	<p>quarantine</p>	<p>quarantine</p>
	<sp>none</sp>	<sp>none</sp>
	<np>none</np>	<np>none</np>
	<testing>n</testing>	<testing>n</testing>
	<discovery_method>treewalk</discovery_method>	<discovery_method>treewalk</discovery_method>
	</policy_published>	</policy_published>
	<record>	<record>
	<row>	<row>
	<source_ip>192.0.2.123</source_ip>	<source_ip>192.0.2.123</source_ip>
	<count>123</count>	<count>123</count>
	<policy_evaluated>	<policy_evaluated>
	<disposition>pass</disposition>	<disposition>pass</disposition>
	<dkim>pass</dkim>	<dkim>pass</dkim>
	<spf>fail</spf>	<spf>fail</spf>
	</policy_evaluated>	</policy_evaluated>
	</row>	</row>
	<identifiers>	<identifiers>
	<envelope_from>example.com</envelope_from>	<envelope_from>example.com</envelope_from>
	<header_from>example.com</header_from>	<header_from>example.com</header_from>
	</identifiers>	</identifiers>
	<auth_results>	<auth_results>
	<dkim>	<dkim>
	<domain>example.com</domain>	<domain>example.com</domain>
	<result>pass</result>	<result>pass</result>
	<selector>abc123</selector>	<selector>abc123</selector>
	</dkim>	</dkim>
	<spf>	<spf>
	<domain>example.com</domain>	<domain>example.com</domain>
	<result>fail</result>	<result>fail</result>
	</spf>	</spf>
	</auth_results>	</auth_results>
	</record>	</record>
	</feedback>	</feedback>]]></sourcecode>
	</sourcecode>
	</section>	</section>


	<section anchor="differences-from-rfc7489"><name>Differences from RFC7489</name>	<section anchor="differences-from-rfc7489"><name>Differences from RFC 7489</name
	<t>A bulleted list of some of the more noticeable/important differences	>
	between DMARC <xref target="RFC7489"></xref> and this document:</t>	<t>Here is a bulleted list of some of the more noticeable/important differences
		between DMARC <xref target="RFC7489"/> and this document:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Many elements of the defining XSD have been clarified, which means the	<li>Many elements of the defining XSD have been 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>The report identifier has more structure</li>

	<li>Clarification about the number of domains to be addressed per report</li>	<li>Clarification provided about the number of domains to be addressed per repor t</li>
	<li>The addition of extensions as part of the report structure</li>	<li>The addition of extensions as part of the report structure</li>
	<li>PSD is now included as part of the specification</li>	<li>PSD is now included as part of the specification</li>
	<li>Selector is now required when reporting a DKIM signature</li>	<li>Selector is now required when reporting a DKIM signature</li>
	</ul>	</ul>
	<t>Furthermore, the original DMARC specification was contained within a single	<t>Furthermore, the original DMARC specification was contained within a single

	document, <xref target="RFC7489"></xref>. The original document has	document: <xref target="RFC7489"/>. The original document has
	been split into three documents, DMARCbis <xref target="I-D.ietf-dmarc-dmarcbis"	been split into three documents: <xref target="RFC9989"/>, this
	></xref>, this	document, and <xref target="RFC9991"/>. This allows these pieces to
	document, and DMARCbis Failure
	Reporting <xref target="I-D.ietf-dmarc-failure-reporting"></xref>. 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
	the content was created from the original <xref target="RFC7489"></xref>, and ha	<section numbered="false">
	s now been	<name>Acknowledgements</name>
	updated to be more clear and correct some outstanding issues. The IETF
	DMARC Working Group has spent much time working to finalize this effort,	<!--[rfced] FYI - We have alphabetized the names listed in the Acknowledgements
	and significant contributions were made by Seth Blank, Todd Herr, Steve Jones,	section. We believe that was the intent as only two were out of order. Let us
	Murray S. Kucherawy, Barry Leiba, John Levine, Scott Kitterman, Daniel Kvål,	know if you prefer the original order.
	Martijn van der Lee, Alessandro Veseley, and Matthäus Wander.</t>	-->

		<t>Many thanks are deserved to those that helped create this document. Much
		of the content was created from <xref target="RFC7489"/> and has
		now been updated to be more clear and correct some outstanding issues. The
		IETF DMARC Working Group has spent much time working to finalize this effort,
		and significant contributions were made by <contact fullname="Seth Blank"/>,
		<contact fullname="Todd Herr"/>, <contact fullname="Steve Jones"/>, <contact
		fullname="Scott Kitterman"/>, <contact fullname="Murray S. Kucherawy"/>, <contac
		t
		fullname="Daniel Kvål"/>, <contact fullname="Barry Leiba"/>, <contact
		fullname="John Levine"/>, <contact fullname="Martijn van der Lee"/>, <contact
		fullname="Alessandro Veseley"/>, and <contact fullname="Matthäus
		Wander"/>.</t>
	</section>	</section>

	</back>	</back>


		<!-- [rfced] FYI - We have added expansions for the following
		abbreviation per Section 3.6 of RFC 7322 ("RFC Style
		Guide"). Please review each expansion in the document carefully
		to ensure correctness.

		UUID = Universally Unique Identifier (UUID)
		-->

		<!-- [rfced] Please review the "Inclusive Language" portion of the online
		Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Updates of this nature typically
		result in more precise language, which is helpful for readers.

		Note that our script did not flag any words in particular, but this should
		still be reviewed as a best practice.
		-->

	</rfc>	</rfc>

End of changes. 221 change blocks.
	857 lines changed or deleted	1174 lines changed or added
This html diff was produced by rfcdiff 1.48.