Diff: rfc9989.original.xml

	rfc9989.original.xml	rfc9989.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-dmarcbis-41" submis
	sionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XI
	nclude" obsoletes="7489, 9091" indexInclude="true">


	<front>	<!DOCTYPE rfc [
	<title abbrev="DMARCbis">Domain-based Message Authentication, Reporting, and Con	<!ENTITY nbsp " ">
	formance (DMARC)</title><seriesInfo value="draft-ietf-dmarc-dmarcbis-41" stream=	<!ENTITY zwsp "">
	"IETF" status="standard" name="Internet-Draft"></seriesInfo>	<!ENTITY nbhy "‑">
	<author initials="T." surname="Herr (ed)" fullname="Todd M. Herr"><organization>	<!ENTITY wj "⁠">
	Valimail</organization><address><postal><street></street>	]>
	</postal><email>todd@someguyinva.com</email>
	</address></author><author initials="J." surname="Levine (ed)" fullname="John Le	<rfc version="3" ipr="trust200902" docName="draft-ietf-dmarc-dmarcbis-41" number
	vine"><organization>Standcore LLC</organization><address><postal><street></stree	="9989" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.
	t>	w3.org/2001/XInclude" obsoletes="7489, 9091" updates="" consensus="true" tocIncl
	</postal><email>standards@standcore.com</email>	ude="true" symRefs="true" sortRefs="true">
	</address></author><date/>
	<area>Application</area>	<front>
	<workgroup>DMARC</workgroup>	<!--[rfced] Note that we have updated the document title and the short
		title that appears in the running header in the PDF output as follows.

		Original (Document Title):
		Domain-based Message Authentication, Reporting,
		and Conformance (DMARC)

		Current:
		Domain-Based Message Authentication, Reporting,
		and Conformance (DMARC)

		...
		Original (Short title):
		DMARCbis

		Current:
		DMARC
		-->
		<title abbrev="DMARC">Domain-Based Message Authentication, Reporting, and Co
		nformance (DMARC)</title>
		<seriesInfo name="RFC" value="9989"/>
		<author initials="T." surname="Herr" fullname="Todd M. Herr" role="editor">
		<organization>Valimail</organization>
		<address>
		<email>todd@someguyinva.com</email>
		</address>
		</author>
		<author initials="J." surname="Levine" fullname="John Levine" role="editor">
		<organization>Standcore LLC</organization>
		<address>
		<email>standards@standcore.com</email>
		</address>
		</author>
		<date month="May" year="2026"/>
		<area>ART</area>
		<workgroup>dmarc</workgroup>

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

		<keyword>example</keyword>

	<abstract>	<abstract>
	<t>This document describes the Domain-based Message Authentication,	<t>This document describes the Domain-based Message Authentication,
	Reporting, and Conformance (DMARC) protocol.</t>	Reporting, and Conformance (DMARC) protocol.</t>
	<t>DMARC permits the owner of an email's Author Domain to enable validation of	<t>DMARC permits the owner of an email's Author Domain to enable validation of

	the domain's use, to indicate the Domain Owner's or Public Suffix Operator's	the domain's use to indicate the Domain Owner's or Public Suffix Operator's
	message handling preference regarding failed validation, and to request reports	message handling preference regarding failed validation and to request reports
	about the use of the domain name. Mail receiving organizations can use this	about the use of the domain name. Mail-receiving organizations can use this
	information when evaluating handling choices for incoming mail.</t>	information when evaluating handling choices for incoming mail.</t>
	<t>This document obsoletes RFCs 7489 and 9091.</t>	<t>This document obsoletes RFCs 7489 and 9091.</t>
	</abstract>	</abstract>

	</front>	</front>

	<middle>	<middle>

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

	<t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
	The source for this draft is maintained on GitHub at:
	<eref target="https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis">https:
	//github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis</eref></t>
	<t>Abusive email often includes unauthorized and deceptive use of a	<t>Abusive email often includes unauthorized and deceptive use of a

	domain name in the "From" header field defined in section 3.6.2 of <xr ef target="RFC5322"></xref>	domain name in the "From" header field defined in <xref target="RFC5322" section ="3.6.2"/>
	and referred to as RFC5322.From. The domain typically belongs to an organization	and referred to as RFC5322.From. The domain typically belongs to an organization

	expected to be known to - and presumably trusted by - the recipient. The Sender	expected to be known to -- and presumably trusted by -- the recipient. The Sende
	Policy Framework (SPF) <xref target="RFC7208"></xref> and DomainKeys Identified	r
	Mail (DKIM) <xref target="RFC6376"></xref>	Policy Framework (SPF) <xref target="RFC7208"/> and DomainKeys Identified Mail (
		DKIM) <xref target="RFC6376"/>
	protocols provide domain-level authentication but are not directly associated	protocols provide domain-level authentication but are not directly associated

	with the RFC5322.From domain, also known as the <eref target="#author-domain">Au thor Domain</eref>.	with the RFC5322.From domain, also known as the <xref target="author-domain">Aut hor Domain</xref>.
	DMARC leverages these two protocols, providing a method for Domain Owners to pub lish	DMARC leverages these two protocols, providing a method for Domain Owners to pub lish
	a DNS TXT record describing the email authentication policies for the Author Dom ain	a DNS TXT record describing the email authentication policies for the Author Dom ain
	and to request specific handling for messages using that domain that fail valida tion	and to request specific handling for messages using that domain that fail valida tion

	checks. These DNS records are called <eref target="#dmarc-policy-record">DMARC P	checks. These DNS records are called <xref target="dmarc-policy-record">DMARC Po
	olicy Records</eref>.</t>	licy Records</xref>.</t>
	<t>As with SPF and DKIM, DMARC validation results in a verdict of either "p	<t>As with SPF and DKIM, DMARC validation results in a verdict of either "pass"
	ass" or	or
	"fail". A DMARC result of "pass" requires not only an SPF or	"fail". A DMARC result of "pass" requires not only an SPF or DKIM pass verdict f
	DKIM pass verdict for	or
	the email message, but also and more importantly that the domain associated with	the email message but also and more importantly that the domain associated with
	the SPF or DKIM pass be "aligned" with the Author Domain in one of two	the SPF or DKIM pass be "aligned" with the Author Domain in one of two
	modes - "relaxed" or "strict". Domains are said to be in &qu	modes -- "relaxed" or "strict". Domains are said to be in "relaxed alignment"
	ot;relaxed alignment"	if they have the same <xref target="organizational-domain">Organizational Domain
	if they have the same <eref target="#organizational-domain">Organizational Domai	</xref>; a
	n</eref>; a
	domain's Organizational Domain is the domain at the top of the namespace	domain's Organizational Domain is the domain at the top of the namespace
	hierarchy for that domain while having the same administrative authority as	hierarchy for that domain while having the same administrative authority as

	that domain. On the other hand, domains are in "strict alignment" if a nd only	that domain. On the other hand, domains are in "strict alignment" if and only
	if they are identical. The choice of required alignment mode is left to the	if they are identical. The choice of required alignment mode is left to the

	<eref target="#domain-owner">Domain Owner</eref> that publishes a DMARC Policy R ecord.</t>	<xref target="domain-owner">Domain Owner</xref> that publishes a DMARC Policy Re cord.</t>
	<t>A DMARC pass for a message indicates only that the use of the Author Domain h as been	<t>A DMARC pass for a message indicates only that the use of the Author Domain h as been
	validated for that message as authorized by the Domain Owner. Such authorizatio n	validated for that message as authorized by the Domain Owner. Such authorizatio n
	does not carry an explicit or implicit value assertion about that message or abo ut	does not carry an explicit or implicit value assertion about that message or abo ut
	the Domain Owner, and so a DMARC pass by itself does not guarantee that delivery to	the Domain Owner, and so a DMARC pass by itself does not guarantee that delivery to

	the recipient's Inbox would be safe or desirable. For a mail-receiving organiza tion	the recipient's inbox would be safe or desirable. For a mail-receiving organiza tion
	participating in DMARC, a message that passes DMARC validation is part of a mess age	participating in DMARC, a message that passes DMARC validation is part of a mess age
	stream reliably associated with the Author Domain. Therefore, reputation assessm ent	stream reliably associated with the Author Domain. Therefore, reputation assessm ent
	of that stream by the mail-receiving organization can assume the use of that Aut hor	of that stream by the mail-receiving organization can assume the use of that Aut hor
	Domain is authorized by the Domain Owner.</t>	Domain is authorized by the Domain Owner.</t>
	<t>On the other hand, a message that fails this validation is not necessarily as sociated	<t>On the other hand, a message that fails this validation is not necessarily as sociated
	with the Author Domain and so should not affect the Author Domain's reputation. The phrase	with the Author Domain and so should not affect the Author Domain's reputation. The phrase

	"not necessarily associated" was purposely chosen here, as it is impor tatnt to understand	"not necessarily associated" was purposely chosen here, as it is important to un derstand
	that some messages making authorized use of the Author Domain can still fail DMA RC validation	that some messages making authorized use of the Author Domain can still fail DMA RC validation

	checks. <xref target="RFC7960"></xref> and <xref target="other-topics"></xref> of this document both discuss reasons	checks. <xref target="RFC7960"/> and <xref target="other-topics"/> of this docu ment both discuss reasons
	why such failures may happen. Because of this, a mail-receiving organization th at performs	why such failures may happen. Because of this, a mail-receiving organization th at performs
	DMARC validation can choose to honor the Domain Owner's requested message handli ng for validation	DMARC validation can choose to honor the Domain Owner's requested message handli ng for validation
	failures, but it is not required to do so. DMARC is commonly used as one input t o more complex	failures, but it is not required to do so. DMARC is commonly used as one input t o more complex
	filtering decisions, and so the mail-receiving organization might choose differe nt actions entirely.</t>	filtering decisions, and so the mail-receiving organization might choose differe nt actions entirely.</t>

	<t>DMARC, in the associated <xref target="I-D.ietf-dmarc-aggregate-reporting"></	<t>DMARC, in the associated documents <xref target="RFC9990"/> and <xref target=
	xref> and <xref target="I-D.ietf-dmarc-failure-reporting"></xref>	"RFC9991"/>,
	documents, also specifies a reporting framework. Using it, a mail-receiving	also specifies a reporting framework. Using it, a mail-receiving
	organization can generate regular reports about messages that use Author	organization can generate regular reports about messages that use Author
	Domains for which a DMARC Policy Record exists; those reports are sent to the	Domains for which a DMARC Policy Record exists; those reports are sent to the
	address(es) specified by the Domain Owner in the DMARC Policy Record. Domain Own ers	address(es) specified by the Domain Owner in the DMARC Policy Record. Domain Own ers
	can use these reports, especially the aggregate reports, not only to identify	can use these reports, especially the aggregate reports, not only to identify

	sources of mail attempting to fraudulently use their domain, but also (and perha ps	sources of mail attempting to fraudulently use their domain but also (and perhap s
	more importantly) to flag and fix gaps in their own authentication practices. H owever,	more importantly) to flag and fix gaps in their own authentication practices. H owever,
	as with honoring the Domain Owner's stated mail handling preference, a mail-rece iving	as with honoring the Domain Owner's stated mail handling preference, a mail-rece iving

	organization supporting DMARC is under no obligation to send requested reports, although	organization supporting DMARC is under no obligation to send requested reports; although,
	it is recommended that they do send aggregate reports.</t>	it is recommended that they do send aggregate reports.</t>
	<t>The use of DMARC creates some interoperability challenges that require due	<t>The use of DMARC creates some interoperability challenges that require due
	consideration before deployment, particularly with configurations that	consideration before deployment, particularly with configurations that

	can cause mail to be rejected. These are discussed in <xref target="other-topics "></xref>.</t>	can cause mail to be rejected. These are discussed in <xref target="other-topics "/>.</t>
	</section>	</section>

	<section anchor="requirements"><name>Requirements</name>	<section anchor="requirements"><name>Requirements</name>
	<t>The following sections describe topics that guide the specification of DMARC. </t>	<t>The following sections describe topics that guide the specification of DMARC. </t>

	<section anchor="high-level-goals"><name>High-Level Goals</name>	<section anchor="high-level-goals"><name>High-Level Goals</name>
	<t>DMARC has the following high-level goals:</t>	<t>DMARC has the following high-level goals:</t>

	<ul>	<ul>

	<li><t>Allow <eref target="#domain-owner">Domain Owners</eref> and <eref target= "#public-suffix-operator">Public Suffix Operators (PSOs)</eref> to validate thei r email authentication deployments.</t>	<li><t>Allow <xref target="domain-owner">Domain Owners</xref> and <xref target=" public-suffix-operator">Public Suffix Operators (PSOs)</xref> to validate their email authentication deployments.</t>
	</li>	</li>
	<li><t>Allow Domain Owners and PSOs to assert their desired message handling	<li><t>Allow Domain Owners and PSOs to assert their desired message handling
	for validation failures on messages purporting to have authorship	for validation failures on messages purporting to have authorship
	within the domain.</t>	within the domain.</t>
	</li>	</li>
	<li><t>Minimize implementation complexity for both senders and receivers.</t>	<li><t>Minimize implementation complexity for both senders and receivers.</t>
	</li>	</li>
	<li><t>Reduce the amount of successfully delivered spoofed emails.</t>	<li><t>Reduce the amount of successfully delivered spoofed emails.</t>
	</li>	</li>
	<li><t>Work at Internet scale.</t>	<li><t>Work at Internet scale.</t>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>

	<section anchor="anti-phishing"><name>Anti-Phishing</name>	<section anchor="anti-phishing"><name>Anti-Phishing</name>

	<t>DMARC is designed to prevent the unauthorized use of the <eref target="#autho	<t>DMARC is designed to prevent the unauthorized use of the <xref target="author
	r-domain">Author Domain</eref>	-domain">Author Domain</xref>
	of an email message, a technique known as "spoofing". Such unauthorize	of an email message, a technique known as "spoofing". Such unauthorized usage ca
	d usage can	n
	frequently be found in messages impersonating a domain belonging to a business e	frequently be found in messages impersonating a domain belonging to a business e
	ntity,	ntity, i.e.,
	messages that are meant to entice the recipient to provide sensitive information , such	messages that are meant to entice the recipient to provide sensitive information , such
	as usernames, passwords, and financial account information. These spoofed messag es are	as usernames, passwords, and financial account information. These spoofed messag es are

	commonly referred to as "phishing".</t>	commonly referred to as "phishing".</t>
	<t>DMARC can only be used to combat specific forms of exact-domain spoofing dire ctly. DMARC	<t>DMARC can only be used to combat specific forms of exact-domain spoofing dire ctly. DMARC
	does not attempt to solve all problems with spoofed or otherwise fraudulent emai ls. In	does not attempt to solve all problems with spoofed or otherwise fraudulent emai ls. In
	particular, it does not address the use of visually similar domain names or abus e of the	particular, it does not address the use of visually similar domain names or abus e of the

	RFC5322.From human-readable display-name, as defined in <xref target="RFC5322" s ectionFormat="of" section="3.4"></xref>.</t>	RFC5322.From human-readable display name, as defined in <xref target="RFC5322" s ectionFormat="of" section="3.4"/>.</t>
	</section>	</section>

	<section anchor="scalability"><name>Scalability</name>	<section anchor="scalability"><name>Scalability</name>
	<t>Scalability is a significant issue for systems that need to operate in	<t>Scalability is a significant issue for systems that need to operate in
	an environment as widely deployed as current SMTP email. For this reason,	an environment as widely deployed as current SMTP email. For this reason,
	DMARC seeks to avoid the need for third parties or pre-sending	DMARC seeks to avoid the need for third parties or pre-sending
	agreements between senders and receivers. This preserves the	agreements between senders and receivers. This preserves the
	positive aspects of the current email infrastructure.</t>	positive aspects of the current email infrastructure.</t>
	<t>Although DMARC does not introduce third-party senders (namely	<t>Although DMARC does not introduce third-party senders (namely
	external agents authorized to send on behalf of an operator) to the	external agents authorized to send on behalf of an operator) to the
	email-handling flow, it also does not preclude them. Such third	email-handling flow, it also does not preclude them. Such third
	parties are free to provide services in conjunction with DMARC.</t>	parties are free to provide services in conjunction with DMARC.</t>
	</section>	</section>

	<section anchor="out-of-scope"><name>Out of Scope</name>	<section anchor="out-of-scope"><name>Out of Scope</name>
	<t>Several topics and issues are specifically out of scope of this	<t>Several topics and issues are specifically out of scope of this
	work. These include the following:</t>	work. These include the following:</t>

	<ul>	<ul>
	<li><t>Different treatment of messages that are not authenticated (e.g.,	<li><t>Different treatment of messages that are not authenticated (e.g.,

	those that have no DKIM signature or those sent using an <eref target="#author-d	those that have no DKIM signature or those sent using an <xref target="author-do
	omain">Author	main">Author
	Domain</eref> for which no <eref target="#dmarc-policy-record">DMARC Policy Reco	Domain</xref> for which no <xref target="dmarc-policy-record">DMARC Policy Recor
	rd</eref>	d</xref>
	exists) versus those that fail validation;</t>	exists versus those that fail validation;</t>
	</li>	</li>

	<li><t>Evaluation of anything other than RFC5322.From header field;</t>	<li><t>Evaluation of anything other than the RFC5322.From header field;</t>
	</li>	</li>
	<li><t>Multiple reporting formats;</t>	<li><t>Multiple reporting formats;</t>
	</li>	</li>
	<li><t>Publishing policy other than via the DNS;</t>	<li><t>Publishing policy other than via the DNS;</t>
	</li>	</li>
	<li><t>Reporting or otherwise evaluating other than the last-hop IP	<li><t>Reporting or otherwise evaluating other than the last-hop IP
	address;</t>	address;</t>
	</li>	</li>

	<li><t>Attacks in the display-name portions of the RFC5322.From header field,	<li><t>Attacks in the display name portions of the RFC5322.From header field,
	also known as "display name" attacks;</t>	also known as "display name" attacks;</t>
	</li>	</li>
	<li><t>Authentication of entities other than domains, since DMARC is	<li><t>Authentication of entities other than domains, since DMARC is
	built upon SPF and DKIM, which authenticate domains; and</t>	built upon SPF and DKIM, which authenticate domains; and</t>
	</li>	</li>
	<li><t>Content analysis.</t>	<li><t>Content analysis.</t>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>
	</section>	</section>

	<section anchor="terminology"><name>Terminology and Definitions</name>	<section anchor="terminology"><name>Terminology and Definitions</name>
	<t>This section defines terms used in the rest of the document.</t>	<t>This section defines terms used in the rest of the document.</t>

	<section anchor="conventions-used-in-this-document"><name>Conventions Used in Th is Document</name>	<section anchor="conventions-used-in-this-document"><name>Conventions Used in Th is Document</name>

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

	<t>Readers are encouraged to be familiar with the contents of	<t>Readers are encouraged to be familiar with the contents of

	<xref target="RFC5598"></xref>. In particular, that document	<xref target="RFC5598"/>. In particular, that document
	defines various roles in the messaging infrastructure that can appear the same	defines various roles in the messaging infrastructure that can appear the same

	or separate in various contexts. For example, a <eref target="#domain-owner">Dom ain Owner</eref> could,	or separate in various contexts. For example, a <xref target="domain-owner">Doma in Owner</xref> could,
	via the messaging security mechanisms on which DMARC is based, delegate the	via the messaging security mechanisms on which DMARC is based, delegate the
	ability to send mail as the Domain Owner to a third party with	ability to send mail as the Domain Owner to a third party with
	another role. This document does not address the distinctions among	another role. This document does not address the distinctions among
	such roles; the reader is encouraged to become familiar with that	such roles; the reader is encouraged to become familiar with that
	material before continuing.</t>	material before continuing.</t>
	</section>	</section>

	<section anchor="definitions"><name>Definitions</name>	<section anchor="definitions"><name>Definitions</name>
	<t>The following sections define the terms used in this document.</t>	<t>The following sections define the terms used in this document.</t>

	<section anchor="authenticated-identifiers"><name>Authenticated Identifiers</nam e>	<section anchor="authenticated-identifiers"><name>Authenticated Identifiers</nam e>
	<t>Authenticated Identifiers are those domain-level identifiers for which author ized	<t>Authenticated Identifiers are those domain-level identifiers for which author ized

	use is validated using a supported <eref target="#authentication-mechanisms">aut hentication mechanism</eref>.</t>	use is validated using a supported <xref target="authentication-mechanisms">auth entication mechanism</xref>.</t>
	</section>	</section>

	<section anchor="author-domain"><name>Author Domain</name>	<section anchor="author-domain"><name>Author Domain</name>

	<t>The domain name of the apparent author as extracted from the RFC5322.From hea der field.</t>	<t>The Author Domain is the domain name of the apparent author as extracted from the RFC5322.From header field.</t>
	</section>	</section>

	<section anchor="dkim-signing-domain"><name>DKIM Signing Domain</name>	<section anchor="dkim-signing-domain"><name>DKIM Signing Domain</name>

	<t>The domain name that is the value of the "d" tag in a validated DKI M-Signature header	<t>The DKIM Signing Domain is the domain name that is the value of the "d" tag i n a validated DKIM-Signature header
	field in an email message.</t>	field in an email message.</t>
	</section>	</section>

	<section anchor="spf-domain"><name>SPF Domain</name>	<section anchor="spf-domain"><name>SPF Domain</name>

	<t>SPF, <xref target="RFC7208"></xref>, can validate the uses of both the domain found in an SMTP <xref target="RFC5321"></xref>	<t>SPF <xref target="RFC7208"/> can validate the uses of both the domain found i n an SMTP <xref target="RFC5321"/>
	HELO/EHLO command (the HELO identity) and the domain found in an SMTP MAIL comma nd (the	HELO/EHLO command (the HELO identity) and the domain found in an SMTP MAIL comma nd (the
	MAIL FROM identity). DMARC relies solely on SPF validation of the MAIL FROM ide ntity.	MAIL FROM identity). DMARC relies solely on SPF validation of the MAIL FROM ide ntity.

	Section 2.4 of <xref target="RFC7208"></xref> describes the determination of the MAIL FROM identity for	<xref section="2.4" target="RFC7208"/> describes the determination of the MAIL F ROM identity for
	cases in which the SMTP MAIL command has a null path, i.e., the mailbox composed of	cases in which the SMTP MAIL command has a null path, i.e., the mailbox composed of

	the local-part "postmaster" and the HELO identity.</t>	the local-part "postmaster" and the HELO identity.</t>
	<t>The term "SPF Domain" when used in this document refers to an SPF v	<t>The term "SPF Domain" when used in this document refers to an SPF-validated M
	alidated MAIL FROM	AIL FROM
	identity.</t>	identity.</t>
	</section>	</section>

	<section anchor="dmarc-policy-domain"><name>DMARC Policy Domain</name>	<section anchor="dmarc-policy-domain"><name>DMARC Policy Domain</name>

	<t>The domain name at which an applicable <eref target="#dmarc-policy-record">DM	<t>The DMARC Policy Domain is the domain name at which an applicable <xref targe
	ARC Policy Record</eref> is discovered	t="dmarc-policy-record">DMARC Policy Record</xref> is discovered
	for the <eref target="#author-domain">Author Domain</eref> of an email message.<	for the <xref target="author-domain">Author Domain</xref> of an email message.</
	/t>	t>
	</section>	</section>

	<section anchor="dmarc-policy-record"><name>DMARC Policy Record</name>	<section anchor="dmarc-policy-record"><name>DMARC Policy Record</name>

	<t>A DNS TXT record published by a <eref target="#domain-owner">Domain Owner</er	<t>A DMARC Policy Record is a DNS TXT record published by a <xref target="domain
	ef> or <eref target="#public-suffix-operator">Public Suffix	-owner">Domain Owner</xref> or <xref target="public-suffix-operator">Public Suff
	Operator (PSO)</eref> to enable validation of an <eref target="#author-domain">A	ix
	uthor	Operator (PSO)</xref> to enable validation of an <xref target="author-domain">Au
	Domain's</eref> use, to indicate the Domain Owner's or PSO's message	thor
		Domain's</xref> use, to indicate the Domain Owner's or PSO's message
	handling preference regarding failed validation, and optionally to request repor ts	handling preference regarding failed validation, and optionally to request repor ts
	about the use of the Author Domain.</t>	about the use of the Author Domain.</t>
	</section>	</section>

	<section anchor="domain-owner"><name>Domain Owner</name>	<section anchor="domain-owner"><name>Domain Owner</name>

	<t>An entity or organization that has control of a given DNS domain,	<t>A Domain Owner is an entity or organization that has control of a given DNS d omain,
	usually by holding its registration. Domain Owners range from complex,	usually by holding its registration. Domain Owners range from complex,
	globally distributed organizations to service providers working on	globally distributed organizations to service providers working on
	behalf of non-technical clients to individuals responsible for maintaining	behalf of non-technical clients to individuals responsible for maintaining
	personal domains. This specification uses this term as analogous to an	personal domains. This specification uses this term as analogous to an

	Administrative Management Domain as defined in <xref target="RFC5598"></xref>. I	Administrative Management Domain (ADMD), as defined in <xref target="RFC5598"/>.
	t can also	It can also
	refer to delegates, such as Report Consumers when those are outside of	refer to delegates, such as Report Consumers, when those are outside of
	their immediate management domain.</t>	their immediate management domain.</t>
	</section>	</section>

	<section anchor="domain-owner-policy"><name>Domain Owner Assessment Policy</name >	<section anchor="domain-owner-policy"><name>Domain Owner Assessment Policy</name >

	<t>The message handling preference expressed in a <eref target="#dmarc-policy-re	<t>The Domain Owner Assessment Policy is the message handling preference express
	cord">DMARC Policy Record</eref>	ed in a <xref target="dmarc-policy-record">DMARC Policy Record</xref>
	by the <eref target="#domain-owner">Domain Owner</eref> regarding failed validat	by the <xref target="domain-owner">Domain Owner</xref> regarding failed validati
	ion of the <eref target="#author-domain">Author Domain</eref> is called the &quo	on of the <xref target="author-domain">Author Domain</xref>. Possible values are
	t;Domain Owner Assessment Policy". Possible values are described in	described in
	<xref target="policy-record-format"></xref>.</t>	<xref target="policy-record-format"/>.</t>
	</section>	</section>

	<section anchor="enforcement"><name>Enforcement</name>	<section anchor="enforcement"><name>Enforcement</name>

	<t>Enforcement describes a state where the existing <eref target="#domain-owner-	<t>Enforcement describes a state where the existing <xref target="domain-owner-p
	policy">Domain Owner Assessment Policy</eref>	olicy">Domain Owner Assessment Policy</xref>
	for an <eref target="#organizational-domain">Organizational Domain</eref> and al	for an <xref target="organizational-domain">Organizational Domain</xref> and all
	l subdomains below it	subdomains below it
	is not "p=none". This state means that the Organizational Domain and i	is not "p=none". This state means that the Organizational Domain and its subdoma
	ts subdomains	ins
	can only be used as <eref target="#author-domain">Author Domains</eref> if they	can only be used as <xref target="author-domain">Author Domains</xref> if they a
	are properly validated	re properly validated
	using the DMARC mechanism.</t>	using the DMARC mechanism.</t>

	<t>Historically, Domain Owner Assessment Policies of "p=quarantine" or	<t>Historically, Domain Owner Assessment Policies of "p=quarantine" or "p=reject
	"p=reject"	"
	have been higher value signals to <eref target="#mail-receiver">Mail Receivers</	have been higher value signals to <xref target="mail-receiver">Mail Receivers</x
	eref>. Messages with Author	ref>. Messages with Author
	Domains for which such policies exist that are not validated using the DMARC mec hanism	Domains for which such policies exist that are not validated using the DMARC mec hanism
	will not reach the inbox at Mail Receivers that participate in DMARC and honor t he	will not reach the inbox at Mail Receivers that participate in DMARC and honor t he
	Domain Owner's expressed handling preference.</t>	Domain Owner's expressed handling preference.</t>
	</section>	</section>

	<section anchor="identifier-alignment"><name>Identifier Alignment</name>	<section anchor="identifier-alignment"><name>Identifier Alignment</name>

	<t>DMARC describes the concept of alignment between the <eref target="#author-do	<t>DMARC describes the concept of alignment between the <xref target="author-dom
	main">Author Domain</eref>	ain">Author Domain</xref>
	and an <eref target="#authenticated-identifiers">Authenticated Identifier</eref>	and an <xref target="authenticated-identifiers">Authenticated Identifier</xref>
	, and requires	and requires
	such Identifier Alignment between the two for a message to achieve a DMARC pass. DMARC	such Identifier Alignment between the two for a message to achieve a DMARC pass. DMARC
	defines two states for alignment.</t>	defines two states for alignment.</t>

	<section anchor="relaxed-alignment"><name>Relaxed Alignment</name>	<section anchor="relaxed-alignment"><name>Relaxed Alignment</name>

	<t>When the <eref target="#author-domain">Author Domain</eref> has the same <ere	<t>When the <xref target="author-domain">Author Domain</xref> has the same <xref
	f target="#organizational-domain">Organizational Domain</eref>	target="organizational-domain">Organizational Domain</xref>
	as an <eref target="#authenticated-identifier">Authenticated Identifier</eref>,	as an <xref target="authenticated-identifiers">Authenticated Identifier</xref>,
	the two are said to be	the two are said to be
	in relaxed alignment.</t>	in relaxed alignment.</t>
	</section>	</section>

	<section anchor="strict-alignment"><name>Strict Alignment</name>	<section anchor="strict-alignment"><name>Strict Alignment</name>

	<t>When the <eref target="#author-domain">Author Domain</eref> is identical to a n <eref target="#authenticated-identifier">Authenticated Identifier</eref>, the two are said to be in strict alignment.</t>	<t>When the <xref target="author-domain">Author Domain</xref> is identical to an <xref target="authenticated-identifiers">Authenticated Identifier</xref>, the t wo are said to be in strict alignment.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="mail-receiver"><name>Mail Receiver</name>	<section anchor="mail-receiver"><name>Mail Receiver</name>

	<t>The entity or organization that receives and processes email. Mail	<t>The Mail Receiver is the entity or organization that receives and processes e mail. Mail
	Receivers operate one or more Internet-facing Message Transfer Agents (MTAs).</t >	Receivers operate one or more Internet-facing Message Transfer Agents (MTAs).</t >
	</section>	</section>

	<section anchor="monitoring-mode"><name>Monitoring Mode</name>	<section anchor="monitoring-mode"><name>Monitoring Mode</name>

	<t>Monitoring Mode describes a state where the existing <eref target="#domain-ow	<t>Monitoring Mode describes a state where the existing <xref target="domain-own
	ner-policy">Domain Owner Assessment Policy</eref> for an	er-policy">Domain Owner Assessment Policy</xref> for an
	<eref target="#organizational-domain">Organizational Domain</eref> and all subdo	<xref target="organizational-domain">Organizational Domain</xref> and all subdom
	mains below it	ains below it
	is "p=none", and the <eref target="#domain-owner">Domain Owner</eref>	is "p=none", and the <xref target="domain-owner">Domain Owner</xref> is receivin
	is receiving aggregate reports	g aggregate reports
	for the Organizational Domain. While the use of the Organizational Domain and a ll	for the Organizational Domain. While the use of the Organizational Domain and a ll

	its subdomains as <eref target="#author-domain">Author Domains</eref> can still	its subdomains as <xref target="author-domain">Author Domains</xref> can still b
	be validated by a <eref target="#mail-receiver">Mail Receiver</eref> deploying t	e validated by a <xref target="mail-receiver">Mail Receiver</xref> deploying the
	he DMARC mechanism, the Domain Owner expresses no handling	DMARC mechanism, the Domain Owner expresses no handling
	preference for messages that fail DMARC validation. The Domain Owner is, howeve	preference for messages that fail DMARC validation. However, the Domain Owner i
	r, using	s using
	the content of the DMARC aggregate reports to make any needed adjustments to	the content of the DMARC aggregate reports to make any needed adjustments to
	the authentication practices for its mail streams.</t>	the authentication practices for its mail streams.</t>
	</section>	</section>


	<section anchor="non-existent-domains"><name>Non-existent Domains</name>	<section anchor="non-existent-domains"><name>Non-Existent Domains</name>
	<t>For DMARC purposes, a non-existent domain is consistent with the term's meani ng	<t>For DMARC purposes, a non-existent domain is consistent with the term's meani ng

	as described in <xref target="RFC8020"></xref>. That is, if the response code re ceived for a query	as described in <xref target="RFC8020"/>. That is, if the response code received for a query
	for a domain name is NXDOMAIN, then the domain name and any possible subdomains	for a domain name is NXDOMAIN, then the domain name and any possible subdomains
	do not exist.</t>	do not exist.</t>
	</section>	</section>

	<section anchor="organizational-domain"><name>Organizational Domain</name>	<section anchor="organizational-domain"><name>Organizational Domain</name>
	<t>The Organizational Domain for any domain is akin to the ADMD described in	<t>The Organizational Domain for any domain is akin to the ADMD described in

	<xref target="RFC5598"></xref>. A domain's Organizational Domain is the domain a t the top of	<xref target="RFC5598"/>. A domain's Organizational Domain is the domain at the top of
	the namespace hierarchy for that domain while having the same administrative	the namespace hierarchy for that domain while having the same administrative
	authority as the domain. An Organizational Domain is determined by applying	authority as the domain. An Organizational Domain is determined by applying

	the algorithm found in <xref target="dns-tree-walk"></xref>.</t>	the algorithm found in <xref target="dns-tree-walk"/>.</t>
	</section>	</section>

	<section anchor="public-suffix-domain"><name>Public Suffix Domain (PSD)</name>	<section anchor="public-suffix-domain"><name>Public Suffix Domain (PSD)</name>
	<t>Some domains allow the registration of subdomains that are	<t>Some domains allow the registration of subdomains that are

	"owned" by independent organizations. Real-world examples of	"owned" by independent organizations. Real-world examples of
	these domains are ".com", ".org", ".us", and &quot	these domains are ".com", ".org", ".us", and ".co.uk", to name just a few.
	;.co.uk", to name just a few.	These domains are called "Public Suffix Domains" (PSDs).
	These domains are called "Public Suffix Domains" (PSDs).	For example, "ietf.org" is a registered domain name, and ".org" is its PSD.</t>
	For example, "ietf.org" is a registered domain name, and ".org&qu
	ot; is its PSD.</t>
	</section>	</section>

	<section anchor="public-suffix-operator"><name>Public Suffix Operator (PSO)</nam e>	<section anchor="public-suffix-operator"><name>Public Suffix Operator (PSO)</nam e>
	<t>A Public Suffix Operator is an organization that manages operations	<t>A Public Suffix Operator is an organization that manages operations
	within a PSD, particularly the DNS records published for names at and	within a PSD, particularly the DNS records published for names at and
	under that domain name.</t>	under that domain name.</t>
	</section>	</section>


	<section anchor="pso-controlled-domain-names"><name>PSO Controlled Domain Names< /name>	<section anchor="pso-controlled-domain-names"><name>PSO-Controlled Domain Names< /name>
	<t>PSO-Controlled Domain Names are names in the DNS that are managed by	<t>PSO-Controlled Domain Names are names in the DNS that are managed by

	a PSO. PSO-controlled Domain Names may have one label (e.g., ".com") o	a PSO. PSO-Controlled Domain Names may have one label (e.g., ".com") or more
	r more	(e.g., ".co.uk"), depending on the PSD's policy.</t>
	(e.g., ".co.uk"), depending on the PSD's policy.</t>
	</section>	</section>

	<section anchor="report-consumer"><name>Report Consumer</name>	<section anchor="report-consumer"><name>Report Consumer</name>
	<t>A Report Consumer is an operator that receives reports from another operator	<t>A Report Consumer is an operator that receives reports from another operator

	implementing the reporting mechanisms described in the documents	implementing the reporting mechanisms described in
	<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref> and <xref target="I-D.	<xref target="RFC9990"/> and <xref target="RFC9991"/>.
	ietf-dmarc-failure-reporting"></xref>.
	This term applies collectively to the system components that receive and process	This term applies collectively to the system components that receive and process
	these reports and the organizations that operate those components.</t>	these reports and the organizations that operate those components.</t>


		<!--[rfced] To clarify "designated third parties to so act", may we update
		the text as follows?

		Original:
		The DMARC mechanism permits a Domain
		Owner to act as a Report Consumer for its domain(s) and/or to
		designate third parties to so act.

		Perhaps:
		The DMARC mechanism permits a Domain
		Owner to act as a Report Consumer for its domain(s) and/or to
		designate a third party to act as a Report Consumer.
		-->

	<t>Report Consumers can receive reports concerning domains for which the Report	<t>Report Consumers can receive reports concerning domains for which the Report

	Consumer is also the <eref target="#domain-owner">Domain Owner</eref> or <eref t arget="#public-suffix-operator">PSO</eref>,	Consumer is also the <xref target="domain-owner">Domain Owner</xref> or <xref ta rget="public-suffix-operator">PSO</xref>
	or concerning domains that belong to another operator entirely. The DMARC mechan ism	or concerning domains that belong to another operator entirely. The DMARC mechan ism
	permits a Domain Owner to act as a Report Consumer for its domain(s) and/or to	permits a Domain Owner to act as a Report Consumer for its domain(s) and/or to

	designate third parties to so act. See <xref target="external-report-addresses"> </xref> for further	designate third parties to so act. See <xref target="external-report-addresses"/ > for further
	discussion of such designation.</t>	discussion of such designation.</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="overview-and-key-concepts"><name>Overview and Key Concepts</nam e>	<section anchor="overview-and-key-concepts"><name>Overview and Key Concepts</nam e>
	<t>This section provides a general overview of the design and operation	<t>This section provides a general overview of the design and operation
	of the DMARC environment.</t>	of the DMARC environment.</t>

	<section anchor="dmarc-basics"><name>DMARC Basics</name>	<section anchor="dmarc-basics"><name>DMARC Basics</name>

	<t>DMARC permits a <eref target="#domain-owner">Domain Owner</eref> or <eref tar	<t>DMARC permits a <xref target="domain-owner">Domain Owner</xref> or <xref targ
	get="#public-suffix-operator">PSO</eref> to enable	et="public-suffix-operator">PSO</xref> to enable
	validation of an <eref target="#author-domain">Author Domain's</eref> use in an	validation of an <xref target="author-domain">Author Domain's</xref> use in an e
	email message, to indicate	mail message, to indicate
	the Domain Owner's or PSO's message handling preference regarding failed validat ion, and	the Domain Owner's or PSO's message handling preference regarding failed validat ion, and

	to request reports about use of the Author Domain. A domain's <eref target="#dma	to request reports about use of the Author Domain. A domain's <xref target="dmar
	rc-policy-record">DMARC Policy Record</eref> is published in the DNS as a TXT re	c-policy-record">DMARC Policy Record</xref> is published in the DNS as a TXT rec
	cord at the name created by prepending	ord at the name created by prepending
	the label "_dmarc" to the domain name and is retrieved through normal	the label "_dmarc" to the domain name and is retrieved through normal DNS querie
	DNS queries.</t>	s.</t>
	<t>DMARC's validation mechanism produces a "pass" result if a DMARC Po	<t>DMARC's validation mechanism produces a "pass" result if a DMARC Policy Recor
	licy Record exists for	d exists for
	the Author Domain of an email message and the Author Domain is <eref target="#id	the Author Domain of an email message and the Author Domain is <xref target="ide
	entifier-alignment">aligned</eref>	ntifier-alignment">aligned</xref>
	with an <eref target="#authenticated-identifiers">Authenticated Identifier</eref	with an <xref target="authenticated-identifiers">Authenticated Identifier</xref>
	> from that message.	from that message.
	When a DMARC Policy Record exists for the Author Domain and the DMARC mechanism does not	When a DMARC Policy Record exists for the Author Domain and the DMARC mechanism does not

	produce a "pass" result, the <eref target="#mail-receiver">Mail Receiv	produce a "pass" result, the <xref target="mail-receiver">Mail Receiver's</xref>
	er's</eref> handling of that message	handling of that message
	can be influenced by the <eref target="#domain-owner-policy">Domain Owner Assess	can be influenced by the <xref target="domain-owner-policy">Domain Owner Assessm
	ment Policy</eref> expressed	ent Policy</xref> expressed
	in the DMARC Policy Record.</t>	in the DMARC Policy Record.</t>
	<t>It is important to note that the authentication mechanisms employed	<t>It is important to note that the authentication mechanisms employed
	by DMARC only validate the usage of a DNS domain in an email message.	by DMARC only validate the usage of a DNS domain in an email message.
	They do not validate the local-part of any email address identifier	They do not validate the local-part of any email address identifier
	found in that message, nor do such validations carry an explicit or	found in that message, nor do such validations carry an explicit or
	implicit value assertion about that message or about the Domain Owner.</t>	implicit value assertion about that message or about the Domain Owner.</t>
	<t>DMARC's reporting component involves the collection of information	<t>DMARC's reporting component involves the collection of information
	about received messages using the Author Domain for periodic aggregate reports	about received messages using the Author Domain for periodic aggregate reports
	to the Domain Owner or PSO. The parameters and format for such reports are	to the Domain Owner or PSO. The parameters and format for such reports are

	discussed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>	discussed in <xref target="RFC9990"/>.</t>
	<t>A Mail Receiver participating in DMARC might also generate per-message failur e	<t>A Mail Receiver participating in DMARC might also generate per-message failur e
	reports that contain information related to individual messages that fail DMARC	reports that contain information related to individual messages that fail DMARC

	validation checks. Per-message failure reports are a useful source of	validation checks. Per-message failure reports are useful sources of
	information when debugging deployments (if messages can be determined	information when debugging deployments (if messages can be determined

	to be legitimate even though failing validation) or in analyzing	to be legitimate despite failing validation) or in analyzing
	attacks. The capability for such services is enabled by DMARC but	attacks. The capability for such services is enabled by DMARC but
	defined in other referenced material such as	defined in other referenced material such as

	<xref target="RFC6591"></xref> and <xref target="I-D.ietf-dmarc-failure-reportin g"></xref></t>	<xref target="RFC6591"/> and <xref target="RFC9991"/>.</t>
	</section>	</section>

	<section anchor="use-of-rfc5322-from"><name>Use of RFC5322.From</name>	<section anchor="use-of-rfc5322-from"><name>Use of RFC5322.From</name>
	<t>One of the most obvious points of security scrutiny for DMARC is the	<t>One of the most obvious points of security scrutiny for DMARC is the
	choice to focus on an identifier, namely the RFC5322.From address,	choice to focus on an identifier, namely the RFC5322.From address,
	which is part of a body of data that has been trivially forged	which is part of a body of data that has been trivially forged
	throughout the history of email. This field is the one used by end	throughout the history of email. This field is the one used by end
	users to identify the source of the message, and so it has always	users to identify the source of the message, and so it has always
	been a prime target for abuse through such forgery and other means.	been a prime target for abuse through such forgery and other means.
	That said, of all the identifiers that are part of the message itself,	That said, of all the identifiers that are part of the message itself,
	this is the only one required to be present. A message without a single,	this is the only one required to be present. A message without a single,
	properly formed RFC5322.From header field does not comply with	properly formed RFC5322.From header field does not comply with

	<xref target="RFC5322"></xref>, and handling such a message is outside of the sc ope of this specification.</t>	<xref target="RFC5322"/>, and handling such a message is outside of the scope of this specification.</t>
	</section>	</section>

	<section anchor="authentication-mechanisms"><name>Authentication Mechanisms</nam e>	<section anchor="authentication-mechanisms"><name>Authentication Mechanisms</nam e>

	<t>The following mechanisms for determining <eref target="#authenticated-identif iers">Authenticated Identifiers</eref> are supported in this version of DMARC:</ t>	<t>The following mechanisms for determining <xref target="authenticated-identifi ers">Authenticated Identifiers</xref> are supported in this version of DMARC:</t >

	<ul>	<ul>

	<li><t>DKIM, <xref target="RFC6376"></xref>. The <eref target="#dkim-signing-dom	<li>DKIM <xref target="RFC6376"/>: The <xref target="dkim-signing-domain">DKIM
	ain">DKIM Signing Domain</eref>	Signing Domain</xref>
	from a validated DKIM-Signature header field is an Authenticated Identifier.</t>	from a validated DKIM-Signature header field is an Authenticated Identifier.</li
	</li>	>
	<li><t>SPF, <xref target="RFC7208"></xref>. The validated <eref target="#spf-dom	<li>SPF <xref target="RFC7208"/>: The validated <xref target="spf-domain">SPF
	ain">SPF Domain</eref> from the email	Domain</xref> from the email
	message is the Authenticated Identifier.</t>	message is the Authenticated Identifier.</li>
	</li>
	</ul>	</ul>
	</section>	</section>

	<section anchor="identifier-alignment-explained"><name>Identifier Alignment Expl ained</name>	<section anchor="identifier-alignment-explained"><name>Identifier Alignment Expl ained</name>

	<t>DMARC validates the authorized use of the <eref target="#author-domain">Autho	<t>DMARC validates the authorized use of the <xref target="author-domain">Author
	r Domain</eref> by requiring	Domain</xref> by requiring
	either that it have the same <eref target="#organizational-domain">Organizationa	either that it have the same <xref target="organizational-domain">Organizational
	l Domain</eref> as an	Domain</xref> as an
	<eref target="#authenticated-identifier">Authenticated Identifier</eref> (a cond	<xref target="authenticated-identifiers">Authenticated Identifier</xref> (a cond
	ition known as "<eref target="#relaxed-alignment">Relaxed	ition known as <xref target="relaxed-alignment">"relaxed
	Alignment</eref>") or that it be identical to the Authenticated Identifier	alignment"</xref>) or that it be identical to the Authenticated Identifier
	(a condition known as "<eref target="#strict-alignment">Strict Alignment</	(a condition known as <xref target="strict-alignment">"strict alignment"</xref>
	eref>"). The choice of relaxed	). The choice of relaxed
	or strict alignment is left to the <eref target="#domain-owner">Domain Owner</er	or strict alignment is left to the <xref target="domain-owner">Domain Owner</xre
	ef> and is expressed in	f> and is expressed in
	the domain's <eref target="#dmarc-policy-record">DMARC Policy Record</eref>. In	the domain's <xref target="dmarc-policy-record">DMARC Policy Record</xref>. In p
	practice, nearly all Domain	ractice, nearly all Domain
	Owners have found relaxed alignment sufficient to meet their needs. Domain name comparisons	Owners have found relaxed alignment sufficient to meet their needs. Domain name comparisons

	in this context are case-insensitive, per <xref target="RFC4343"></xref>.</t>	in this context are case-insensitive, per <xref target="RFC4343"/>.</t>
	<t>The following table is meant to illustrate possible alignment conditions.</t>	<t>The following table is meant to illustrate possible alignment conditions.</t>

	<table align="left"><name>"Alignment Examples"	<table align="center"><name>Alignment Examples
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Authenticated Identifier</th>	<th>Authenticated Identifier</th>
	<th>Author Domain</th>	<th>Author Domain</th>
	<th>Identifier Alignment</th>	<th>Identifier Alignment</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>

	skipping to change at line 445 ¶	skipping to change at line 499 ¶
	<td>strict; the two are identical</td>	<td>strict; the two are identical</td>
	</tr>	</tr>

	<tr>	<tr>
	<td>foo.example.net</td>	<td>foo.example.net</td>
	<td>news.example.com</td>	<td>news.example.com</td>
	<td>none; the two do not share a common Organizational Domain</td>	<td>none; the two do not share a common Organizational Domain</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table><t>It is important to note that Identifier Alignment cannot occur with a	</table><t>It is important to note that Identifier Alignment cannot occur with a

	message that is not valid per <xref target="RFC5322"></xref>, particularly one w	message that is not valid per <xref target="RFC5322"/>, particularly one with a
	ith a	malformed, absent, or repeated RFC5322.From header field, since in that case,
	malformed, absent, or repeated RFC5322.From header field, since in that case	there is no reliable way to determine a <xref target="dmarc-policy-record">DMARC
	there is no reliable way to determine a <eref target="#dmarc-policy-record">DMAR	Policy Record</xref>
	C Policy Record</eref>
	that applies to the message. Accordingly, DMARC operation is predicated on the i nput	that applies to the message. Accordingly, DMARC operation is predicated on the i nput

	being a valid RFC5322 message object. For non-compliant cases, handling	being a valid message object <xref target="RFC5322"/>. For non-compliant cases, handling
	is outside of the scope of this specification. Further discussion of this	is outside of the scope of this specification. Further discussion of this

	can be found in <xref target="denial-of-dmarc-attacks"></xref>.</t>	can be found in <xref target="denial-of-dmarc-attacks"/>.</t>

	<section anchor="dkim-identifiers"><name>DKIM-Authenticated Identifiers</name>	<section anchor="dkim-identifiers"><name>DKIM-Authenticated Identifiers</name>
	<t>DKIM permits a Domain Owner to claim some responsibility for a message by	<t>DKIM permits a Domain Owner to claim some responsibility for a message by
	associating the domain to the message. This association is done by inserting	associating the domain to the message. This association is done by inserting

	the domain as the value of the "d" tag in a DKIM-Signature header fiel d, and the	the domain as the value of the "d" tag in a DKIM-Signature header field, and the
	assertion of responsibility is validated through a cryptographic signature in	assertion of responsibility is validated through a cryptographic signature in
	the header field. If the cryptographic signature validates, then the DKIM Signin g	the header field. If the cryptographic signature validates, then the DKIM Signin g
	Domain is the DKIM-Authenticated Identifier.</t>	Domain is the DKIM-Authenticated Identifier.</t>
	<t>There is currently no generally accepted mechanism by which a Domain Owner ma y	<t>There is currently no generally accepted mechanism by which a Domain Owner ma y
	assert a list of third-party DKIM Signing Domains that are authorized to sign on	assert a list of third-party DKIM Signing Domains that are authorized to sign on
	behalf of a given Author Domain. Therefore, DMARC requires that Identifier	behalf of a given Author Domain. Therefore, DMARC requires that Identifier
	Alignment is applied to the DKIM-Authenticated Identifier because a message can	Alignment is applied to the DKIM-Authenticated Identifier because a message can
	bear a valid signature from any domain, even one used by a bad actor. Only a	bear a valid signature from any domain, even one used by a bad actor. Only a
	DKIM-Authenticated Identifier that has Identifier Alignment with the Author Doma in	DKIM-Authenticated Identifier that has Identifier Alignment with the Author Doma in
	is enough to validate the authorized use of the Author Domain.</t>	is enough to validate the authorized use of the Author Domain.</t>
	<t>A single email can contain multiple DKIM signatures, and it is considered to	<t>A single email can contain multiple DKIM signatures, and it is considered to

	produce a DMARC "pass" result if any DKIM-Authenticated Identifier ali gns with	produce a DMARC "pass" result if any DKIM-Authenticated Identifier aligns with
	the Author Domain.</t>	the Author Domain.</t>
	</section>	</section>

	<section anchor="spf-identifiers"><name>SPF-Authenticated Identifiers</name>	<section anchor="spf-identifiers"><name>SPF-Authenticated Identifiers</name>
	<t>SPF can validate the uses of both the domain found in an SMTP HELO/EHLO comma nd	<t>SPF can validate the uses of both the domain found in an SMTP HELO/EHLO comma nd
	(the HELO identity) and the domain found in an SMTP MAIL command (the MAIL FROM	(the HELO identity) and the domain found in an SMTP MAIL command (the MAIL FROM
	identity). DMARC relies solely on SPF validation of the MAIL FROM identity. If	identity). DMARC relies solely on SPF validation of the MAIL FROM identity. If
	the use of the domain in the MAIL FROM identity is validated by SPF, then that	the use of the domain in the MAIL FROM identity is validated by SPF, then that
	domain is the SPF-Authenticated Identifier.</t>	domain is the SPF-Authenticated Identifier.</t>
	<t>There is currently no generally accepted mechanism by which a Domain Owner ma y	<t>There is currently no generally accepted mechanism by which a Domain Owner ma y
	assert a list of third-party domains that are authorized for use as the MAIL FRO M	assert a list of third-party domains that are authorized for use as the MAIL FRO M
	identity for mail using a given Author Domain. Therefore, DMARC requires that Id entifier Alignment	identity for mail using a given Author Domain. Therefore, DMARC requires that Id entifier Alignment
	is applied to the SPF-Authenticated Identifier because any Domain Owner, even a bad	is applied to the SPF-Authenticated Identifier because any Domain Owner, even a bad

	actor, can publish an SPF record for its domain and send email that will obtain	actor, can publish an SPF record for its domain and send an email that will obta
	an	in an
	SPF pass result. Only an SPF-Authenticated Identifier that has Identifier Alignm	SPF "pass" result. Only an SPF-Authenticated Identifier that has Identifier Alig
	ent	nment
	with the Author Domain is enough to validate the authorized use of the Author Do main.</t>	with the Author Domain is enough to validate the authorized use of the Author Do main.</t>
	</section>	</section>

	<section anchor="alignment-and-extension-technologies"><name>Alignment and Exten sion Technologies</name>	<section anchor="alignment-and-extension-technologies"><name>Alignment and Exten sion Technologies</name>

	<t>If in the future DMARC is extended to include the use of other authentication	<t>In the future, if DMARC is extended to include the use of other authenticatio n
	mechanisms, the extensions <bcp14>MUST</bcp14> allow for the assignment of a dom ain	mechanisms, the extensions <bcp14>MUST</bcp14> allow for the assignment of a dom ain
	as an Authenticated Identifier so that alignment with the Author Domain	as an Authenticated Identifier so that alignment with the Author Domain
	can be validated.</t>	can be validated.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="dmarc-policy-record-explained"><name>DMARC Policy Record Explai ned</name>	<section anchor="dmarc-policy-record-explained"><name>DMARC Policy Record Explai ned</name>

	<t>A <eref target="#domain-owner">Domain Owner</eref> or <eref target="#public-s	<t>A <xref target="domain-owner">Domain Owner</xref> or <xref target="public-suf
	uffix-operator">PSO</eref> advertises	fix-operator">PSO</xref> advertises
	DMARC participation of one or more of its domains by publishing <eref target="#d	DMARC participation of one or more of its domains by publishing <xref target="dm
	marc-policy-record">DMARC Policy Records</eref> that will apply to those domains	arc-policy-record">DMARC Policy Records</xref> that will apply to those domains.
	. In doing so, Domain Owners	In doing so, Domain Owners
	and PSOs indicate their handling preference regarding failed validation for emai l	and PSOs indicate their handling preference regarding failed validation for emai l
	messages using their domain in the RFC5322.From header field as well as their	messages using their domain in the RFC5322.From header field as well as their
	desire (if any) to receive feedback about such messages in the form of aggregate and/or	desire (if any) to receive feedback about such messages in the form of aggregate and/or
	failure reports.</t>	failure reports.</t>
	<t>DMARC Policy Records are stored as DNS TXT records with names starting with	<t>DMARC Policy Records are stored as DNS TXT records with names starting with

	the label "_dmarc". For example, the Domain Owner of "example.co	the label "_dmarc". For example, the Domain Owner of "example.com" would publis
	m" would publish	h
	a DMARC Policy Record at the name "_dmarc.example.com", and a <eref ta	a DMARC Policy Record at the name "_dmarc.example.com", and a <xref target="mail
	rget="#mail-receiver">Mail Receiver</eref>	-receiver">Mail Receiver</xref>
	wishing to find the DMARC Policy Record for mail with an <eref target="#author-d	wishing to find the DMARC Policy Record for mail with an <xref target="author-do
	omain">Author Domain</eref>	main">Author Domain</xref>
	of "example.com" would issue a TXT query to the DNS for the name &quot	of "example.com" would issue a TXT query to the DNS for the name "_dmarc.example
	;_dmarc.example.com".	.com".
	A Domain Owner or PSO may choose not to participate in DMARC validation by Mail Receivers	A Domain Owner or PSO may choose not to participate in DMARC validation by Mail Receivers
	simply by not publishing a DMARC Policy Record for its Author Domain(s).</t>	simply by not publishing a DMARC Policy Record for its Author Domain(s).</t>


		<!--[rfced] In the sentence below, does "or different" mean "or
		another domain"? If yes, may we update this text for clarity?

		Original:
		The Domain Owner Assessment Policy (#domain-owner-policy) that
		applies to the subdomains can be identical to the Domain Owner
		Assessment Policy that applies to the Organizational Domain or
		different, depending on the presence or absence of certain values
		in the DMARC Policy Record.

		Perhaps:
		The Domain Owner Assessment Policy (Section 3.2.8) that applies to
		the subdomains can be identical to the Domain Owner Assessment
		Policy that applies to the Organizational Domain or another domain,
		depending on the presence or absence of certain values in the DMARC
		Policy Record.
		-->

	<t>DMARC Policy Records can also apply to subdomains of the name at which they	<t>DMARC Policy Records can also apply to subdomains of the name at which they

	are published in the DNS, if the record is published at an <eref target="#organi	are published in the DNS if the record is published at an <xref target="organiza
	zational-domain">Organizational	tional-domain">Organizational
	Domain</eref> for the subdomains. The <eref target="#domain-owner-policy">Domain	Domain</xref> for the subdomains. The <xref target="domain-owner-policy">Domain
	Owner Assessment Policy</eref> that applies to the subdomains can be identical	Owner Assessment Policy</xref> that applies to the subdomains can be identical t
	to the Domain	o the Domain
	Owner Assessment Policy that applies to the Organizational Domain or different, depending	Owner Assessment Policy that applies to the Organizational Domain or different, depending

	on the presence or absence of certain values in the DMARC Policy Record. See <xr ef target="policy-record-format"></xref>	on the presence or absence of certain values in the DMARC Policy Record. See <xr ef target="policy-record-format"/>
	for more details.</t>	for more details.</t>
	<t>DMARC's use of the Domain Name Service is driven by DMARC's use of domain	<t>DMARC's use of the Domain Name Service is driven by DMARC's use of domain
	names and the nature of the query it performs. The query requirement matches	names and the nature of the query it performs. The query requirement matches
	with the DNS for obtaining simple parametric information. It uses an established	with the DNS for obtaining simple parametric information. It uses an established
	method of storing the information associated with the domain name targeted by	method of storing the information associated with the domain name targeted by
	a DNS query, specifically an isolated TXT record that is restricted to the	a DNS query, specifically an isolated TXT record that is restricted to the
	DMARC context. Using the DNS as the query service has the benefit of reusing	DMARC context. Using the DNS as the query service has the benefit of reusing
	an extremely well-established operations, administration, and management	an extremely well-established operations, administration, and management
	infrastructure, rather than creating a new one.</t>	infrastructure, rather than creating a new one.</t>

	<t>Per <xref target="RFC1035"></xref>, a TXT record can comprise multiple " character-string" objects.	<t>Per <xref target="RFC1035"/>, a TXT record can comprise multiple "character-s tring" objects.
	Where this is the case, the module performing DMARC evaluation <bcp14>MUST</bcp1 4> concatenate	Where this is the case, the module performing DMARC evaluation <bcp14>MUST</bcp1 4> concatenate
	these strings by joining together the objects in order and parsing the result as a single string.</t>	these strings by joining together the objects in order and parsing the result as a single string.</t>
	<t>A Domain Owner can choose not to have some underlying authentication mechanis ms	<t>A Domain Owner can choose not to have some underlying authentication mechanis ms
	apply to DMARC evaluation of its Author Domain(s). For example, if a Domain Owne r	apply to DMARC evaluation of its Author Domain(s). For example, if a Domain Owne r
	only wants to use DKIM as the underlying authentication mechanism, then the Doma in	only wants to use DKIM as the underlying authentication mechanism, then the Doma in
	Owner does not publish an SPF record that can produce Identifier Alignment	Owner does not publish an SPF record that can produce Identifier Alignment
	between an SPF-Authenticated Identifier and the Author Domain. Alternatively, if	between an SPF-Authenticated Identifier and the Author Domain. Alternatively, if
	the Domain Owner wishes to rely solely on SPF, then it can send email messages t hat	the Domain Owner wishes to rely solely on SPF, then it can send email messages t hat
	have no DKIM-Signature header field that would produce Identifier Alignment betw een	have no DKIM-Signature header field that would produce Identifier Alignment betw een
	a DKIM-Authenticated Identifier and the Author Domain. However, it is <bcp14>REC OMMENDED</bcp14>	a DKIM-Authenticated Identifier and the Author Domain. However, it is <bcp14>REC OMMENDED</bcp14>
	that Domain Owners use both DKIM and SPF as underlying authentication mechanisms for DMARC.</t>	that Domain Owners use both DKIM and SPF as underlying authentication mechanisms for DMARC.</t>
	<t>A Mail Receiver implementing the DMARC mechanism gets the Domain Owner's or	<t>A Mail Receiver implementing the DMARC mechanism gets the Domain Owner's or
	PSO's published Domain Owner Assessment Policy and can use it to inform its hand ling decisions	PSO's published Domain Owner Assessment Policy and can use it to inform its hand ling decisions

	for messages that undergo DMARC validation checks and do not produce a result of	for messages that undergo DMARC validation checks and do not produce a result of
	pass. Mail handling considerations based on Domain Owner Assessment Policy enfo	"pass".
	rcement	Mail handling considerations based on Domain Owner Assessment Policy enforcement
	are discussed below in <xref target="policy-enforcement-considerations"></xref>.	are discussed below in <xref target="policy-enforcement-considerations"/>.</t>
	</t>
	</section>	</section>

	<section anchor="dmarc-uris"><name>DMARC Reporting URIs</name>	<section anchor="dmarc-uris"><name>DMARC Reporting URIs</name>

	<t><xref target="RFC3986"></xref> defines a syntax for identifying a resource. T	<t><xref target="RFC3986"/> defines a syntax for identifying a resource. The DMA
	he DMARC	RC
	mechanism uses this as the format by which a <eref target="#domain-owner">Domain	mechanism uses this as the format by which a <xref target="domain-owner">Domain
	Owner</eref>	Owner</xref>
	or <eref target="#public-suffix-organization">PSO</eref> specifies the destinati	or <xref target="public-suffix-operator">PSO</xref> specifies the destination(s)
	on(s) for the two	for the two
	report types that are supported. The <eref target="#policy-record-format">DMARC	report types that are supported. The <xref target="policy-record-format">DMARC P
	Policy Record format</eref>	olicy Record format</xref>
	allows for a list of these URIs to be provided, with each URI separated by comma s (ASCII 0x2c).</t>	allows for a list of these URIs to be provided, with each URI separated by comma s (ASCII 0x2c).</t>

	<t>A formal definition is provided in <xref target="formal-definition"></xref>.< /t>	<t>A formal definition is provided in <xref target="formal-definition"/>.</t>
	</section>	</section>

	<section anchor="policy-record-format"><name>DMARC Policy Record Format</name>	<section anchor="policy-record-format"><name>DMARC Policy Record Format</name>

	<t>DMARC Policy Records follow the extensible "tag-value" syntax for D	<t>DMARC Policy Records follow the extensible "tag-value" syntax for DNS-based
	NS-based	key records defined in DKIM <xref target="RFC6376"/>.</t>
	key records defined in DKIM <xref target="RFC6376"></xref>.</t>	<t><xref target="iana-considerations"/> creates a registry for known DMARC tags
	<t><xref target="iana-considerations"></xref> creates a registry for known DMARC	and
	tags and
	registers the initial set defined in this document. Only tags defined	registers the initial set defined in this document. Only tags defined
	in that registry are to be processed; unknown tags <bcp14>MUST</bcp14> be ignore d.</t>	in that registry are to be processed; unknown tags <bcp14>MUST</bcp14> be ignore d.</t>
	<t>The following tags are valid DMARC tags:</t>	<t>The following tags are valid DMARC tags:</t>

	<dl>	<dl>
	<dt>adkim:</dt>	<dt>adkim:</dt>

	<dd><t>(plain-text; <bcp14>OPTIONAL</bcp14>; default is "r".) Indicate	<dd><t>(plain-text; <bcp14>OPTIONAL</bcp14>; default is "r".) Indicates whether
	s whether	the <xref target="domain-owner">Domain Owner</xref> or <xref target="public-suff
	the <eref target="#domain-owner">Domain Owner</eref> or <eref target="#public-su	ix-operator">PSO</xref> requires
	ffix-organization">PSO</eref> requires	strict or relaxed DKIM Identifier Alignment mode. See <xref target="dkim-identif
	strict or relaxed DKIM Identifier Alignment mode. See <xref target="dkim-identif	iers"/> for details.
	iers"></xref> for details.
	Valid values are as follows:</t>	Valid values are as follows:</t>

	<dl spacing="compact">	<dl spacing="compact">
	<dt>r:</dt>	<dt>r:</dt>
	<dd>relaxed mode</dd>	<dd>relaxed mode</dd>
	<dt>s:</dt>	<dt>s:</dt>
	<dd>strict mode</dd>	<dd>strict mode</dd>
	</dl></dd>	</dl></dd>


	<dt>aspf:</dt>	<dt>aspf:</dt>

	<dd><t>(plain-text; <bcp14>OPTIONAL</bcp14>; default is "r".) Indicat es whether	<dd><t>(plain-text; <bcp14>OPTIONAL</bcp14>; default is "r".) Indicates whether
	the Domain Owner or PSO requires strict or relaxed SPF Identifier Alignment	the Domain Owner or PSO requires strict or relaxed SPF Identifier Alignment

	mode. See <xref target="spf-identifiers"></xref> for details. Valid values are a s follows:</t>	mode. See <xref target="spf-identifiers"/> for details. Valid values are as foll ows:</t>

	<dl spacing="compact">	<dl spacing="compact">
	<dt>r:</dt>	<dt>r:</dt>
	<dd>relaxed mode</dd>	<dd>relaxed mode</dd>
	<dt>s:</dt>	<dt>s:</dt>
	<dd>strict mode</dd>	<dd>strict mode</dd>
	</dl></dd>	</dl></dd>


	<dt>fo:</dt>	<dt>fo:</dt>

	<dd><t>Failure reporting options (plain-text; <bcp14>OPTIONAL</bcp14>; default i s "0") Provides	<dd><t>Failure reporting options (plain-text; <bcp14>OPTIONAL</bcp14>; default i s "0"). Provides
	requested options for the generation of failure reports. Report generators	requested options for the generation of failure reports. Report generators
	may choose to adhere to the requested options. This tag's content <bcp14>MUST</ bcp14>	may choose to adhere to the requested options. This tag's content <bcp14>MUST</ bcp14>

	be ignored if a "ruf" tag (below) is not also specified. This tag can	be ignored if a "ruf" tag (below) is not also specified. This tag can include
	include	one or more of the values shown here, with the exception that "0" and "1" are
	one or more of the values shown here, with the exception that "0" and
	"1" are
	mutually exclusive. If more than one value is assigned to the tag, the list of	mutually exclusive. If more than one value is assigned to the tag, the list of
	values should be separated by colons (e.g., fo=0:d), and the values may appear	values should be separated by colons (e.g., fo=0:d), and the values may appear

	in the list in any order. Valid values and their meanings are:</t>	in the list in any order. Valid values and their meanings are as follows:</t>


	<dl spacing="compact">	<dl spacing="normal">
	<dt>0:</dt>	<dt>0:</dt>
	<dd>Generate a DMARC failure report if all underlying authentication	<dd>Generate a DMARC failure report if all underlying authentication

	mechanisms fail to produce an aligned "pass" result.</dd>	mechanisms fail to produce an aligned "pass" result.</dd>
	<dt>1:</dt>	<dt>1:</dt>
	<dd>Generate a DMARC failure report if any underlying authentication	<dd>Generate a DMARC failure report if any underlying authentication

	mechanism fails to produce an aligned "pass" result.</dd>	mechanism fails to produce an aligned "pass" result.</dd>
	<dt>d:</dt>	<dt>d:</dt>
	<dd>Generate a DKIM failure report if the message had a signature	<dd>Generate a DKIM failure report if the message had a signature
	that failed evaluation, regardless of its alignment. DKIM-specific	that failed evaluation, regardless of its alignment. DKIM-specific

	reporting is described in <xref target="RFC6651"></xref>.</dd>	reporting is described in <xref target="RFC6651"/>.</dd>
	<dt>s:</dt>	<dt>s:</dt>
	<dd>Generate an SPF failure report if the message failed SPF	<dd>Generate an SPF failure report if the message failed SPF
	evaluation, regardless of its alignment. SPF-specific	evaluation, regardless of its alignment. SPF-specific

	reporting is described in <xref target="RFC6652"></xref>.</dd>	reporting is described in <xref target="RFC6652"/>.</dd>
	</dl></dd>	</dl></dd>


	<dt>np:</dt>	<dt>np:</dt>

	<dd><t><eref target="#domain-owner-policy">Domain Owner Assessment Policy</eref> for non-existent subdomains	<dd><t><xref target="domain-owner-policy">Domain Owner Assessment Policy</xref> for non-existent subdomains
	of the given Organizational Domain (plain-text; <bcp14>OPTIONAL</bcp14>). For th is tag, the definition	of the given Organizational Domain (plain-text; <bcp14>OPTIONAL</bcp14>). For th is tag, the definition

	of "non-existent subdomain" is the same as that used for "Non-exi stent Domains" in <xref target="non-existent-domains"></xref>.	of "non-existent subdomain" is the same as that used for "non-existent domains" in <xref target="non-existent-domains"/>.
	The policy expressed by this tag indicates the message handling preference of th e Domain Owner	The policy expressed by this tag indicates the message handling preference of th e Domain Owner
	or PSO for mail using non-existent subdomains	or PSO for mail using non-existent subdomains
	of the prevailing Organizational Domain and not passing DMARC validation. It app lies	of the prevailing Organizational Domain and not passing DMARC validation. It app lies
	only to non-existent subdomains of the Organizational Domain queried and not to either	only to non-existent subdomains of the Organizational Domain queried and not to either

	existing subdomains or the domain itself. Its syntax is identical to that of the	existing subdomains or the domain itself. Its syntax is identical to that of the
	"p"	"p"
	tag defined below. If the "np" tag is absent, the policy specified by	tag defined below. If the "np" tag is absent, the policy specified by the "sp" t
	the "sp" tag (if	ag (if
	the "sp" tag is present) or the policy specified by the "p"	the "sp" tag is present) or the policy specified by the "p" tag (if the "sp"
	tag, if the "sp"	tag is not present) <bcp14>MUST</bcp14> be applied for non-existent subdomains.<
	tag is not present, <bcp14>MUST</bcp14> be applied for non-existent subdomains.<	/t>
	/t>
	</dd>	</dd>


	<dt>p:</dt>	<dt>p:</dt>

	<dd><t><eref target="#domain-owner-policy">Domain Owner Assessment Policy</eref> (plain-text; <bcp14>RECOMMENDED</bcp14>	<dd><t><xref target="domain-owner-policy">Domain Owner Assessment Policy</xref> (plain-text; <bcp14>RECOMMENDED</bcp14>
	for DMARC Policy Records). Indicates the message handling preference of the Doma in Owner	for DMARC Policy Records). Indicates the message handling preference of the Doma in Owner
	or PSO for mail using its domain but not passing DMARC validation.	or PSO for mail using its domain but not passing DMARC validation.
	The policy applies to the domain queried and to subdomains, unless the	The policy applies to the domain queried and to subdomains, unless the

	subdomain policy is explicitly described using the "sp" or "np&qu ot; tags.	subdomain policy is explicitly described using the "sp" or "np" tags.
	If this tag is not present in an otherwise syntactically valid DMARC	If this tag is not present in an otherwise syntactically valid DMARC

	Policy Record, then the record is treated as if it included "p=none" (	Policy Record, then the record is treated as if it included "p=none" (see
	see	<xref target="dmarc-policy-discovery"/>). This tag is not applicable for third-p
	<xref target="dmarc-policy-discovery"></xref>). This tag is not applicable for t	arty
	hird-party	reporting records (see <xref target="RFC9990"/> and <xref target="RFC9991"/>).
	reporting records (see <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>
	and <xref target="I-D.ietf-dmarc-failure-reporting"></xref>).
	Possible values are as follows:</t>	Possible values are as follows:</t>


	<dl spacing="compact">	<dl spacing="normal">
	<dt>none:</dt>	<dt>none:</dt>
	<dd>The Domain Owner offers no expression of preference.</dd>	<dd>The Domain Owner offers no expression of preference.</dd>
	<dt>quarantine:</dt>	<dt>quarantine:</dt>
	<dd>The Domain Owner considers such mail to be suspicious. It is possible	<dd>The Domain Owner considers such mail to be suspicious. It is possible
	the mail is valid, although the failure creates a significant concern.</dd>	the mail is valid, although the failure creates a significant concern.</dd>
	<dt>reject:</dt>	<dt>reject:</dt>
	<dd>The Domain Owner considers all such failures to be a clear indication	<dd>The Domain Owner considers all such failures to be a clear indication

	that the use of the domain name is not valid. See <xref target="rejecting-messag es"></xref>	that the use of the domain name is not valid. See <xref target="rejecting-messag es"/>
	for some discussion of SMTP rejection methods and their implications.</dd>	for some discussion of SMTP rejection methods and their implications.</dd>
	</dl></dd>	</dl></dd>


	<dt>psd:</dt>	<dt>psd:</dt>

	<dd><t>A flag indicating whether the domain is a PSD. (plain-text; <bcp14>OPTION	<dd><t>A flag indicating whether the domain is a PSD (plain-text; <bcp14>OPTIONA
	AL</bcp14>;	L</bcp14>;
	default is "u"). Possible values are:</t>	default is "u"). Possible values are as follows:</t>


	<dl spacing="compact">	<dl spacing="normal">
	<dt>y:</dt>	<dt>y:</dt>

	<dd>PSOs include this tag with a value of "y" to indicate that the dom	<dd>PSOs include this tag with a value of "y" to indicate that the domain
	ain	is a PSD. If a record containing this tag with a value of "y" is found during
	is a PSD. If a record containing this tag with a value of "y" is found
	during
	policy discovery, this information will be used to determine the Organizational	policy discovery, this information will be used to determine the Organizational
	Domain and DMARC Policy Domain applicable to the message in question.</dd>	Domain and DMARC Policy Domain applicable to the message in question.</dd>
	<dt>n:</dt>	<dt>n:</dt>
	<dd>The DMARC Policy Record is published for a domain that is not a PSD, but it is	<dd>The DMARC Policy Record is published for a domain that is not a PSD, but it is
	the Organizational Domain for itself and its subdomains.</dd>	the Organizational Domain for itself and its subdomains.</dd>
	<dt>u:</dt>	<dt>u:</dt>
	<dd>The default indicates that the DMARC Policy Record is published for a domain	<dd>The default indicates that the DMARC Policy Record is published for a domain

	that is not a PSD, and may or may not be an Organizational Domain for itself and	that is not a PSD and may or may not be an Organizational Domain for itself and
	its subdomains. Use the mechanism described in <xref target="dns-tree-walk"></xr	its subdomains. Use the mechanism described in <xref target="dns-tree-walk"/> fo
	ef> for determining	r determining
	the Organizational Domain for this domain.</dd>	the Organizational Domain for this domain.</dd>
	</dl></dd>	</dl></dd>


	<dt>rua:</dt>	<dt>rua:</dt>
	<dd><t>Addresses to which aggregate feedback reports are to be sent (comma-separ ated plain-text	<dd><t>Addresses to which aggregate feedback reports are to be sent (comma-separ ated plain-text
	list of DMARC Reporting URIs; <bcp14>OPTIONAL</bcp14>). If present, the Domain O wner is requesting	list of DMARC Reporting URIs; <bcp14>OPTIONAL</bcp14>). If present, the Domain O wner is requesting

	Mail Receivers to send aggregate feedback reports as defined in <xref target="I- D.ietf-dmarc-aggregate-reporting"></xref>	Mail Receivers to send aggregate feedback reports as defined in <xref target="RF C9990"/>
	to the URIs listed. Any valid URI can be specified. A Mail Receiver that sends aggregate	to the URIs listed. Any valid URI can be specified. A Mail Receiver that sends aggregate

	feedback reports <bcp14>MUST</bcp14> implement support for a "mailto:&quot ; URI, i.e., the ability to send a DMARC	feedback reports <bcp14>MUST</bcp14> implement support for a "mailto:" URI, i.e ., the ability to send a DMARC
	report via electronic mail. If the tag is not provided, Mail Receivers <bcp14>MU ST NOT</bcp14> generate	report via electronic mail. If the tag is not provided, Mail Receivers <bcp14>MU ST NOT</bcp14> generate
	aggregate feedback reports for the domain. URIs involving schemes not supported by Mail Receivers	aggregate feedback reports for the domain. URIs involving schemes not supported by Mail Receivers

	<bcp14>MUST</bcp14> be ignored. <xref target="I-D.ietf-dmarc-aggregate-reportin g"></xref> also discusses considerations that	<bcp14>MUST</bcp14> be ignored. <xref target="RFC9990"/> also discusses conside rations that
	apply when the domain name of a URI differs from the domain publishing the DMARC Policy Record. See	apply when the domain name of a URI differs from the domain publishing the DMARC Policy Record. See

	<xref target="external-report-addresses"></xref> for additional considerations.< /t>	<xref target="external-report-addresses"/> for additional considerations.</t>
	</dd>	</dd>


	<dt>ruf:</dt>	<dt>ruf:</dt>
	<dd><t>Addresses to which message-specific failure information is to be reported	<dd><t>Addresses to which message-specific failure information is to be reported
	(comma-separated plain-text list of DMARC URIs; <bcp14>OPTIONAL</bcp14>). If pre sent, the	(comma-separated plain-text list of DMARC URIs; <bcp14>OPTIONAL</bcp14>). If pre sent, the
	Domain Owner is requesting Mail Receivers to send detailed failure reports about	Domain Owner is requesting Mail Receivers to send detailed failure reports about

	messages that fail the DMARC evaluation in specific ways (see the "fo"	messages that fail the DMARC evaluation in specific ways (see the "fo" tag above
	tag above) to	) to
	the URIs listed. Depending on the value of the "fo" tag, the format f	the URIs listed. Depending on the value of the "fo" tag, the format for such re
	or such reports	ports
	is described in <xref target="I-D.ietf-dmarc-failure-reporting"></xref>, <xref t	is described in <xref target="RFC9991"/>, <xref target="RFC6651"/>, and <xref ta
	arget="RFC6651"></xref>, or <xref target="RFC6652"></xref>. Any	rget="RFC6652"/>. Any
	valid URI can be specified. A Mail Receiver sending failure reports <bcp14>MUST< /bcp14> implement	valid URI can be specified. A Mail Receiver sending failure reports <bcp14>MUST< /bcp14> implement

	support for a "mailto:" URI, i.e., the ability to send message-specifi c failure information	support for a "mailto:" URI, i.e., the ability to send message-specific failure information
	via electronic mail. If the tag is not provided, Mail Receivers <bcp14>MUST NOT< /bcp14> generate	via electronic mail. If the tag is not provided, Mail Receivers <bcp14>MUST NOT< /bcp14> generate
	failure reports for the domain. URIs involving schemes not supported by Mail Rec eivers	failure reports for the domain. URIs involving schemes not supported by Mail Rec eivers

	<bcp14>MUST</bcp14> be ignored. <xref target="I-D.ietf-dmarc-aggregate-reportin g"></xref> discusses considerations	<bcp14>MUST</bcp14> be ignored. <xref target="RFC9990"/> discusses consideratio ns
	that apply when the domain name of a URI differs from that of the domain adverti sing the	that apply when the domain name of a URI differs from that of the domain adverti sing the

	policy. See <xref target="external-report-addresses"></xref> for additional con siderations.</t>	policy. See <xref target="external-report-addresses"/> for additional considera tions.</t>
	</dd>	</dd>


		<!--[rfced] We are having difficulty parsing "Organizational Domain for and
		not passing DMARC validation" in this sentence. May we update it as follows
		for clarity?

		Original:
		Indicates the
		message handling preference of the Domain Owner or PSO for mail
		using an existing subdomain of the prevailing Organizational
		Domain for and not passing DMARC validation.

		Perhaps:
		Indicates the
		message handling preference of the Domain Owner or PSO for mail
		that uses an existing subdomain of the prevailing Organizational
		Domain but does not pass DMARC validation.
		-->

	<dt>sp:</dt>	<dt>sp:</dt>
	<dd><t>Domain Owner Assessment Policy for all subdomains of the given Organizati onal Domain	<dd><t>Domain Owner Assessment Policy for all subdomains of the given Organizati onal Domain
	(plain-text; <bcp14>OPTIONAL</bcp14>). Indicates the message handling preference of the Domain Owner	(plain-text; <bcp14>OPTIONAL</bcp14>). Indicates the message handling preference of the Domain Owner
	or PSO for mail using an existing subdomain of the prevailing Organizational Dom ain for	or PSO for mail using an existing subdomain of the prevailing Organizational Dom ain for
	and not passing DMARC validation. It applies only to existing subdomains of the message's	and not passing DMARC validation. It applies only to existing subdomains of the message's
	Organizational Domain in the DNS hierarchy and not to the Organizational Domain itself.	Organizational Domain in the DNS hierarchy and not to the Organizational Domain itself.

	Its syntax is identical to that of the "p" tag defined above. If both	Its syntax is identical to that of the "p" tag defined above. If both the "sp" t
	the "sp" tag is	ag is
	absent, and the "np" tag is either absent or not applicable, the polic	absent and the "np" tag is either absent or not applicable, the policy specified
	y specified by	by
	the "p" tag <bcp14>MUST</bcp14> be applied for subdomains. Note that	the "p" tag <bcp14>MUST</bcp14> be applied for subdomains. Note that "sp" will
	"sp" will be ignored for	be ignored for
	DMARC Policy Records published on subdomains of Organizational Domains and PSDs due	DMARC Policy Records published on subdomains of Organizational Domains and PSDs due

	to the effect of the <eref target="#dmarc-policy-discovery">DMARC Policy Discove ry</eref>.</t>	to the effect of the <xref target="dmarc-policy-discovery">DMARC policy discover y</xref>.</t>
	</dd>	</dd>


	<dt>t:</dt>	<dt>t:</dt>

	<dd><t>DMARC policy test mode (plain-text; <bcp14>OPTIONAL</bcp14>; default is &	<dd><t>DMARC policy test mode (plain-text; <bcp14>OPTIONAL</bcp14>; default is "
	quot;n"). For	n"). For
	the Author Domain to which the DMARC Policy Record applies, the "t" ta	the Author Domain to which the DMARC Policy Record applies, the "t" tag serves
	g serves
	as a signal to the actor performing DMARC validation checks as to whether or not	as a signal to the actor performing DMARC validation checks as to whether or not

	the Domain Owner wishes the Domain Owner Assessment Policy declared in the &quot	the Domain Owner wishes the Domain Owner Assessment Policy declared in the "p",
	;p",	"sp", and/or "np" tags to actually be applied. This tag does not affect the
	"sp", and/or "np" tags to actually be applied. This tag does	generation of DMARC reports, and it has no effect on any policy ("p", "sp", or "
	not affect the	np")
	generation of DMARC reports, and it has no effect on any policy ("p",	that is "none". See <xref target="removal-of-the-pct-tag"/> for further discuss
	"sp", or "np")	ion of the use
	that is "none". See <xref target="removal-of-the-pct-tag"></xref> for
	further discussion of the use
	of this tag. Possible values are as follows:</t>	of this tag. Possible values are as follows:</t>


	<dl spacing="compact">	<dl spacing="normal">
	<dt>y:</dt>	<dt>y:</dt>
	<dd>A request that the actor performing the DMARC validation check not	<dd>A request that the actor performing the DMARC validation check not
	apply the policy, but instead apply any special handling rules it might have	apply the policy, but instead apply any special handling rules it might have

	in place, such as rewriting the RFC5322.From header field (see <xref target="rem	in place, such as rewriting the RFC5322.From header field (see <xref target="rem
	oval-of-the-pct-tag"></xref>).	oval-of-the-pct-tag"/>).
	The Domain Owner is currently testing its specified DMARC assessment policy, and	The Domain Owner is currently testing its specified DMARC assessment policy and
	has	has
	an expectation that the policy applied to any failing messages will be one level below the	an expectation that the policy applied to any failing messages will be one level below the

	specified policy. That is, if the policy is "quarantine" and the value	specified policy. That is, if the policy is "quarantine" and the value of the "t
	of the "t"	"
	tag is "y", a policy of "none" will be applied to failing me	tag is "y", a policy of "none" will be applied to failing messages; if the polic
	ssages; if the policy	y
	is "reject" and the value of the "t" tag is "y", a	is "reject" and the value of the "t" tag is "y", a policy of "quarantine" will b
	policy of "quarantine" will be	e
	applied to failing messages, irrespective of any other special handling rules th at	applied to failing messages, irrespective of any other special handling rules th at

	might be triggered by the "t" tag having a value of "y".</dd >	might be triggered by the "t" tag having a value of "y".</dd>
	<dt>n:</dt>	<dt>n:</dt>
	<dd>The default is a request to apply the Domain Owner Assessment Policy as spec ified	<dd>The default is a request to apply the Domain Owner Assessment Policy as spec ified

	to any message that produces a DMARC "fail" result.</dd>	to any message that produces a DMARC "fail" result.</dd>
	</dl></dd>	</dl></dd>


	<dt>v:</dt>	<dt>v:</dt>
	<dd><t>Version (plain-text; <bcp14>REQUIRED</bcp14>). Identifies the record ret rieved	<dd><t>Version (plain-text; <bcp14>REQUIRED</bcp14>). Identifies the record ret rieved
	as a DMARC Policy Record. This tag <bcp14>MUST</bcp14> be the first tag in the l ist.	as a DMARC Policy Record. This tag <bcp14>MUST</bcp14> be the first tag in the l ist.

	The tag value is case sensitive, and the only possible value is "DMARC1&quo	The tag value is case sensitive, and the only possible value is "DMARC1". If the
	t;. If the	tag is not the first in the list, the tag is absent, or the value is not
	tag is not the first in the list, or the tag is absent, or the value is not	"DMARC1", then the entire record <bcp14>MUST</bcp14> be ignored.</t>
	"DMARC1", then the entire record <bcp14>MUST</bcp14> be ignored.</t>
	</dd>	</dd>
	</dl>	</dl>


	</section>	</section>

	<section anchor="formal-definition"><name>Formal Definition</name>	<section anchor="formal-definition"><name>Formal Definition</name>


		<!--[rfced] We are having difficulty understanding how "of same" fits into
		this sentence. May we remove it?

		Original:
		A DMARC Policy Record MUST comply with the formal definition of same
		found in this section.

		Perhaps:
		A DMARC Policy Record MUST comply with the formal definition
		found in this section.
		-->

	<t>A DMARC Policy Record <bcp14>MUST</bcp14> comply with the formal definition o f same	<t>A DMARC Policy Record <bcp14>MUST</bcp14> comply with the formal definition o f same
	found in this section. Unknown tags <bcp14>MUST</bcp14> be ignored. Syntax error s	found in this section. Unknown tags <bcp14>MUST</bcp14> be ignored. Syntax error s
	in the remainder of the record <bcp14>MUST</bcp14> be discarded in favor of	in the remainder of the record <bcp14>MUST</bcp14> be discarded in favor of
	default values (if any) or ignored outright.</t>	default values (if any) or ignored outright.</t>
	<t>Because unknown tags <bcp14>MUST</bcp14> be ignored, the addition of a new ta g into the	<t>Because unknown tags <bcp14>MUST</bcp14> be ignored, the addition of a new ta g into the
	registered list of tags does not itself require a new version of DMARC to be	registered list of tags does not itself require a new version of DMARC to be

	generated (with a corresponding change to the "v" tag's value), but a change	generated (with a corresponding change to the "v" tag's value), but a change
	to any existing tags does require a new version of DMARC.</t>	to any existing tags does require a new version of DMARC.</t>

	<t>The formal definition of the DMARC Policy Record format, using <xref target="	<t>The formal definition of the DMARC Policy Record format, using ABNF syntax as
	RFC5234"></xref>	described in <xref target="RFC5234"/>
	and <xref target="RFC7405"></xref>, is as follows:</t>	and <xref target="RFC7405"/>, is as follows:</t>


	<artwork><![CDATA[ dmarc-uri = URI	<!--[rfced] ABNF in Section 4.8

		a) FYI: We moved each description in the DMARC Policy Record over two
		spaces to the right so that each entry aligns under the first word on
		the line above (after the equals sign). This also matches the format
		in the companion document (RFC-to-be 9990). Please let us know of any
		concerns.

		b) The following line exceeds the 72-character limit. Please let us
		know how it can be modified.

		Original:
		dmarc-urilist = (dmarc-uri / obs-dmarc-uri) (WSP "," *WSP (dmarc-uri /
		obs-dmarc-uri))
		-->

		<sourcecode type="abnf"><![CDATA[
		dmarc-uri = URI
	; "URI" is imported from [RFC3986];	; "URI" is imported from [RFC3986];
	; commas (ASCII 0x2C) and exclamation	; commas (ASCII 0x2C) and exclamation
	; points (ASCII 0x21) MUST be	; points (ASCII 0x21) MUST be
	; encoded	; encoded


	obs-dmarc-uri = dmarc-uri obs-dmarc-report-size	obs-dmarc-uri = dmarc-uri obs-dmarc-report-size
	; Obsolete syntax, reporters should ignore the	; Obsolete syntax, reporters should ignore the

	; obs-dmarc-report-size if it is found in a DMARC Policy Record.	; obs-dmarc-report-size if it is found in a
		; DMARC Policy Record.


	obs-dmarc-report-size = "!" 1*DIGIT [ "k" / "m" / "g" / "t" ]	obs-dmarc-report-size = "!" 1*DIGIT [ "k" / "m" / "g" / "t" ]


	dmarc-sep = WSP ";" WSP	dmarc-sep = WSP ";" WSP


	equals = WSP "=" WSP	equals = WSP "=" WSP


	dmarc-record = dmarc-version *(dmarc-sep dmarc-tag) [dmarc-sep]	dmarc-record = dmarc-version *(dmarc-sep dmarc-tag) [dmarc-sep]


	dmarc-tag = 1ALPHA equals 1dmarc-value	dmarc-tag = 1ALPHA equals 1dmarc-value


	; any printing characters but semicolon	; any printing characters but semicolon
	dmarc-value = %x20-3A / %x3C-7E	dmarc-value = %x20-3A / %x3C-7E


	dmarc-version = "v" equals %s"DMARC1" ; case sensitive	dmarc-version = "v" equals %s"DMARC1" ; case sensitive


	; specialized syntax of DMARC values	; specialized syntax of DMARC values
	dmarc-request = "none" / "quarantine" / "reject"	dmarc-request = "none" / "quarantine" / "reject"


	dmarc-yorn = "y" / "n"	dmarc-yorn = "y" / "n"


	dmarc-psd = "y" / "n" / "u"	dmarc-psd = "y" / "n" / "u"


	dmarc-rors = "r" / "s"	dmarc-rors = "r" / "s"


	dmarc-urilist = (dmarc-uri / obs-dmarc-uri) (WSP "," *WSP (dmarc-uri / obs-d marc-uri))	dmarc-urilist = (dmarc-uri / obs-dmarc-uri) (WSP "," *WSP (dmarc-uri / obs-dma rc-uri))


	dmarc-fo = ("0" / "1") *(":" dmarc-afrf)	dmarc-fo = ("0" / "1") *(":" dmarc-afrf)
	/ dmarc-afrf [":" ("0" / "1")] [":" dmarc-afrf]	/ dmarc-afrf [":" ("0" / "1")] [":" dmarc-afrf]
	/ *(dmarc-afrf ":") ("0" / "1")	/ *(dmarc-afrf ":") ("0" / "1")

		dmarc-afrf = "d" / "s"
		; each may appear at most once in dmarc-fo]]></sourcecode>


	dmarc-afrf = "d" / "s"
	; each may appear at most once in dmarc-fo
	]]></artwork>
	<t>In each dmarc-tag, the dmarc-value has a syntax that depends on the tag name.	<t>In each dmarc-tag, the dmarc-value has a syntax that depends on the tag name.
	The ABNF rule for each dmarc-value is specified in the following table:</t>	The ABNF rule for each dmarc-value is specified in the following table:</t>

	<table align="left"><name>"Tag Names and Values"	<table align="center"><name>Tag Names and Values
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Tag Name</th>	<th>Tag Name</th>
	<th>Value Rule</th>	<th>Value Rule</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>

	skipping to change at line 860 ¶	skipping to change at line 992 ¶

	<tr>	<tr>
	<td>fo</td>	<td>fo</td>
	<td>dmarc-fo</td>	<td>dmarc-fo</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table></section>	</table></section>

	<section anchor="flow-diagram"><name>Flow Diagram</name>	<section anchor="flow-diagram"><name>Flow Diagram</name>


	<sourcecode type="ascii-art"><![CDATA[ +---------------+	<!--[rfced] As the <artwork> in Section 4.9 contains a legend defining
	+--------------------+	"MSA" and "MDA", may we move the definitions of "sMTA" and "rMTA" from
		the succeeding paragraph into the legend?

		Original:
		MSA = Mail Submission Agent
		MDA = Mail Delivery Agent
		...
		"sMTA" is the sending MTA, and "rMTA" is the receiving MTA.

		Perhaps:
		MSA = Mail Submission Agent
		MDA = Mail Delivery Agent
		sMTA = sending MTA
		rMTA = receiving MTA
		-->

		<artwork><![CDATA[
		+---------------+ +--------------------+
	\| Author Domain \|< . . . . . . . . . . . . \| Return-Path Domain \|	\| Author Domain \|< . . . . . . . . . . . . \| Return-Path Domain \|
	+---------------+ . +--------------------+	+---------------+ . +--------------------+
	\| . ^	\| . ^
	V V .	V V .
	+-----------+ +--------+ +----------+ v	+-----------+ +--------+ +----------+ v
	\| MSA \|<***>\| DKIM \| \| DMARC \| +----------+	\| MSA \|<***>\| DKIM \| \| DMARC \| +----------+
	\| Service \| \| Signer \| \| Validator\|<***>\| SPF \|	\| Service \| \| Signer \| \| Validator\|<***>\| SPF \|
	+-----------+ +--------+ +----------+ * \| Validator\|	+-----------+ +--------+ +----------+ * \| Validator\|
	\| ^ * +----------+	\| ^ * +----------+
	\| * *	\| * *

	skipping to change at line 884 ¶	skipping to change at line 1034 ¶
	+------+ (~~~~~~~~~~~~) +------+ \| Validator\|	+------+ (~~~~~~~~~~~~) +------+ \| Validator\|
	\| +----------+	\| +----------+
	\| ^	\| ^
	V .	V .
	+-----------+ .	+-----------+ .
	+---------+ \| MDA \| v	+---------+ \| MDA \| v
	\| User \|<--\| Filtering \| +-----------+	\| User \|<--\| Filtering \| +-----------+
	\| Mailbox \| \| Engine \| \| DKIM \|	\| Mailbox \| \| Engine \| \| DKIM \|
	+---------+ +-----------+ \| Signing \|	+---------+ +-----------+ \| Signing \|
	\| Domain(s) \|	\| Domain(s) \|

	+-----------+	+-----------+]]>

	MSA = Mail Submission Agent	MSA = Mail Submission Agent
	MDA = Mail Delivery Agent	MDA = Mail Delivery Agent

	]]></sourcecode>	</artwork>
	<t>The above diagram shows a typical flow of messages through a	<t>The above diagram shows a typical flow of messages through a
	DMARC-aware system. Dashed lines (e.g., -->) denote the actual message	DMARC-aware system. Dashed lines (e.g., -->) denote the actual message
	flow, dotted lines (e.g., < . . >) represent DNS queries used to retrieve	flow, dotted lines (e.g., < . . >) represent DNS queries used to retrieve
	message policy related to the supported message authentication schemes,	message policy related to the supported message authentication schemes,
	and starred lines (e.g., <**>) indicate data exchange between message-hand ling	and starred lines (e.g., <**>) indicate data exchange between message-hand ling

	modules and message authentication modules. "sMTA" is the sending MTA,	modules and message authentication modules. "sMTA" is the sending MTA, and
	and	"rMTA" is the receiving MTA.</t>
	"rMTA" is the receiving MTA.</t>
	<t>Put simply, when a message reaches a DMARC-aware rMTA, a DNS query	<t>Put simply, when a message reaches a DMARC-aware rMTA, a DNS query
	will be initiated to determine if a DMARC Policy Record exists that applies	will be initiated to determine if a DMARC Policy Record exists that applies
	to the Author Domain. If a DMARC Policy Record is found, the rMTA will use	to the Author Domain. If a DMARC Policy Record is found, the rMTA will use

	the results of SPF and DKIM validation checks to determine DMARC validation	the results of SPF and DKIM validation checks to determine the DMARC validation
	status. The DMARC validation status can then factor into the message handling	status. The DMARC validation status can then factor into the message handling
	decision made by the recipient's mail system.</t>	decision made by the recipient's mail system.</t>
	<t>More details on specific actions for the parties involved can be	<t>More details on specific actions for the parties involved can be

	found in <xref target="domain-owner-actions"></xref> and <xref target="mail-rece iver-actions"></xref>.</t>	found in Sections <xref target="domain-owner-actions" format="counter"/> and <xr ef target="mail-receiver-actions" format="counter"/>.</t>
	</section>	</section>

	<section anchor="dns-tree-walk"><name>DNS Tree Walk</name>	<section anchor="dns-tree-walk"><name>DNS Tree Walk</name>

	<t>An <eref target="#organizational-domain">Organizational Domain</eref> serves two different purposes,	<t>An <xref target="organizational-domain">Organizational Domain</xref> serves t wo different purposes,
	depending on the context:</t>	depending on the context:</t>

	<ul>	<ul>

	<li><t>The Organizational Domain of the <eref target="#author-domain">Author Dom	<li><t>The Organizational Domain of the <xref target="author-domain">Author Doma
	ain</eref> establishes	in</xref> establishes
	the <eref target="#dmarc-policy-record">DMARC Policy Record</eref> for that doma	the <xref target="dmarc-policy-record">DMARC Policy Record</xref> for that domai
	in when no DMARC Policy	n when no DMARC Policy
	Record is published specifically for the Author Domain. (see <xref target="dmarc	Record is published specifically for the Author Domain (see <xref target="dmarc-
	-policy-discovery"></xref>)</t>	policy-discovery"/>).</t>
	</li>	</li>

	<li><t>The Organizational Domains of an <eref target="#authenticated-identifiers	<li><t>The Organizational Domains of an <xref target="authenticated-identifiers"
	">Authenticated Identifier</eref>	>Authenticated Identifier</xref>
	and the Author Domain are used in determining Identifier Alignment between the t	and the Author Domain are used in determining Identifier Alignment between the t
	wo. (see	wo (see
	<xref target="identifier-alignment-evaluation"></xref>).</t>	<xref target="identifier-alignment-evaluation"/>).</t>
	</li>	</li>
	</ul>	</ul>

	<t><xref target="RFC7489"></xref> defined an Organizational Domain as "The	<t><xref target="RFC7489"/> defined an Organizational Domain as "The domain that
	domain that was registered with a domain	was registered with a domain
	name registrar." RFC 7489 discussed using a "public suffix" list	name registrar". <xref target="RFC7489"/> discussed using a Public Suffix List (
	(PSL) as the authoritative	PSL) as the authoritative
	list of the parent domains for Organizational Domains, and further described a m	list of the parent domains for Organizational Domains and further described a me
	ethod for	thod for
	determining the Organizational Domain of an Author Domain or an Authenticated Id entifier.	determining the Organizational Domain of an Author Domain or an Authenticated Id entifier.

	However, RFC 7489 mandated no requirement for a specific PSL for Mail Receivers	However, <xref target="RFC7489"/> mandated no requirement for a specific PSL for
	to use	Mail Receivers to use
	(though it did suggest the one found at <eref target="https://publicsuffix.org/"	(though it did suggest the one found at <eref target="https://publicsuffix.org/"
	>https://publicsuffix.org/</eref>) nor did it provide	brackets="angle"/>) nor did it provide
	any guidance for the frequency of regular retrieval of the PSL by Mail Receivers participating	any guidance for the frequency of regular retrieval of the PSL by Mail Receivers participating

	in DMARC. RFC 7489 acknowledged the possibility of interoperability issues cause	in DMARC. <xref target="RFC7489"/> acknowledged the possibility of interoperabil
	d by Mail	ity issues caused by Mail
	Receivers choosing different PSLs, and even suggested that if a more reliable an	Receivers choosing different PSLs and even suggested that if a more reliable and
	d secure	secure
	method for determining the Organizational Domain could be created, that method s hould	method for determining the Organizational Domain could be created, that method s hould

	replace reliance on a public suffix list.</t>	replace reliance on a PSL.</t>
	<t>This update to DMARC offers more flexibility to Domain Owners, especially tho se with large,	<t>This update to DMARC offers more flexibility to Domain Owners, especially tho se with large,
	complex organizations that might want to apply decentralized management to their DNS and their	complex organizations that might want to apply decentralized management to their DNS and their

	DMARC Policy Records. Rather than just using a public suffix list to help identi fy	DMARC Policy Records. Rather than just using a Public Suffix List to help identi fy
	an Organizational Domain, this update defines a discovery technique known colloq uially as	an Organizational Domain, this update defines a discovery technique known colloq uially as

	the "DNS Tree Walk". The target of any DNS Tree Walk is discovery of a valid DMARC Policy Record,	the "DNS Tree Walk". The target of any DNS Tree Walk is discovery of a valid DMA RC Policy Record,
	and its use in determining an Organizational Domain allows for publishing DMARC Policy Records	and its use in determining an Organizational Domain allows for publishing DMARC Policy Records
	at multiple points in the namespace.</t>	at multiple points in the namespace.</t>

	<t>This flexibility comes at a possible cost, however. Since the DNS Tree Walk	<t>However, this flexibility comes at a possible cost. Since the DNS Tree Walk
	relies on the Mail Receiver making a series of DNS queries, the potential	relies on the Mail Receiver making a series of DNS queries, the potential
	exists for an ill-intentioned Domain Owner to send mail with Author Domains	exists for an ill-intentioned Domain Owner to send mail with Author Domains

	with tens or even hundreds of labels for the purpose of executing a Denial	with tens or even hundreds of labels for the purpose of executing a
	of Service Attack on the Mail Receiver. To guard against such abuse of the	denial-of-service attack on the Mail Receiver. To guard against such abuse of t
		he
	DNS, a shortcut is built into the process so that Author Domains with more	DNS, a shortcut is built into the process so that Author Domains with more
	than eight labels do not result in more than eight DNS queries. Observed data	than eight labels do not result in more than eight DNS queries. Observed data
	at the time of publication showed that Author Domains with up to seven labels	at the time of publication showed that Author Domains with up to seven labels
	were in usage, and so eight was chosen as the query limit to allow for some	were in usage, and so eight was chosen as the query limit to allow for some

	future expansion of the name space that did not require updating this document.< /t>	future expansion of the namespace that did not require updating this document.</ t>
	<t>The generic steps for a DNS Tree Walk are as follows:</t>	<t>The generic steps for a DNS Tree Walk are as follows:</t>

	<ol>	<ol>
	<li><t>Query the DNS for a TXT record that matches the format of a DMARC Policy Record at	<li><t>Query the DNS for a TXT record that matches the format of a DMARC Policy Record at
	the starting point for the Tree Walk. The starting point for the DNS Tree Walk will	the starting point for the Tree Walk. The starting point for the DNS Tree Walk will

	depend on the ultimate target of the DNS Tree Walk. <xref target="dmarc-policy-d	depend on the ultimate target of the DNS Tree Walk. Sections <xref target="dmarc
	iscovery"></xref> and	-policy-discovery" format="counter"/> and
	<xref target="identifier-alignment-evaluation"></xref> describe the possible sta	<xref target="identifier-alignment-evaluation" format="counter"/> describe the p
	rting points. A possibly	ossible starting points. A possibly
	empty set of records is returned.</t>	empty set of records is returned.</t>
	</li>	</li>

	<li><t>Records that do not start with a "v" tag that identifies the cu rrent	<li><t>Records that do not start with a "v" tag that identifies the current
	version of DMARC are discarded. If multiple DMARC Policy Records are	version of DMARC are discarded. If multiple DMARC Policy Records are
	returned for a single target, they are all discarded. If a single record	returned for a single target, they are all discarded. If a single record

	remains and it contains a "psd=n" or "psd=y" tag, stop.</t>	remains and it contains a "psd=n" or "psd=y" tag, stop.</t>
	</li>	</li>
	<li><t>Break the subject DNS domain name into a set of ordered labels. Assign	<li><t>Break the subject DNS domain name into a set of ordered labels. Assign

	the count of labels to "x", and number the labels from right to left;	the count of labels to "x", and number the labels from right to left, e.g.,
	e.g.,	for "a.mail.example.com", "x" would be assigned the value 4, "com" would be
	for "a.mail.example.com", "x" would be assigned the value 4,	label 1, "example" would be label 2, "mail" would be label 3, and so forth.</t>
	"com" would be
	label 1, "example" would be label 2, "mail" would be label 3
	, and so forth.</t>
	</li>	</li>
	<li><t>If x < 8, remove the left-most (highest-numbered) label from the subje ct	<li><t>If x < 8, remove the left-most (highest-numbered) label from the subje ct
	domain. If x >= 8, remove the left-most (highest-numbered) labels from the	domain. If x >= 8, remove the left-most (highest-numbered) labels from the
	subject domain until 7 labels remain. The resulting DNS domain name is the	subject domain until 7 labels remain. The resulting DNS domain name is the
	new target for the next lookup.</t>	new target for the next lookup.</t>
	</li>	</li>
	<li><t>Query the DNS for a DMARC Policy Record at the DNS domain name matching t his	<li><t>Query the DNS for a DMARC Policy Record at the DNS domain name matching t his
	new target. A possibly empty set of records is returned.</t>	new target. A possibly empty set of records is returned.</t>
	</li>	</li>

	<li><t>Records that do not start with a "v" tag that identifies the cu rrent	<li><t>Records that do not start with a "v" tag that identifies the current
	version of DMARC are discarded. If multiple DMARC Policy Records are returned fo r	version of DMARC are discarded. If multiple DMARC Policy Records are returned fo r
	a single target, they are all discarded. If a single record remains and it	a single target, they are all discarded. If a single record remains and it

	contains a "psd=n" or "psd=y" tag, stop.</t>	contains a "psd=n" or "psd=y" tag, stop.</t>
	</li>	</li>
	<li><t>Determine the target for the next query by removing the left-most label	<li><t>Determine the target for the next query by removing the left-most label
	from the target of the previous query. Repeat steps 5, 6, and 7 until the	from the target of the previous query. Repeat steps 5, 6, and 7 until the
	process stops or there are no more labels remaining.</t>	process stops or there are no more labels remaining.</t>
	</li>	</li>
	</ol>	</ol>
	<t>To illustrate, for a message with the arbitrary Author Domain of	<t>To illustrate, for a message with the arbitrary Author Domain of

	"a.b.c.d.e.f.g.h.i.j.mail.example.com", a full DNS Tree Walk would req uire the following	"a.b.c.d.e.f.g.h.i.j.mail.example.com", a full DNS Tree Walk would require the f ollowing
	eight queries to potentially locate the DMARC Policy Record or Organizational Do main:</t>	eight queries to potentially locate the DMARC Policy Record or Organizational Do main:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com</li>	<li>_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com</li>
	<li>_dmarc.g.h.i.j.mail.example.com</li>	<li>_dmarc.g.h.i.j.mail.example.com</li>
	<li>_dmarc.h.i.j.mail.example.com</li>	<li>_dmarc.h.i.j.mail.example.com</li>
	<li>_dmarc.i.j.mail.example.com</li>	<li>_dmarc.i.j.mail.example.com</li>
	<li>_dmarc.j.mail.example.com</li>	<li>_dmarc.j.mail.example.com</li>
	<li>_dmarc.mail.example.com</li>	<li>_dmarc.mail.example.com</li>
	<li>_dmarc.example.com</li>	<li>_dmarc.example.com</li>
	<li>_dmarc.com</li>	<li>_dmarc.com</li>
	</ul>	</ul>

	<section anchor="dmarc-policy-discovery"><name>DMARC Policy Discovery</name>	<section anchor="dmarc-policy-discovery"><name>DMARC Policy Discovery</name>
	<t>The DMARC Policy Record to be applied to an email message will be the record found at any	<t>The DMARC Policy Record to be applied to an email message will be the record found at any
	of the following locations, listed from highest preference to lowest:</t>	of the following locations, listed from highest preference to lowest:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>The Author Domain</li>	<li>The Author Domain</li>
	<li>The Organizational Domain of the Author Domain</li>	<li>The Organizational Domain of the Author Domain</li>
	<li>The Public Suffix Domain of the Author Domain</li>	<li>The Public Suffix Domain of the Author Domain</li>
	</ul>	</ul>

	<t>Policy discovery starts first with a query for a valid DMARC Policy Record at	<t>Policy discovery first starts with a query for a valid DMARC Policy Record at
	the	the
	name created by prepending the label "_dmarc" to the Author Domain of	name created by prepending the label "_dmarc" to the Author Domain of the
	the
	message being evaluated. If a valid DMARC Policy Record is found there, then thi s is the	message being evaluated. If a valid DMARC Policy Record is found there, then thi s is the
	DMARC Policy Record to be applied to the message; however, this does not necessa rily mean	DMARC Policy Record to be applied to the message; however, this does not necessa rily mean
	that the Author Domain is the Organizational Domain to be used in Identifier	that the Author Domain is the Organizational Domain to be used in Identifier
	Alignment checks. Whether this is also the Organizational Domain is dependent	Alignment checks. Whether this is also the Organizational Domain is dependent

	on the value of the "psd" tag, if present, or some conditions describe	on the value of the "psd" tag, if present, or some conditions described in
	d in	<xref target="identifier-alignment-evaluation"/>.</t>
	<xref target="identifier-alignment-evaluation"></xref>.</t>
	<t>If no valid DMARC Policy Record is found by the first query, then perform a D NS	<t>If no valid DMARC Policy Record is found by the first query, then perform a D NS
	Tree Walk to find the Author Domain's Organizational Domain or its Public	Tree Walk to find the Author Domain's Organizational Domain or its Public
	Suffix Domain. The starting point for this DNS Tree Walk is determined as	Suffix Domain. The starting point for this DNS Tree Walk is determined as
	follows:</t>	follows:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>If the Author Domain has eight or fewer labels, the starting point will be	<li>If the Author Domain has eight or fewer labels, the starting point will be
	the immediate parent domain of the Author Domain.</li>	the immediate parent domain of the Author Domain.</li>
	<li>Otherwise, the starting point will be the name produced by shortening the Au thor	<li>Otherwise, the starting point will be the name produced by shortening the Au thor

	Domain as described starting in step 3 of <xref target="dns-tree-walk"></xref>.< /li>	Domain as described starting in step 3 of <xref target="dns-tree-walk"/>.</li>
	</ul>	</ul>
	<t>If the DMARC Policy Record to be applied is that of the Author Domain, then t he	<t>If the DMARC Policy Record to be applied is that of the Author Domain, then t he

	Domain Owner Assessment Policy is taken from the "p" tag of the record .</t>	Domain Owner Assessment Policy is taken from the "p" tag of the record.</t>
	<t>If the DMARC Policy Record to be applied is that of either the Organizational Domain or the	<t>If the DMARC Policy Record to be applied is that of either the Organizational Domain or the
	Public Suffix Domain and the Author Domain is a subdomain of that domain, then t he Domain	Public Suffix Domain and the Author Domain is a subdomain of that domain, then t he Domain

	Owner Assessment Policy is taken from the "sp" tag (if any) if the Aut	Owner Assessment Policy is taken from the "sp" tag (if any) if the Author Domain
	hor Domain exists,	exists
	or the "np" tag (if any) if the Author Domain does not exist. In the a	or the "np" tag (if any) if the Author Domain does not exist. In the absence of
	bsence of	applicable "sp" or "np" tags, the "p" tag policy is used for subdomains.</t>
	applicable "sp" or "np" tags, the "p" tag policy i	<t>If a retrieved DMARC Policy Record does not contain a valid "p" tag, or conta
	s used for subdomains.</t>	ins an "sp" or
	<t>If a retrieved DMARC Policy Record does not contain a valid "p" tag	"np" tag that is not valid, then:</t>
	, or contains an "sp" or
	"np" tag that is not valid, then:</t>

	<ul>	<ul>

	<li><t>If a "rua" tag is present and contains at least one syntactical	<li><t>If a "rua" tag is present and contains at least one syntactically valid r
	ly valid reporting	eporting
	URI, the Mail Receiver <bcp14>MUST</bcp14> act as if a record containing "p	URI, the Mail Receiver <bcp14>MUST</bcp14> act as if a record containing "p=none
	=none" was	" was
	retrieved and continue processing;</t>	retrieved and continue processing.</t>
	</li>	</li>
	<li><t>Otherwise, the Mail Receiver applies no DMARC processing to this message. </t>	<li><t>Otherwise, the Mail Receiver applies no DMARC processing to this message. </t>
	</li>	</li>
	</ul>	</ul>
	<t>If the set produced by the DNS Tree Walk contains no DMARC Policy Record (i.e .,	<t>If the set produced by the DNS Tree Walk contains no DMARC Policy Record (i.e .,
	any indication that there is no such record as opposed to a transient DNS error) ,	any indication that there is no such record as opposed to a transient DNS error) ,
	Mail Receivers <bcp14>MUST NOT</bcp14> apply the DMARC mechanism to the message. </t>	Mail Receivers <bcp14>MUST NOT</bcp14> apply the DMARC mechanism to the message. </t>
	<t>Handling of DNS errors when querying for the DMARC Policy Record is	<t>Handling of DNS errors when querying for the DMARC Policy Record is
	left to the discretion of the Mail Receiver. For example, to ensure	left to the discretion of the Mail Receiver. For example, to ensure
	minimal disruption of mail flow, transient errors could result in	minimal disruption of mail flow, transient errors could result in

	delivery of the message ("fail open"), or they could result in the	delivery of the message ("fail open"), or they could result in the
	message being temporarily rejected (i.e., an SMTP 4yx reply), which	message being temporarily rejected (i.e., an SMTP 4yx reply), which
	invites the sending MTA to try again after the condition has possibly	invites the sending MTA to try again after the condition has possibly

	cleared, allowing a definite DMARC conclusion to be reached ("fail	cleared, allowing a definite DMARC conclusion to be reached ("fail
	closed").</t>	closed").</t>
	<t>Note: PSD policy is not used for Organizational Domains that have	<t>Note: PSD policy is not used for Organizational Domains that have
	published a DMARC Policy Record. Specifically, this is not a mechanism to	published a DMARC Policy Record. Specifically, this is not a mechanism to
	provide feedback addresses (rua/ruf) when an Organizational Domain has	provide feedback addresses (rua/ruf) when an Organizational Domain has
	declined to do so.</t>	declined to do so.</t>
	</section>	</section>

	<section anchor="identifier-alignment-evaluation"><name>Identifier Alignment Eva luation</name>	<section anchor="identifier-alignment-evaluation"><name>Identifier Alignment Eva luation</name>
	<t>It may be necessary to perform multiple DNS Tree Walks to determine if an	<t>It may be necessary to perform multiple DNS Tree Walks to determine if an
	Authenticated Identifier and an Author Domain are in alignment, meaning	Authenticated Identifier and an Author Domain are in alignment, meaning
	that they have either the same Organizational Domain (relaxed alignment) or	that they have either the same Organizational Domain (relaxed alignment) or
	that they're identical (strict alignment). DNS Tree Walks done to discover an	that they're identical (strict alignment). DNS Tree Walks done to discover an
	Organizational Domain for use in Identifier Alignment Evaluation might start	Organizational Domain for use in Identifier Alignment Evaluation might start
	at any of the following locations:</t>	at any of the following locations:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>The Author Domain of the message being evaluated.</li>	<li>The Author Domain of the message being evaluated.</li>

	<li>The SPF-Authenticated Identifier if there is an SPF pass result for the mess age	<li>The SPF-Authenticated Identifier if there is an SPF "pass" result for the me ssage
	being evaluated.</li>	being evaluated.</li>

	<li>Any DKIM-Authenticated Identifier if one or more DKIM pass results exist for	<li>Any DKIM-Authenticated Identifier if one or more DKIM "pass" results exist f or
	the message being evaluated.</li>	the message being evaluated.</li>
	</ul>	</ul>
	<t>Note: There is no need to perform Identifier Alignment Evaluations under any of	<t>Note: There is no need to perform Identifier Alignment Evaluations under any of
	the following conditions:</t>	the following conditions:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>The Author Domain and the Authenticated Identifier(s) are all the	<li>The Author Domain and the Authenticated Identifier(s) are all the
	same domain, and there is a DMARC Policy Record published for that domain.	same domain, and there is a DMARC Policy Record published for that domain.
	In this case, this common domain is treated as the Organizational Domain.	In this case, this common domain is treated as the Organizational Domain.

	For example, if the common domain in question is "mail.example.com", a	For example, if the common domain in question is "mail.example.com", and
	nd	there is a valid DMARC Policy Record published at "_dmarc.mail.example.com",
	there is a valid DMARC Policy Record published at "_dmarc.mail.example.com&	then "mail.example.com" is the Organizational Domain.</li>
	quot;,
	then "mail.example.com" is the Organizational Domain.</li>
	<li>No applicable DMARC Policy Record is discovered for the Author Domain. In	<li>No applicable DMARC Policy Record is discovered for the Author Domain. In
	this case, the DMARC mechanism does not apply to the message in question.</li>	this case, the DMARC mechanism does not apply to the message in question.</li>
	<li>The DMARC Policy Record for the Author Domain indicates strict alignment. In	<li>The DMARC Policy Record for the Author Domain indicates strict alignment. In
	this case, a simple string comparison of the Author Domain and the Authenticated	this case, a simple string comparison of the Author Domain and the Authenticated
	Identifier(s) is all that is required.</li>	Identifier(s) is all that is required.</li>
	</ul>	</ul>
	<t>To discover the Organizational Domain for a domain, perform the DNS Tree Walk	<t>To discover the Organizational Domain for a domain, perform the DNS Tree Walk

	described in <xref target="dns-tree-walk"></xref> as needed for any of the domai ns in question.</t>	described in <xref target="dns-tree-walk"/> as needed for any of the domains in question.</t>
	<t>For each Tree Walk that retrieved valid DMARC Policy Records, select the Orga nizational	<t>For each Tree Walk that retrieved valid DMARC Policy Records, select the Orga nizational
	Domain from the domains for which valid DMARC Policy Records were retrieved from the longest	Domain from the domains for which valid DMARC Policy Records were retrieved from the longest
	to the shortest:</t>	to the shortest:</t>

	<ol>	<ol>

	<li><t>If a valid DMARC Policy Record contains the "psd" tag set to &q uot;n" ("psd=n"), this is the	<li><t>If a valid DMARC Policy Record contains the "psd" tag set to "n" ("psd=n" ), this is the
	Organizational Domain, and the selection process is complete.</t>	Organizational Domain, and the selection process is complete.</t>
	</li>	</li>

	<li><t>If a valid DMARC Policy Record, other than the one for the domain where t	<li><t>If a valid DMARC Policy Record, other than the one for the domain where t
	he tree	he Tree
	walk started, contains the "psd" tag set to "y" ("psd=y	Walk started, contains the "psd" tag set to "y" ("psd=y"), the Organizational
	"), the Organizational
	Domain is the domain one label below this one in the DNS hierarchy, and the	Domain is the domain one label below this one in the DNS hierarchy, and the

	selection process is complete. For example, if in the course of a tree walk a DM	selection process is complete. For example, if in the course of a Tree Walk a DM
	ARC	ARC
	Policy Record is queried for at first "_dmarc.mail.example.com" and th	Policy Record is queried for at first "_dmarc.mail.example.com" and then "_dmarc
	en "_dmarc.example.com",	.example.com",
	and a valid DMARC Policy Record containing the "psd" tag set to "	and a valid DMARC Policy Record containing the "psd" tag set to "y" is found at
	y" is found at	"_dmarc.example.com", then "mail.example.com" is the domain one label below "exa
	"_dmarc.example.com", then "mail.example.com" is the domain	mple.com"
	one label below "example.com"
	in the DNS hierarchy and is thus the Organizational Domain.</t>	in the DNS hierarchy and is thus the Organizational Domain.</t>
	</li>	</li>
	<li><t>Otherwise, select the DMARC Policy Record found at the name with the fewe st number	<li><t>Otherwise, select the DMARC Policy Record found at the name with the fewe st number
	of labels. This is the Organizational Domain and the selection process is compl ete.</t>	of labels. This is the Organizational Domain and the selection process is compl ete.</t>
	</li>	</li>
	</ol>	</ol>
	<t>If this process does not determine the Organizational Domain, then the initia l target	<t>If this process does not determine the Organizational Domain, then the initia l target
	domain is the Organizational Domain.</t>	domain is the Organizational Domain.</t>

	<t>For example, given the starting domain "a.mail.example.com", a sear ch	<t>For example, given the starting domain "a.mail.example.com", a search
	for the Organizational Domain would require a series of DNS queries for DMARC Po licy	for the Organizational Domain would require a series of DNS queries for DMARC Po licy

	Records starting with "_dmarc.a.mail.example.com" and finishing with &	Records starting with "_dmarc.a.mail.example.com" and finishing with "_dmarc.com
	quot;_dmarc.com".	".
	If there are DMARC Policy Records published at "_dmarc.mail.example.com&quo	If there are DMARC Policy Records published at "_dmarc.mail.example.com" and
	t; and	"_dmarc.example.com", but not at "_dmarc.a.mail.example.com" or
	"_dmarc.example.com", but not at "_dmarc.a.mail.example.com"	"_dmarc.com", then the Organizational Domain for this domain would be
	or	"example.com".</t>
	"_dmarc.com", then the Organizational Domain for this domain would be	<t>As another example, given the starting domain "a.mail.example.com", if a
	"example.com".</t>	search for the Organizational Domain yields a DMARC Policy Record at "_dmarc.mai
	<t>As another example, given the starting domain "a.mail.example.com",	l.example.com"
	if a	with the "psd" tag set to "n", then the Organizational Domain for this domain wo
	search for the Organizational Domain yields a DMARC Policy Record at "_dmar	uld
	c.mail.example.com"	be "mail.example.com".</t>
	with the "psd" tag set to "n", then the Organizational Domai	<t>As a last example, given the starting domain "a.mail.example.com", if a
	n for this domain would	search for the Organizational Domain only yields a DMARC Policy Record at "_dmar
	be "mail.example.com".</t>	c.com"
	<t>As a last example, given the starting domain "a.mail.example.com",	and that record contains the tag "psd=y", then the Organizational Domain for
	if a	this domain would be "example.com".</t>
	search for the Organizational Domain only yields a DMARC Policy Record at "
	_dmarc.com"
	and that record contains the tag "psd=y", then the Organizational Doma
	in for
	this domain would be "example.com".</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="dmarc-participation"><name>DMARC Participation</name>	<section anchor="dmarc-participation"><name>DMARC Participation</name>
	<t>This section describes the actions for participating in DMARC for each of	<t>This section describes the actions for participating in DMARC for each of

	three unique entities - Domain Owners, PSOs, and Mail Receivers.</t>	three unique entities -- Domain Owners, PSOs, and Mail Receivers.</t>

	<section anchor="domain-owner-actions"><name>Domain Owner Actions</name>	<section anchor="domain-owner-actions"><name>Domain Owner Actions</name>

	<t>A <eref target="#domain-owner">Domain Owner</eref> wishing to fully participa
	te in DMARC will	<!--[rfced] Please consider if this text should be a list for easier readability
	publish a <eref target="#dmarc-policy-record">DMARC Policy Record</eref> to cove	.
	r each <eref target="#author-domain">Author Domain</eref> and corresponding <ere
	f target="#organizational-domain">Organizational Domain</eref>	Current:
	to which DMARC validation should apply, send email that produces at least one, a	A Domain Owner (Section 3.2.7) wishing to fully participate in DMARC
	nd	will publish a DMARC Policy Record (Section 3.2.6) to cover each
	preferably two, <eref target="#authenticated-identifiers">Authenticated Identifi	Author Domain (Section 3.2.2) and corresponding Organizational Domain
	ers</eref> that align	(Section 3.2.14) to which DMARC validation should apply; will send
	with the Author Domain, will receive and monitor the content of DMARC aggregate	email that produces at least one - preferably two - Authenticated
	reports, and will correct any authentication shortcomings in mail making authori	Identifiers (Section 3.2.1) that align with the Author Domain; will
	zed	receive and monitor the content of DMARC aggregate reports; and will
		correct any authentication shortcomings in mail making authorized use
		of its domains.

		Perhaps:
		A Domain Owner (Section 3.2.7) wishing to fully participate in DMARC will:

		* Publish a DMARC Policy Record (Section 3.2.6) to cover each
		Author Domain (Section 3.2.2) and corresponding Organizational
		Domain (Section 3.2.14) to which DMARC validation should apply;

		* Send email that produces at least one - preferably two - Authenticated
		Identifiers (Section 3.2.1) that align with the Author Domain;

		* Receive and monitor the content of DMARC aggregate reports; and

		* Correct authentication shortcomings in mail making authorized use
		of its domains.
		-->

		<t>A <xref target="domain-owner">Domain Owner</xref> wishing to fully participat
		e in DMARC will
		publish a <xref target="dmarc-policy-record">DMARC Policy Record</xref> to cover
		each <xref target="author-domain">Author Domain</xref> and corresponding <xref
		target="organizational-domain">Organizational Domain</xref>
		to which DMARC validation should apply; will send email that produces at least o
		ne --
		preferably two -- <xref target="authenticated-identifiers">Authenticated Identif
		iers</xref> that align
		with the Author Domain; will receive and monitor the content of DMARC aggregate
		reports; and will correct any authentication shortcomings in mail making authori
		zed
	use of its domains.</t>	use of its domains.</t>
	<t>The following sections describe how to achieve this.</t>	<t>The following sections describe how to achieve this.</t>

	<section anchor="publish-an-spf-record-for-an-aligned-domain"><name>Publish an S PF Record for an Aligned Domain</name>	<section anchor="publish-an-spf-record-for-an-aligned-domain"><name>Publish an S PF Record for an Aligned Domain</name>
	<t>To configure SPF for DMARC, the Domain Owner <bcp14>MUST</bcp14> send mail th at has	<t>To configure SPF for DMARC, the Domain Owner <bcp14>MUST</bcp14> send mail th at has

	an RFC5321.MailFrom domain that will produce an <eref target="#spf-identifiers">	an RFC5321.MailFrom domain that will produce an <xref target="spf-identifiers">S
	SPF-Authenticated	PF-Authenticated
	Identifier</eref> that has <eref target="#identifier-alignment-explained">Identi	Identifier</xref> that has <xref target="identifier-alignment-explained">Identif
	fier Alignment</eref>	ier Alignment</xref>
	with the Author Domain.</t>	with the Author Domain.</t>
	</section>	</section>

	<section anchor="configure-sending-system-for-dkim-signing-using-an-aligned-doma in"><name>Configure Sending System for DKIM Signing Using an Aligned Domain</nam e>	<section anchor="configure-sending-system-for-dkim-signing-using-an-aligned-doma in"><name>Configure Sending System for DKIM Signing Using an Aligned Domain</nam e>
	<t>To configure DKIM for DMARC, the Domain Owner <bcp14>MUST</bcp14> send mail t hat	<t>To configure DKIM for DMARC, the Domain Owner <bcp14>MUST</bcp14> send mail t hat

	has a <eref target="#dkim-signing-domain">DKIM Signing Domain</eref> that will p	has a <xref target="dkim-signing-domain">DKIM Signing Domain</xref> that will pr
	roduce a	oduce a
	<eref target="#dkim-identifiers">DKIM-Authenticated Identifier</eref> that	<xref target="dkim-identifiers">DKIM-Authenticated Identifier</xref> that
	has <eref target="#identifier-alignment-explained">Identifier Alignment</eref> w	has <xref target="identifier-alignment-explained">Identifier Alignment</xref> wi
	ith the Author Domain.</t>	th the Author Domain.</t>
	</section>	</section>

	<section anchor="set-up-a-mailbox-to-receive-aggregate-reports"><name>Set Up a M ailbox to Receive Aggregate Reports</name>	<section anchor="set-up-a-mailbox-to-receive-aggregate-reports"><name>Set Up a M ailbox to Receive Aggregate Reports</name>
	<t>Proper consumption and analysis of DMARC aggregate reports are essential	<t>Proper consumption and analysis of DMARC aggregate reports are essential
	to any successful DMARC deployment for a Domain Owner. DMARC aggregate	to any successful DMARC deployment for a Domain Owner. DMARC aggregate

	reports, which are defined in <xref target="I-D.ietf-dmarc-aggregate-reporting"> </xref>,	reports, which are defined in <xref target="RFC9990"/>,
	contain valuable data for the Domain Owner, showing sources of mail	contain valuable data for the Domain Owner, showing sources of mail
	using the Author Domain.</t>	using the Author Domain.</t>
	</section>	</section>

	<section anchor="publish-a-dmarc-policy-record-for-the-author-domain-and-organiz ational-domain"><name>Publish a DMARC Policy Record for the Author Domain and Or ganizational Domain</name>	<section anchor="publish-a-dmarc-policy-record-for-the-author-domain-and-organiz ational-domain"><name>Publish a DMARC Policy Record for the Author Domain and Or ganizational Domain</name>
	<t>Once SPF, DKIM, and the aggregate reports mailbox are all in place,	<t>Once SPF, DKIM, and the aggregate reports mailbox are all in place,
	it's time to publish a DMARC Policy Record. For best results, Domain Owners	it's time to publish a DMARC Policy Record. For best results, Domain Owners

	usually start with "p=none", (see <xref target="collect-and-analyze"><	usually start with "p=none" (see <xref target="collect-and-analyze"/>)
	/xref>)	with the "rua" tag containing a URI that references the mailbox created
	with the "rua" tag containing a URI that references the mailbox create
	d
	in the previous step. This is commonly referred to as putting the Author	in the previous step. This is commonly referred to as putting the Author

	Domain into <eref target="#monitoring-mode">Monitoring Mode</eref>. If the Organ izational Domain	Domain into <xref target="monitoring-mode">Monitoring Mode</xref>. If the Organi zational Domain
	is different from the Author Domain, a record also needs to be published for the	is different from the Author Domain, a record also needs to be published for the
	Organizational Domain.</t>	Organizational Domain.</t>
	</section>	</section>

	<section anchor="collect-and-analyze"><name>Collect and Analyze Reports</name>	<section anchor="collect-and-analyze"><name>Collect and Analyze Reports</name>

	<t>The reason for starting at "p=none" is to ensure that nothing's bee n	<t>The reason for starting at "p=none" is to ensure that nothing's been
	missed in the initial SPF and DKIM deployments. In all but the most	missed in the initial SPF and DKIM deployments. In all but the most
	trivial setups, a Domain Owner can overlook a server here or be unaware	trivial setups, a Domain Owner can overlook a server here or be unaware

	of a third party sending agreement there. Starting at "p=none", there fore,	of a third-party sending agreement there. Starting at "p=none", therefore,
	takes advantage of DMARC's aggregate reporting function, with the Domain	takes advantage of DMARC's aggregate reporting function, with the Domain
	Owner using the reports to audit its own mail streams' authentication	Owner using the reports to audit its own mail streams' authentication
	configurations.</t>	configurations.</t>
	<t>While it is possible for a human to read aggregate reports, they are	<t>While it is possible for a human to read aggregate reports, they are
	formatted in such a way that it is recommended that they be machine-parsed,	formatted in such a way that it is recommended that they be machine-parsed,
	so setting up a mailbox involves more than just the physical creation	so setting up a mailbox involves more than just the physical creation
	of that mailbox. Many third-party services exist that will process DMARC	of that mailbox. Many third-party services exist that will process DMARC

	aggregate reports or the Domain Owner can create its own set of tools.	aggregate reports, or the Domain Owner can create its own set of tools.
	No matter which method is chosen, the ability to consume these reports and	No matter which method is chosen, the ability to consume these reports and
	parse the data contained in them will go a long way to ensuring a	parse the data contained in them will go a long way to ensuring a
	successful deployment.</t>	successful deployment.</t>
	</section>	</section>

	<section anchor="remediate-unaligned-or-unauthenticated-mail-streams"><name>Reme diate Unaligned or Unauthenticated Mail Streams</name>	<section anchor="remediate-unaligned-or-unauthenticated-mail-streams"><name>Reme diate Unaligned or Unauthenticated Mail Streams</name>
	<t>DMARC aggregate reports can reveal to the Domain Owner mail streams using the	<t>DMARC aggregate reports can reveal to the Domain Owner mail streams using the
	Author Domain but not passing DMARC validation checks. These mail streams may	Author Domain but not passing DMARC validation checks. These mail streams may
	be a combination of illegitimate uses of the domain, such as spoofing or other	be a combination of illegitimate uses of the domain, such as spoofing or other
	attempted abuse, and legitimate uses, as in the case of a mail stream created	attempted abuse, and legitimate uses, as in the case of a mail stream created

	by an agent of the Domain Owner but one which is not passing is due to Authentic ated	by an agent of the Domain Owner but one that is not passing due to Authenticated
	Identifiers being unaligned or missing entirely. For such legitimate uses, these	Identifiers being unaligned or missing entirely. For such legitimate uses, these
	shortcomings <bcp14>MUST</bcp14> be addressed prior to any attempt by the Domain Owner to	shortcomings <bcp14>MUST</bcp14> be addressed prior to any attempt by the Domain Owner to

	publish a <eref target="#domain-owner-policy">Domain Owner Assessment Policy</er	publish a <xref target="domain-owner-policy">Domain Owner Assessment Policy</xre
	ef> of	f> of
	<eref target="#enforcement">Enforcement</eref> for the Author Domain.</t>	<xref target="enforcement">Enforcement</xref> for the Author Domain.</t>
	</section>	</section>

	<section anchor="decide-whether-to-update-domain-owner-assessment-policy-to-enfo rcement"><name>Decide Whether to Update Domain Owner Assessment Policy to Enforc ement</name>	<section anchor="decide-whether-to-update-domain-owner-assessment-policy-to-enfo rcement"><name>Decide Whether to Update Domain Owner Assessment Policy to Enforc ement</name>
	<t>Once the Domain Owner is satisfied that it is properly authenticating	<t>Once the Domain Owner is satisfied that it is properly authenticating
	all of its mail, then it is time to decide if it is appropriate to	all of its mail, then it is time to decide if it is appropriate to

	change its Domain Owner Assessment Policy to <eref target="#enforcement">Enforce ment</eref>.	change its Domain Owner Assessment Policy to <xref target="enforcement">Enforcem ent</xref>.
	Depending on its cadence for sending mail, it may take many months	Depending on its cadence for sending mail, it may take many months
	of consuming DMARC aggregate reports before a Domain Owner reaches	of consuming DMARC aggregate reports before a Domain Owner reaches
	the point where it is sure that it is properly authenticating all	the point where it is sure that it is properly authenticating all

	of its mail, and the decision on which "p" value to use will depend	of its mail, and the decision on which "p" value to use will depend
	on its needs.</t>	on its needs.</t>

	<t>In making this decision it is important to understand the	<t>In making this decision, it is important to understand the
	interoperability issues involved and problems that can result for	interoperability issues involved and problems that can result for
	mailing lists and for delivery of legitimate mail. Those	mailing lists and for delivery of legitimate mail. Those

	issues are discussed in detail in <xref target="interoperability-considerations" ></xref></t>	issues are discussed in detail in <xref target="interoperability-considerations" /></t>
	</section>	</section>

	<section anchor="a-note-on-large-complex-organizations-and-decentralized-dns-man agement"><name>A Note on Large, Complex Organizations and Decentralized DNS Mana gement</name>	<section anchor="a-note-on-large-complex-organizations-and-decentralized-dns-man agement"><name>A Note on Large, Complex Organizations and Decentralized DNS Mana gement</name>
	<t>Large, complex organizations frequently adopt a decentralized model for	<t>Large, complex organizations frequently adopt a decentralized model for

	DNS management, whereby management of a subtree of the name space is delegated	DNS management, whereby management of a subtree of the namespace is delegated
	to a local department by the central IT organization. In such situations, the	to a local department by the central IT organization. In such situations, the

	"psd" tag makes it possible for those local departments to declare any arbitrary	"psd" tag makes it possible for those local departments to declare any arbitrary
	node in their subtree as an Organizational Domain. This would be accomplished by	node in their subtree as an Organizational Domain. This would be accomplished by

	publishing a DMARC Policy Record at that node with the "psd" tag set t o "n". The	publishing a DMARC Policy Record at that node with the "psd" tag set to "n". The
	reasons that departments might declare their own Organizational Domains include a	reasons that departments might declare their own Organizational Domains include a
	desire to have different policy settings or reporting URIs than the DMARC Policy Record	desire to have different policy settings or reporting URIs than the DMARC Policy Record
	published for the apex domain.</t>	published for the apex domain.</t>
	<t>Such configurations would work in theory, and they might involve domain names with	<t>Such configurations would work in theory, and they might involve domain names with
	many labels, reflecting the structure of the organization, for example:</t>	many labels, reflecting the structure of the organization, for example:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Apex domain (DMARC Policy Record published here): example.com</li>	<li>Apex domain (DMARC Policy Record published here): example.com</li>

	<li>Zone cut domain (DMARC Policy Record with "psd=n" published here): b.c.d.e.f.g.example.com</li>	<li>Zone cut domain (DMARC Policy Record with "psd=n" published here): b.c.d.e.f .g.example.com</li>
	<li>Author Domain: mail.a.b.c.d.e.f.g.example.com</li>	<li>Author Domain: mail.a.b.c.d.e.f.g.example.com</li>
	</ul>	</ul>
	<t>However, Domain Owners should be aware that due to the anti-abuse protections	<t>However, Domain Owners should be aware that due to the anti-abuse protections

	built into the <eref target="#dns-tree-walk">DNS Tree Walk</eref>, the DMARC Pol icy Record published	built into the <xref target="dns-tree-walk">DNS Tree Walk</xref>, the DMARC Poli cy Record published
	at the zone cut domain in this example will never be discovered. A Mail Receiver	at the zone cut domain in this example will never be discovered. A Mail Receiver
	performing a Tree Walk would only perform queries for these names:</t>	performing a Tree Walk would only perform queries for these names:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>_dmarc.mail.a.b.c.d.e.f.g.example.com</li>	<li>_dmarc.mail.a.b.c.d.e.f.g.example.com</li>
	<li>_dmarc.c.d.e.f.g.example.com</li>	<li>_dmarc.c.d.e.f.g.example.com</li>
	<li>_dmarc.d.e.f.g.example.com</li>	<li>_dmarc.d.e.f.g.example.com</li>
	<li>_dmarc.e.f.g.example.com</li>	<li>_dmarc.e.f.g.example.com</li>
	<li>_dmarc.f.g.example.com</li>	<li>_dmarc.f.g.example.com</li>
	<li>_dmarc.g.example.com</li>	<li>_dmarc.g.example.com</li>
	<li>_dmarc.example.com</li>	<li>_dmarc.example.com</li>
	<li>_dmarc.com</li>	<li>_dmarc.com</li>
	</ul>	</ul>
	<t>To avoid this circumstance, Domain Owners wishing to have a specific DMARC Po licy	<t>To avoid this circumstance, Domain Owners wishing to have a specific DMARC Po licy

	Record applied to a given <eref target="#author-domain">Author Domain</eref> lon ger than eight labels	Record applied to a given <xref target="author-domain">Author Domain</xref> long er than eight labels
	<bcp14>MUST</bcp14> publish a DMARC Policy Record at that domain's location in t he DNS namespace,	<bcp14>MUST</bcp14> publish a DMARC Policy Record at that domain's location in t he DNS namespace,
	as such records are always queried by Mail Receivers that participate in DMARC b efore	as such records are always queried by Mail Receivers that participate in DMARC b efore
	the Tree Walk begins. In the above example, this would mean publishing a DMARC Policy	the Tree Walk begins. In the above example, this would mean publishing a DMARC Policy

	Record at the name "_dmarc.mail.a.b.c.d.e.f.g.example.com.".</t>	Record at the name "_dmarc.mail.a.b.c.d.e.f.g.example.com.".</t>
	</section>	</section>
	</section>	</section>

	<section anchor="pso-actions"><name>PSO Actions</name>	<section anchor="pso-actions"><name>PSO Actions</name>

	<t>In addition to the DMARC Domain Owner actions, if a <eref target="#public-suf	<t>In addition to the DMARC Domain Owner actions, if a <xref target="public-suff
	fix-operator">PSO</eref>	ix-operator">PSO</xref>
	publishes a DMARC Policy Record it <bcp14>MUST</bcp14> include the "psd&quo	publishes a DMARC Policy Record, it <bcp14>MUST</bcp14> include the "psd" tag (s
	t; tag (see <xref target="policy-record-format"></xref>)	ee <xref target="policy-record-format"/>)
	with a value of "y" ("psd=y").</t>	with a value of "y" ("psd=y").</t>
	</section>	</section>

	<section anchor="mail-receiver-actions"><name>Mail Receiver Actions</name>	<section anchor="mail-receiver-actions"><name>Mail Receiver Actions</name>

	<t><eref target="#mail-receiver">Mail Receivers</eref> wishing to fully particip	<t><xref target="mail-receiver">Mail Receivers</xref> wishing to fully participa
	ate in DMARC	te in DMARC
	will apply the DMARC mechanism to inbound email messages when a <eref target="#d	will apply the DMARC mechanism to inbound email messages when a <xref target="dm
	marc-policy-record">DMARC	arc-policy-record">DMARC
	Policy Record</eref> exists that applies to the <eref target="#author-domain">Au	Policy Record</xref> exists that applies to the <xref target="author-domain">Aut
	thor	hor
	Domain</eref>, and will send aggregate feedback reports to Domain	Domain</xref> and will send aggregate feedback reports to Domain
	Owners that request them. Mail Receivers might also send failure reports	Owners that request them. Mail Receivers might also send failure reports
	to Domain Owners that request them. The following sections describe how	to Domain Owners that request them. The following sections describe how
	to achieve this.</t>	to achieve this.</t>
	<t>The steps for applying the DMARC mechanism to an email message can take	<t>The steps for applying the DMARC mechanism to an email message can take

	place during the SMTP transaction, and should do so if the Mail Receiver	place during the SMTP transaction and should do so if the Mail Receiver
	plans to honor <eref target="#domain-owner-policy">Domain Owner Assessment Polic	plans to honor <xref target="domain-owner-policy">Domain Owner Assessment Polici
	ies</eref> that	es</xref> that
	are at the <eref target="#enforcement">Enforcement</eref> state.</t>	are at the <xref target="enforcement">Enforcement</xref> state.</t>
	<t>Many Mail Receivers perform one or both of the underlying <eref target="#auth	<t>Many Mail Receivers perform one or both of the underlying <xref target="authe
	entication-mechanisms">Authentication	ntication-mechanisms">Authentication
	Mechanisms</eref> on inbound messages even in cases	Mechanisms</xref> on inbound messages even in cases
	where no DMARC Policy Record exists for the Author Domain of a given message,	where no DMARC Policy Record exists for the Author Domain of a given message,
	or where the Mail Receiver is not participating in DMARC. Nothing in this	or where the Mail Receiver is not participating in DMARC. Nothing in this

	section is intended to imply that the underlying Authentication Mechanisms	section is intended to imply that the underlying authentication mechanisms
	should only be performed by Mail Receivers participating in DMARC.</t>	should only be performed by Mail Receivers participating in DMARC.</t>

	<section anchor="extract-author-domain"><name>Extract Author Domain</name>	<section anchor="extract-author-domain"><name>Extract Author Domain</name>
	<t>Once the email message has been transmitted to the Mail Receiver, the Mail	<t>Once the email message has been transmitted to the Mail Receiver, the Mail
	Receiver extracts the domain in the RFC5322.From header field as the Author	Receiver extracts the domain in the RFC5322.From header field as the Author
	Domain. If the domain is a U-label, the domain <bcp14>MUST</bcp14> be converted to an	Domain. If the domain is a U-label, the domain <bcp14>MUST</bcp14> be converted to an

	A-label, as described in Section 2.3 of <xref target="RFC5890"></xref>, for furt her processing.</t>	A-label, as described in <xref section="2.3" target="RFC5890"/>, for further pro cessing.</t>
	<t>If zero or more than one domain is extracted from the RFC5322.From header	<t>If zero or more than one domain is extracted from the RFC5322.From header
	field, then DMARC validation is not possible and the process terminates.	field, then DMARC validation is not possible and the process terminates.
	In the case where more than one domain is retrieved, the Mail Receiver	In the case where more than one domain is retrieved, the Mail Receiver
	<bcp14>MAY</bcp14> choose to go forward with DMARC validation anyway. See	<bcp14>MAY</bcp14> choose to go forward with DMARC validation anyway. See

	<xref target="denial-of-dmarc-attacks"></xref> for further discussion.</t>	<xref target="denial-of-dmarc-attacks"/> for further discussion.</t>
	</section>	</section>


	<section anchor="determine-mechanism-applies"><name>Determine If The DMARC Mecha nism Applies</name>	<section anchor="determine-mechanism-applies"><name>Determine If the DMARC Mecha nism Applies</name>
	<t>If precisely one Author Domain exists for the message, then perform the	<t>If precisely one Author Domain exists for the message, then perform the

	step described in <eref target="#dmarc-policy-discovery">DMARC Policy Discovery<	step described in <xref target="dmarc-policy-discovery">"DMARC Policy Discovery"
	/eref> to determine	</xref> to determine
	if the DMARC mechanism applies. If a <eref target="#dmarc-policy-record">DMARC P	if the DMARC mechanism applies. If a <xref target="dmarc-policy-record">DMARC Po
	olicy Record</eref> is not	licy Record</xref> is not
	discovered during this step, then the DMARC mechanism does not apply and	discovered during this step, then the DMARC mechanism does not apply and
	DMARC validation terminates for the message.</t>	DMARC validation terminates for the message.</t>
	</section>	</section>

	<section anchor="determine-authenticated-identifiers"><name>Determine If Authent icated Identifiers Exist</name>	<section anchor="determine-authenticated-identifiers"><name>Determine If Authent icated Identifiers Exist</name>

	<t>For each Authentication Mechanism underlying DMARC, perform the required	<t>For each authentication mechanism underlying DMARC, perform the required
	check to determine if an <eref target="#authenticated-identifier">Authenticated	check to determine if an <xref target="authenticated-identifiers">Authenticated
	Identifier</eref>	Identifier</xref>
	exists for the message if such check has not already been performed. Results fro m	exists for the message if such check has not already been performed. Results fro m
	each check must be preserved for later use as follows:</t>	each check must be preserved for later use as follows:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>For SPF, the preserved results <bcp14>MUST</bcp14> include "pass"	<li>For SPF, the preserved results <bcp14>MUST</bcp14> include "pass" or "fail".
	or "fail", and if "fail", <bcp14>SHOULD</bcp14>	If the result is "fail", it <bcp14>SHOULD</bcp14>
	include information about the reasons for failure if available. The results <bcp	include information about the reasons for failure, if available. The results <bc
	14>MUST</bcp14> further	p14>MUST</bcp14> further
	include the domain name used to complete the SPF check.</li>	include the domain name used to complete the SPF check.</li>
	<li>For DKIM signature validation checks, for each signature checked, the	<li>For DKIM signature validation checks, for each signature checked, the

	results <bcp14>MUST</bcp14> include "pass" or "fail", and if "fail", <bcp14>SHOULD</bcp14> include	results <bcp14>MUST</bcp14> include "pass" or "fail". If the result is "fail", i t <bcp14>SHOULD</bcp14> include
	information about the reasons for failure. The results <bcp14>MUST</bcp14> furth er include	information about the reasons for failure. The results <bcp14>MUST</bcp14> furth er include

	the value of the "d" and "s" tags from each checked DKIM sig nature.</li>	the value of the "d" and "s" tags from each checked DKIM signature.</li>
	</ul>	</ul>
	</section>	</section>

	<section anchor="conduct-alignment-checks"><name>Conduct Identifier Alignment Ch ecks If Necessary</name>	<section anchor="conduct-alignment-checks"><name>Conduct Identifier Alignment Ch ecks If Necessary</name>
	<t>For each Authenticated Identifier found in the message, the Mail Receiver che cks	<t>For each Authenticated Identifier found in the message, the Mail Receiver che cks

	to see if the Authenticated Identifier is <eref target="#identifier-alignment-ev aluation">aligned</eref>	to see if the Authenticated Identifier is <xref target="identifier-alignment-eva luation">aligned</xref>
	with the Author Domain.</t>	with the Author Domain.</t>
	</section>	</section>


	<section anchor="pass-or-fail"><name>Determine DMARC "Pass" or "F ail"</name>	<section anchor="pass-or-fail"><name>Determine DMARC "Pass" or "Fail"</name>
	<t>If one or more of the Authenticated Identifiers align with the Author Domain, the	<t>If one or more of the Authenticated Identifiers align with the Author Domain, the
	message is considered to pass the DMARC mechanism check.</t>	message is considered to pass the DMARC mechanism check.</t>
	<t>If no Authenticated Identifiers exist for the domain, or none of the Authenti cated	<t>If no Authenticated Identifiers exist for the domain, or none of the Authenti cated
	Identifiers align with the Author Domain, the message is considered to fail the	Identifiers align with the Author Domain, the message is considered to fail the
	DMARC mechanism check.</t>	DMARC mechanism check.</t>
	</section>	</section>

	<section anchor="apply-policy"><name>Apply Policy If Appropriate</name>	<section anchor="apply-policy"><name>Apply Policy If Appropriate</name>
	<t>Email messages that fail the DMARC mechanism check are handled in accordance with	<t>Email messages that fail the DMARC mechanism check are handled in accordance with
	the Mail Receiver's local policies. These local policies may take into account t he Domain	the Mail Receiver's local policies. These local policies may take into account t he Domain
	Owner Assessment Policy for the Author Domain at the Mail Receiver's discretion. </t>	Owner Assessment Policy for the Author Domain at the Mail Receiver's discretion. </t>
	<t>If one or more DNS queries required to perform DMARC validation on the messag e	<t>If one or more DNS queries required to perform DMARC validation on the messag e
	do not complete due to temporary or permanent DNS errors, the message cannot be	do not complete due to temporary or permanent DNS errors, the message cannot be
	considered to pass or fail the DMARC mechanism check. In such cases, the Domain	considered to pass or fail the DMARC mechanism check. In such cases, the Domain
	Owner Assessment Policy cannot be applied to the message, and any other handling	Owner Assessment Policy cannot be applied to the message, and any other handling
	decisions for the message are left to the discretion of the Mail Receiver.</t>	decisions for the message are left to the discretion of the Mail Receiver.</t>

	<t>See <xref target="rejecting-messages"></xref> for further discussion of topic s regarding rejecting messages.</t>	<t>See <xref target="rejecting-messages"/> for further discussion of topics rega rding rejecting messages.</t>
	</section>	</section>

	<section anchor="store-results-of-dmarc-processing"><name>Store Results of DMARC Processing</name>	<section anchor="store-results-of-dmarc-processing"><name>Store Results of DMARC Processing</name>
	<t>If the Mail Receiver intends to send aggregate feedback reports and/or failur e reports,	<t>If the Mail Receiver intends to send aggregate feedback reports and/or failur e reports,
	then results obtained from the application of the DMARC mechanism by the Mail Re ceiver	then results obtained from the application of the DMARC mechanism by the Mail Re ceiver
	<bcp14>MUST</bcp14> be preserved for eventual presentation back to the Domain Ow ner in the form	<bcp14>MUST</bcp14> be preserved for eventual presentation back to the Domain Ow ner in the form

	of such reports. <xref target="policy-record-format"></xref> and <xref target="I -D.ietf-dmarc-aggregate-reporting"></xref>	of such reports. <xref target="policy-record-format"/> and <xref target="RFC9990 "/>
	discuss aggregate feedback reports.</t>	discuss aggregate feedback reports.</t>
	</section>	</section>

	<section anchor="send-aggregate-reports"><name>Send Aggregate Reports</name>	<section anchor="send-aggregate-reports"><name>Send Aggregate Reports</name>
	<t>To ensure maximum usefulness for DMARC across the email ecosystem, Mail	<t>To ensure maximum usefulness for DMARC across the email ecosystem, Mail
	Receivers <bcp14>SHOULD</bcp14> generate and send aggregate reports with a frequ ency	Receivers <bcp14>SHOULD</bcp14> generate and send aggregate reports with a frequ ency
	of at least once every 24 hours. Such reports provide Domain Owners with	of at least once every 24 hours. Such reports provide Domain Owners with
	insight into all mail streams using Author Domains under the Domain Owner's	insight into all mail streams using Author Domains under the Domain Owner's

	control, and aid the Domain Owner in determining whether and when to transition	control and aid the Domain Owner in determining whether and when to transition
	from <eref target="#monitoring-mode">Monitoring Mode</eref> to <eref target="#en	from <xref target="monitoring-mode">Monitoring Mode</xref> to <xref target="enfo
	forcement">Enforcement</eref>.</t>	rcement">Enforcement</xref>.</t>
	<t>The most common reasons for a Mail Receiver to opt out of sending aggregate	<t>The most common reasons for a Mail Receiver to opt out of sending aggregate
	reports include resource constraints, local policy against sharing data, and	reports include resource constraints, local policy against sharing data, and
	concerns about user privacy.</t>	concerns about user privacy.</t>
	</section>	</section>

	<section anchor="send-failure-reports"><name>Optionally Send Failure Reports</na me>	<section anchor="send-failure-reports"><name>Optionally Send Failure Reports</na me>

	<t>Per-message failure reports can be a useful source of information for a Domai n	<t>Per-message failure reports can be useful sources of information for a Domain
	Owner, either for debugging deployments or in analyzing attacks, and so Mail	Owner, either for debugging deployments or in analyzing attacks, and so Mail
	Receivers <bcp14>MAY</bcp14> choose to send them. Experience has shown, however , that Mail	Receivers <bcp14>MAY</bcp14> choose to send them. Experience has shown, however , that Mail
	Receivers rightly concerned about protecting user privacy have either chosen to	Receivers rightly concerned about protecting user privacy have either chosen to
	heavily redact the information in such reports (which can hinder their usefulnes s)	heavily redact the information in such reports (which can hinder their usefulnes s)

	or not send them at all. See <xref target="I-D.ietf-dmarc-failure-reporting"></ xref> for further information.</t>	or not send them at all. See <xref target="RFC9991"/> for further information.< /t>
	</section>	</section>
	</section>	</section>

	<section anchor="policy-enforcement-considerations"><name>Policy Enforcement Con siderations</name>	<section anchor="policy-enforcement-considerations"><name>Policy Enforcement Con siderations</name>
	<t>The final handling of any message is always a matter of local policy and is	<t>The final handling of any message is always a matter of local policy and is
	left to the discretion of the Mail Receiver.</t>	left to the discretion of the Mail Receiver.</t>

	<t>A DMARC pass for a message indicates only that the use of the <eref target="#	<t>A DMARC pass for a message indicates only that the use of the <xref target="a
	author-domain">Author Domain</eref>	uthor-domain">Author Domain</xref>
	has been validated for that message as authorized by the <eref target="#domain-o	has been validated for that message as authorized by the <xref target="domain-ow
	wner">Domain Owner</eref>.	ner">Domain Owner</xref>.
	Such authorization does not carry an explicit or implicit value assertion about	Such authorization does not carry an explicit or implicit value assertion about
	that message or the Domain Owner, and Mail Receivers <bcp14>MAY</bcp14> choose t o reject or	that message or the Domain Owner, and Mail Receivers <bcp14>MAY</bcp14> choose t o reject or
	quarantine a message even if it passes the DMARC validation check. Mail Receive rs	quarantine a message even if it passes the DMARC validation check. Mail Receive rs
	are encouraged to maintain anti-abuse technologies to combat the possibility of	are encouraged to maintain anti-abuse technologies to combat the possibility of
	DMARC-enabled abuse.</t>	DMARC-enabled abuse.</t>
	<t>Mail Receivers <bcp14>MAY</bcp14> choose to accept email that fails the DMARC	<t>Mail Receivers <bcp14>MAY</bcp14> choose to accept email that fails the DMARC
	validation check even if the published Domain Owner Assessment Policy	validation check even if the published Domain Owner Assessment Policy

	is "reject". In particular, because of the considerations discussed	is "reject". In particular, because of the considerations discussed
	in <xref target="RFC7960"></xref> and in <xref target="interoperability-consider	in <xref target="RFC7960"/> and in <xref target="interoperability-considerations
	ations"></xref> of this document, it is important that Mail	"/> of this document, it is important that Mail
	Receivers <bcp14>SHOULD NOT</bcp14> reject messages solely because of a publishe	Receivers <bcp14>SHOULD NOT</bcp14> reject messages solely because of a publishe
	d policy of "reject",	d policy of "reject"
	but that they apply other knowledge and analysis to avoid situations such as rej ection	but that they apply other knowledge and analysis to avoid situations such as rej ection
	of legitimate messages sent in ways that DMARC cannot describe, harm to the oper ation of	of legitimate messages sent in ways that DMARC cannot describe, harm to the oper ation of
	mailing lists, and similar.</t>	mailing lists, and similar.</t>
	<t>If a Mail Receiver chooses not to honor the published Domain Owner	<t>If a Mail Receiver chooses not to honor the published Domain Owner
	Assessment Policy to improve interoperability among mail systems, it may	Assessment Policy to improve interoperability among mail systems, it may
	increase the likelihood of accepting abusive mail. At a minimum, Mail	increase the likelihood of accepting abusive mail. At a minimum, Mail
	Receivers <bcp14>SHOULD</bcp14> add the Authentication-Results header field (see	Receivers <bcp14>SHOULD</bcp14> add the Authentication-Results header field (see

	<xref target="RFC8601"></xref>), and it is <bcp14>RECOMMENDED</bcp14> when deliv ering messages that fail the DMARC validation check.</t>	<xref target="RFC8601"/>), and it is <bcp14>RECOMMENDED</bcp14> when delivering messages that fail the DMARC validation check.</t>
	<t>When Mail Receivers deviate from a published Domain Owner	<t>When Mail Receivers deviate from a published Domain Owner

	Assessment Policy during message processing they <bcp14>SHOULD</bcp14> make	Assessment Policy during message processing, they <bcp14>SHOULD</bcp14> make
	available the fact of and reason for the deviation to the Domain	available the fact of and reason for the deviation to the Domain
	Owner via feedback reporting, specifically using the	Owner via feedback reporting, specifically using the

	"PolicyOverride" feature of the aggregate report defined in	"PolicyOverride" feature of the aggregate report defined in
	<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>	<xref target="RFC9990"/>.</t>
	<t>To enable Domain Owners to receive DMARC feedback without impacting	<t>To enable Domain Owners to receive DMARC feedback without impacting

	existing mail processing, discovered policies of "p=none" <bcp14>MUST NOT</bcp14>	existing mail processing, discovered policies of "p=none" <bcp14>MUST NOT</bcp14 >
	modify existing mail handling processes.</t>	modify existing mail handling processes.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="dmarc-feedback"><name>DMARC Feedback</name>	<section anchor="dmarc-feedback"><name>DMARC Feedback</name>

	<t>DMARC Feedback is described in <xref target="I-D.ietf-dmarc-aggregate-reporti ng"></xref></t>	<t>DMARC feedback is described in <xref target="RFC9990"/>.</t>
	<t>As an operational note for Public Suffix Operators, feedback for non-existent	<t>As an operational note for Public Suffix Operators, feedback for non-existent
	domains can be desirable and useful, just as it can be for Organizational	domains can be desirable and useful, just as it can be for Organizational

	Domains. Therefore, both such entities should consider including "rua=&quot	Domains. Therefore, both such entities should consider including "rua=" tags
	; tags	in any DMARC Policy Records they publish for themselves. See <xref target="priva
	in any DMARC Policy Records they publish for themselves. See <xref target="priva	cy-considerations"/>
	cy-considerations"></xref>	for discussion of privacy considerations.</t>
	for discussion of Privacy Considerations.</t>
	</section>	</section>

	<section anchor="other-topics"><name>Other Topics</name>	<section anchor="other-topics"><name>Other Topics</name>
	<t>This section discusses some topics regarding choices made in the	<t>This section discusses some topics regarding choices made in the
	development of DMARC, largely to commit the history to record.</t>	development of DMARC, largely to commit the history to record.</t>

	<section anchor="issues-specific-to-spf"><name>Issues Specific to SPF</name>	<section anchor="issues-specific-to-spf"><name>Issues Specific to SPF</name>
	<t>Though DMARC does not inherently change the semantics of an SPF	<t>Though DMARC does not inherently change the semantics of an SPF
	policy record, historically lax enforcement of such policies has led	policy record, historically lax enforcement of such policies has led
	many to publish extremely broad records containing many extensive network	many to publish extremely broad records containing many extensive network

	ranges. <eref target="#domain-owner">Domain Owners</eref> are strongly encourage d to carefully review	ranges. <xref target="domain-owner">Domain Owners</xref> are strongly encouraged to carefully review
	their SPF records to understand which networks are authorized to send	their SPF records to understand which networks are authorized to send
	on behalf of the Domain Owner before publishing a DMARC Policy Record. Furthermo re,	on behalf of the Domain Owner before publishing a DMARC Policy Record. Furthermo re,
	Domain Owners should periodically review their SPF records to ensure that	Domain Owners should periodically review their SPF records to ensure that
	the authorization conveyed by the records matches the domain's current needs.</t >	the authorization conveyed by the records matches the domain's current needs.</t >
	<t>SPF was intended to be implemented early in the SMTP transaction, meaning it' s	<t>SPF was intended to be implemented early in the SMTP transaction, meaning it' s
	possible for a message to fail SPF validation prior to any message content being	possible for a message to fail SPF validation prior to any message content being
	transmitted, and so some Mail Receiver architectures might implement SPF in	transmitted, and so some Mail Receiver architectures might implement SPF in

	advance of any DMARC operations. This means that an SPF hard fail ("-"	advance of any DMARC operations. This means that an SPF hard fail ("-") prefix
	) prefix	on a sender's SPF mechanism, such as "-all", could cause a message to be rejecte
	on a sender's SPF mechanism, such as "-all", could cause a message to	d early in
	be rejected early in
	the SMTP transaction, before any DMARC processing takes place, if the message	the SMTP transaction, before any DMARC processing takes place, if the message

	fails SPF authentication checks. Domain Owners choosing to use "-all"	fails SPF authentication checks. Domain Owners choosing to use "-all" to termin
	to terminate	ate
	SPF records should be aware of this, and should understand that messages that	SPF records should be aware of this and should understand that messages that
	might otherwise pass DMARC due to an aligned <eref target="#dkim-identifiers">DK	might otherwise pass DMARC due to an aligned <xref target="dkim-identifiers">DKI
	IM-Authenticated Identifier</eref> could be rejected solely due to an SPF fail.	M-Authenticated Identifier</xref> could be rejected solely due to an SPF fail.
	Moreover, messages rejected early in the SMTP transaction will never appear in	Moreover, messages rejected early in the SMTP transaction will never appear in

	aggregate DMARC reports, as the transaction will never proceed to the DATA phase	aggregate DMARC reports, as the transaction will never proceed to the DATA phase ,
	and so the RFC5322.From domain will never be revealed and its DMARC policy will	and so the RFC5322.From domain will never be revealed and its DMARC policy will

	never be discovered. Domain Owners and <eref target="#mail-receiver">Mail Recei	never be discovered. Domain Owners and <xref target="mail-receiver">Mail Receiv
	vers</eref> can consult	ers</xref> can consult
	<xref target="M3SPF"></xref> and <xref target="M3AUTH"></xref> for more discussi	<xref target="M3SPF"/> and <xref target="M3AUTH"/> for more discussion of the to
	on of the topic and best practices	pic and best practices
	regarding publishing SPF records and when to reject based solely on SPF failure:	regarding publishing SPF records and when to reject based solely on SPF failure.
	</t>	</t>
	</section>	</section>

	<section anchor="rejecting-messages"><name>Rejecting Messages</name>	<section anchor="rejecting-messages"><name>Rejecting Messages</name>
	<t>The DMARC mechanism calls for rejection of a message during the SMTP	<t>The DMARC mechanism calls for rejection of a message during the SMTP
	session under certain circumstances. This is preferable to	session under certain circumstances. This is preferable to
	generation of a Delivery Status Notification	generation of a Delivery Status Notification

	<xref target="RFC3464"></xref>, since fraudulent messages caught and rejected us ing the DMARC	<xref target="RFC3464"/>, since fraudulent messages caught and rejected using th e DMARC
	mechanism would then result in the annoying generation of such failure reports	mechanism would then result in the annoying generation of such failure reports
	that go back to the RFC5321.MailFrom address.</t>	that go back to the RFC5321.MailFrom address.</t>
	<t>This synchronous rejection is typically done in one of two ways:</t>	<t>This synchronous rejection is typically done in one of two ways:</t>

	<ul>	<ul>

	<li><t>Full rejection, wherein the SMTP server issues a 5xy reply code to the	<li><t>A "full rejection", wherein the SMTP server issues a 5xy reply code to th e
	DATA command as an indication to the SMTP client that the transaction failed;	DATA command as an indication to the SMTP client that the transaction failed;
	the SMTP client is then responsible for generating a notification that	the SMTP client is then responsible for generating a notification that

	delivery failed (see <xref target="RFC5321" sectionFormat="of" section="4.2.5">< /xref>).</t>	delivery failed (see <xref target="RFC5321" sectionFormat="of" section="4.2.5"/> ).</t>
	</li>	</li>

	<li><t>A "silent discard", wherein the SMTP server returns a 2xy reply	<li><t>A "silent discard", wherein the SMTP server returns a 2xy reply
	code implying to the client that delivery (or, at least, relay)	code implying to the client that delivery (or at least relay)
	was successfully completed, but then simply discards the message	was successfully completed but then simply discards the message
	with no further action.</t>	with no further action.</t>
	</li>	</li>
	</ul>	</ul>
	<t>Each of these has a cost. For instance, a silent discard can help to	<t>Each of these has a cost. For instance, a silent discard can help to
	prevent backscatter, but it also effectively means that the SMTP	prevent backscatter, but it also effectively means that the SMTP
	server has to be programmed to give a false result, which can	server has to be programmed to give a false result, which can
	confound external debugging efforts.</t>	confound external debugging efforts.</t>
	<t>Similarly, the text portion of the SMTP reply may be important to	<t>Similarly, the text portion of the SMTP reply may be important to
	consider. For example, when rejecting a message, revealing the	consider. For example, when rejecting a message, revealing the
	reason for the rejection might give an attacker enough information to	reason for the rejection might give an attacker enough information to
	bypass those efforts on a later attempt, though it might also assist	bypass those efforts on a later attempt, though it might also assist
	a legitimate client to determine the source of some local issue that	a legitimate client to determine the source of some local issue that
	caused the rejection.</t>	caused the rejection.</t>
	<t>In the latter case, when doing an SMTP rejection, providing a clear	<t>In the latter case, when doing an SMTP rejection, providing a clear

	hint can be useful in resolving issues. A <eref target="#mail-receiver">Mail Rec eiver</eref>	hint can be useful in resolving issues. A <xref target="mail-receiver">Mail Rece iver</xref>
	might indicate in plain text the reason for the rejection by using the	might indicate in plain text the reason for the rejection by using the

	word "DMARC" somewhere in the reply text. For example:</t>	word "DMARC" somewhere in the reply text. For example:</t>

		<artwork><![CDATA[
		550 5.7.1 Email rejected per DMARC policy for example.com]]></artwork>


	<artwork><![CDATA[550 5.7.1 Email rejected per DMARC policy for example.com
	]]></artwork>
	<t>Many systems are able to scan the SMTP reply text to determine the nature	<t>Many systems are able to scan the SMTP reply text to determine the nature
	of the rejection. Thus, providing a machine-detectable reason for rejection	of the rejection. Thus, providing a machine-detectable reason for rejection
	allows the problems causing rejections to be properly addressed by automated sys tems.</t>	allows the problems causing rejections to be properly addressed by automated sys tems.</t>
	<t>If a Mail Receiver elects to defer delivery due to the inability to	<t>If a Mail Receiver elects to defer delivery due to the inability to
	retrieve or apply DMARC policy, this is best done with a 4xy SMTP	retrieve or apply DMARC policy, this is best done with a 4xy SMTP
	reply code.</t>	reply code.</t>
	</section>	</section>

	<section anchor="interoperability-issues"><name>Interoperability Issues</name>	<section anchor="interoperability-issues"><name>Interoperability Issues</name>

	<t>DMARC limits which end-to-end scenarios can achieve a "pass" result	<t>DMARC limits which end-to-end scenarios can achieve a "pass" result.</t>
	.</t>	<t>Because DMARC relies on SPF <xref target="RFC7208"/> and/or DKIM <xref target
	<t>Because DMARC relies on SPF <xref target="RFC7208"></xref> and/or DKIM <xref	="RFC6376"/> to achieve
	target="RFC6376"></xref> to achieve	a "pass", their limitations also apply.</t>
	a "pass", their limitations also apply.</t>
	<t>Issues specific to the use of policy mechanisms alongside DKIM are	<t>Issues specific to the use of policy mechanisms alongside DKIM are

	further discussed in <xref target="RFC6377"></xref>, particularly Section 5.2.</ t>	further discussed in <xref target="RFC6377"/>, particularly Section <xref target ="RFC6377" section="5.2" sectionFormat="bare"/>.</t>
	<t>Mail that is sent by authorized, independent third parties might not be	<t>Mail that is sent by authorized, independent third parties might not be

	sent with Identifier Alignment, also preventing a "pass" result. A Dom ain	sent with Identifier Alignment, also preventing a "pass" result. A Domain
	Owner can use DMARC aggregate reports to identify this mail and take steps	Owner can use DMARC aggregate reports to identify this mail and take steps
	to address authentication shortcomings.</t>	to address authentication shortcomings.</t>
	</section>	</section>


	<section anchor="interoperability-considerations"><name>Interoperability Conside	<section
	rations</name>	anchor="interoperability-considerations"><name>Interoperability
	<t>As discussed in "Interoperability Issues between DMARC and Indirect	Considerations</name> <t>As discussed in "Interoperability Issues
	Email Flows" <xref target="RFC7960"></xref>, use of "p=reject" ca	between Domain-based Message Authentication, Reporting, and
	n be incompatible with and	Conformance (DMARC) and Indirect Email Flows" <xref
		target="RFC7960"/>, the use of "p=reject" can be incompatible with and
	cause interoperability problems to indirect message flows such as	cause interoperability problems to indirect message flows such as

	"alumni forwarders", role-based email aliases, and mailing lists	"alumni forwarders", role-based email aliases, and mailing lists
	across the Internet.</t>	across the Internet.</t>
	<t>As an example of this, a bank might send only targeted messages to	<t>As an example of this, a bank might send only targeted messages to
	account holders. Those account holders might have given their bank	account holders. Those account holders might have given their bank

	addresses such as "jones@alumni.example.edu" (an address that relays	addresses such as "jones@alumni.example.edu" (an address that relays
	the messages to another address with a real mailbox) or	the messages to another address with a real mailbox) or

	"finance@association.example" (a role-based address that does similar	"finance@association.example" (a role-based address that does similar
	relaying for the current head of finance at the association). When	relaying for the current head of finance at the association). When
	such mail is delivered to the actual recipient mailbox, it will	such mail is delivered to the actual recipient mailbox, it will
	most likely fail SPF checks unless the RFC5321.MailFrom address is	most likely fail SPF checks unless the RFC5321.MailFrom address is
	rewritten by the relaying MTA, as the incoming IP address will be that	rewritten by the relaying MTA, as the incoming IP address will be that

	of "example.edu" or "association.example", and not an IP add ress authorized	of "example.edu" or "association.example" and not an IP address authorized
	by the originating RFC5321.MailFrom domain. DKIM signatures will generally	by the originating RFC5321.MailFrom domain. DKIM signatures will generally
	remain valid in these relay situations.</t>	remain valid in these relay situations.</t>

	<blockquote><t>It is therefore critical that domains that publish "p=reject	<t indent="3">It is therefore critical that domains that publish "p=reject"
	"	<bcp14>MUST NOT</bcp14> rely solely on SPF to secure a DMARC pass and
	<bcp14>MUST NOT</bcp14> rely solely on SPF to secure a DMARC pass, and
	<bcp14>MUST</bcp14> apply valid DKIM signatures to their messages.</t>	<bcp14>MUST</bcp14> apply valid DKIM signatures to their messages.</t>

	</blockquote><t>In the case of domains that have general users who send routine	<t>In the case of domains that have general users who send routine email,
	email,	those that publish a <xref target="domain-owner-policy">Domain Owner Assessment
	those that publish a <eref target="#domain-owner-policy">Domain Owner Assessment	Policy</xref>
	Policy</eref>	of "p=reject" are likely to create significant interoperability
	of "p=reject" are likely to create significant interoperability
	issues. In particular, if users in such domains post messages to mailing	issues. In particular, if users in such domains post messages to mailing
	lists on the Internet, those messages can cause significant operational problems	lists on the Internet, those messages can cause significant operational problems
	for the mailing lists and for the subscribers to those lists, as explained below and	for the mailing lists and for the subscribers to those lists, as explained below and

	in <xref target="RFC7960"></xref>.</t>	in <xref target="RFC7960"/>.</t>
	<blockquote><t>It is therefore critical that domains that host users who might	<t indent="3">It is therefore critical that domains that host users who might
	post messages to mailing lists <bcp14>SHOULD NOT</bcp14> publish Domain Owner As sessment Policies	post messages to mailing lists <bcp14>SHOULD NOT</bcp14> publish Domain Owner As sessment Policies

	of "p=reject". Any such domains wishing to publish "p=reject&quot ; <bcp14>SHOULD</bcp14> first	of "p=reject". Any such domains wishing to publish "p=reject" <bcp14>SHOULD</bcp 14> first
	take advantage of DMARC aggregate report data for their domain to	take advantage of DMARC aggregate report data for their domain to
	determine the possible impact to their users, first by publishing	determine the possible impact to their users, first by publishing

	"p=none" for at least a month, followed by publishing "p=quaranti ne" for	"p=none" for at least a month, followed by publishing "p=quarantine" for
	an equally long period of time, and comparing the message disposition	an equally long period of time, and comparing the message disposition

	results. Domains that choose to publish "p=reject" <bcp14>SHOULD</bcp1 4> either	results. Domains that choose to publish "p=reject" <bcp14>SHOULD</bcp14>
	implement policies that their users not post to Internet mailing lists	implement policies that their users not post to Internet mailing lists
	and/or inform their users that their participation in mailing lists may	and/or inform their users that their participation in mailing lists may
	be hindered.</t>	be hindered.</t>

	</blockquote><t>As noted in <xref target="policy-enforcement-considerations"></x ref>, <eref target="#mail-receivers">Mail Receivers</eref>	<t>As noted in <xref target="policy-enforcement-considerations"/>, <xref target= "mail-receiver">Mail Receivers</xref>
	need to apply more analysis than just DMARC validation in their	need to apply more analysis than just DMARC validation in their
	disposition of incoming messages. An example of the consequences of	disposition of incoming messages. An example of the consequences of

	honoring a Domain Owner Assessment Policy of "p=reject" without furthe r analysis	honoring a Domain Owner Assessment Policy of "p=reject" without further analysis
	is that rejecting messages that have been relayed by a mailing list can cause	is that rejecting messages that have been relayed by a mailing list can cause
	the Mail Receiver's users to have their subscriptions to that mailing list cance led	the Mail Receiver's users to have their subscriptions to that mailing list cance led

	by the list software's automated handling of such rejections - it looks	by the list software's automated handling of such rejections -- it looks
	to the list manager as though the recipient's email address is no	to the list manager as though the recipient's email address is no
	longer working, so the address is automatically unsubscribed. An example of this	longer working, so the address is automatically unsubscribed. An example of this
	scenario, albeit with DKIM Author Domain Signing Practices (ADSP) rather than DM ARC,	scenario, albeit with DKIM Author Domain Signing Practices (ADSP) rather than DM ARC,

	can be found in <xref target="RFC6377" sectionFormat="of" section="5.2"></xref>.	can be found in <xref target="RFC6377" sectionFormat="of" section="5.2"/>.</t>
	</t>	<t indent="3">It is therefore critical that Mail Receivers <bcp14>MUST NOT</bcp1
	<blockquote><t>It is therefore critical that Mail Receivers <bcp14>MUST NOT</bcp	4> reject
	14> reject	incoming messages solely on the basis of a "p=reject" policy by
	incoming messages solely on the basis of a "p=reject" policy by
	the sending domain. Mail Receivers must use the DMARC	the sending domain. Mail Receivers must use the DMARC
	policy as part of their disposition decision, along with other	policy as part of their disposition decision, along with other

	knowledge and analysis. "Other knowledge and analysis" here might	knowledge and analysis. "Other knowledge and analysis" here might
	refer to observed sending patterns for properly-authenticated mail	refer to observed sending patterns for properly authenticated mail
	using the sending domain, content filtering, etc. In the absence of	using the sending domain, content filtering, etc. In the absence of
	other knowledge and analysis, Mail Receivers <bcp14>MUST</bcp14> treat such fail ing	other knowledge and analysis, Mail Receivers <bcp14>MUST</bcp14> treat such fail ing

	mail as if the policy were "p=quarantine" rather than "p=reject&q	mail as if the policy were "p=quarantine" rather than "p=reject".</t>
	uot;.</t>	<t>Failure to understand and abide by these considerations can cause
	</blockquote><t>Failure to understand and abide by these considerations can caus	legitimate, sometimes important, email to be rejected; can cause
	e	operational damage to mailing lists throughout the Internet; and
	legitimate, sometimes important email to be rejected, can cause
	operational damage to mailing lists throughout the Internet, and
	can result in trouble-desk calls and complaints from the Mail Receiver's	can result in trouble-desk calls and complaints from the Mail Receiver's
	employees, customers, and clients.</t>	employees, customers, and clients.</t>
	<t>In practice, despite this advice, few Mail Receivers apply any mitigation	<t>In practice, despite this advice, few Mail Receivers apply any mitigation
	techniques when receiving indirect mail flows, few organizations consider	techniques when receiving indirect mail flows, few organizations consider
	the effect of DMARC policies on their users' indirect mail, and it is unlikely	the effect of DMARC policies on their users' indirect mail, and it is unlikely
	that any advice in this document will change that. As a result, mail forwarded	that any advice in this document will change that. As a result, mail forwarded
	through mailing lists with unmodified From: header lines is frequently rejected	through mailing lists with unmodified From: header lines is frequently rejected

	due to a p=reject policy.</t>	due to a "p=reject" policy.</t>
	<t>In the ten years since large consumer mail systems started publishing p=rejec t	<t>In the ten years since large consumer mail systems started publishing p=rejec t
	policies, mailing list software has all adopted workarounds to make the From:	policies, mailing list software has all adopted workarounds to make the From:
	header line DMARC aligned. Some simply use the list's address, while others do	header line DMARC aligned. Some simply use the list's address, while others do
	per-address modifications intended to be reversible or to allow mail to be	per-address modifications intended to be reversible or to allow mail to be
	forwarded back to the original author, e.g., bob@example.com turned into	forwarded back to the original author, e.g., bob@example.com turned into
	bob=example.com@user.somelist.example. While these workarounds are far from	bob=example.com@user.somelist.example. While these workarounds are far from
	ideal, they are firmly established and list operators treat them as a fact of li fe.</t>	ideal, they are firmly established and list operators treat them as a fact of li fe.</t>
	<t>Mail developers have been trying for a decade to invent technical methods	<t>Mail developers have been trying for a decade to invent technical methods
	to allow mailing lists to continue to work without modifying the From: header	to allow mailing lists to continue to work without modifying the From: header
	line, with a prominent example being the Authenticated Received Chain (ARC)	line, with a prominent example being the Authenticated Received Chain (ARC)

	protocol described in <xref target="RFC8617"></xref>. While work continues, as of this document's	protocol described in <xref target="RFC8617"/>. While work continues, as of thi s document's
	publication, none of the methods have become widely used. Should such a technica l	publication, none of the methods have become widely used. Should such a technica l
	method achieve widespread adoption in the future, this document can be updated t o	method achieve widespread adoption in the future, this document can be updated t o
	reflect that.</t>	reflect that.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="conformance-requirements"><name>Conformance Requirements for Fu ll DMARC Participation</name>	<section anchor="conformance-requirements"><name>Conformance Requirements for Fu ll DMARC Participation</name>

	<t>This document describes the DMARC mechanism, and allows Domain Owners and Mai l Receivers	<t>This document describes the DMARC mechanism and allows Domain Owners and Mail Receivers
	some leeway in deciding which parts of the mechanism to implement. This section summarizes	some leeway in deciding which parts of the mechanism to implement. This section summarizes
	the requirements for full participation in DMARC, either by Domain Owners or by Mail Receivers.</t>	the requirements for full participation in DMARC, either by Domain Owners or by Mail Receivers.</t>
	<t>In order to fully participate in DMARC, Domain Owners:</t>	<t>In order to fully participate in DMARC, Domain Owners:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li><bcp14>MUST</bcp14> send mail so it produces an SPF-Authenticated identifier	<li><bcp14>MUST</bcp14> send mail so it produces an SPF-Authenticated Identifier
	that has Identifier	that has Identifier
	Alignment with the Author Domain</li>	Alignment with the Author Domain.</li>
	<li><bcp14>MUST</bcp14> send mail that has a DKIM Signing Domain that will produ ce a DKIM-Authenticated	<li><bcp14>MUST</bcp14> send mail that has a DKIM Signing Domain that will produ ce a DKIM-Authenticated

	Identifier that has Identifier Alignment with the Author Domain</li>	Identifier that has Identifier Alignment with the Author Domain.</li>
	<li><bcp14>MUST</bcp14> set up a mailbox to receive aggregate reports and collec	<li><bcp14>MUST</bcp14> set up a mailbox to receive aggregate reports and collec
	t and analyze those reports</li>	t and analyze those reports.</li>
	<li><bcp14>MUST</bcp14> publish a DMARC Policy Record for the Author Domain and the Organizational Domain,	<li><bcp14>MUST</bcp14> publish a DMARC Policy Record for the Author Domain and the Organizational Domain,

	if it differs from the Author Domain</li>	if it differs from the Author Domain.</li>
	<li><bcp14>MUST NOT</bcp14> rely solely on SPF for a DMARC pass if the DMARC pol icy for the Author Domain	<li><bcp14>MUST NOT</bcp14> rely solely on SPF for a DMARC pass if the DMARC pol icy for the Author Domain

	is "p=reject"</li>	is "p=reject".</li>
	</ul>	</ul>

	<t>In order to fully participate in DMARC, Mail Receivers</t>	<t>In order to fully participate in DMARC, Mail Receivers:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li><bcp14>MUST</bcp14> check for the existence of a DMARC Policy Record for the Author Domain of an inbound	<li><bcp14>MUST</bcp14> check for the existence of a DMARC Policy Record for the Author Domain of an inbound
	mail message to determine if the DMARC mechanism applies to that message.</li>	mail message to determine if the DMARC mechanism applies to that message.</li>
	<li><bcp14>MUST</bcp14> determine if Authenticated Identifiers exist for the mes sage and preserve the results of those	<li><bcp14>MUST</bcp14> determine if Authenticated Identifiers exist for the mes sage and preserve the results of those

	checks for future use in reportging if the DMARC mechanism applies to the messag	checks for future use in reporting if the DMARC mechanism applies to the message
	e</li>	.</li>
	<li><bcp14>MUST</bcp14> conduct necessary Identifier Alignmeent checks if the DM	<li><bcp14>MUST</bcp14> conduct necessary Identifier Alignment checks if the DMA
	ARC mechanism applies for the message and	RC mechanism applies for the message and
	Authenticated Identifiers exist</li>	Authenticated Identifiers exist.</li>
	<li><bcp14>MUST</bcp14> use the information from the checks for Authenticated Id entifiers to determine if the DMARC	<li><bcp14>MUST</bcp14> use the information from the checks for Authenticated Id entifiers to determine if the DMARC

	validation result is "pass" or "fail" for the message.</li>	validation result is "pass" or "fail" for the message.</li>
	<li><bcp14>MUST</bcp14> support the "mailto:" URI for sending requeste	<li><bcp14>MUST</bcp14> support the "mailto:" URI for sending requested reports.
	d reports</li>	</li>
	<li><bcp14>SHOULD</bcp14> send aggregate reports on at least a daily basis</li>	<li><bcp14>SHOULD</bcp14> send aggregate reports on at least a daily basis.</li>
	<li><bcp14>MUST NOT</bcp14> reject messages solely on the basis of a "p=rej	<li><bcp14>MUST NOT</bcp14> reject messages solely on the basis of a "p=reject"
	ect" policy for the Author Domain</li>	policy for the Author Domain.</li>
	</ul>	</ul>
	</section>	</section>

	<section anchor="iana-considerations"><name>IANA Considerations</name>	<section anchor="iana-considerations"><name>IANA Considerations</name>

	<t>This section describes actions to be completed by IANA.</t>	<t>This section describes actions completed by IANA.</t>

	<section anchor="email-authentication-methods-registry-update"><name>Email Authe ntication Methods Registry Update</name>	<section anchor="email-authentication-methods-registry-update"><name>Email Authe ntication Methods Registry Update</name>

	<t>A registry group called "Email Authentication Parameters" exists, a	<t>The properties of an email message to be evaluated by an email authentication
	nd within it a registry group	method have been registered by IANA in the "Email Authentication Methods" regis
	called "Email Authentication Methods" exists and needs to be updated i	try within the "Email Authentication Parameters" registry group.
	n the manner specified in	</t>
	this section.</t>	<t>Each registration includes the authentication method;
	<t>The properties of an email message to be evaluated by an email authentication
	method are registered
	with IANA in this registry. Entries are assigned only for values that have been
	documented in a manner that
	satisfies the terms of Specification Required, per <xref target="RFC8126"></xref
	>. Each registration includes the authentication method;
	the specification that defines the authentication method; the property type (pty pe), which is one of the ptype	the specification that defines the authentication method; the property type (pty pe), which is one of the ptype

	values from the entries in the "Email Authentication Property Types" r	values from the entries in the "Email Authentication Property Types" registry in
	egistry in this same registry group; the	this same registry group; the
	property; the value for that property; the status of the property, which is one	property; the value for that property; the status of the property, which is one
	of "active" or "deprecated"; and its	of "active" or "deprecated"; and its
	version. The Designated Expert needs to confirm that the provided specification	version. The designated expert needs to confirm that the provided specification
	adequately describes the property	adequately describes the property
	and the method for its evaluation and clearly presents how they would be used wi thin the DMARC context by Domain	and the method for its evaluation and clearly presents how they would be used wi thin the DMARC context by Domain
	Owners and Mail Receivers.</t>	Owners and Mail Receivers.</t>

	<t>The set of entries to be updated in this registry is as follows:</t>	<t>IANA has changed the registration procedure from Expert Review to Specificati
	<table align="left"><name>"Email Authentication Methods Registry Update&quo	on Required <xref target="RFC8126"/> and has listed this document as an addition
	t;	al reference for the registry. IANA has updated the registry as follows:</t>
		<table align="center"><name>Email Authentication Methods Registry Update
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th align="left">Method</th>	<th align="left">Method</th>

	<th align="left">Defined</th>	<th align="left">Definition</th>
	<th align="left">ptype</th>	<th align="left">ptype</th>
	<th align="left">Property</th>	<th align="left">Property</th>
	<th align="left">Value</th>	<th align="left">Value</th>
	<th align="left">Status</th>	<th align="left">Status</th>
	<th align="left">Version</th>	<th align="left">Version</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td align="left">dmarc</td>	<td align="left">dmarc</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">header</td>	<td align="left">header</td>
	<td align="left">from</td>	<td align="left">from</td>
	<td align="left">The domain portion of the RFC5322.From header field</td>	<td align="left">The domain portion of the RFC5322.From header field</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">1</td>	<td align="left">1</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">dmarc</td>	<td align="left">dmarc</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">policy</td>	<td align="left">policy</td>
	<td align="left">dmarc</td>	<td align="left">dmarc</td>

	<td align="left">The evaluated DMARC policy applied/to be applied after policy o ptions have been processed. Must be "none", "quarantine", or "reject".</td>	<td align="left">The evaluated DMARC policy applied / to be applied after policy options have been processed. Must be "none", "quarantine", or "reject".</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">1</td>	<td align="left">1</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table></section>	</table></section>

	<section anchor="authentication-results-result-registry"><name>Email Authenticat ion Result Names Registry Update</name>	<section anchor="authentication-results-result-registry"><name>Email Authenticat ion Result Names Registry Update</name>

	<t>Also within the registry group "Email Authentication Parameters" a	<t>Result codes for DMARC are registered with IANA in the "Email Authentication
	registry called "Email Authentication	Result Names" registry within "Email Authentication Parameters" registry group.
	Result Names" exists and should be updated to reference this section of thi	</t>
	s document.</t>	<t> Each registration includes the auth method; the
	<t>Result codes for DMARC are registered with IANA in this registry. Entries are	code; the specification that defines the code; and the code's status, which is o
	assigned only for values that have been documented in a manner that satisfies th	ne of "active" or
	e terms	"deprecated". Note that the "Description" field is included here solely for the
	of Specification Required, per <xref target="RFC8126"></xref>. Each registration	reader's reference and
	includes the auth method; the	does not appear in the IANA registry. The designated expert needs to confirm tha
	code; the specification that defines the code; and the code's status, which is o	t the provided
	ne of "active" or
	"deprecated". The "Description" field is included here solel
	y for the reader's reference, and
	does not appear in the IANA registry. The Designated Expert needs to confirm tha
	t the provided
	specification adequately describes the result code and clearly presents how it w ould be used	specification adequately describes the result code and clearly presents how it w ould be used
	within the DMARC context by Domain Owners and Mail Receivers.</t>	within the DMARC context by Domain Owners and Mail Receivers.</t>

	<t>The set of entries to be updated in this registry is as follows:</t>	<t>IANA has changed the registration procedure from Expert Review to Specificati
	<table align="left"><name>"Email Authentication Result Names Registry Updat	on Required <xref target="RFC8126"/> and has listed this document as an addition
	e"	al reference for the registry. IANA has updated the registry as follows, replaci
		ng references to <xref target="RFC7489"/> with references to this document:</t>
		<table align="center"><name>Email Authentication Result Names Registry Update
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>

	<th align="left">Auth Method</th>	<th align="left">Auth Method(s)</th>
	<th align="left">Code</th>	<th align="left">Code</th>
	<th align="left">Specification</th>	<th align="left">Specification</th>
	<th align="left">Status</th>	<th align="left">Status</th>
	<th align="left">Description</th>	<th align="left">Description</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td align="left">dmarc</td>	<td align="left">dmarc</td>
	<td align="left">fail</td>	<td align="left">fail</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">A DMARC Policy Record exists for the Author Domain, but no Auth enticated Identifier with Identifier Alignment exists</td>	<td align="left">A DMARC Policy Record exists for the Author Domain, but no Auth enticated Identifier with Identifier Alignment exists</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">dmarc</td>	<td align="left">dmarc</td>
	<td align="left">none</td>	<td align="left">none</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">No DMARC Policy Record exists for the Author Domain</td>	<td align="left">No DMARC Policy Record exists for the Author Domain</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">dmarc</td>	<td align="left">dmarc</td>
	<td align="left">pass</td>	<td align="left">pass</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">A DMARC Policy Record exists for the Author Domain, and an Auth enticated Identifier with Identifier Alignment exists</td>	<td align="left">A DMARC Policy Record exists for the Author Domain, and an Auth enticated Identifier with Identifier Alignment exists</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">dmarc</td>	<td align="left">dmarc</td>
	<td align="left">permerror</td>	<td align="left">permerror</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">An error occurred during DMARC evaluation that is unrecoverable , such as the retrieval of an improperly formatted DMARC Policy Record. A later attempt is unlikely to produce a final result</td>	<td align="left">An error occurred during DMARC evaluation that is unrecoverable , such as the retrieval of an improperly formatted DMARC Policy Record. A later attempt is unlikely to produce a final result</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">dmarc</td>	<td align="left">dmarc</td>
	<td align="left">temperror</td>	<td align="left">temperror</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">An error occurred during DMARC evaluation that is likely transi ent in nature, such as a DNS server being temporarily unreachable. A later attem pt might produce a final result</td>	<td align="left">An error occurred during DMARC evaluation that is likely transi ent in nature, such as a DNS server being temporarily unreachable. A later attem pt might produce a final result</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table></section>	</table></section>

	<section anchor="dmarc-tag-registry-update"><name>DMARC Tags Registry Update</na me>	<section anchor="dmarc-tag-registry-update"><name>DMARC Tags Registry Update</na me>

	<t>A registry group called "Domain-based Message Authentication,	<t>Names of tags used in DMARC Policy Records as part of "tag-value" pairs are r
	Reporting, and Conformance (DMARC)" exists, and within it, a	egistered with IANA in the "DMARC Tags" registry within the "Domain-based Messag
	registry called "DMARC Tags" exists. That registry should be updated	e Authentication, Reporting, and Conformance (DMARC)" registry group.
	as described in this section.</t>	</t>
	<t>Names of tags used in DMARC Policy Records as part of "tag-value" p	<t>Entries are assigned only for values that have been documented in a manner th
	airs are registered with IANA	at
	in this registry. Entries are assigned only for values that have been documented	satisfies the terms of Specification Required, per <xref target="RFC8126"/>. Eac
	in a manner that	h registration includes the tag
	satisfies the terms of Specification Required, per [RFC8126]. Each registration
	includes the tag
	name, the specification that defines the tag, the status of the tag, and a brief description of	name, the specification that defines the tag, the status of the tag, and a brief description of

	the tag. The Designated Expert needs to confirm that the provided specification adequately describes	the tag. The designated expert needs to confirm that the provided specification adequately describes
	the tag and clearly presents how it would be used within the DMARC context by Do main Owners and Mail	the tag and clearly presents how it would be used within the DMARC context by Do main Owners and Mail

	Receivers. The "status" column is one of the following:</t>	Receivers. The "status" column is one of the following:</t>


	<ul spacing="compact">	<ul>
	<li>"active", meaning the tag is in use in current implementations, an	<li>"active", meaning the tag is in use in current
	d its specifications is expected	implementations, and its specifications is expected to be stable</li>
	to be stable</li>	<li>"experimental", meaning the tag is relatively new and
	<li>"experimental", meaning the tag is relatively new and may be in us	may be in use in some current implementations but not in others, and its
	e in some current implementations	specification is not expected to be stable</li>
	but not in others, and its specification is not expected to be stable</li>	<li>"historic", meaning the tag is considered deprecated
	<li>"historic", meaning the tag is considered deprecated and is not ex	and is not expected to be in use in any current implementation</li>
	pected to be in use in any current
	implementation</li>
	</ul>	</ul>


	<t>To avoid version compatibility issues, tags added to the DMARC	<t>To avoid version compatibility issues, tags added to the DMARC
	specification are to avoid changing the semantics of existing records	specification are to avoid changing the semantics of existing records
	when processed by implementations conforming to prior specifications.</t>	when processed by implementations conforming to prior specifications.</t>

	<t>The set of entries to be updated in this registry is as follows:</t>	<t>IANA has listed this document (rather than <xref target="RFC7489"/>) as the r
	<table align="left"><name>"DMARC Tags Registry Updatee"	eference for the registry. IANA has updated the registry as follows, including t
		he addition of the new "t" registration:</t>
		<table align="center"><name>DMARC Tags Registry Update
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th align="left">Tag Name</th>	<th align="left">Tag Name</th>
	<th align="left">Reference</th>	<th align="left">Reference</th>
	<th align="left">Status</th>	<th align="left">Status</th>
	<th align="left">Description</th>	<th align="left">Description</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td align="left">adkim</td>	<td align="left">adkim</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">DKIM Identifier Alignment mode</td>	<td align="left">DKIM Identifier Alignment mode</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">aspf</td>	<td align="left">aspf</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">SPF Identifier Alignment mode</td>	<td align="left">SPF Identifier Alignment mode</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">fo</td>	<td align="left">fo</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">Failure reporting options</td>	<td align="left">Failure reporting options</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">np</td>	<td align="left">np</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">Requested Domain Owner Assessment Policy for non-existent subdo mains</td>	<td align="left">Requested Domain Owner Assessment Policy for non-existent subdo mains</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">p</td>	<td align="left">p</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">Requested Domain Owner Assessment Policy</td>	<td align="left">Requested Domain Owner Assessment Policy</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">pct</td>	<td align="left">pct</td>

	<td align="left"><xref target="RFC7489"></xref></td>	<td align="left"><xref target="RFC7489"/></td>
	<td align="left">historic</td>	<td align="left">historic</td>
	<td align="left">Sampling rate</td>	<td align="left">Sampling rate</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">psd</td>	<td align="left">psd</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">Indicates whether the DMARC Policy Record is published by a Pub lic Suffix Domain</td>	<td align="left">Indicates whether the DMARC Policy Record is published by a Pub lic Suffix Domain</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">rf</td>	<td align="left">rf</td>

	<td align="left"><xref target="RFC7489"></xref></td>	<td align="left"><xref target="RFC7489"/></td>
	<td align="left">historic</td>	<td align="left">historic</td>
	<td align="left">Failure reporting format(s)</td>	<td align="left">Failure reporting format(s)</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">ri</td>	<td align="left">ri</td>

	<td align="left"><xref target="RFC7489"></xref></td>	<td align="left"><xref target="RFC7489"/></td>
	<td align="left">historic</td>	<td align="left">historic</td>
	<td align="left">Aggregate Reporting interval</td>	<td align="left">Aggregate Reporting interval</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">rua</td>	<td align="left">rua</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">Reporting URI(s) for DMARC aggregate feedback reports</td>	<td align="left">Reporting URI(s) for DMARC aggregate feedback reports</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">ruf</td>	<td align="left">ruf</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">Reporting URI(s) for message-specific DMARC failure reports</td >	<td align="left">Reporting URI(s) for message-specific DMARC failure reports</td >
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">sp</td>	<td align="left">sp</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">Requested Domain Owner Assessment Policy for subdomains</td>	<td align="left">Requested Domain Owner Assessment Policy for subdomains</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">t</td>	<td align="left">t</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">DMARC policy test mode</td>	<td align="left">DMARC policy test mode</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="left">v</td>	<td align="left">v</td>

	<td align="left">[this document]</td>	<td align="left">RFC 9989</td>
	<td align="left">active</td>	<td align="left">active</td>
	<td align="left">DMARC specification version</td>	<td align="left">DMARC specification version</td>
	</tr>	</tr>
	</tbody>	</tbody>

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

	<section anchor="dmarc-report-formats-registry"><name>DMARC Report Formats Regis try Update</name>	<section anchor="dmarc-report-formats-registry"><name>DMARC Report Formats Regis try Update</name>

	<t>Also within the registry group "Domain-based Message Authentication, Rep	<t>Names of DMARC failure reporting formats are registered with IANA in the "DMA
	orting, and	RC Report Formats" registry within the "Domain-based Message Authentication, Rep
	Conformance (DMARC)" a registry called "DMARC Report Formats" exi	orting, and
	sts and should be updated	Conformance (DMARC)" registry group.</t>
	to reference this document.</t>	<t>Entries
	<t>Names of DMARC failure reporting formats are registered with IANA in this reg
	istry. Entries
	are assigned only for values that have been documented in a manner that satisfie s the terms of	are assigned only for values that have been documented in a manner that satisfie s the terms of

	Specification Required, per [RFC8126]. In addition to a reference to a permanent specification, each	Specification Required, per <xref target="RFC8126"/>. In addition to a reference to a permanent specification, each
	registration includes the format name, the format's status, and a brief descript ion of the format.	registration includes the format name, the format's status, and a brief descript ion of the format.

	The Designated Expert needs to confirm that the provided specification adequatel y describes the	The designated expert needs to confirm that the provided specification adequatel y describes the
	report format and clearly presents how it would be used within the DMARC context by Domain Owners	report format and clearly presents how it would be used within the DMARC context by Domain Owners

	and Mail Receivers. The "status" column is one of the following:</t>	and Mail Receivers. The "status" column is one of the following:</t>


	<ul spacing="compact">	<ul>
	<li>"active", meaning the format is in use in current implementations,	<li>"active", meaning the format is in use in current
	and its specifications is expected	implementations, and its specifications is expected to be stable</li>
	to be stable</li>	<li>"experimental", meaning the format is relatively new
	<li>"experimental", meaning the format is relatively new and may be in	and may be in use in some current implementations but not in others, and its
	use in some current implementations	specification is not expected to be stable</li>
	but not in others, and its specification is not expected to be stable</li>	<li>"historic", meaning the format is considered deprecated
	<li>"historic", meaning the format is considered deprecated and is not	and is not expected to be in use in any current implementation</li>
	expected to be in use in any current
	implementation</li>
	</ul>	</ul>

	<t>The entry to be updated in this registry is as follows:</t>
	<table align="left"><name>"DMARC Report Formats Registry Update"	<t>IANA has listed this document (rather than <xref target="RFC7489"/>) as the r
		eference for the registry. IANA has updated the registry as follows:</t>
		<table align="center"><name>DMARC Report Formats Registry Update
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>Format Name</th>	<th>Format Name</th>
	<th>Reference</th>	<th>Reference</th>
	<th>Status</th>	<th>Status</th>
	<th>Description</th>	<th>Description</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td>afrf</td>	<td>afrf</td>

	<td>[this document]</td>	<td>RFC 9989</td>
	<td>active</td>	<td>active</td>

	<td>Authentication Failure Reporting Format (see <xref target="RFC6591"></xref>) </td>	<td>Authentication Failure Reporting Format (see <xref target="RFC6591"/>)</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table></section>	</table></section>

	<section anchor="underscored-and-globally-scoped-dns-node-names-registry-update" ><name>Underscored and Globally Scoped DNS Node Names Registry Update</name>	<section anchor="underscored-and-globally-scoped-dns-node-names-registry-update" ><name>Underscored and Globally Scoped DNS Node Names Registry Update</name>

	<t>A registry group called "Domain Name System (DNS) Parameters" exist	<t>The names of DNS Resource Records (RRs) beginning with an underscore characte
	s, and within it, a registry called	r that are globally scoped (as per <xref target="RFC8552"/>) are registered with
	"Underscored and Globally Scoped DNS Node Names" exists, and that regi	IANA in the "Underscored and Globally Scoped DNS Node Names" registry within th
	stry should be updated to reference	e "Domain Name System (DNS) Parameters" registry group.</t>
	this document.</t>	<t>In addition to a reference to a permanent specification, each registration co
	<t>The names of DNS Resource Records beginning with an underscore character that	ntains the DNS Resource Record (RR) type and Node Name.
	are globally	The designated expert needs to confirm that the provided specification adequatel
	scoped (as per <xref target="RFC8552"></xref>) are registered with IANA in this	y describes the Node
	registry. In addition to a reference to
	a permanent specification, each registration contains the DNS Resource Record (R
	R) type and Node Name.
	The Designated Expert needs to confirm that the provided specification adequatel
	y describes the Node
	Name and clearly presents how it would be used within the DMARC context by Domai n Owners and	Name and clearly presents how it would be used within the DMARC context by Domai n Owners and
	Mail Receivers.</t>	Mail Receivers.</t>

	<t>The entry to be updated in this registry is as follows:</t>	<t>IANA has updated the reference for following entry to point to this document
	<table align="left"><name>"Underscored and Globally Scoped DNS Node Names R	(instead of <xref target="RFC7489"/>):</t>
	egistry Update"	<table align="center"><name>Underscored and Globally Scoped DNS Node Names Regis
		try Update
	</name>	</name>
	<thead>	<thead>
	<tr>	<tr>
	<th>RR Type</th>	<th>RR Type</th>
	<th>_NODE NAME</th>	<th>_NODE NAME</th>
	<th>Reference</th>	<th>Reference</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td>TXT</td>	<td>TXT</td>
	<td>_dmarc</td>	<td>_dmarc</td>

	<td>[this document]</td>	<td>RFC 9989</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table></section>	</table></section>
	</section>	</section>

	<section anchor="privacy-considerations"><name>Privacy Considerations</name>	<section anchor="privacy-considerations"><name>Privacy Considerations</name>
	<t>This section discusses issues specific to private data that may be	<t>This section discusses issues specific to private data that may be
	included if DMARC reports are requested. Issues associated with	included if DMARC reports are requested. Issues associated with
	sending aggregate reports and failure reports are addressed in	sending aggregate reports and failure reports are addressed in

	<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref> and	<xref target="RFC9990"/> and
	<xref target="I-D.ietf-dmarc-failure-reporting"></xref> respectively.</t>	<xref target="RFC9991"/>, respectively.</t>

	<section anchor="aggregate-report-considerations"><name>Aggregate Report Conside rations</name>	<section anchor="aggregate-report-considerations"><name>Aggregate Report Conside rations</name>
	<t>Aggregate reports may, particularly for small organizations, provide some	<t>Aggregate reports may, particularly for small organizations, provide some
	limited insight into email sending patterns. As an example, in a small	limited insight into email sending patterns. As an example, in a small
	organization, an aggregate report from a particular domain may be sufficient	organization, an aggregate report from a particular domain may be sufficient
	to make the Report Consumer aware of sensitive personal or business	to make the Report Consumer aware of sensitive personal or business

	information. If setting an "rua" tag in a DMARC Policy Record, the re porting	information. If setting a "rua" tag in a DMARC Policy Record, the reporting
	address needs controls appropriate to the organizational requirements to	address needs controls appropriate to the organizational requirements to
	mitigate any risk associated with receiving and handling reports.</t>	mitigate any risk associated with receiving and handling reports.</t>

	<t>In the case of "rua" requests for multi-organizational PSDs, additi onal	<t>In the case of "rua" requests for multi-organizational PSDs, additional
	information leakage considerations exist. Multi-organizational PSDs that	information leakage considerations exist. Multi-organizational PSDs that
	do not mandate DMARC use by registrants risk exposure of private data of	do not mandate DMARC use by registrants risk exposure of private data of

	registrant domains if they include the "rua" tag in their DMARC Policy Record.</t>	registrant domains if they include the "rua" tag in their DMARC Policy Record.</ t>
	</section>	</section>

	<section anchor="failure-report-considerations"><name>Failure Report Considerati ons</name>	<section anchor="failure-report-considerations"><name>Failure Report Considerati ons</name>
	<t>Failure reports do provide insight into email sending patterns, including	<t>Failure reports do provide insight into email sending patterns, including
	specific users. If requesting failure reports, data management controls	specific users. If requesting failure reports, data management controls
	are needed to support appropriate management of this information. The	are needed to support appropriate management of this information. The

	additional detail available through failure reports (relative to aggregate	additional details available through failure reports (relative to aggregate
	reports) can drive a need for additional controls. As an example, a	reports) can drive a need for additional controls. As an example, a
	company may be legally restricted from receiving data related to a specific	company may be legally restricted from receiving data related to a specific
	subsidiary. Before requesting failure reports, any such data spillage risks	subsidiary. Before requesting failure reports, any such data spillage risks
	have to be addressed through data management controls or publishing DMARC	have to be addressed through data management controls or publishing DMARC
	Policy Records for relevant subdomains to prevent reporting on data related to	Policy Records for relevant subdomains to prevent reporting on data related to
	their emails.</t>	their emails.</t>

	<t>Due to the nature of the email contents which may be shared through Failure	<t>Due to the nature of the email contents that may be shared through failure
	Reports, most Mail Receivers refuse to send them out of privacy concerns. Out	reports, most Mail Receivers refuse to send them out of privacy concerns.
	of band agreements between Report Consumers and Mail Receivers may be required	Out-of-band agreements between Report Consumers and Mail Receivers may be requir
		ed
	to address these concerns.</t>	to address these concerns.</t>

	<t>DMARC Policy Records for multi-organizational PSDs <bcp14>MUST NOT</bcp14> in clude the "ruf" tag.</t>	<t>DMARC Policy Records for multi-organizational PSDs <bcp14>MUST NOT</bcp14> in clude the "ruf" tag.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="security-considerations"><name>Security Considerations</name>	<section anchor="security-considerations"><name>Security Considerations</name>
	<t>This section discusses security issues and possible remediations	<t>This section discusses security issues and possible remediations
	(where available) for DMARC.</t>	(where available) for DMARC.</t>

	<section anchor="authentication-methods"><name>Authentication Methods</name>	<section anchor="authentication-methods"><name>Authentication Methods</name>
	<t>Security considerations from the authentication methods used by DMARC	<t>Security considerations from the authentication methods used by DMARC
	are incorporated here by reference.</t>	are incorporated here by reference.</t>
	<t>Both of the email authentication methods that underlie DMARC provide some	<t>Both of the email authentication methods that underlie DMARC provide some

	assurance that an email was transmitted by an MTA which is authorized to	assurance that an email was transmitted by an MTA that is authorized to
	do so. SPF policies map domain names to sets of authorized MTAs (see <xref targe	do so. SPF policies map domain names to sets of authorized MTAs (see <xref targe
	t="RFC7208" sectionFormat="of" section="11.4"></xref>).	t="RFC7208" sectionFormat="of" section="11.4"/>).
	Validated DKIM signatures indicate that an email was transmitted by an MTA with	Validated DKIM signatures indicate that an email was transmitted by an MTA with
	access to a private key that matches the published DKIM key record.</t>	access to a private key that matches the published DKIM key record.</t>
	<t>Whenever mail is sent, there is a risk that an overly permissive source	<t>Whenever mail is sent, there is a risk that an overly permissive source

	may send mail that will receive a DMARC pass result that was not, in fact,	may send mail that will receive a DMARC "pass" result that was not, in fact,
	intended by the Domain Owner. These results may lead to issues when	intended by the Domain Owner. These results may lead to issues when

	systems interpret DMARC pass results to indicate a message is in some way	systems interpret DMARC "pass" results to indicate a message is in some way
	authentic. They also allow such unauthorized senders to evade the Domain	authentic. They also allow such unauthorized senders to evade the Domain
	Owner's intended message handling for DMARC validation failures.</t>	Owner's intended message handling for DMARC validation failures.</t>

	<t>To avoid this risk one must ensure that no unauthorized source can add	<t>To avoid this risk, one must ensure that no unauthorized source can add
	DKIM signatures to the domain's mail or transmit mail which will evaluate	DKIM signatures to the domain's mail or transmit mail that will evaluate
	as SPF pass. If, nonetheless, a Domain Owner wishes to include a	as an SPF "pass" result. Nonetheless, if a Domain Owner wishes to include a
	permissive source in a domain's SPF record, the source can be excluded	permissive source in a domain's SPF record, the source can be excluded

	from DMARC consideration by using the "?" qualifier on the SPF record	from DMARC consideration by using the "?" qualifier on the SPF record
	mechanism associated with that source. The DMARC working group had a	mechanism associated with that source. The DMARC Working Group had a
	lively discussion about possibly eliminating SPF entirely as an underlying	lively discussion about possibly eliminating SPF entirely as an underlying

	Authentication Mechanism for DMARC, but consensus was not reached, and	authentication mechanism for DMARC, but consensus was not reached, and
	the suggestion to use the "?" qualifier for permissive sources is pres	the suggestion to use the "?" qualifier for permissive sources is presented
	ented
	here instead.</t>	here instead.</t>
	</section>	</section>

	<section anchor="attacks-on-reporting-uris"><name>Attacks on Reporting URIs</nam e>	<section anchor="attacks-on-reporting-uris"><name>Attacks on Reporting URIs</nam e>
	<t>URIs published in DNS TXT records are well-understood possible	<t>URIs published in DNS TXT records are well-understood possible

	targets for attack. Specifications such as <xref target="RFC1035"></xref> and	targets for an attack. Specifications such as <xref target="RFC1035"/> and
	<xref target="RFC2142"></xref> either expose or cause the exposure of email addr	<xref target="RFC2142"/> either expose or cause the exposure of email addresses
	esses that	that
	could be flooded by an attacker, for example. Records found in the DNS such as M X, NS,	could be flooded by an attacker, for example. Records found in the DNS such as M X, NS,

	and others advertise potential attack destinations. Common DNS names such	and others advertise potential attack destinations. Common DNS names, such
	as "www" plainly identify the locations at which particular services c	as "www", plainly identify the locations at which particular services can
	an
	be found, providing destinations for targeted denial-of-service or	be found, providing destinations for targeted denial-of-service or
	penetration attacks. This all means that Domain Owners will need to harden	penetration attacks. This all means that Domain Owners will need to harden
	these addresses against various attacks, including but not limited to:</t>	these addresses against various attacks, including but not limited to:</t>

	<ul>	<ul>
	<li><t>high-volume denial-of-service attacks;</t>	<li><t>high-volume denial-of-service attacks;</t>
	</li>	</li>
	<li><t>deliberate construction of malformed reports intended to identify	<li><t>deliberate construction of malformed reports intended to identify

	or exploit parsing or processing vulnerabilities;</t>	or exploit parsing or processing vulnerabilities; and</t>
	</li>	</li>
	<li><t>deliberate construction of reports containing false claims for the	<li><t>deliberate construction of reports containing false claims for the
	Submitter or Reported-Domain fields, including the possibility of	Submitter or Reported-Domain fields, including the possibility of
	false data from compromised but known Mail Receivers.</t>	false data from compromised but known Mail Receivers.</t>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>

	<section anchor="dns-security"><name>DNS Security</name>	<section anchor="dns-security"><name>DNS Security</name>

	<t>The DMARC mechanism and its underlying Authentication Mechanisms (SPF and DKI M)	<t>The DMARC mechanism and its underlying authentication mechanisms (SPF and DKI M)
	depend on the security of the DNS. Examples of how hostile parties can	depend on the security of the DNS. Examples of how hostile parties can
	have an adverse impact on DNS traffic include:</t>	have an adverse impact on DNS traffic include:</t>

	<ul>	<ul>
	<li><t>If they can snoop on DNS traffic, they can get an idea of who is	<li><t>If they can snoop on DNS traffic, they can get an idea of who is
	receiving mail using the domain(s) in question.</t>	receiving mail using the domain(s) in question.</t>
	</li>	</li>
	<li><t>If they can block outgoing or reply DNS messages, they can prevent	<li><t>If they can block outgoing or reply DNS messages, they can prevent
	systems from discovering senders' DMARC policies.</t>	systems from discovering senders' DMARC policies.</t>
	</li>	</li>
	<li><t>If they can send forged response packets, they can make aligned mail	<li><t>If they can send forged response packets, they can make aligned mail

	appear unaligned or vice-versa.</t>	appear unaligned or vice versa.</t>
	</li>	</li>
	</ul>	</ul>
	<t>None of these threats are unique to DMARC, and they can be addressed using	<t>None of these threats are unique to DMARC, and they can be addressed using

	a variety of techniques, including, but not limited to:</t>	a variety of techniques including, but not limited to, the following:</t>

	<ul>	<ul>

	<li><t>Signing DNS records with Domain Name System Security Extensions (DNSSEC) <xref target="RFC9364"></xref>,	<li><t>Signing DNS records with Domain Name System Security Extensions (DNSSEC) <xref target="RFC9364"/>,
	which enables recipients to validate the integrity of DNS data and detect and di scard	which enables recipients to validate the integrity of DNS data and detect and di scard
	forged responses.</t>	forged responses.</t>
	</li>	</li>

	<li><t>DNS over TLS <xref target="RFC7858"></xref> or DNS over HTTPS <xref targe t="RFC8484"></xref> can mitigate snooping	<li><t>DNS over TLS <xref target="RFC7858"/> or DNS over HTTPS <xref target="RFC 8484"/> can mitigate snooping
	and forged responses.</t>	and forged responses.</t>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>

	<section anchor="display-name-attacks"><name>Display Name Attacks</name>	<section anchor="display-name-attacks"><name>Display Name Attacks</name>
	<t>An increasingly common attack in messaging abuse is the presentation of false	<t>An increasingly common attack in messaging abuse is the presentation of false

	information in the display-name portion of the RFC5322.From header field.	information in the display name portion of the RFC5322.From header field.
	For example, it is possible for the email address in that field to be	For example, it is possible for the email address in that field to be
	an arbitrary address or domain name while containing a well-known	an arbitrary address or domain name while containing a well-known
	name (a person, brand, role, etc.) in the display name, intending to	name (a person, brand, role, etc.) in the display name, intending to
	fool the end user into believing that the name is used legitimately.</t>	fool the end user into believing that the name is used legitimately.</t>
	<t>Such attacks, known as display name attacks, are out of scope for DMARC.</t>	<t>Such attacks, known as display name attacks, are out of scope for DMARC.</t>
	</section>	</section>

	<section anchor="denial-of-dmarc-attacks"><name>Denial of DMARC Processing Attac ks</name>	<section anchor="denial-of-dmarc-attacks"><name>Denial of DMARC Processing Attac ks</name>

	<t>The declaration in <xref target="extract-author-domain"></xref> and elsewhere in this document	<t>The declaration in <xref target="extract-author-domain"/> and elsewhere in th is document
	that messages that do not contain precisely one RFC5322.From domain are	that messages that do not contain precisely one RFC5322.From domain are
	outside the scope of this document exposes an attack vector that must be	outside the scope of this document exposes an attack vector that must be
	taken into consideration.</t>	taken into consideration.</t>
	<t>Because such messages are outside the scope of this document, an attacker	<t>Because such messages are outside the scope of this document, an attacker
	can craft messages with multiple RFC5322.From domains, including the spoofed	can craft messages with multiple RFC5322.From domains, including the spoofed
	domain, in an effort to bypass DMARC validation and get the fraudulent message	domain, in an effort to bypass DMARC validation and get the fraudulent message

	to be displayed by the victim's MUA with the spoofed domain successfully shown	to be displayed by the victim's Mail User Agent (MUA) with the spoofed domain su ccessfully shown
	to the victim. In those cases where such messages are not rejected due to other	to the victim. In those cases where such messages are not rejected due to other

	reasons (for example, many such messages would violate RFC5322's requirement tha t	reasons (for example, many such messages would violate the requirement described in <xref target="RFC5322"/> that
	there be precisely one From: header field), care must be taken by the Mail Recei ver	there be precisely one From: header field), care must be taken by the Mail Recei ver
	to recognize such messages as the threats they might be and handle them	to recognize such messages as the threats they might be and handle them
	appropriately.</t>	appropriately.</t>
	<t>The case of a syntactically valid multi-valued RFC5322.From field presents a	<t>The case of a syntactically valid multi-valued RFC5322.From field presents a
	particular challenge. Experience has shown that most such messages are abusive	particular challenge. Experience has shown that most such messages are abusive
	and/or unwanted by their recipients, and given this fact, a Mail Receiver may ma ke a	and/or unwanted by their recipients, and given this fact, a Mail Receiver may ma ke a
	negative disposition decision for the message prior to and instead of its being	negative disposition decision for the message prior to and instead of its being
	subjected to DMARC processing. However, in a case where a Mail Receiver requires	subjected to DMARC processing. However, in a case where a Mail Receiver requires
	that the message be subject to DMARC validation, a recommended approach as per	that the message be subject to DMARC validation, a recommended approach as per

	<xref target="RFC7489"></xref> is to apply the DMARC mechanism to each domain fo und in the RFC5322.From	<xref target="RFC7489"/> is to apply the DMARC mechanism to each domain found in the RFC5322.From
	field as the Author Domain and apply the most strict policy selected among the	field as the Author Domain and apply the most strict policy selected among the
	checks that fail. Such an approach might prove useful for a small number of	checks that fail. Such an approach might prove useful for a small number of
	Author Domains, but it is possible that applying such logic to messages with	Author Domains, but it is possible that applying such logic to messages with

	a large number of domains (where "large" is defined by each Mail Recei	a large number of domains (where "large" is defined by each Mail Receiver) will
	ver) will	expose the Mail Receiver to a form of denial-of-service attack. Limiting the num
	expose the Mail Receiver to a form of denial of service attack. Limiting the num	ber of
	ber of
	Author Domains processed will avoid this risk. If not all Author Domains are	Author Domains processed will avoid this risk. If not all Author Domains are
	processed, then the DMARC evaluation is incomplete.</t>	processed, then the DMARC evaluation is incomplete.</t>
	</section>	</section>

	<section anchor="external-report-addresses"><name>External Reporting Addresses</ name>	<section anchor="external-report-addresses"><name>External Reporting Addresses</ name>
	<t>To avoid abuse by bad actors, reporting addresses generally have to	<t>To avoid abuse by bad actors, reporting addresses generally have to
	be inside the domains about which reports are requested. To	be inside the domains about which reports are requested. To

	accommodate special cases such as a need to get reports about domains	accommodate special cases, such as a need to get reports about domains
	that cannot actually receive mail, <xref target="I-D.ietf-dmarc-aggregate-report	that cannot actually receive mail, <xref target="RFC9990" sectionFormat="of" sec
	ing" sectionFormat="of" section="3"></xref> describes	tion="3"/> describes
	a DNS-based mechanism for validating approved external reporting.</t>	a DNS-based mechanism for validating approved external reporting.</t>
	<t>The obvious consideration here is an increased DNS load against	<t>The obvious consideration here is an increased DNS load against
	domains that are claimed as external recipients. Negative caching	domains that are claimed as external recipients. Negative caching
	will mitigate this problem, but only to a limited extent, mostly	will mitigate this problem, but only to a limited extent, mostly
	dependent on the default TTL in the domain's SOA record.</t>	dependent on the default TTL in the domain's SOA record.</t>
	<t>Where possible, external reporting is best achieved by having the	<t>Where possible, external reporting is best achieved by having the
	report be directed to domains that can receive mail and simply having	report be directed to domains that can receive mail and simply having
	it automatically forwarded to the desired external destination.</t>	it automatically forwarded to the desired external destination.</t>

	<t>Note that the addresses shown in the "ruf" tag receive more	<t>Note that the addresses shown in the "ruf" tag receive more
	information that might be considered private data since it is	information that might be considered private data since it is
	possible for actual email content to appear in the failure reports.	possible for actual email content to appear in the failure reports.
	The URIs identified there are thus more attractive targets for	The URIs identified there are thus more attractive targets for

	intrusion attempts than those found in the "rua" tag. Moreover,	intrusion attempts than those found in the "rua" tag. Moreover,
	attacking the DNS of the subject domain to cause failure data to be	attacking the DNS of the subject domain to cause failure data to be
	routed fraudulently to an attacker's systems may be an attractive	routed fraudulently to an attacker's systems may be an attractive

	prospect. Deployment of DNSSEC <xref target="RFC9364"></xref> is advisable if th is is a concern.</t>	prospect. Deployment of DNSSEC <xref target="RFC9364"/> is advisable if this is a concern.</t>
	</section>	</section>

	<section anchor="secure-protocols"><name>Secure Protocols</name>	<section anchor="secure-protocols"><name>Secure Protocols</name>
	<t>This document encourages the use of secure transport mechanisms to	<t>This document encourages the use of secure transport mechanisms to
	prevent the loss of private data to third parties that may be able to	prevent the loss of private data to third parties that may be able to
	monitor such transmissions. Unencrypted mechanisms <bcp14>SHOULD</bcp14> be	monitor such transmissions. Unencrypted mechanisms <bcp14>SHOULD</bcp14> be
	avoided.</t>	avoided.</t>
	<t>In particular, a message that was originally encrypted or otherwise	<t>In particular, a message that was originally encrypted or otherwise
	secured might appear in a report that is not sent securely, which	secured might appear in a report that is not sent securely, which
	could reveal private information.</t>	could reveal private information.</t>
	</section>	</section>

	<section anchor="relaxed-alignment-considerations"><name>Relaxed Alignment Consi derations</name>	<section anchor="relaxed-alignment-considerations"><name>Relaxed Alignment Consi derations</name>

	<t>The DMARC mechanism allows both <eref target="#identifier-alignment-explained	<t>The DMARC mechanism allows both <xref target="identifier-alignment-explained"
	">DKIM- and SPF-Authenticated Identifiers</eref>	>DKIM- and SPF-Authenticated Identifiers</xref>
	to validate authorized use of an <eref target="#author-domain">Author Domain</er	to validate authorized use of an <xref target="author-domain">Author Domain</xre
	ef> on behalf of a <eref target="#domain-owner">Domain Owner</eref>. If malicio	f> on behalf of a <xref target="domain-owner">Domain Owner</xref>. If malicious
	us or unaware users can gain control of the SPF record or DKIM selector	or unaware users can gain control of the SPF record or DKIM selector
	records for a subdomain of the Organizational Domain, the subdomain can be used to generate email	records for a subdomain of the Organizational Domain, the subdomain can be used to generate email
	that achieves a DMARC pass on behalf of the Organizational Domain.</t>	that achieves a DMARC pass on behalf of the Organizational Domain.</t>
	<t>A scenario such as this could occur under the following conditions:</t>	<t>A scenario such as this could occur under the following conditions:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>A DMARC Policy Record exists for the domain "example.com", such th	<li>A DMARC Policy Record exists for the domain "example.com", such that "exampl
	at "example.com" is an Organizational Domain</li>	e.com" is an Organizational Domain.</li>
	<li>An attacker controls DNS for the domain "evil.example.com" and pub	<li>An attacker controls DNS for the domain "evil.example.com" and publishes an
	lishes an SPF record for that domain</li>	SPF record for that domain.</li>
	<li>The attacker sends email with RFC5322.From header field containing "foo	<li>The attacker sends email with the RFC5322.From header field containing "foo@
	@example.com" and an SPF-Authenticated Identifier of "evil.example.com	example.com" and an SPF-Authenticated Identifier of "evil.example.com".</li>
	"</li>
	</ul>	</ul>
	<t>Although this email was not authorized by the Domain Owner, it can produce a DMARC pass because the SPF-Authenticated Identifier	<t>Although this email was not authorized by the Domain Owner, it can produce a DMARC pass because the SPF-Authenticated Identifier

	("evil.example.com") has Identifier Alignment with the Author Domain ( "example.com").</t>	("evil.example.com") has Identifier Alignment with the Author Domain ("example.c om").</t>
	<t>The Organizational Domain Owner should be careful not to delegate control of subdomains if this is an	<t>The Organizational Domain Owner should be careful not to delegate control of subdomains if this is an

	issue, and consider using the <eref target="#strict-alignment">Strict Alignment< /eref> option if appropriate.</t>	issue and consider using the <xref target="strict-alignment">strict alignment</x ref> option if appropriate.</t>
	<t>DMARC evaluation for relaxed alignment is also highly sensitive to errors in	<t>DMARC evaluation for relaxed alignment is also highly sensitive to errors in
	determining the Organizational Domain if the Author Domain does not have a publi shed	determining the Organizational Domain if the Author Domain does not have a publi shed

	<eref target="#dmarc-policy-record">DMARC Policy Record</eref>. If an incorrectl y selected Organizational	<xref target="dmarc-policy-record">DMARC Policy Record</xref>. If an incorrectly selected Organizational
	Domain is a parent of the correct Organizational Domain, then relaxed alignment could	Domain is a parent of the correct Organizational Domain, then relaxed alignment could
	potentially allow a malicious sender to send mail that achieves a DMARC pass ver dict.	potentially allow a malicious sender to send mail that achieves a DMARC pass ver dict.

	This potential exists for both the legacy <xref target="RFC7489"></xref> and cur	This potential exists for both the legacy <xref target="RFC7489"/> and current m
	rent methods for determining	ethods for determining
	the organizational domain, the latter described in <xref target="identifier-alig	the Organizational Domain; the latter is described in <xref target="identifier-a
	nment-evaluation"></xref>.</t>	lignment-evaluation"/>.</t>
	<t>The following example illustrates this possibility:</t>	<t>The following example illustrates this possibility:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Mail is sent with an Author Domain of "a.mail.example.com" and Aut	<li>Mail is sent with an Author Domain of "a.mail.example.com" and Authenticated
	henticated Identifiers of "mail.example.com"</li>	Identifiers of "mail.example.com".</li>
	<li>There is no DMARC Policy Record published at "_dmarc.a.mail.example.com	<li>There is no DMARC Policy Record published at "_dmarc.a.mail.example.com".</l
	"</li>	i>
	<li>There is one published at "_dmarc.mail.example.com" and this is in	<li>There is one published at "_dmarc.mail.example.com" and this is intended to
	tended to be the Organizational Domain for this message</li>	be the Organizational Domain for this message.</li>
	<li>There is also a DMARC Policy Record published at "_dmarc.example.com&qu	<li>There is also a DMARC Policy Record published at "_dmarc.example.com", with
	ot;, with default alignment (relaxed)</li>	default alignment (relaxed).</li>
	<li>An attacker is able to send mail with the Author Domain of "evil.exampl	<li>An attacker is able to send mail with the Author Domain of "evil.example.com
	e.com" and an Authenticated Identifier of "mail.example.com"</li>	" and an Authenticated Identifier of "mail.example.com".</li>
	</ul>	</ul>

	<t>In this scenario, if a Mail Receiver incorrectly determines the Organizationa l Domain to be "example.com",	<t>In this scenario, if a Mail Receiver incorrectly determines the Organizationa l Domain to be "example.com",
	then the attacker's mail will pass DMARC validation checks.</t>	then the attacker's mail will pass DMARC validation checks.</t>

	<t>This issue is entirely avoided by the use of Strict Alignment and publishing explicit	<t>This issue is entirely avoided by the use of strict alignment and publishing explicit
	DMARC Policy Records for all Author Domains used in an organization's email.</t>	DMARC Policy Records for all Author Domains used in an organization's email.</t>

	<t>For cases where Strict Alignment is not appropriate, this issue can be mitiga	<t>For cases where strict alignment is not appropriate, this issue can be mitiga
	ted by the Domain	ted by the Domain
	Owner periodically (perhaps weekly, or whatever frequency might be appropriate f	Owner periodically checking (perhaps weekly or whatever frequency might be appro
	or a given organization's	priate for a given organization's
	operational needs) checking the DMARC Policy Records, if any, of <eref target="#	operational needs) the DMARC Policy Records, if any, of <xref target="public-suf
	public-suffix-domain">PSDs</eref>	fix-domain">PSDs</xref>
	above the Organizational Domain in the DNS tree and (for legacy <xref target="RF	above the Organizational Domain in the DNS tree (and for legacy <xref target="RF
	C7489"></xref> checking that	C7489"/>, checking that
	appropriate PSL entries remain present). If a PSD publishes a DMARC Policy Recor d without	appropriate PSL entries remain present). If a PSD publishes a DMARC Policy Recor d without

	the appropriate "psd=y" tag, Organizational Domain owners can add &quo t;psd=n" to their Organizational	the appropriate "psd=y" tag, Organizational Domain owners can add "psd=n" to the ir Organizational
	Domain's DMARC Policy Record so that the PSD's DMARC Policy Record will not be i ncorrectly	Domain's DMARC Policy Record so that the PSD's DMARC Policy Record will not be i ncorrectly
	interpreted to indicate that the PSD is the Organizational Domain.</t>	interpreted to indicate that the PSD is the Organizational Domain.</t>
	</section>	</section>
	</section>	</section>

	</middle>	</middle>


		<!-- [rfced] References

		a) [M3AUTH] Please review. The current URL for this reference -
		https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-
		recommended-best-practices-09-2020.pdf - resolves to a page with the right
		title, but there doesn't appear to be any content at the URL. Is this the
		correct link for this reference?

		b) [M3SPF] Please review. The current URL for this reference -
		https://www.m3aawg.org/Managing-SPF-Records - results in a page with a
		"Page not found" message. We were unable to find a URL matching the
		information for this reference. Is there another URL we should use for
		this reference?
		-->

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

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dma	<!--
	rc-aggregate-reporting.xml"/>	draft-ietf-dmarc-aggregate-reporting-32
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dma	companion doc RFC YYY1
	rc-failure-reporting.xml"/>	in EDIT as of 03/30/26
		-->

		<reference anchor="RFC9990" target="https://www.rfc-editor.org/info/rfc9990">
		<front>
		<title>Domain-Based Message Authentication, Reporting, and Conformance (DMAR
		C) Aggregate Reporting</title>
		<author fullname="Alex Brotman" initials="A." surname="Brotman" role="editor
		">
		<organization>Comcast, Inc.</organization>
		</author>
		<date month="May" year="2026"/>
		</front>
		<seriesInfo name="RFC" value="9990"/>
		<seriesInfo name="DOI" value="10.17487/RFC9990"/>
		</reference>
		<!--
		draft-ietf-dmarc-failure-reporting-25
		companion doc RFC YYY2
		in RFC-EDITOR as of 05/08/26
		-->
		<reference anchor="RFC9991" target="https://www.rfc-editor.org/info/rfc9991">
		<front>
		<title>Domain-Based Message Authentication, Reporting, and Conformance (DMAR
		C) Failure Reporting</title>
		<author fullname="Steven M Jones" initials="S. M." surname="Jones" role="edi
		tor">
		<organization>DMARC.org</organization>
		</author>
		<author fullname="Alessandro Vesely" initials="A." surname="Vesely" role="ed
		itor">
		<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.1035.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4343.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4343.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.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.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.6376.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6377.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6377.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6591.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6591.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6651.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6651.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6652.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6652.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.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.7405.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" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8601.xml" />
	</references>	</references>
	<references><name>Informative References</name>	<references><name>Informative References</name>
	<reference anchor="M3AUTH" target="https://www.m3aawg.org/sites/default/files/m3 aawg-email-authentication-recommended-best-practices-09-2020.pdf">	<reference anchor="M3AUTH" target="https://www.m3aawg.org/sites/default/files/m3 aawg-email-authentication-recommended-best-practices-09-2020.pdf">
	<front>	<front>
	<title>M3AAWG Email Authentication Recommended Best Practices</title>	<title>M3AAWG Email Authentication Recommended Best Practices</title>

	<author></author>	<author>
		<organization>Messaging Malware Mobile Anti-Abuse Working Group (M3AAWG)</
		organization>
		</author>
	</front>	</front>
	</reference>	</reference>
	<reference anchor="M3SPF" target="https://www.m3aawg.org/Managing-SPF-Records">	<reference anchor="M3SPF" target="https://www.m3aawg.org/Managing-SPF-Records">
	<front>	<front>
	<title>M3AAWG Best Practices for Managing SPF Records</title>	<title>M3AAWG Best Practices for Managing SPF Records</title>

	<author></author>	<author>
		<organization>Messaging Malware Mobile Anti-Abuse Working Group (M3AAWG)</
		organization>
		</author>
	</front>	</front>
	</reference>	</reference>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2142.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2142.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3464.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3464.xml" />

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4870.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4870.xml" />
	<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.5598.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.7489.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7960.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7960.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8020.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8020.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.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.8484.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8617.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8617.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9091.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9091.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml" />
	</references>	</references>
	</references>	</references>

	<section anchor="technology-considerations"><name>Technology Considerations</nam e>	<section anchor="technology-considerations"><name>Technology Considerations</nam e>
	<t>This section documents some design decisions made in the	<t>This section documents some design decisions made in the
	development of DMARC. Specifically addressed here are some	development of DMARC. Specifically addressed here are some
	suggestions that were considered but not included in the design,	suggestions that were considered but not included in the design,
	with explanatory text regarding the decision.</t>	with explanatory text regarding the decision.</t>

	<section anchor="s-mime"><name>S/MIME</name>	<section anchor="s-mime"><name>S/MIME</name>

	<t>S/MIME, or Secure Multipurpose Internet Mail Extensions <xref target="RFC8551 "></xref>,	<t>S/MIME, or Secure Multipurpose Internet Mail Extensions <xref target="RFC8551 "/>,
	is a standard for encrypting and signing MIME data in a message. This	is a standard for encrypting and signing MIME data in a message. This
	was suggested and considered as a third security protocol for	was suggested and considered as a third security protocol for
	authenticating the source of a message.</t>	authenticating the source of a message.</t>
	<t>DMARC is focused on authentication at the domain level (i.e., the	<t>DMARC is focused on authentication at the domain level (i.e., the
	Domain Owner taking responsibility for the message), while S/MIME is	Domain Owner taking responsibility for the message), while S/MIME is
	really intended for user-to-user authentication and encryption. This	really intended for user-to-user authentication and encryption. This
	alone appears to make it a bad fit for DMARC's goals.</t>	alone appears to make it a bad fit for DMARC's goals.</t>
	<t>S/MIME also suffers from the heavyweight problem of Public Key	<t>S/MIME also suffers from the heavyweight problem of Public Key

	Infrastructure, which means that distribution of keys used to validate	Infrastructure (PKI), which means that distribution of keys used to validate
	signatures needs to be incorporated. In many instances, this alone	signatures needs to be incorporated. In many instances, this alone
	is a showstopper. There have been consistent promises that PKI	is a showstopper. There have been consistent promises that PKI
	usability and deployment will improve, but these have yet to	usability and deployment will improve, but these have yet to
	materialize. DMARC can revisit this choice after those barriers are	materialize. DMARC can revisit this choice after those barriers are
	addressed.</t>	addressed.</t>
	<t>S/MIME has extensive deployment in specific market segments	<t>S/MIME has extensive deployment in specific market segments
	(government, for example) but does not enjoy similar widespread	(government, for example) but does not enjoy similar widespread
	deployment over the general Internet, and this shows no signs of	deployment over the general Internet, and this shows no signs of
	changing. DKIM and SPF are both deployed widely over the general	changing. DKIM and SPF are both deployed widely over the general
	Internet, and their adoption rates continue to be positive.</t>	Internet, and their adoption rates continue to be positive.</t>
	<t>Finally, experiments have shown that including S/MIME support in the	<t>Finally, experiments have shown that including S/MIME support in the
	initial version of DMARC would neither cause nor enable a substantial	initial version of DMARC would neither cause nor enable a substantial
	increase in the accuracy of the overall mechanism.</t>	increase in the accuracy of the overall mechanism.</t>
	</section>	</section>

	<section anchor="method-exclusion"><name>Method Exclusion</name>	<section anchor="method-exclusion"><name>Method Exclusion</name>
	<t>It was suggested that DMARC include a mechanism by which a Domain	<t>It was suggested that DMARC include a mechanism by which a Domain
	Owner could instruct Mail Receivers not to attempt validation by one	Owner could instruct Mail Receivers not to attempt validation by one

	of the supported methods (e.g., "check DKIM, but not SPF").</t>	of the supported methods (e.g., "check DKIM, but not SPF").</t>
	<t>Specifically, consider a Domain Owner that has deployed one of the	<t>Specifically, consider a Domain Owner that has deployed one of the
	technologies and that technology fails for some messages, but such	technologies and that technology fails for some messages, but such
	failures don't cause enforcement action. Deploying DMARC would cause	failures don't cause enforcement action. Deploying DMARC would cause

	enforcement action for policies other than "none", which would appear	enforcement action for policies other than "none", which would appear
	to exclude participation by that Domain Owner.</t>	to exclude participation by that Domain Owner.</t>
	<t>The DMARC development team evaluated the idea of policy exception	<t>The DMARC development team evaluated the idea of policy exception
	mechanisms on several occasions and invariably concluded that there	mechanisms on several occasions and invariably concluded that there
	was not a strong enough use case to include them. The target audience	was not a strong enough use case to include them. The target audience
	for DMARC does not appear to have concerns about the failure modes of	for DMARC does not appear to have concerns about the failure modes of
	one or the other being a barrier to DMARC's adoption.</t>	one or the other being a barrier to DMARC's adoption.</t>
	<t>In the scenario described above, the Domain Owner has a few options:</t>	<t>In the scenario described above, the Domain Owner has a few options:</t>

	<ol>	<ol>
	<li><t>Tighten up its infrastructure to minimize the failure modes of	<li><t>Tighten up its infrastructure to minimize the failure modes of
	the single deployed technology.</t>	the single deployed technology.</t>
	</li>	</li>

	<li><t>Deploy the other supported authentication mechanism, to offset	<li><t>Deploy the other supported authentication mechanism to offset
	the failure modes of the first.</t>	the failure modes of the first.</t>
	</li>	</li>
	<li><t>Deploy DMARC in a reporting-only mode.</t>	<li><t>Deploy DMARC in a reporting-only mode.</t>
	</li>	</li>
	</ol>	</ol>
	</section>	</section>

	<section anchor="sender-header-field"><name>Sender Header Field</name>	<section anchor="sender-header-field"><name>Sender Header Field</name>
	<t>It has been suggested in several message authentication efforts that	<t>It has been suggested in several message authentication efforts that
	the Sender header field be checked for an identifier of interest, as	the Sender header field be checked for an identifier of interest, as
	the standards indicate this as the proper way to indicate a	the standards indicate this as the proper way to indicate a
	re-mailing of content such as through a mailing list. Most recently,	re-mailing of content such as through a mailing list. Most recently,

	it was a protocol-level option for DomainKeys <xref target="RFC4870"></xref>, bu t on evolution to	it was a protocol-level option for DomainKeys <xref target="RFC4870"/>, but on e volution to
	DKIM, this property was removed.</t>	DKIM, this property was removed.</t>
	<t>The DMARC development team considered this and decided not to include	<t>The DMARC development team considered this and decided not to include
	support for doing so for the following reasons:</t>	support for doing so for the following reasons:</t>

	<ol>	<ol>
	<li><t>The main user protection approach is to be concerned with what	<li><t>The main user protection approach is to be concerned with what
	the user sees when a message is rendered. There is no consistent	the user sees when a message is rendered. There is no consistent
	behavior among MUAs regarding what to do with the content of the	behavior among MUAs regarding what to do with the content of the
	Sender field, if present. Accordingly, supporting the checking of	Sender field, if present. Accordingly, supporting the checking of
	the Sender identifier would mean applying policy to an identifier	the Sender identifier would mean applying policy to an identifier

	skipping to change at line 2367 ¶	skipping to change at line 2597 ¶
	candidate for inclusion in the DMARC evaluation algorithm.</t>	candidate for inclusion in the DMARC evaluation algorithm.</t>
	</li>	</li>
	<li><t>Allowing multiple ways to discover policy introduces unacceptable	<li><t>Allowing multiple ways to discover policy introduces unacceptable
	ambiguity into the DMARC validation algorithm in terms of which	ambiguity into the DMARC validation algorithm in terms of which
	policy is to be applied and when.</t>	policy is to be applied and when.</t>
	</li>	</li>
	</ol>	</ol>
	</section>	</section>

	<section anchor="domain-existence-test"><name>Domain Existence Test</name>	<section anchor="domain-existence-test"><name>Domain Existence Test</name>

	<t>The presence of the "np" tag in this specification seemingly implie s that	<t>The presence of the "np" tag in this specification seemingly implies that
	there would be an agreed-upon standard for determining a domain's existence.</t>	there would be an agreed-upon standard for determining a domain's existence.</t>
	<t>Since the DMARC mechanism is focused on email, one might think that the	<t>Since the DMARC mechanism is focused on email, one might think that the

	definition of "resolvable" in <xref target="RFC5321"></xref> applies. Using that definition, only	definition of "resolvable" in <xref target="RFC5321"/> applies. Using that defin ition, only
	names that resolve to MX Resource Records (RRs), A RRs, or AAAA RRs are deemed	names that resolve to MX Resource Records (RRs), A RRs, or AAAA RRs are deemed
	to be resolvable and to exist in the DNS. This is a common practice among Mail	to be resolvable and to exist in the DNS. This is a common practice among Mail
	Receivers to determine whether or not to accept a mail message before performing	Receivers to determine whether or not to accept a mail message before performing
	other more expensive processing.</t>	other more expensive processing.</t>
	<t>The DMARC mechanism makes no such requirement for the existence of specific D NS	<t>The DMARC mechanism makes no such requirement for the existence of specific D NS
	RRs in order for a domain to exist; instead, if any RR exists for a domain, then	RRs in order for a domain to exist; instead, if any RR exists for a domain, then

	the domain exists. To use the terminology from <xref target="RFC2308"></xref>, a	the domain exists. To use the terminology from <xref target="RFC2308"/>, an "NXD
	n "NXDOMAIN" response	OMAIN" response
	(rcode "Name Error") to a DNS query means that the domain name does no	(rcode "Name Error") to a DNS query means that the domain name does not exist,
	t exist,	while a "NODATA" response (rcode "NOERROR") means that the given Resource Record
	while a "NODATA" response (rcode "NOERROR") means that the g
	iven resource record
	type queried for does not exist, but the domain name does.</t>	type queried for does not exist, but the domain name does.</t>

	<t>Furthermore, in keeping with <xref target="RFC8020"></xref>, if a query for a name returns NXDOMAIN,	<t>Furthermore, in keeping with <xref target="RFC8020"/>, if a query for a name returns NXDOMAIN,
	then not only does the name not exist, every name below it in the DNS hierarchy	then not only does the name not exist, every name below it in the DNS hierarchy
	also does not exist.</t>	also does not exist.</t>
	</section>	</section>

	<section anchor="organizational-domain-discovery-issues"><name>Organizational Do main Discovery Issues</name>	<section anchor="organizational-domain-discovery-issues"><name>Organizational Do main Discovery Issues</name>

	<t>An earlier informational version of the DMARC mechanism <xref target="RFC7489
	"></xref>	<t>An earlier Informational version of the DMARC mechanism <xref target="RFC7489
	noted that the DNS does not provide a method by which the "domain of record	"/>
	",	noted that the DNS does not provide a method by which the "domain of record",
	or the domain that was actually registered with a domain registrar, can	or the domain that was actually registered with a domain registrar, can
	be determined given an arbitrary domain name. That version further mentioned	be determined given an arbitrary domain name. That version further mentioned
	suggestions that have been made that attempt to glean such information from	suggestions that have been made that attempt to glean such information from

	SOA or NS resource records, but these too are not fully reliable, as the	SOA or NS Resource Records, but these too are not fully reliable, as the
	partitioning of the DNS is not always done at administrative boundaries.</t>	partitioning of the DNS is not always done at administrative boundaries.</t>

	<t>That previous version posited that one could "climb the tree" to fi	<t>That previous version posited that one could "climb the tree" to find the
	nd the	Organizational Domain but expressed concern that an attacker could exploit
	Organizational Domain, but expressed concern that an attacker could exploit	this for a denial-of-service attack through sending a high number of messages,
	this for a denial-of-service attack through sending a high number of messages
	each with a relatively large number of nonsense labels, causing a Mail Receiver	each with a relatively large number of nonsense labels, causing a Mail Receiver
	to perform a large number of DNS queries in search of a DMARC Policy Record. Thi s	to perform a large number of DNS queries in search of a DMARC Policy Record. Thi s

	version defines a method for performing a <eref target="#dns-tree-walk">DNS Tree Walk</eref>,	version defines a method for performing a <xref target="dns-tree-walk">DNS Tree Walk</xref>
	and further mitigates the risk of the denial-of-service attack by expressly limi ting	and further mitigates the risk of the denial-of-service attack by expressly limi ting
	the number of DNS queries to execute regardless of the number of labels in the d omain	the number of DNS queries to execute regardless of the number of labels in the d omain
	name.</t>	name.</t>
	<t>Readers curious about the previous method for Organizational Domain Discovery are	<t>Readers curious about the previous method for Organizational Domain Discovery are

	directed to <xref target="RFC7489" sectionFormat="of" section="3.2"></xref>.</t>	directed to <xref target="RFC7489" sectionFormat="of" section="3.2"/>.</t>
	</section>	</section>


	<section anchor="removal-of-the-pct-tag"><name>Removal of the "pct" Ta	<section anchor="removal-of-the-pct-tag"><name>Removal of the "pct" Tag</name>
	g</name>	<t>An earlier informational version of the DMARC mechanism <xref target="RFC7489
	<t>An earlier informational version of the DMARC mechanism <xref target="RFC7489	"/>
	"></xref>	included a "pct" tag and specified all integers from 0 to 100 inclusive
	included a "pct" tag and specified all integers from 0 to 100 inclusiv	as valid values for the tag. The intent of the tag was to provide Domain
	e	Owners with a method to gradually change their preferred Domain Owner Assessment
	as valid values for the tag. The intent of the tag was to provide domain	Policy (the "p" tag) from "none" to "quarantine" or from "quarantine" to "reject
	owners with a method to gradually change their preferred Domain Owner Assessment	"
	Policy (the "p" tag) from "none" to "quarantine" o
	r from "quarantine" to "reject"
	by requesting the stricter treatment for just a percentage of messages	by requesting the stricter treatment for just a percentage of messages

	that produced DMARC results of "fail".</t>	that produced DMARC results of "fail".</t>
	<t>Operational experience showed that the pct tag was usually not accurately	<t>Operational experience showed that the "pct" tag was usually not accurately
	applied, unless the value specified was either 0 or 100 (the default),	applied, unless the value specified was either 0 or 100 (the default),
	and the inaccuracies with other values varied widely from one implementation to	and the inaccuracies with other values varied widely from one implementation to
	another. The default value was easily implemented, as it required no	another. The default value was easily implemented, as it required no
	special processing on the part of the Mail Receiver, while the value	special processing on the part of the Mail Receiver, while the value
	of 0 took on unintended significance as a value used by some intermediaries	of 0 took on unintended significance as a value used by some intermediaries
	and mailbox providers as an indicator to deviate from standard handling of	and mailbox providers as an indicator to deviate from standard handling of
	the message, usually by rewriting the RFC5322.From header field in an effort to	the message, usually by rewriting the RFC5322.From header field in an effort to
	avoid DMARC failures downstream.</t>	avoid DMARC failures downstream.</t>

	<t>These custom actions when the "pct" tag was set to 0 proved valuabl e to the	<t>These custom actions when the "pct" tag was set to 0 proved value to the
	email community. In particular, header field rewriting by an intermediary meant	email community. In particular, header field rewriting by an intermediary meant
	that a Domain Owner's aggregate reports could reveal to the Domain Owner	that a Domain Owner's aggregate reports could reveal to the Domain Owner
	how much of its traffic was routing through intermediaries that don't rewrite	how much of its traffic was routing through intermediaries that don't rewrite
	the RFC5322.From header field. Such information wasn't explicit in the aggregate	the RFC5322.From header field. Such information wasn't explicit in the aggregate
	reports received; rather, sussing it out required work on the part of the Domain	reports received; rather, sussing it out required work on the part of the Domain

	Owner to compare aggregate reports from before and after the "p" value	Owner to compare aggregate reports from before and after the "p" value was chang
	was changed	ed
	and "pct=0" was included in the DMARC Policy Record, but the data was	and "pct=0" was included in the DMARC Policy Record, but the data was there.
	there.
	Consequently, knowing how much mail was subject to possible DMARC failure due to	Consequently, knowing how much mail was subject to possible DMARC failure due to
	a lack of RFC5322.From header field rewriting by intermediaries could assist the	a lack of RFC5322.From header field rewriting by intermediaries could assist the

	Domain Owner in choosing whether to move from <eref target="#monitoring-mode">Mo	Domain Owner in choosing whether to move from <xref target="monitoring-mode">Mon
	nitoring Mode</eref>	itoring Mode</xref>
	to <eref target="#enforcement">Enforcement</eref>. Armed with this knowledge, t	to <xref target="enforcement">Enforcement</xref>. Armed with this knowledge, th
	he Domain Owner could	e Domain Owner could
	make an informed decision regarding subjecting its mail traffic to possible DMAR C	make an informed decision regarding subjecting its mail traffic to possible DMAR C
	failures based on the Domain Owner's tolerance for such things.</t>	failures based on the Domain Owner's tolerance for such things.</t>

	<t>Because of the value provided by "pct=0" to Domain Owners, it was l ogical	<t>Because of the value provided by "pct=0" to Domain Owners, it was logical
	to keep this functionality in the protocol; at the same time, it didn't make	to keep this functionality in the protocol; at the same time, it didn't make

	sense to support a tag named "pct" that had only two valid values. Thi	sense to support a tag named "pct" that had only two valid values. This version
	s version	of the DMARC mechanism, therefore, introduces the "t" tag as shorthand for "test
	of the DMARC mechanism, therefore, introduces the "t" tag as shorthand	ing",
	for "testing",	with the valid values of "y" and "n", which are meant to be analogous in their
	with the valid values of "y" and "n", which are meant to be	application by mailbox providers and intermediaries to the "pct" tag values
	analogous in their	"0" and "100", respectively.</t>
	application by mailbox providers and intermediaries to the "pct" tag v
	alues
	"0" and "100", respectively.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="examples"><name>Examples</name>	<section anchor="examples"><name>Examples</name>
	<t>This section illustrates both the Domain Owner side and the Mail	<t>This section illustrates both the Domain Owner side and the Mail
	Receiver side of a DMARC exchange.</t>	Receiver side of a DMARC exchange.</t>

	<section anchor="identifier-alignment-examples"><name>Identifier Alignment Examp les</name>	<section anchor="identifier-alignment-examples"><name>Identifier Alignment Examp les</name>
	<t>The following examples illustrate the DMARC mechanism's use of	<t>The following examples illustrate the DMARC mechanism's use of
	Identifier Alignment. For brevity's sake, only message header fields and	Identifier Alignment. For brevity's sake, only message header fields and
	relevant SMTP commands are shown, as message bodies are not considered	relevant SMTP commands are shown, as message bodies are not considered
	when conducting DMARC checks.</t>	when conducting DMARC checks.</t>

	<section anchor="spf"><name>SPF</name>	<section anchor="spf"><name>SPF</name>
	<t>The following SPF examples assume that SPF produces a passing result.	<t>The following SPF examples assume that SPF produces a passing result.
	Alignment cannot exist if SPF does not produce a passing result.</t>	Alignment cannot exist if SPF does not produce a passing result.</t>
	<t>Example 1: SPF in Strict Alignment:</t>	<t>Example 1: SPF in Strict Alignment:</t>


	<artwork><![CDATA[ MAIL FROM: <sender@example.com>	<artwork><![CDATA[
		MAIL FROM: <sender@example.com>

	From: sender@example.com	From: sender@example.com
	Date: Fri, Feb 15 2002 16:54:30 -0800	Date: Fri, Feb 15 2002 16:54:30 -0800
	To: receiver@example.org	To: receiver@example.org

	Subject: here's a sample	Subject: here's a sample]]></artwork>
	]]></artwork>
	<t>In this case, the RFC5321.MailFrom domain and the Author Domain are identical .	<t>In this case, the RFC5321.MailFrom domain and the Author Domain are identical .

	Thus, the identifiers are in Strict Alignment.</t>	Thus, the identifiers are in strict alignment.</t>
	<t>Example 2: SPF in Relaxed Alignment:</t>	<t>Example 2: SPF in Relaxed Alignment:</t>


	<artwork><![CDATA[ MAIL FROM: <sender@child.example.com>	<artwork><![CDATA[
		MAIL FROM: <sender@child.example.com>

	From: sender@example.com	From: sender@example.com
	Date: Fri, Feb 15 2002 16:54:30 -0800	Date: Fri, Feb 15 2002 16:54:30 -0800
	To: receiver@example.org	To: receiver@example.org

	Subject: here's a sample	Subject: here's a sample]]></artwork>
	]]></artwork>
	<t>In this case, the Author Domain (example.com) is a parent of the	<t>In this case, the Author Domain (example.com) is a parent of the
	RFC5321.MailFrom domain. Thus, the identifiers are in relaxed alignment	RFC5321.MailFrom domain. Thus, the identifiers are in relaxed alignment
	because they both have the same Organizational Domain (example.com).</t>	because they both have the same Organizational Domain (example.com).</t>
	<t>Example 3: No SPF Identifier Alignment:</t>	<t>Example 3: No SPF Identifier Alignment:</t>


	<artwork><![CDATA[ MAIL FROM: <sender@example.net>	<artwork><![CDATA[
		MAIL FROM: <sender@example.net>

	From: sender@child.example.com	From: sender@child.example.com
	Date: Fri, Feb 15 2002 16:54:30 -0800	Date: Fri, Feb 15 2002 16:54:30 -0800
	To: receiver@example.org	To: receiver@example.org

	Subject: here's a sample	Subject: here's a sample]]></artwork>
	]]></artwork>
	<t>In this case, the RFC5321.MailFrom domain that is neither the same as,	<t>In this case, the RFC5321.MailFrom domain is neither the same as,
	a parent of, nor a child of the Author Domain. Thus, the identifiers	a parent of, nor a child of the Author Domain. Thus, the identifiers
	are not in alignment.</t>	are not in alignment.</t>
	</section>	</section>

	<section anchor="dkim"><name>DKIM</name>	<section anchor="dkim"><name>DKIM</name>
	<t>The examples below assume that the DKIM signatures pass validation.	<t>The examples below assume that the DKIM signatures pass validation.
	Alignment cannot exist with a DKIM signature that does not validate.</t>	Alignment cannot exist with a DKIM signature that does not validate.</t>
	<t>Example 1: DKIM in Strict Alignment:</t>	<t>Example 1: DKIM in Strict Alignment:</t>


	<artwork><![CDATA[ DKIM-Signature: v=1; ...; d=example.com; ...	<artwork><![CDATA[
		DKIM-Signature: v=1; ...; d=example.com; ...
	From: sender@example.com	From: sender@example.com
	Date: Fri, Feb 15 2002 16:54:30 -0800	Date: Fri, Feb 15 2002 16:54:30 -0800
	To: receiver@example.org	To: receiver@example.org

	Subject: here's a sample	Subject: here's a sample]]></artwork>
	]]></artwork>
	<t>In this case, the DKIM "d" tag and the Author Domain have	<t>In this case, the DKIM "d" tag and the Author Domain have
	identical DNS domains. Thus, the identifiers are in Strict Alignment.</t>	identical DNS domains. Thus, the identifiers are in strict alignment.</t>
	<t>Example 2: DKIM in Relaxed Alignment:</t>	<t>Example 2: DKIM in Relaxed Alignment:</t>


	<artwork><![CDATA[ DKIM-Signature: v=1; ...; d=example.com; ...	<artwork><![CDATA[
		DKIM-Signature: v=1; ...; d=example.com; ...
	From: sender@child.example.com	From: sender@child.example.com
	Date: Fri, Feb 15 2002 16:54:30 -0800	Date: Fri, Feb 15 2002 16:54:30 -0800
	To: receiver@example.org	To: receiver@example.org

	Subject: here's a sample	Subject: here's a sample]]></artwork>
	]]></artwork>
	<t>In this case, the DKIM signature's "d" tag includes a DNS	<t>In this case, the DKIM signature's "d" tag includes a DNS
	domain that is a parent of the Author Domain. Thus, the	domain that is a parent of the Author Domain. Thus, the
	identifiers are in relaxed alignment, as they have the same	identifiers are in relaxed alignment, as they have the same
	Organizational Domain (example.com).</t>	Organizational Domain (example.com).</t>
	<t>Example 3: No DKIM Identifier Alignment:</t>	<t>Example 3: No DKIM Identifier Alignment:</t>


	<artwork><![CDATA[ DKIM-Signature: v=1; ...; d=example.net; ...	<artwork><![CDATA[
		DKIM-Signature: v=1; ...; d=example.net; ...
	From: sender@child.example.com	From: sender@child.example.com
	Date: Fri, Feb 15 2002 16:54:30 -0800	Date: Fri, Feb 15 2002 16:54:30 -0800
	To: receiver@example.org	To: receiver@example.org

	Subject: here's a sample	Subject: here's a sample]]></artwork>
	]]></artwork>
	<t>In this case, the DKIM signature's "d" tag includes a DNS	<t>In this case, the DKIM signature's "d" tag includes a DNS
	domain that is neither the same as, a parent of, nor a child of the	domain that is neither the same as, a parent of, nor a child of the
	Author Domain. Thus, the identifiers are not in alignment.</t>	Author Domain. Thus, the identifiers are not in alignment.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="domain-owner-example"><name>Domain Owner Example</name>	<section anchor="domain-owner-example"><name>Domain Owner Example</name>
	<t>A Domain Owner that wants to use DMARC should have already deployed	<t>A Domain Owner that wants to use DMARC should have already deployed
	and tested SPF and DKIM. The next step is to publish a DMARC Policy	and tested SPF and DKIM. The next step is to publish a DMARC Policy
	Record for the Domain Owner's Organizational Domain.</t>	Record for the Domain Owner's Organizational Domain.</t>

	<section anchor="entire-domain-monitoring-mode"><name>Entire Domain, Monitoring Mode</name>	<section anchor="entire-domain-monitoring-mode"><name>Entire Domain, Monitoring Mode</name>

	<t>The Domain Owner for "example.com" has deployed SPF and DKIM on	<t>The Domain Owner for "example.com" has deployed SPF and DKIM on
	its messaging infrastructure. The Domain Owner wishes to begin using DMARC	its messaging infrastructure. The Domain Owner wishes to begin using DMARC
	with a policy that will solicit aggregate feedback from Mail Receivers	with a policy that will solicit aggregate feedback from Mail Receivers
	without affecting how the messages are processed in order to:</t>	without affecting how the messages are processed in order to:</t>

	<ul>	<ul>
	<li><t>Confirm that its legitimate messages are authenticating correctly</t>	<li><t>Confirm that its legitimate messages are authenticating correctly</t>
	</li>	</li>
	<li><t>Validate that all authorized message sources have implemented	<li><t>Validate that all authorized message sources have implemented
	authentication measures</t>	authentication measures</t>
	</li>	</li>
	<li><t>Determine how many messages from other sources would be affected	<li><t>Determine how many messages from other sources would be affected
	by publishing a Domain Owner Assessment Policy at Enforcement</t>	by publishing a Domain Owner Assessment Policy at Enforcement</t>
	</li>	</li>
	</ul>	</ul>
	<t>The Domain Owner accomplishes this by constructing a DMARC Policy Record	<t>The Domain Owner accomplishes this by constructing a DMARC Policy Record
	indicating that:</t>	indicating that:</t>

	<ul>	<ul>

	<li><t>The version of DMARC being used is "DMARC1" ("v=DMARC1;&qu ot;)</t>	<li><t>The version of DMARC being used is "DMARC1" ("v=DMARC1;")</t>
	</li>	</li>
	<li><t>Mail Receivers should not alter how they treat these messages because	<li><t>Mail Receivers should not alter how they treat these messages because

	of this DMARC Policy Record ("p=none")</t>	of this DMARC Policy Record ("p=none")</t>
	</li>	</li>
	<li><t>Aggregate feedback reports are sent via email to the address	<li><t>Aggregate feedback reports are sent via email to the address

	"dmarc-feedback@example.com"	"dmarc-feedback@example.com"
	<tt>("rua=mailto:dmarc-feedback@example.com")</tt></t>	<tt>("rua=mailto:dmarc-feedback@example.com")</tt></t>
	</li>	</li>
	<li><t>All messages from this Organizational Domain are subject to this	<li><t>All messages from this Organizational Domain are subject to this

	policy (no "t" tag present, so the default of "n" applies).< /t>	policy (no "t" tag present, so the default of "n" applies)</t>
	</li>	</li>
	</ul>	</ul>
	<t>To publish such a record, the DNS administrator for the Domain Owner	<t>To publish such a record, the DNS administrator for the Domain Owner
	creates an entry like the following in the appropriate zone file	creates an entry like the following in the appropriate zone file
	(following the conventional zone file format):</t>	(following the conventional zone file format):</t>


	<artwork><![CDATA[ ; DMARC Policy Record for the domain example.com	<artwork><![CDATA[
		; DMARC Policy Record for the domain example.com
	_dmarc IN TXT ( "v=DMARC1; p=none; "	_dmarc IN TXT ( "v=DMARC1; p=none; "

	"rua=mailto:dmarc-feedback@example.com" )	"rua=mailto:dmarc-feedback@example.com" )]]></artwork>
	]]></artwork>
	</section>	</section>

	<section anchor="entire-domain-monitoring-mode-per-message-failure-reports"><nam e>Entire Domain, Monitoring Mode, Per-Message Failure Reports</name>	<section anchor="entire-domain-monitoring-mode-per-message-failure-reports"><nam e>Entire Domain, Monitoring Mode, Per-Message Failure Reports</name>
	<t>The Domain Owner from the previous example has used the aggregate	<t>The Domain Owner from the previous example has used the aggregate
	reporting to discover some messaging systems that had not yet	reporting to discover some messaging systems that had not yet
	implemented DKIM correctly, but they are still seeing periodic	implemented DKIM correctly, but they are still seeing periodic
	authentication failures. To diagnose these intermittent	authentication failures. To diagnose these intermittent
	problems, they wish to request per-message failure reports when	problems, they wish to request per-message failure reports when
	authentication failures occur.</t>	authentication failures occur.</t>
	<t>Not all Mail Receivers will honor such a request, but the Domain Owner	<t>Not all Mail Receivers will honor such a request, but the Domain Owner
	feels that any reports it does receive will be helpful enough to	feels that any reports it does receive will be helpful enough to
	justify publishing this record. The default per-message failure report	justify publishing this record. The default per-message failure report

	format (<xref target="RFC6591"></xref>) meets the Domain Owner's needs in this s cenario.</t>	format <xref target="RFC6591"/> meets the Domain Owner's needs in this scenario. </t>
	<t>The Domain Owner accomplishes this by adding the following to its	<t>The Domain Owner accomplishes this by adding the following to its

	DMARC Policy Record from <xref target="entire-domain-monitoring-mode"></xref>:</ t>	DMARC Policy Record from <xref target="entire-domain-monitoring-mode"/>:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Per-message failure reports are sent via email to the	<li>Per-message failure reports are sent via email to the

	address "auth-reports@example.com"	address "auth-reports@example.com"
	<tt>("ruf=mailto:auth-reports@example.com")</tt> </li>	<tt>("ruf=mailto:auth-reports@example.com")</tt> </li>
	</ul>	</ul>
	<t>To publish such a record, the DNS administrator for the Domain Owner	<t>To publish such a record, the DNS administrator for the Domain Owner
	might create an entry like the following in the appropriate zone file	might create an entry like the following in the appropriate zone file
	(following the conventional zone file format):</t>	(following the conventional zone file format):</t>


	<artwork><![CDATA[ ; DMARC Policy Record for the domain example.com	<artwork><![CDATA[
		; DMARC Policy Record for the domain example.com
	_dmarc IN TXT ( "v=DMARC1; p=none; "	_dmarc IN TXT ( "v=DMARC1; p=none; "
	"rua=mailto:dmarc-feedback@example.com; "	"rua=mailto:dmarc-feedback@example.com; "

	"ruf=mailto:auth-reports@example.com" )	"ruf=mailto:auth-reports@example.com" )]]></artwork>
	]]></artwork>
	</section>	</section>

	<section anchor="per-message-failure-reports-directed-to-third-party"><name>Per- Message Failure Reports Directed to Third Party</name>	<section anchor="per-message-failure-reports-directed-to-third-party"><name>Per- Message Failure Reports Directed to Third Party</name>
	<t>The Domain Owner from the previous example is maintaining the same	<t>The Domain Owner from the previous example is maintaining the same
	policy but now wishes to have a third party serve as a Report Consumer.	policy but now wishes to have a third party serve as a Report Consumer.
	Again, not all Mail Receivers will honor this request, but those that	Again, not all Mail Receivers will honor this request, but those that
	do <bcp14>MUST</bcp14> implement additional checks to validate that the third pa rty	do <bcp14>MUST</bcp14> implement additional checks to validate that the third pa rty
	authorizes reception of failure reports on behalf of this domain.</t>	authorizes reception of failure reports on behalf of this domain.</t>

	<t>The Domain Owner needs to alter its DMARC Policy Record from <xref target="en tire-domain-monitoring-mode-per-message-failure-reports"></xref>	<t>The Domain Owner needs to alter its DMARC Policy Record from <xref target="en tire-domain-monitoring-mode-per-message-failure-reports"/>
	as follows:</t>	as follows:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Per-message failure reports are sent via email to the	<li>Per-message failure reports are sent via email to the

	address "auth-reports@thirdparty.example.net"	address "auth-reports@thirdparty.example.net"
	<tt>("ruf=mailto:auth-reports@thirdparty.example.net")</tt></li>	<tt>("ruf=mailto:auth-reports@thirdparty.example.net")</tt></li>
	</ul>	</ul>
	<t>To publish such a record, the DNS administrator for the Domain Owner	<t>To publish such a record, the DNS administrator for the Domain Owner
	might create an entry like the following in the appropriate zone file	might create an entry like the following in the appropriate zone file
	(following the conventional zone file format):</t>	(following the conventional zone file format):</t>


	<artwork><![CDATA[ ; DMARC Policy Record for the domain example.com	<artwork><![CDATA[
		; DMARC Policy Record for the domain example.com
	_dmarc IN TXT ( "v=DMARC1; p=none; "	_dmarc IN TXT ( "v=DMARC1; p=none; "
	"rua=mailto:dmarc-feedback@example.com; "	"rua=mailto:dmarc-feedback@example.com; "

	"ruf=mailto:auth-reports@thirdparty.example.net" )	"ruf=mailto:auth-reports@thirdparty.example.net" )]]></artwork
	]]></artwork>	>
	<t>Because the address used in the "ruf" tag is outside the Organizati
	onal Domain	<t>Because the address used in the "ruf" tag is outside the Organizational Domai
		n
	in which this record is published, conforming Mail Receivers <bcp14>MUST</bcp14> implement	in which this record is published, conforming Mail Receivers <bcp14>MUST</bcp14> implement

	additional checks as described in <xref target="I-D.ietf-dmarc-aggregate-reporti ng" sectionFormat="of" section="3"></xref>.	additional checks as described in <xref target="RFC9990" sectionFormat="of" sect ion="3"/>.
	To pass these additional checks, the Report Consumer's Domain Owner will need to	To pass these additional checks, the Report Consumer's Domain Owner will need to
	publish an additional DMARC Policy Record as follows:</t>	publish an additional DMARC Policy Record as follows:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Given the DMARC Policy Record published by the Domain Owner at	<li>Given the DMARC Policy Record published by the Domain Owner at

	"_dmarc.example.com", the DNS administrator for the Report Consumer	"_dmarc.example.com", the DNS administrator for the Report Consumer
	will need to publish a TXT resource record at	will need to publish a TXT Resource Record at
	"example.com._report._dmarc.thirdparty.example.net" with the value	"example.com._report._dmarc.thirdparty.example.net" with the value
	"v=DMARC1;" to authorize receipt of the reports.</li>	"v=DMARC1;" to authorize receipt of the reports.</li>
	</ul>	</ul>
	<t>To publish such a record, the DNS administrator for example.net might	<t>To publish such a record, the DNS administrator for example.net might
	create an entry like the following in the appropriate zone file	create an entry like the following in the appropriate zone file
	(following the conventional zone file format):</t>	(following the conventional zone file format):</t>


	<artwork><![CDATA[ ; zone file for thirdparty.example.net	<artwork><![CDATA[
		; zone file for thirdparty.example.net
	; Accept DMARC reports on behalf of example.com	; Accept DMARC reports on behalf of example.com

	example.com._report._dmarc IN TXT "v=DMARC1;"	example.com._report._dmarc IN TXT "v=DMARC1;"]]></artwork>
	]]></artwork>
	</section>	</section>


	<section anchor="overriding-destination-addresses"><name>Overriding destination	<section anchor="overriding-destination-addresses"><name>Overriding Destination
	addresses</name>	Addresses</name>
	<t>The third party Report Consumer can also publish "rua" and "ru	<t>The third-party Report Consumer can also publish "rua" and "ruf" tags in orde
	f" tags in order	r
	to override the specific address published by example.com with a different	to override the specific address published by example.com with a different

	address in the same third party domain. This may be necessary if the third	address in the same third-party domain. This may be necessary if the
	party Report Consumer has changed its email address, or want to guard against	third-party Report Consumer has changed its email address or wants to guard agai
		nst
	typos in the DMARC Policy Record of the Author Domain. Intermediaries and other	typos in the DMARC Policy Record of the Author Domain. Intermediaries and other

	third parties should refer to <xref target="I-D.ietf-dmarc-aggregate-reporting" sectionFormat="of" section="3"></xref>	third parties should refer to <xref target="RFC9990" sectionFormat="of" section= "3"/>
	for the full details of this mechanism.</t>	for the full details of this mechanism.</t>

	<t>The third party Report Consumer accomplishes this by adding the following to	<t>The third-party Report Consumer accomplishes this by adding the following to
	its	its
	DMARC Policy Record from <xref target="per-message-failure-reports-directed-to-t	DMARC Policy Record from <xref target="per-message-failure-reports-directed-to-t
	hird-party"></xref>:</t>	hird-party"/>:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>The override address for aggregate reports is	<li>The override address for aggregate reports is

	"aggregate-reports@thirdparty.example.net"	"aggregate-reports@thirdparty.example.net"
	<tt>("rua=mailto:aggregate-reports@thirdparty.example.net")</tt></li>	<tt>("rua=mailto:aggregate-reports@thirdparty.example.net")</tt></li>
	<li>The override address for failure reports is	<li>The override address for failure reports is

	"failure-reports@thirdparty.example.net"	"failure-reports@thirdparty.example.net"
	<tt>("ruf=mailto:failure-reports@thirdparty.example.net")</tt></li>	<tt>("ruf=mailto:failure-reports@thirdparty.example.net")</tt></li>
	</ul>	</ul>
	<t>To publish such a record, the DNS administrator for example.net might	<t>To publish such a record, the DNS administrator for example.net might
	create an entry like the following in the appropriate zone file	create an entry like the following in the appropriate zone file
	(following the conventional zone file format):</t>	(following the conventional zone file format):</t>


	<artwork><![CDATA[ ; zone file for thirdparty.example.net	<artwork><![CDATA[
		; zone file for thirdparty.example.net
	; Accept DMARC reports on behalf of example.com	; Accept DMARC reports on behalf of example.com
	; Override destination mailboxes	; Override destination mailboxes
	example.com._report._dmarc IN TXT (	example.com._report._dmarc IN TXT (
	"v=DMARC1; "	"v=DMARC1; "
	"rua=mailto:aggregate-reports@thirdparty.example.net; "	"rua=mailto:aggregate-reports@thirdparty.example.net; "

	"ruf=mailto:failure-reports@thirdparty.example.net" )	"ruf=mailto:failure-reports@thirdparty.example.net" )]]></artwork>
	]]></artwork>
	<t>In this case only the "ruf" tag is actually overridden, because, in	<t>In this case, only the "ruf" tag is actually overridden, because in the
	the
	previous example, failure reporting is the only reporting type that was	previous example, failure reporting is the only reporting type that was

	directed to the third party Report Consumer.</t>	directed to the third-party Report Consumer.</t>
	</section>	</section>

	<section anchor="subdomain-sampling-and-multiple-aggregate-report-uris"><name>Su bdomain, Testing, and Multiple Aggregate Report URIs</name>	<section anchor="subdomain-sampling-and-multiple-aggregate-report-uris"><name>Su bdomain, Testing, and Multiple Aggregate Report URIs</name>
	<t>The Domain Owner has implemented SPF and DKIM in a subdomain used for	<t>The Domain Owner has implemented SPF and DKIM in a subdomain used for
	pre-production testing of messaging services. It now wishes to express	pre-production testing of messaging services. It now wishes to express
	a handling preference for messages from this subdomain that fail DMARC validatio n	a handling preference for messages from this subdomain that fail DMARC validatio n
	to indicate to participating Mail Receivers that use of this domain is not valid .</t>	to indicate to participating Mail Receivers that use of this domain is not valid .</t>
	<t>As a first step, it will express that it considers messages using this	<t>As a first step, it will express that it considers messages using this
	subdomain that fail DMARC validation to be suspicious. The goal here	subdomain that fail DMARC validation to be suspicious. The goal here
	will be to enable examination of messages sent to mailboxes hosted by	will be to enable examination of messages sent to mailboxes hosted by
	participating Mail Receivers as a method for troubleshooting any existing	participating Mail Receivers as a method for troubleshooting any existing
	authentication issues. Aggregate feedback reports will be sent to	authentication issues. Aggregate feedback reports will be sent to

	a mailbox within the Organizational Domain, and to a mailbox at a Report	a mailbox within the Organizational Domain and to a mailbox at a Report
	Consumer selected and authorized to receive them by the Domain Owner.</t>	Consumer selected and authorized to receive them by the Domain Owner.</t>
	<t>The Domain Owner will accomplish this by constructing a DMARC Policy Record	<t>The Domain Owner will accomplish this by constructing a DMARC Policy Record
	indicating that:</t>	indicating that:</t>

	<ul>	<ul>

	<li><t>The version of DMARC being used is "DMARC1" ("v=DMARC1;&qu ot;)</t>	<li><t>The version of DMARC being used is "DMARC1" ("v=DMARC1;")</t>
	</li>	</li>
	<li><t>It is applied only to this subdomain (the DMARC Policy Record is publishe d at	<li><t>It is applied only to this subdomain (the DMARC Policy Record is publishe d at

	"_dmarc.test.example.com" and not "_dmarc.example.com")</t>	"_dmarc.test.example.com" and not "_dmarc.example.com")</t>
	</li>	</li>
	<li><t>Mail Receivers are advised that the Domain Owner considers messages	<li><t>Mail Receivers are advised that the Domain Owner considers messages

	that fail to authenticate to be suspicious ("p=quarantine")</t>	that fail to authenticate to be suspicious ("p=quarantine")</t>
	</li>	</li>
	<li><t>Aggregate feedback reports are sent via email to the	<li><t>Aggregate feedback reports are sent via email to the

	addresses "dmarc-feedback@example.com" and	addresses "dmarc-feedback@example.com" and
	"example-tld-test@thirdparty.example.net"	"example-tld-test@thirdparty.example.net"
	<tt>("rua=mailto:dmarc-feedback@example.com,	<tt>("rua=mailto:dmarc-feedback@example.com,
	mailto:example-tld-test@thirdparty.example.net")</tt></t>	mailto:example-tld-test@thirdparty.example.net")</tt></t>
	</li>	</li>
	<li><t>The Domain Owner desires only that an actor performing a DMARC	<li><t>The Domain Owner desires only that an actor performing a DMARC
	validation check apply any special handling rules it might have	validation check apply any special handling rules it might have
	in place, such as rewriting the RFC53322.From header field; the Domain	in place, such as rewriting the RFC53322.From header field; the Domain
	Owner is testing its setup at this point and so does not want	Owner is testing its setup at this point and so does not want

	the Domain Owner Assessment Policy to be applied. ("t=y")</t>	the Domain Owner Assessment Policy to be applied ("t=y").</t>
	</li>	</li>
	</ul>	</ul>
	<t>To publish such a record, the DNS administrator for the Domain Owner	<t>To publish such a record, the DNS administrator for the Domain Owner
	might create an entry like the following in the appropriate zone	might create an entry like the following in the appropriate zone
	file (following the conventional zone file format):</t>	file (following the conventional zone file format):</t>


	<artwork><![CDATA[ ; DMARC Policy Record for the domain test.example.com	<artwork><![CDATA[
		; DMARC Policy Record for the domain test.example.com
	_dmarc IN TXT ( "v=DMARC1; p=quarantine; "	_dmarc IN TXT ( "v=DMARC1; p=quarantine; "
	"rua=mailto:dmarc-feedback@example.com,"	"rua=mailto:dmarc-feedback@example.com,"
	"mailto:tld-test@thirdparty.example.net; "	"mailto:tld-test@thirdparty.example.net; "

	"t=y" )	"t=y" )]]></artwork>
	]]></artwork>
	<t>Once enough time has passed to allow for collecting enough reports to	<t>Once enough time has passed to allow for collecting enough reports to
	give the Domain Owner confidence that all authorized email sent using	give the Domain Owner confidence that all authorized email sent using
	the subdomain is properly authenticating and passing DMARC validation checks,	the subdomain is properly authenticating and passing DMARC validation checks,
	then the Domain Owner can update the DMARC Policy Record to indicate that it con siders	then the Domain Owner can update the DMARC Policy Record to indicate that it con siders
	validation failures to be a clear indication that use of the subdomain	validation failures to be a clear indication that use of the subdomain
	is not valid. It would do this by altering the record to advise Mail Receivers	is not valid. It would do this by altering the record to advise Mail Receivers

	of its position on such messages ("p=reject") and removing the testing flag ("t=y").</t>	of its position on such messages ("p=reject") and removing the testing flag ("t= y").</t>
	<t>To publish such a record, the DNS administrator for the Domain Owner	<t>To publish such a record, the DNS administrator for the Domain Owner
	might create an entry like the following in the appropriate zone	might create an entry like the following in the appropriate zone
	file (following the conventional zone file format):</t>	file (following the conventional zone file format):</t>


	<artwork><![CDATA[ ; DMARC Policy Record for the domain test.example.com	<artwork><![CDATA[
		; DMARC Policy Record for the domain test.example.com
	_dmarc IN TXT ( "v=DMARC1; p=reject; "	_dmarc IN TXT ( "v=DMARC1; p=reject; "
	"rua=mailto:dmarc-feedback@example.com,"	"rua=mailto:dmarc-feedback@example.com,"

	"mailto:tld-test@thirdparty.example.net" )	"mailto:tld-test@thirdparty.example.net" )]]></artwork>
	]]></artwork>
	</section>	</section>
	</section>	</section>

	<section anchor="mail-receiver-example"><name>Mail Receiver Example</name>	<section anchor="mail-receiver-example"><name>Mail Receiver Example</name>
	<t>A Mail Receiver that wants to participate in DMARC should already be checking	<t>A Mail Receiver that wants to participate in DMARC should already be checking

	SPF and DKIM, and possess the ability to collect relevant information	SPF and DKIM and possess the ability to collect relevant information
	from various email-processing stages to provide feedback to Domain	from various email-processing stages to provide feedback to Domain
	Owners (possibly via Report Consumers).</t>	Owners (possibly via Report Consumers).</t>

	<section anchor="smtp-session-example"><name>SMTP Session Example</name>	<section anchor="smtp-session-example"><name>SMTP Session Example</name>
	<t>An optimal DMARC-enabled Mail Receiver performs validation and	<t>An optimal DMARC-enabled Mail Receiver performs validation and

	Identifier Alignment checking during the SMTP <xref target="RFC5321"></xref> con versation.</t>	Identifier Alignment checking during the SMTP <xref target="RFC5321"/> conversat ion.</t>
	<t>Before returning a final reply to the DATA command, the Mail	<t>Before returning a final reply to the DATA command, the Mail
	Receiver's MTA has performed:</t>	Receiver's MTA has performed:</t>

	<ol>	<ol>
	<li><t>An SPF check to determine an SPF-Authenticated Identifier.</t>	<li><t>An SPF check to determine an SPF-Authenticated Identifier.</t>
	</li>	</li>
	<li><t>DKIM checks that yield one or more DKIM-Authenticated	<li><t>DKIM checks that yield one or more DKIM-Authenticated
	Identifiers.</t>	Identifiers.</t>
	</li>	</li>
	<li><t>A DMARC Policy Record lookup.</t>	<li><t>A DMARC Policy Record lookup.</t>
	</li>	</li>
	</ol>	</ol>
	<t>The presence of an Author Domain DMARC Policy Record indicates that the Mail	<t>The presence of an Author Domain DMARC Policy Record indicates that the Mail
	Receiver should continue with DMARC-specific processing before returning a	Receiver should continue with DMARC-specific processing before returning a
	reply to the DATA command.</t>	reply to the DATA command.</t>
	<t>Given a DMARC Policy Record and the set of Authenticated Identifiers, the	<t>Given a DMARC Policy Record and the set of Authenticated Identifiers, the
	Mail Receiver checks to see if the Authenticated Identifiers align	Mail Receiver checks to see if the Authenticated Identifiers align
	with the Author Domain (taking into consideration any strict versus	with the Author Domain (taking into consideration any strict versus
	relaxed options found in the DMARC Policy Record).</t>	relaxed options found in the DMARC Policy Record).</t>
	<t>For example, the following sample data is considered to be from a	<t>For example, the following sample data is considered to be from a

	piece of email originating from the Domain Owner of "example.com":</t>	piece of email originating from the Domain Owner of "example.com":</t>


	<artwork><![CDATA[ Author Domain: example.com	<artwork><![CDATA[
		Author Domain: example.com
	SPF-authenticated Identifier: mail.example.com	SPF-authenticated Identifier: mail.example.com
	DKIM-authenticated Identifier: example.com	DKIM-authenticated Identifier: example.com
	DMARC Policy Record:	DMARC Policy Record:
	"v=DMARC1; p=reject; aspf=r;	"v=DMARC1; p=reject; aspf=r;

	rua=mailto:dmarc-feedback@example.com"	rua=mailto:dmarc-feedback@example.com"]]></artwork>
	]]></artwork>
	<t>In the above sample, the SPF-Authenticated Identifier and the	<t>In the above sample, the SPF-Authenticated Identifier and the
	DKIM-Authenticated Identifier both align with the Author Domain. The	DKIM-Authenticated Identifier both align with the Author Domain. The
	Mail Receiver considers the above email to pass the DMARC check, avoiding	Mail Receiver considers the above email to pass the DMARC check, avoiding

	the "reject" policy that is requested to be applied to email that fail s	the "reject" policy that is requested to be applied to email that fails
	the DMARC validation check.</t>	the DMARC validation check.</t>
	<t>If no Authenticated Identifiers align with the Author Domain, then	<t>If no Authenticated Identifiers align with the Author Domain, then
	the Mail Receiver applies the Domain Owner Assessment Policy. However,	the Mail Receiver applies the Domain Owner Assessment Policy. However,
	before this action is taken, the Mail Receiver can consult external	before this action is taken, the Mail Receiver can consult external
	information to override the Domain Owner Assessment Policy. For example,	information to override the Domain Owner Assessment Policy. For example,
	if the Mail Receiver knows that this particular email came	if the Mail Receiver knows that this particular email came
	from a known and trusted forwarder (that happens to break both SPF	from a known and trusted forwarder (that happens to break both SPF
	and DKIM), then the Mail Receiver may choose to ignore the Domain	and DKIM), then the Mail Receiver may choose to ignore the Domain
	Owner Assessment Policy.</t>	Owner Assessment Policy.</t>
	<t>The Mail Receiver is now ready to reply to the DATA command. If the	<t>The Mail Receiver is now ready to reply to the DATA command. If the
	DMARC check yields that the message is to be rejected, then the Mail	DMARC check yields that the message is to be rejected, then the Mail
	Receiver replies with a 5xy code to inform the sender of failure. If	Receiver replies with a 5xy code to inform the sender of failure. If
	the DMARC check cannot be resolved due to transient network errors,	the DMARC check cannot be resolved due to transient network errors,
	then the Mail Receiver replies with a 4xy code to inform the sender	then the Mail Receiver replies with a 4xy code to inform the sender
	as to the need to reattempt delivery later. If the DMARC check	as to the need to reattempt delivery later. If the DMARC check
	yields a passing message, then the Mail Receiver continues with	yields a passing message, then the Mail Receiver continues with
	email processing, perhaps using the result of the DMARC check as an	email processing, perhaps using the result of the DMARC check as an
	input to additional processing modules such as a domain reputation	input to additional processing modules such as a domain reputation
	query.</t>	query.</t>
	<t>Before exiting DMARC-specific processing, the Mail Receiver checks to	<t>Before exiting DMARC-specific processing, the Mail Receiver checks to

	see if the Author Domain DMARC Policy Record requests AFRF-based reporting.	see if the Author Domain DMARC Policy Record requests reporting based on an Auth entication Failure Reporting Format (AFRF).
	If so, then the Mail Receiver can emit an AFRF to the reporting	If so, then the Mail Receiver can emit an AFRF to the reporting
	address supplied in the DMARC Policy Record.</t>	address supplied in the DMARC Policy Record.</t>
	<t>At the exit of DMARC-specific processing, the Mail Receiver captures	<t>At the exit of DMARC-specific processing, the Mail Receiver captures
	(through logging or direct insertion into a data store) the result of	(through logging or direct insertion into a data store) the result of
	DMARC processing. Captured information is used to build feedback for	DMARC processing. Captured information is used to build feedback for
	Domain Owner consumption. This is unnecessary if the Domain Owner	Domain Owner consumption. This is unnecessary if the Domain Owner

	has not requested aggregate reports, i.e., no "rua" tag was found in	has not requested aggregate reports, i.e., no "rua" tag was found in
	the policy record.</t>	the policy record.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="treewalk-example"><name>Organizational and Policy Domain Tree W alk Examples</name>	<section anchor="treewalk-example"><name>Organizational and Policy Domain Tree W alk Examples</name>

	<t>If an Author Domain has no DMARC Policy Record, a Mail Receiver uses a tree w alk	<t>If an Author Domain has no DMARC Policy Record, a Mail Receiver uses a Tree W alk
	to find the DMARC Policy.</t>	to find the DMARC Policy.</t>
	<t>If the DMARC Policy Record allows relaxed alignment and the SPF- or DKIM-Auth enticated	<t>If the DMARC Policy Record allows relaxed alignment and the SPF- or DKIM-Auth enticated

	Identifiers are different from the Author Domain, a Mail Receiver uses a tree wa lk to	Identifiers are different from the Author Domain, a Mail Receiver uses a Tree Wa lk to
	discover the respective Organizational Domains to determine Identifier Alignment .</t>	discover the respective Organizational Domains to determine Identifier Alignment .</t>

	<section anchor="simple-organizational-and-policy-example"><name>Simple Organiza tional and Policy Example</name>	<section anchor="simple-organizational-and-policy-example"><name>Simple Organiza tional and Policy Example</name>
	<t>A Mail Receiver receives an email with:</t>	<t>A Mail Receiver receives an email with:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Author Domain: example.com</li>	<li>Author Domain: example.com</li>
	<li>RFC5321.MailFrom Domain: example.com</li>	<li>RFC5321.MailFrom Domain: example.com</li>
	<li>DKIM-Authenticated Identifier: signing.example.com</li>	<li>DKIM-Authenticated Identifier: signing.example.com</li>
	</ul>	</ul>

	<t>In this example, "_dmarc.example.com" and "_dmarc.signing.exam	<t>In this example, "_dmarc.example.com" and "_dmarc.signing.example.com" both
	ple.com" both	have DMARC Policy Records, while "_dmarc.com" does not. If SPF or DKIM yield "pa
	have DMARC Policy Records while "_dmarc.com" does not. If SPF or DKIM	ss"
	yield pass
	results, they still have to be aligned to support a DMARC pass. Since	results, they still have to be aligned to support a DMARC pass. Since

	not all domains are the same, if the alignment is relaxed then the tree	not all domains are the same, if the alignment is relaxed, then the Tree
	walk is performed to determine the Organizational Domain for each.</t>	Walk is performed to determine the Organizational Domain for each.</t>
	<t>To determine the Organizational Domain for the Author Domain,	<t>To determine the Organizational Domain for the Author Domain,

	query "_dmarc.example.com" and "_dmarc.com"; "example.c om" is the last	query "_dmarc.example.com" and "_dmarc.com"; "example.com" is the last
	element of the DNS tree with a DMARC Policy Record, so it is the Organizational	element of the DNS tree with a DMARC Policy Record, so it is the Organizational

	Domain for "example.com".</t>	Domain for "example.com".</t>
	<t>For the RFC5321.MailFrom domain, the Organizational Domain already found for	<t>For the RFC5321.MailFrom domain, the Organizational Domain already found for

	"example.com" is "example.com", so SPF is aligned.</t>	"example.com" is "example.com", so SPF is aligned.</t>
	<t>To determine the Organizational Domain for the DKIM-Authenticated Identifier,	<t>To determine the Organizational Domain for the DKIM-Authenticated Identifier,

	query "_dmarc.signing.example.com", "_dmarc.example.com", an	query "_dmarc.signing.example.com", "_dmarc.example.com", and "_dmarc.com".
	d "_dmarc.com".	Both "signing.example.com" and "example.com" have DMARC Policy Records,
	Both "signing.example.com" and "example.com" have DMARC Poli	but "example.com" is the highest element in the tree with a DMARC Policy Record
	cy Records,	(it has the fewest labels), so "example.com" is the Organizational Domain. Since
	but "example.com" is the highest element in the tree with a DMARC Poli
	cy Record
	(it has the fewest labels), so "example.com" is the Organizational Dom
	ain. Since
	this is also the Organizational Domain for the Author Domain, DKIM is aligned	this is also the Organizational Domain for the Author Domain, DKIM is aligned
	for relaxed alignment.</t>	for relaxed alignment.</t>
	<t>Since both SPF and DKIM are aligned, they can be used to determine if the	<t>Since both SPF and DKIM are aligned, they can be used to determine if the

	message has a DMARC pass result. If the result is not pass, then the policy	message has a DMARC "pass" result. If the result is not "pass", then the policy
	domain's DMARC Policy Record is used to determine the appropriate policy. In thi s	domain's DMARC Policy Record is used to determine the appropriate policy. In thi s
	case, since the RFC5322.From domain has a DMARC Policy Record, that is the polic y	case, since the RFC5322.From domain has a DMARC Policy Record, that is the polic y
	domain.</t>	domain.</t>
	</section>	</section>

	<section anchor="deep-tree-walk-example"><name>Deep Tree Walk Example</name>	<section anchor="deep-tree-walk-example"><name>Deep Tree Walk Example</name>
	<t>A Mail Receiver receives an email with:</t>	<t>A Mail Receiver receives an email with:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Author Domain: a.b.c.d.e.f.g.h.i.j.k.example.com</li>	<li>Author Domain: a.b.c.d.e.f.g.h.i.j.k.example.com</li>
	<li>RFC5321.MailFrom Domain: example.com</li>	<li>RFC5321.MailFrom Domain: example.com</li>
	<li>DKIM-Authenticated Identifier: signing.example.com</li>	<li>DKIM-Authenticated Identifier: signing.example.com</li>
	</ul>	</ul>

	<t>Both "_dmarc.example.com" and "_dmarc.signing.example.com&quot	<t>Both "_dmarc.example.com" and "_dmarc.signing.example.com" have DMARC Policy
	; have DMARC Policy Records,	Records,
	while "_dmarc.com" does not. If SPF or DKIM yield pass results, they s	while "_dmarc.com" does not. If SPF or DKIM yield "pass" results, they still hav
	till have	e
	to be aligned to support a DMARC pass. Since not all domains are the same, if	to be aligned to support a DMARC pass. Since not all domains are the same, if

	the alignment is relaxed then the tree walk is performed to determine the Organi zational	the alignment is relaxed, then the Tree Walk is performed to determine the Organ izational
	Domain for each.</t>	Domain for each.</t>

	<t>To determine the Organizational Domain For the Author Domain, query	<t>To determine the Organizational Domain for the Author Domain, query
	"_dmarc.a.b.c.d.e.f.g.h.i.j.k.example.com", then query "_dmarc.g.	"_dmarc.a.b.c.d.e.f.g.h.i.j.k.example.com"; then query "_dmarc.g.h.i.j.k.example
	h.i.j.k.example.com" (skipping	.com" (skipping
	the intermediate names), then query "_dmarc.h.i.j.k.example.com",	the intermediate names); then query "_dmarc.h.i.j.k.example.com",
	"_dmarc.i.j.k.example.com", "_dmarc.j.k.example.com", "	"_dmarc.i.j.k.example.com", "_dmarc.j.k.example.com", "_dmarc.k.example.com",
	_dmarc.k.example.com",	"_dmarc.example.com", and "_dmarc.com". None of
	"_dmarc.example.com", and "_dmarc.com". None of	"a.b.c.d.e.f.g.h.i.j.k.example.com", "g.h.i.j.k.example.com", "h.i.j.k.example.c
	"a.b.c.d.e.f.g.h.i.j.k.example.com", "g.h.i.j.k.example.com"	om",
	, "h.i.j.k.example.com",	"i.j.k.example.com", "j.k.example.com", or "k.example.com" have a DMARC Policy R
	"i.j.k.example.com", "j.k.example.com", or "k.example.c	ecord.</t>
	om" have a DMARC Policy Record.</t>	<t>Since "example.com" is the last element of the DNS tree with a DMARC Policy R
	<t>Since "example.com" is the last element of the DNS tree with a DMAR	ecord,
	C Policy Record,	it is the Organizational Domain for "a.b.c.d.e.f.g.h.i.j.k.example.com".</t>
	it is the Organizational Domain for "a.b.c.d.e.f.g.h.i.j.k.example.com&quot	<t>For the RFC5321.MailFrom domain, the Organizational Domain already found
	;.</t>	for "example.com" is "example.com". SPF is aligned.</t>
	<t>For the RFC5321.MailFrom domain, the Organizational domain already found	<t>For the DKIM-Authenticated Identifier, query "_dmarc.signing.example.com", "_
	for "example.com" is "example.com". SPF is aligned.</t>	dmarc.example.com",
	<t>For the DKIM-Authenticated Identifier, query "_dmarc.signing.example.com	and "_dmarc.com". Both "signing.example.com" and "example.com" have DMARC Policy
	", "_dmarc.example.com",	Records,
	and "_dmarc.com". Both "signing.example.com" and "examp	but "example.com" is the highest element in the tree with a DMARC Policy Record,
	le.com" have DMARC Policy Records,	so
	but "example.com" is the highest element in the tree with a DMARC Poli	"example.com" is the Organizational Domain. Since this is also the Organizationa
	cy Record, so	l Domain
	"example.com" is the Organizational Domain. Since this is also the Org
	anizational Domain
	for the Author Domain, DKIM is aligned for relaxed alignment.</t>	for the Author Domain, DKIM is aligned for relaxed alignment.</t>
	<t>Since both SPF and DKIM are aligned, they can be used to determine if the	<t>Since both SPF and DKIM are aligned, they can be used to determine if the

	message has a DMARC pass result. If the results for both are not pass, then	message has a DMARC "pass" result. If the results for both are not "pass", then
	the policy domain's DMARC Policy Record is used to determine the appropriate pol icy.	the policy domain's DMARC Policy Record is used to determine the appropriate pol icy.
	In this case, the Author Domain does not have a DMARC Policy Record, so the	In this case, the Author Domain does not have a DMARC Policy Record, so the
	policy domain is the highest element in the DNS tree with a DMARC Policy Record,	policy domain is the highest element in the DNS tree with a DMARC Policy Record,
	example.com.</t>	example.com.</t>
	</section>	</section>

	<section anchor="example-with-a-psd-dmarc-policy-record"><name>Example with a PS D DMARC Policy Record</name>	<section anchor="example-with-a-psd-dmarc-policy-record"><name>Example with a PS D DMARC Policy Record</name>

	<t>In rare cases, a PSD publishes a DMARC Policy Record with a psd tag, which th	<t>In rare cases, a PSD publishes a DMARC Policy Record with a "psd" tag, which
	e tree	the Tree
	walk must take into account.</t>	Walk must take into account.</t>
	<t>A Mail Receiver receives an email with:</t>	<t>A Mail Receiver receives an email with:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Author Domain: giant.bank.example</li>	<li>Author Domain: giant.bank.example</li>
	<li>RFC5321.MailFrom Domain: mail.giant.bank.example</li>	<li>RFC5321.MailFrom Domain: mail.giant.bank.example</li>
	<li>DKIM-Authenticated Identifier: mail.mega.bank.example</li>	<li>DKIM-Authenticated Identifier: mail.mega.bank.example</li>
	</ul>	</ul>

	<t>In this case, "_dmarc.bank.example" has a DMARC Policy Record which	<t>In this case, "_dmarc.bank.example" has a DMARC Policy Record that includes t
	includes the	he
	"psd=y" tag, and "_dmarc.example" does not have a DMARC Poli	"psd=y" tag, and "_dmarc.example" does not have a DMARC Policy Record.
	cy Record.	While "_dmarc.giant.bank.example" has a DMARC Policy Record without a "psd" tag,
	While "_dmarc.giant.bank.example" has a DMARC Policy Record without a	"_dmarc.mega.bank.example" and "_dmarc.mail.mega.bank.example" have no DMARC Pol
	"psd" tag,	icy Records.</t>
	"_dmarc.mega.bank.example" and "_dmarc.mail.mega.bank.example&quo	<t>Since the three domains are all different, Tree Walks find their Organization
	t; have no DMARC Policy Records.</t>	al Domains
	<t>Since the three domains are all different, tree walks find their Organization
	al Domains
	to see which are aligned.</t>	to see which are aligned.</t>

	<t>For the Author Domain "giant.bank.example", the tree walk finds the	<t>For the Author Domain "giant.bank.example", the Tree Walk finds both the DMAR
	DMARC Policy Record	C Policy Record
	at "_dmarc.giant.bank.example", then the DMARC Policy Record at "	at "_dmarc.giant.bank.example" and then the DMARC Policy Record at "_dmarc.bank.
	_dmarc.bank.example", and	example" and
	stops because of the "psd=y" flag. The Organizational Domain is &quot	stops because of the "psd=y" flag. The Organizational Domain is "giant.bank.exa
	;giant.bank.example" because	mple" because
	it is the domain directly below the one with "psd=y". Since the Organ	it is the domain directly below the one with "psd=y". Since the Organizational
	izational Domain has a	Domain has a
	DMARC Policy Record, it is also the policy domain.</t>	DMARC Policy Record, it is also the policy domain.</t>

	<t>For the RFC5321.MailFrom domain "mail.giant.bank.example", the tree	<t>For the RFC5321.MailFrom domain "mail.giant.bank.example", the Tree Walk find
	walk finds no DMARC Policy	s no DMARC Policy
	Record at "_dmarc.mail.giant.bank.example", but does find both the DMA	Record at "_dmarc.mail.giant.bank.example" but does find both the DMARC Policy R
	RC Policy Record at	ecord at
	"_dmarc.giant.bank.example" and then the DMARC Policy Record at "	"_dmarc.giant.bank.example" and then the DMARC Policy Record at "_dmarc.bank.exa
	_dmarc.bank.example", and	mple" and
	stops because of the "psd=y" flag. Again the Organizational Domain is	stops because of the "psd=y" flag. Again, the Organizational Domain is "giant.b
	"giant.bank.example" because	ank.example" because
	it is the domain directly below the one with "psd=y". Since this is t	it is the domain directly below the one with "psd=y". Since this is the same Or
	he same Organizational Domain	ganizational Domain
	as the Author Domain, SPF is aligned.</t>	as the Author Domain, SPF is aligned.</t>

	<t>For the DKIM-Authenticated Identifier "mail.mega.bank.example", the	<t>For the DKIM-Authenticated Identifier "mail.mega.bank.example", the Tree Walk
	tree walk finds no DMARC Policy	finds no DMARC Policy
	Records at "_dmarc.mail.mega.bank.example" or "_dmarc.mega.bank.e	Records at "_dmarc.mail.mega.bank.example" or "_dmarc.mega.bank.example", then f
	xample", then finds the DMARC	inds the DMARC
	Policy Record at "_dmarc.bank.example" and stops because of the "	Policy Record at "_dmarc.bank.example", and stops because of the "psd=y" flag.
	psd=y" flag.	The Organizational Domain is "mega.bank.example", so DKIM is not aligned.</t>
	The Organizational Domain is "mega.bank.example", so DKIM is not align	<t>Since SPF is aligned, it can be used to determine if the message has a DMARC
	ed.</t>	"pass" result. If the
	<t>Since SPF is aligned, it can be used to determine if the message has a DMARC	result is not "pass", then the policy domain's DMARC Policy Record is used to de
	pass result. If the	termine the appropriate
	result is not pass, then the policy domain's DMARC Policy Record is used to dete
	rmine the appropriate
	policy.</t>	policy.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="utilization-of-aggregate-feedback-example"><name>Utilization of Aggregate Feedback: Example</name>	<section anchor="utilization-of-aggregate-feedback-example"><name>Utilization of Aggregate Feedback: Example</name>
	<t>Aggregate feedback is consumed by Domain Owners to enable their	<t>Aggregate feedback is consumed by Domain Owners to enable their
	understanding of how a given domain is being processed by the Mail	understanding of how a given domain is being processed by the Mail
	Receiver. Aggregate reporting data on emails that pass all underlying	Receiver. Aggregate reporting data on emails that pass all underlying
	authentication checks is used by Domain Owners to validate that their	authentication checks is used by Domain Owners to validate that their
	authentication practices remain accurate. For example, if a third party	authentication practices remain accurate. For example, if a third party
	is sending on behalf of a Domain Owner, the Domain Owner can use aggregate	is sending on behalf of a Domain Owner, the Domain Owner can use aggregate
	report data to validate ongoing authentication practices of the third party.</t>	report data to validate ongoing authentication practices of the third party.</t>
	<t>Data on email that only partially passes underlying authentication	<t>Data on email that only partially passes underlying authentication
	checks provides visibility into problems that need to be addressed by	checks provides visibility into problems that need to be addressed by
	the Domain Owner. For example, if either SPF or DKIM fails to produce	the Domain Owner. For example, if either SPF or DKIM fails to produce
	an Authenticated Identifier, the Domain Owner is provided with enough	an Authenticated Identifier, the Domain Owner is provided with enough
	information to either directly correct the problem or understand where	information to either directly correct the problem or understand where
	authentication-breaking changes are being introduced in the email	authentication-breaking changes are being introduced in the email

	transmission path. If authentication-breaking changes due to email	transmission path. If authentication-breaking changes due to the email
	transmission path cannot be directly corrected, then the Domain Owner at least	transmission path cannot be directly corrected, then the Domain Owner at least
	maintains an understanding of the effect of DMARC-based policies upon	maintains an understanding of the effect of DMARC-based policies upon
	the Domain Owner's email.</t>	the Domain Owner's email.</t>
	<t>Data on email that fails all underlying authentication checks	<t>Data on email that fails all underlying authentication checks
	provides baseline visibility on how the Domain Owner's domain is	provides baseline visibility on how the Domain Owner's domain is
	being received at the Mail Receiver. Based on this visibility, the	being received at the Mail Receiver. Based on this visibility, the
	Domain Owner can begin deployment of authentication technologies	Domain Owner can begin deployment of authentication technologies

	across uncovered email sources, if the mail that is failing the checks	across uncovered email sources if the mail that is failing the checks
	was generated by or on behalf of the Domain Owner. Data regarding	was generated by or on behalf of the Domain Owner. Data regarding
	failing authentication checks can also allow the Domain Owner to	failing authentication checks can also allow the Domain Owner to
	come to an understanding of how its domain is being misused.</t>	come to an understanding of how its domain is being misused.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="rfc7849-changes"><name>Changes from RFC 7489</name>	<section anchor="rfc7849-changes"><name>Changes from RFC 7489</name>

	<t>This document is intended to render <xref target="RFC7489"></xref> obsolete.	<t>This document is intended to render <xref target="RFC7489"/> obsolete. As one
	As one might guess,	might guess,
	that means there are significant differences between RFC 7489 and this	that means there are significant differences between <xref target="RFC7489"/> an
		d this
	document. This section will summarize those changes.</t>	document. This section will summarize those changes.</t>

	<section anchor="informational-vs-standards-track"><name>Informational vs. Stand ards Track</name>	<section anchor="informational-vs-standards-track"><name>Informational vs. Stand ards Track</name>

	<t>RFC 7489 was not the product of any IETF work stream, but was instead publish	<t><xref target="RFC7489"/> was not the product of any IETF work stream but was
	ed into	instead published into
	the RFC series by the Independent Submissions Editor and is classified as an Inf	the RFC Series by the Independent Submissions Editor and classified as an Inform
	ormational	ational
	RFC.</t>	RFC.</t>

	<t>This document, by contrast, is intended to be Internet Standards Track.</t>	<t>This document, by contrast, is an Internet Standards Track document.</t>
	</section>	</section>

	<section anchor="changes-to-terminology-and-definitions"><name>Changes to Termin ology and Definitions</name>	<section anchor="changes-to-terminology-and-definitions"><name>Changes to Termin ology and Definitions</name>

	<t>The following changes were made to the Terminology and Definitions section.</ t>	<t>The following changes were made to the "Terminology and Definitions" section. </t>

	<section anchor="terms-added"><name>Terms Added</name>	<section anchor="terms-added"><name>Terms Added</name>
	<t>These terms were added:</t>	<t>These terms were added:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Domain Owner Assessment Policy</li>	<li>Domain Owner Assessment Policy</li>
	<li>Enforcement</li>	<li>Enforcement</li>
	<li>Monitoring Mode</li>	<li>Monitoring Mode</li>
	<li>Non-existent Domains</li>	<li>Non-existent Domains</li>
	<li>Public Suffix Domain (PSD)</li>	<li>Public Suffix Domain (PSD)</li>
	<li>Public Suffix Operator (PSO)</li>	<li>Public Suffix Operator (PSO)</li>

	<li>PSO Controlled Domain Names</li>	<li>PSO-Controlled Domain Names</li>
	</ul>	</ul>
	</section>	</section>

	<section anchor="definitions-updated"><name>Definitions Updated</name>	<section anchor="definitions-updated"><name>Definitions Updated</name>
	<t>These definitions were updated:</t>	<t>These definitions were updated:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Organizational Domain</li>	<li>Organizational Domain</li>
	<li>Report Receiver (renamed to Report Consumer)</li>	<li>Report Receiver (renamed to Report Consumer)</li>
	</ul>	</ul>
	</section>	</section>
	</section>	</section>

	<section anchor="policy-determination"><name>Policy Discovery and Organizational Domain Determination</name>	<section anchor="policy-determination"><name>Policy Discovery and Organizational Domain Determination</name>
	<t>The algorithms for DMARC policy discovery and for determining the Organizatio nal Domain	<t>The algorithms for DMARC policy discovery and for determining the Organizatio nal Domain
	have been changed. Specifically, reliance on a Public Suffix List (PSL) has been replaced	have been changed. Specifically, reliance on a Public Suffix List (PSL) has been replaced

	by a technique called a "DNS Tree Walk", and the methodology for the D NS Tree Walk is explained	by a technique called a "DNS Tree Walk", and the methodology for the DNS Tree Wa lk is explained
	in detail in this document.</t>	in detail in this document.</t>
	<t>The DNS Tree Walk also incorporates PSD policy discovery, which was introduce d in	<t>The DNS Tree Walk also incorporates PSD policy discovery, which was introduce d in

	<xref target="RFC9091"></xref>. That RFC was an Experimental RFC, and the result s of that experiment were	<xref target="RFC9091"/>. That RFC was an Experimental RFC, and the results of t hat experiment were
	that the RFC was not implemented as written. Instead, this document redefines th e	that the RFC was not implemented as written. Instead, this document redefines th e

	algorithm for PSD policy discovery, and thus obsoletes <xref target="RFC9091"></ xref>. Specifically, the	algorithm for PSD policy discovery and thus obsoletes <xref target="RFC9091"/>. Specifically, the
	DNS Tree Walk defined in this document obviates the need for a PSD DMARC registr y,	DNS Tree Walk defined in this document obviates the need for a PSD DMARC registr y,

	and that PSD DMARC registry is what made RFC 9091 an Experimental RFC.</t>	and that PSD DMARC registry is what made <xref target="RFC9091"/> an Experimenta l RFC.</t>
	<t>These algorithm changes introduce the possibility of interoperability issues where a	<t>These algorithm changes introduce the possibility of interoperability issues where a
	Domain Owner expects a DMARC Policy Record or an Organizational Domain to be ide ntified by	Domain Owner expects a DMARC Policy Record or an Organizational Domain to be ide ntified by

	the Tree Walk process, but a Mail Receiver using an RFC 7489-based implementatio	the Tree Walk process, but a Mail Receiver using an implementation of DMARC base
	n of	d on <xref target="RFC7489"/>
	DMARC and relying on a PSL might arrive at a different answer.</t>	and relying on a PSL might arrive at a different answer.</t>
	<t>This issue is entirely avoided by the use of Strict Alignment and publishing	<t>This issue is entirely avoided by the use of strict alignment and publishing
	explicit	explicit
	DMARC Policy Records for all Author Domains used in an organization's email.</t>	DMARC Policy Records for all Author Domains used in an organization's email.</t>
	</section>	</section>

	<section anchor="reporting"><name>Reporting</name>	<section anchor="reporting"><name>Reporting</name>

	<t>Discussion of both aggregate and failure reporting have been moved to separat e documents	<t>Discussion of both aggregate and failure reporting has been moved to separate documents
	dedicated to the topics.</t>	dedicated to the topics.</t>
	<t>In addition, the ability to specify a maximum report size in the DMARC URI ha s been removed.</t>	<t>In addition, the ability to specify a maximum report size in the DMARC URI ha s been removed.</t>
	</section>	</section>

	<section anchor="tags"><name>Tags</name>	<section anchor="tags"><name>Tags</name>

	<t>Several tags have been added to the "DMARC Policy Record Format" se	<t>Several tags have been added to the "DMARC Policy Record Format" section of t
	ction of this document since	his document since
	RFC 7489 was published, and at the same time, several others were removed.</t>	<xref target="RFC7489"/> was published, and at the same time, several others wer
		e removed.</t>

	<section anchor="tags-added"><name>Tags Added</name>	<section anchor="tags-added"><name>Tags Added</name>


	<ul spacing="compact">	<dl spacing="normal" newline="false">
	<li>np - Policy for non-existent domains (Imported from <xref target="RFC9091"><	<dt>np:</dt> <dd>Policy for non-existent domains (imported from <xref target="RF
	/xref>)</li>	C9091"/>).</dd>
	<li>psd - Flag indicating whether a domain is a Public Suffix Domain</li>	<dt>psd:</dt> <dd>Flag indicating whether a domain is a Public Suffix Domain.</d
	<li>t - Replacement for some pct tag functionality. See <xref target="removal-of	d>
	-the-pct-tag"></xref> for further discussion</li>	<dt>t:</dt> <dd>Replacement for some "pct" tag functionality. See <xref target="
	</ul>	removal-of-the-pct-tag"/> for further discussion.</dd>
		</dl>
	</section>	</section>

	<section anchor="tags-removed"><name>Tags Removed</name>	<section anchor="tags-removed"><name>Tags Removed</name>


	<ul spacing="compact">	<dl spacing="normal" newline="false">
	<li>pct - Tag requesting application of DMARC policy to only a percentage of mes	<dt>pct:</dt> <dd>Tag requesting application of the DMARC policy to only a perce
	sages. See <xref target="removal-of-the-pct-tag"></xref> for discussion</li>	ntage of messages. See <xref target="removal-of-the-pct-tag"/> for discussion.</
	<li>rf - Tag specifying requested format of failure reports</li>	dd>
	<li>ri - Tag specifying requested interval between aggregate reports</li>	<dt>rf:</dt> <dd>Tag specifying requested format of failure reports.</dd>
	</ul>	<dt>ri</dt> <dd>Tag specifying requested interval between aggregate reports.</dd
		>
		</dl>
	</section>	</section>
	</section>	</section>

	<section anchor="expansion-of-domain-owner-actions-section"><name>Expansion of D omain Owner Actions Section</name>	<section anchor="expansion-of-domain-owner-actions-section"><name>Expansion of D omain Owner Actions Section</name>

	<t>RFC 7489 had just two paragraphs in its Domain Owner Actions section, and whi le	<t><xref target="RFC7489"/> only had two paragraphs in its "Domain Owner Actions " section, and while
	the content of those paragraphs was correct, it was minimalist in its approach t o	the content of those paragraphs was correct, it was minimalist in its approach t o

	providing guidance to domain owners on just how to implement DMARC.</t>	providing guidance to Domain Owners on just how to implement DMARC.</t>
	<t>This document provides much more detail and explanatory text to a Domain Owne r,	<t>This document provides much more detail and explanatory text to a Domain Owne r,

	focusing not just on what to do to implement DMARC, but also on the reasons for	focusing not just on what to do to implement DMARC but also on the reasons for
	each step and the repercussions of each decision.</t>	each step and the repercussions of each decision.</t>
	<t>In particular, this document makes explicit that domains for general-purpose	<t>In particular, this document makes explicit that domains for general-purpose

	email <bcp14>SHOULD NOT</bcp14> deploy a DMARC policy of p=reject. See <xref tar get="interoperability-considerations"></xref>	email <bcp14>SHOULD NOT</bcp14> deploy a DMARC policy of "p=reject". See <xref t arget="interoperability-considerations"/>
	for further discussion of this topic.</t>	for further discussion of this topic.</t>
	</section>	</section>

	<section anchor="report-generator-recommendations"><name>Report Generator Recomm endations</name>	<section anchor="report-generator-recommendations"><name>Report Generator Recomm endations</name>
	<t>In the cases where a DMARC Policy Record specifies multiple destinations for either aggregate	<t>In the cases where a DMARC Policy Record specifies multiple destinations for either aggregate

	reports or failure reports, RFC 7489 stated:</t>	reports or failure reports, <xref target="RFC7489"/> stated:</t>


	<artwork><![CDATA[ Receivers MAY impose a limit on the number of URIs to wh	<blockquote>Receivers <bcp14>MAY</bcp14> impose a limit on the number of URIs to
	ich they	which they
	will send reports but MUST support the ability to send to at least	will send reports but <bcp14>MUST</bcp14> support the ability to send to at le
	two.	ast
	]]></artwork>	two.</blockquote>
	<t>This document in <xref target="dmarc-uris"></xref> says:</t>
		<!-- [rfced] Appendix C.7 cites and quotes Section 4.6 of this document; however
		the quoted text does not appear in this document. Please review and let us know
		if this text should be added to Section 4.6.

		Current:
		Section 4.6 of this document says:

		A report SHOULD be sent to each listed URI provided in the DMARC Policy Re
		cord.
		-->

		<t><xref target="dmarc-uris"/> of this document says:</t>

		<blockquote>A report <bcp14>SHOULD</bcp14> be sent to each listed URI provided i
		n the DMARC
		Policy Record.</blockquote>


	<artwork><![CDATA[ A report SHOULD be sent to each listed URI provided in t
	he DMARC
	Policy Record.
	]]></artwork>
	</section>	</section>


	<section anchor="removal-of-rfc-7489-appendix-a-5"><name>Removal of RFC 7489 App	<section anchor="removal-of-rfc-7489-appendix-a-5"><name>Removal of RFC 7489, Ap
	endix A.5</name>	pendix A.5</name>
	<t>One of the appendices in RFC 7489, specifically <xref target="RFC7489" sectio	<t>One of the appendices in <xref target="RFC7489"/>, specifically Appendix <xre
	nFormat="bare" section="Appendix A.5"></xref>,	f target="RFC7489" sectionFormat="bare" section="A.5"/>,
	has been removed from the text with this update. The appendix was titled	has been removed from the text with this update. The appendix was titled

	"Issues with ADSP in Operation" and it contained a list of issues asso ciated	"Issues with ADSP in Operation", and it contained a list of issues associated
	with ADSP that influenced the direction of DMARC. The ADSP protocol was moved	with ADSP that influenced the direction of DMARC. The ADSP protocol was moved

	to "Historic" status in 2013 and working group consensus was that such a	to "Historic" status in 2013 and working group consensus was that such a
	discussion of ADSP's influence on DMARC was no longer relevant.</t>	discussion of ADSP's influence on DMARC was no longer relevant.</t>
	</section>	</section>

	<section anchor="rfc-7489-errata-summary"><name>RFC 7489 Errata Summary</name>	<section anchor="rfc-7489-errata-summary"><name>RFC 7489 Errata Summary</name>

	<t>This document and its companion documents (<xref target="I-D.ietf-dmarc-aggre	<t>This document and its companion documents (<xref target="RFC9990"/>
	gate-reporting"></xref>	and <xref target="RFC9991"/>) address the following errata
	and <xref target="I-D.ietf-dmarc-failure-reporting"></xref>) address the followi	filed against <xref target="RFC7489"/> since that document's publication in Marc
	ng errata	h,
	filed against <xref target="RFC7489"></xref> since that document's publication i
	n March,
	2015. More details on each of these can be found at	2015. More details on each of these can be found at

	<eref target="https://www.rfc-editor.org/errata_search.php?rfc=7489">https://www .rfc-editor.org/errata_search.php?rfc=7489</eref></t>	<eref brackets="angle" target="https://www.rfc-editor.org/errata_search.php?rfc= 7489"/>.</t>


	<section anchor="rfc-errata-erratum-id-5365-rfc-7489-section-7-2-1-1-https-www-r	<section anchor="rfc-errata-erratum-id-5365-rfc-7489-section-7-2-1-1-https-www-r
	fc-editor-org-errata-eid5365"><name><eref target="https://www.rfc-editor.org/err	fc-editor-org-errata-eid5365"><name>RFC Errata, Erratum ID 5365, RFC 7489, Secti
	ata/eid5365">RFC Errata, Erratum ID 5365, RFC 7489, Section 7.2.1.1</eref></name	on 7.2.1.1</name>
	>	<t>See <eref target="https://www.rfc-editor.org/errata/eid5365" brackets="angle"
	<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>	/>. This erratum is addressed in <xref target="RFC9990"/>.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-5371-rfc-7489-section-7-2-1-1-https-www-r	<section anchor="rfc-errata-erratum-id-5371-rfc-7489-section-7-2-1-1-https-www-r
	fc-editor-org-errata-eid5371"><name><eref target="https://www.rfc-editor.org/err	fc-editor-org-errata-eid5371"><name>RFC Errata, Erratum ID 5371, RFC 7489, Secti
	ata/eid5371">RFC Errata, Erratum ID 5371, RFC 7489, Section 7.2.1.1</eref></name	on 7.2.1.1</name>
	>	<t>See <eref target="https://www.rfc-editor.org/errata/eid5371" brackets="angle"
	<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>	/>. This erratum is addressed in <xref target="RFC9990"/>.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-5440-rfc-7489-sections-7-1-b-2-1-b-2-3-an	<section anchor="rfc-errata-erratum-id-5440-rfc-7489-sections-7-1-b-2-1-b-2-3-an
	d-b-2-4-https-www-rfc-editor-org-errata-eid5440"><name><eref target="https://www	d-b-2-4-https-www-rfc-editor-org-errata-eid5440"><name>RFC Errata, Erratum ID 54
	.rfc-editor.org/errata/eid5440">RFC Errata, Erratum ID 5440, RFC 7489, Sections	40, RFC 7489, Section 7.1 and Appendices B.2.1, B.2.3, and B.2.4</name>
	7.1, B.2.1, B.2.3, and B.2.4</eref></name>	<t>See <eref target="https://www.rfc-editor.org/errata/eid5440" brackets="angle"
	<t>This erratum references several mentions in RFC 7489 of the "v=" ta	/>. This erratum references several mentions in <xref target="RFC7489"/> of the
	g from the Domain Owner Assessment	"v=" tag from the Domain Owner Assessment
	Policy and/or its value, specifically mentions that were not, but should have be	Policy and/or its value, specifically mentions that were not, but should have be
	en, "v=DMARC1;". Some	en, "v=DMARC1;". Some
	of those mentions are preserved in this document and those mentions have been ad	of those mentions are preserved in this document, and those mentions have been a
	dressed as per the	ddressed as per the
	erratum. The rest have moved to <xref target="I-D.ietf-dmarc-aggregate-reporting	erratum. The rest have moved to <xref target="RFC9990"/> and are addressed there
	"></xref> and are addressed there.</t>	.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-6439-rfc-7489-section-7-1-https-www-rfc-e	<section anchor="rfc-errata-erratum-id-6439-rfc-7489-section-7-1-https-www-rfc-e
	ditor-org-errata-eid6439"><name><eref target="https://www.rfc-editor.org/errata/	ditor-org-errata-eid6439"><name>RFC Errata, Erratum ID 6439, RFC 7489, Section 7
	eid6439">RFC Errata, Erratum ID 6439, RFC 7489, Section 7.1</eref></name>	.1</name>
	<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>	<t>See <eref target="https://www.rfc-editor.org/errata/eid6439" brackets="angle"
		/>. This erratum is addressed in <xref target="RFC9990"/>.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-5221-rfc-7489-appendix-c-https-www-rfc-ed	<section anchor="rfc-errata-erratum-id-5221-rfc-7489-appendix-c-https-www-rfc-ed
	itor-org-errata-eid5221"><name><eref target="https://www.rfc-editor.org/errata/e	itor-org-errata-eid5221"><name>RFC Errata, Erratum ID 5221, RFC 7489, Appendix C
	id5221">RFC Errata, Erratum ID 5221, RFC 7489, Appendix C</eref></name>	</name>
	<t>The regular expression pattern for IP addresses has been removed from this do	<t>See <eref target="https://www.rfc-editor.org/errata/eid5221" brackets="angle"
	cument and from	/>. The regular expression pattern for IP addresses has been removed from this d
	<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>	ocument and from
		<xref target="RFC9990"/>.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-5229-rfc-7489-appendix-c-https-www-rfc-ed	<section anchor="rfc-errata-erratum-id-5229-rfc-7489-appendix-c-https-www-rfc-ed
	itor-org-errata-eid5229"><name><eref target="https://www.rfc-editor.org/errata/e	itor-org-errata-eid5229"><name>RFC Errata, Erratum ID 5229, RFC 7489, Appendix C
	id5229">RFC Errata, Erratum ID 5229, RFC 7489, Appendix C</eref></name>	</name>
	<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>	<t>See <eref target="https://www.rfc-editor.org/errata/eid5229" brackets="angle"
		/>. This erratum is addressed in <xref target="RFC9990"/>.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-5495-rfc-7489-section-6-6-3-https-www-rfc-ed	<section anchor="rfc-errata-erratum-5495-rfc-7489-section-6-6-3-https-www-rfc-ed
	itor-org-errata-eid5495"><name><eref target="https://www.rfc-editor.org/errata/e	itor-org-errata-eid5495"><name>RFC Errata, Erratum 5495, RFC 7489, Section 6.6.3
	id5495">RFC Errata, Erratum 5495, RFC 7489, Section 6.6.3</eref></name>	</name>
	<t>This erratum is in reference to the description of the process documented	<t>See <eref target="https://www.rfc-editor.org/errata/eid5495" brackets="angle"
	in RFC 7489 for the applicable DMARC policy for an email message. The process	/>. This erratum is in reference to the description of the process documented
	for doing this has drastically changed in DMARCbis, and so the text identified i	in <xref target="RFC7489"/> for the applicable DMARC policy for an email message
	n	. The process
		for doing this has drastically changed in this document, and so the text identif
		ied in
	this erratum no longer exists.</t>	this erratum no longer exists.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-6485-rfc-7489-section-7-2-1-1-https-www-r	<section anchor="rfc-errata-erratum-id-6485-rfc-7489-section-7-2-1-1-https-www-r
	fc-editor-org-errata-eid6485"><name><eref target="https://www.rfc-editor.org/err	fc-editor-org-errata-eid6485"><name>RFC Errata, Erratum ID 6485, RFC 7489, Secti
	ata/eid6485">RFC Errata, Erratum ID 6485, RFC 7489, Section 7.2.1.1</eref></name	on 7.2.1.1</name>
	>	<t>See <eref target="https://www.rfc-editor.org/errata/eid6485" brackets="angle"
	<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>	/>. This erratum is addressed in <xref target="RFC9990"/>.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-6729-rfc-7489-section-3-2-https-www-rfc-e	<section anchor="rfc-errata-erratum-id-6729-rfc-7489-section-3-2-https-www-rfc-e
	ditor-org-errata-eid6729"><name><eref target="https://www.rfc-editor.org/errata/	ditor-org-errata-eid6729"><name>RFC Errata, Erratum ID 6729, RFC 7489, Section 3
	eid6729">RFC Errata, Erratum ID 6729, RFC 7489, Section 3.2</eref></name>	.2</name>
	<t>This erratum is in reference to a search of the Public Suffix List (PSL) as p	<t>See <eref target="https://www.rfc-editor.org/errata/eid6729" brackets="angle"
	art of finding a DMARC	/>. This erratum is in reference to a search of the Public Suffix List (PSL) as
		part of finding a DMARC
	Policy Record (a.k.a., Domain Owner Assessment Policy). The PSL is no longer rel ied upon for this	Policy Record (a.k.a., Domain Owner Assessment Policy). The PSL is no longer rel ied upon for this
	practice, and the text at issue has been removed from this document.</t>	practice, and the text at issue has been removed from this document.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-7099-rfc-7489-section-7-2-1-1-https-www-r	<section anchor="rfc-errata-erratum-id-7099-rfc-7489-section-7-2-1-1-https-www-r
	fc-editor-org-errata-eid7099"><name><eref target="https://www.rfc-editor.org/err	fc-editor-org-errata-eid7099"><name>RFC Errata, Erratum ID 7099, RFC 7489, Secti
	ata/eid7099">RFC Errata, Erratum ID 7099, RFC 7489, Section 7.2.1.1</eref></name	on 7.2.1.1</name>
	>	<t>See <eref target="https://www.rfc-editor.org/errata/eid7099" brackets="angle"
	<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>	/>. This erratum is addressed in <xref target="RFC9990"/>.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-7100-rfc-7489-section-7-2-1-1-https-www-r	<section anchor="rfc-errata-erratum-id-7100-rfc-7489-section-7-2-1-1-https-www-r
	fc-editor-org-errata-eid7100"><name><eref target="https://www.rfc-editor.org/err	fc-editor-org-errata-eid7100"><name>RFC Errata, Erratum ID 7100, RFC 7489, Secti
	ata/eid7100">RFC Errata, Erratum ID 7100, RFC 7489, Section 7.2.1.1</eref></name	on 7.2.1.1</name>
	>	<t>See <eref target="https://www.rfc-editor.org/errata/eid7100" brackets="angle"
	<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>	/>. This erratum is addressed in <xref target="RFC9990"/>.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-7835-rfc-7489-section-6-6-3-https-www-rfc	<section anchor="rfc-errata-erratum-id-7835-rfc-7489-section-6-6-3-https-www-rfc
	-editor-org-errata-eid7835"><name><eref target="https://www.rfc-editor.org/errat	-editor-org-errata-eid7835"><name>RFC Errata, Erratum ID 7835, RFC 7489, Section
	a/eid7835">RFC Errata, Erratum ID 7835, RFC 7489, Section 6.6.3</eref></name>	6.6.3</name>
	<t>This erratum is in reference to the description of the process documented	<t>See <eref target="https://www.rfc-editor.org/errata/eid7835" brackets="angle"
	in RFC 7489 for the applicable DMARC policy for an email message. The process	/>. This erratum is in reference to the description of the process documented
	for doing this has drastically changed in DMARCbis, and so the text identified i	in <xref target="RFC7489"/> for the applicable DMARC policy for an email message
	n	. The process
		for doing this has drastically changed in this document, and so the text identif
		ied in
	this erratum no longer exists.</t>	this erratum no longer exists.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-7865-rfc-7489-appendix-c-https-www-rfc-ed	<section anchor="rfc-errata-erratum-id-7865-rfc-7489-appendix-c-https-www-rfc-ed
	itor-org-errata-eid7865"><name><eref target="https://www.rfc-editor.org/errata/e	itor-org-errata-eid7865"><name>RFC Errata, Erratum ID 7865, RFC 7489, Appendix C
	id7865">RFC Errata, Erratum ID 7865, RFC 7489, Appendix C</eref></name>	</name>
	<t>The regular expression pattern for IP addresses has been removed from this do	<t>See <eref target="https://www.rfc-editor.org/errata/eid7865" brackets="angle"
	cument and from	/>. The regular expression pattern for IP addresses has been removed from this d
	<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>	ocument and from
		<xref target="RFC9990"/>.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-5151-rfc-7489-section-1-https-www-rfc-edi	<section anchor="rfc-errata-erratum-id-5151-rfc-7489-section-1-https-www-rfc-edi
	tor-org-errata-eid5151"><name><eref target="https://www.rfc-editor.org/errata/ei	tor-org-errata-eid5151"><name>RFC Errata, Erratum ID 5151, RFC 7489, Section 1</
	d5151">RFC Errata, Erratum ID 5151, RFC 7489, Section 1</eref></name>	name>
	<t>This erratum is in reference to the Introduction section of RFC 7489.	<t>See <eref target="https://www.rfc-editor.org/errata/eid5151" brackets="angle"
	That section has been substantially rewritten in DMARCbis, and the text	/>. This erratum is in reference to the Introduction section of <xref target="RF
		C7489"/>.
		That section has been substantially rewritten in this document, and the text
	at issue for this erratum no longer exists.</t>	at issue for this erratum no longer exists.</t>
	</section>	</section>


	<section anchor="rfc-errata-erratum-id-5774-rfc-7489-appendix-c-https-www-rfc-ed	<section anchor="rfc-errata-erratum-id-5774-rfc-7489-appendix-c-https-www-rfc-ed
	itor-org-errata-eid5774"><name><eref target="https://www.rfc-editor.org/errata/e	itor-org-errata-eid5774"><name>RFC Errata, Erratum ID 5774, RFC 7489, Appendix C
	id5774">RFC Errata, Erratum ID 5774, RFC 7489, Appendix C</eref></name>	</name>
	<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>	<t>See <eref target="https://www.rfc-editor.org/errata/eid5774" brackets="angle"
		/>. This erratum is addressed in <xref target="RFC9990"/>.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="general-editing-and-formatting"><name>General Editing and Forma tting</name>	<section anchor="general-editing-and-formatting"><name>General Editing and Forma tting</name>

	<t>A great deal of the content from RFC 7489 was preserved in this document, but	<t>A great deal of the content from <xref target="RFC7489"/> was preserved in th
	much	is document, but much
	of it was subject to either minor editing, re-ordering of sections, and/or both.	of it was subject to minor editing and the reordering of sections, or both.</t>
	</t>
	</section>	</section>
	</section>	</section>

	<section anchor="acknowledgements" numbered="false"><name>Acknowledgements</name >	<section anchor="acknowledgements" numbered="false"><name>Acknowledgements</name >

	<t>This reworking of the DMARC mechanism specified in <xref target="RFC7489"></x	<t>The reworking of the DMARC mechanism specified in <xref target="RFC7489"/>
	ref> is the	is the result of contributions from many participants in the DMARC Working
	result of contributions from many participants in the IETF Working Group	Group. Although the contributors are too numerous to
	dedicated to this effort. Although the contributors are too numerous to	mention, significant contributions were made by <contact fullname="Kurt
	mention, significant contributions were made by Kurt Andersen, Laura Atkins,	Andersen"/>, <contact fullname="Laura Atkins"/>, <contact fullname="Seth
	Seth Blank, Alex Brotman, Dave Crocker, Douglas E. Foster, Ned Freed,	Blank"/>, <contact fullname="Alex Brotman"/>, <contact fullname="Dave
	Mike Hammer, Steven M. Jones, Scott Kitterman, Murray S. Kucherawy,	Crocker"/>, <contact fullname="Douglas E. Foster"/>, <contact fullname="Ned
	Barry Leiba, Alessandro Vesely, and Tim Wicinski.</t>	Freed"/>, <contact fullname="Mike Hammer"/>, <contact fullname="Steven
		M. Jones"/>, <contact fullname="Scott Kitterman"/>, <contact fullname="Murray
		S. Kucherawy"/>, <contact fullname="Barry Leiba"/>, <contact
		fullname="Alessandro Vesely"/>, and <contact fullname="Tim Wicinski"/>.</t>
	<t>The authors and contributors also recognize that this document would not	<t>The authors and contributors also recognize that this document would not
	have been possible without the work done by those who had a hand in producing	have been possible without the work done by those who had a hand in producing

	<xref target="RFC7489"></xref>. The Acknowledgements section from that document is preserved	<xref target="RFC7489"/>. The Acknowledgements section from that document is pre served
	in full below.</t>	in full below.</t>
	</section>	</section>

	<section anchor="acknowledgements-rfc7489" numbered="false"><name>Acknowledgemen ts - RFC 7489</name>	<section anchor="acknowledgements-rfc7489" numbered="false"><name>Acknowledgemen ts - RFC 7489</name>

	<t>DMARC and the draft version of this document submitted to the	<t>DMARC and the earlier draft version of this document that was submitted to th
	Independent Submission Editor were the result of lengthy efforts by	e Independent
	an informal industry consortium: DMARC.org (see <eref target="https://dmarc.org"	Submission Editor were the result of lengthy efforts by an informal industry
	>https://dmarc.org</eref>).	consortium: DMARC.org (see <eref target="https://dmarc.org"
	Participating companies included Agari, American Greetings, AOL, Bank	brackets="angle"/>). Participating companies included Agari, American
	of America, Cloudmark, Comcast, Facebook, Fidelity Investments,	Greetings, AOL, Bank of America, Cloudmark, Comcast, Facebook, Fidelity
	Google, JPMorgan Chase & Company, LinkedIn, Microsoft, Netease,	Investments, Google, JPMorgan Chase & Company, LinkedIn, Microsoft,
	PayPal, ReturnPath, The Trusted Domain Project, and Yahoo!. Although	Netease, PayPal, ReturnPath, The Trusted Domain Project, and Yahoo!. Although
	the contributors and supporters are too numerous to mention, notable	the contributors and supporters are too numerous to mention, notable

	individual contributions were made by J. Trent Adams, Michael Adkins,	individual contributions were made by <contact fullname="J. Trent Adams"/>,
	Monica Chew, Dave Crocker, Tim Draegen, Steve Jones, Franck Martin,	<contact fullname="Michael Adkins"/>, <contact fullname="Monica Chew"/>,
	Brett McDowell, and Paul Midgen. The contributors would also like to	<contact fullname="Dave Crocker"/>, <contact fullname="Tim Draegen"/>,
	recognize the invaluable input and guidance that was provided early	<contact fullname="Steve Jones"/>, <contact fullname="Franck Martin"/>,
	on by J.D. Falk.</t>	<contact fullname="Brett McDowell"/>, and <contact fullname="Paul
	<t>Additional contributions within the IETF context were made by Kurt	Midgen"/>. The contributors would also like to recognize the invaluable input
	Andersen, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton,	and guidance that was provided early on by <contact
	J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine,	fullname="J.D. Falk"/>.</t>
	S. Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull.</t>	<t>Additional contributions within the IETF context were made by <contact
		fullname="Kurt Andersen"/>, <contact fullname="Michael Jack Assels"/>,
		<contact fullname="Les Barstow"/>, <contact fullname="Anne Bennett"/>,
		<contact fullname="Jim Fenton"/>, <contact fullname="J. Gomez"/>, <contact
		fullname="Mike Jones"/>, <contact fullname="Scott Kitterman"/>, <contact
		fullname="Eliot Lear"/>, <contact fullname="John Levine"/>, <contact
		fullname="S. Moonesamy"/>, <contact fullname="Rolf Sonneveld"/>, <contact
		fullname="Henry Timmes"/>, and <contact fullname="Stephen J. Turnbull"/>.</t>
	</section>	</section>

	</back>	</back>


		<!-- [rfced] Please review whether any of these notes in the document
		should be in the <aside> element. It is defined as "a container for
		content that is semantically less important or tangential to the
		content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
		.

		Original:
		Note: PSD policy is not used for Organizational Domains that have
		published a DMARC Policy Record. Specifically, this is not a
		mechanism to provide feedback addresses (rua/ruf) when an
		Organizational Domain has declined to do so.
		...
		Note: There is no need to perform Identifier Alignment Evaluations
		under any of the following conditions:
		-->

		<!--[rfced] Abbreviations

		a) FYI - We have added expansions for the following abbreviations
		per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
		expansion in the document carefully to ensure correctness.

		Authentication Failure Reporting Format (AFRF)
		Mail User Agent (MUA)

		b) Both the expansion and the acronym for the following terms are used
		throughout the document. Would you like to update to using the expansion
		upon first usage and the acronym for the rest of the document for consistency?

		Domain-based Message Authentication, Reporting, and Conformance (DMARC)
		Public Suffix Domain (PSD)
		Public Suffix List (PSL)
		Public Suffix Operator (PSO)
		Resource Record (RR)
		-->

		<!-- [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.

		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. 558 change blocks.
	1403 lines changed or deleted	1653 lines changed or added
This html diff was produced by rfcdiff 1.48.