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 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
or - mmark.miek.nl" --> cName="draft-ietf-dmarc-dmarcbis-41" number="9989" submissionType="IETF" categor
<rfc version="3" ipr="trust200902" docName="draft-ietf-dmarc-dmarcbis-41" submis y="std" xml:lang="en" obsoletes="7489, 9091" updates="" consensus="true" tocIncl
sionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XI ude="true" symRefs="true" sortRefs="true" prepTime="2026-05-19T20:11:44" indexIn
nclude" obsoletes="7489, 9091" indexInclude="true"> clude="true" scripts="Common,Latin" tocDepth="3">
<link href="https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis-41" rel
<front> ="prev"/>
<title abbrev="DMARCbis">Domain-based Message Authentication, Reporting, and Con <link href="https://dx.doi.org/10.17487/rfc9989" rel="alternate"/>
formance (DMARC)</title><seriesInfo value="draft-ietf-dmarc-dmarcbis-41" stream= <link href="urn:issn:2070-1721" rel="alternate"/>
"IETF" status="standard" name="Internet-Draft"></seriesInfo> <front>
<author initials="T." surname="Herr (ed)" fullname="Todd M. Herr"><organization> <title abbrev="DMARC">Domain-Based Message Authentication, Reporting, and Co
Valimail</organization><address><postal><street></street> nformance (DMARC)</title>
</postal><email>todd@someguyinva.com</email> <seriesInfo name="RFC" value="9989" stream="IETF"/>
</address></author><author initials="J." surname="Levine (ed)" fullname="John Le <author initials="T." surname="Herr" fullname="Todd M. Herr" role="editor">
vine"><organization>Standcore LLC</organization><address><postal><street></stree <organization showOnFrontPage="true">Valimail</organization>
t> <address>
</postal><email>standards@standcore.com</email> <email>todd@someguyinva.com</email>
</address></author><date/> </address>
<area>Application</area> </author>
<workgroup>DMARC</workgroup> <author initials="J." surname="Levine" fullname="John Levine" role="editor">
<organization showOnFrontPage="true">Standcore LLC</organization>
<abstract> <address>
<t>This document describes the Domain-based Message Authentication, <email>standards@standcore.com</email>
</address>
</author>
<date month="05" year="2026"/>
<area>ART</area>
<workgroup>dmarc</workgroup>
<keyword>DMARC</keyword>
<keyword>DKIM</keyword>
<keyword>SPF</keyword>
<keyword>Email</keyword>
<keyword>Authentication</keyword>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">This document describes the Domain-b
ased 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 indent="0" pn="section-abstract-2">DMARC permits the owner of an email'
the domain's use, to indicate the Domain Owner's or Public Suffix Operator's s Author Domain to enable validation of
message handling preference regarding failed validation, and to request reports the domain's use to indicate the Domain Owner's or Public Suffix Operator's
about the use of the domain name. Mail receiving organizations can use this message handling preference regarding failed validation and to request reports
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 indent="0" pn="section-abstract-3">This document obsoletes RFCs 7489 an
</abstract> d 9091.</t>
</abstract>
</front> <boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<middle> "exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
<section anchor="introduction"><name>Introduction</name> >
<t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: <t indent="0" pn="section-boilerplate.1-1">
The source for this draft is maintained on GitHub at: This is an Internet Standards Track document.
<eref target="https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis">https: </t>
//github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis</eref></t> <t indent="0" pn="section-boilerplate.1-2">
<t>Abusive email often includes unauthorized and deceptive use of a This document is a product of the Internet Engineering Task Force
domain name in the &quot;From&quot; header field defined in section 3.6.2 of <xr (IETF). It represents the consensus of the IETF community. It has
ef target="RFC5322"></xref> received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9989" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-requirements">Requirements</xref><
/t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><
xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hi
gh-level-goals">High-Level Goals</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><
xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.
2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-an
ti-phishing">Anti-Phishing</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent=
"2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-scalability">Scalabili
ty</xref></t>
</li>
<li pn="section-toc.1-1.2.2.4">
<t indent="0" pn="section-toc.1-1.2.2.4.1"><xref derivedContent=
"2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-out-of-scope">Out of S
cope</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-terminology-and-definitions">Termi
nology and Definitions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-conventions-used-in-th
is-do">Conventions Used in This Document</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-definitions">Definitio
ns</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.2.2">
<li pn="section-toc.1-1.3.2.2.2.1">
<t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derived
Content="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-authentica
ted-identifiers">Authenticated Identifiers</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derived
Content="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-author-dom
ain">Author Domain</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.3">
<t indent="0" pn="section-toc.1-1.3.2.2.2.3.1"><xref derived
Content="3.2.3" format="counter" sectionFormat="of" target="section-3.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-dkim-signi
ng-domain">DKIM Signing Domain</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.4">
<t indent="0" pn="section-toc.1-1.3.2.2.2.4.1"><xref derived
Content="3.2.4" format="counter" sectionFormat="of" target="section-3.2.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-spf-domain
">SPF Domain</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.5">
<t indent="0" pn="section-toc.1-1.3.2.2.2.5.1"><xref derived
Content="3.2.5" format="counter" sectionFormat="of" target="section-3.2.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-dmarc-poli
cy-domain">DMARC Policy Domain</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.6">
<t indent="0" pn="section-toc.1-1.3.2.2.2.6.1"><xref derived
Content="3.2.6" format="counter" sectionFormat="of" target="section-3.2.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-dmarc-poli
cy-record">DMARC Policy Record</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.7">
<t indent="0" pn="section-toc.1-1.3.2.2.2.7.1"><xref derived
Content="3.2.7" format="counter" sectionFormat="of" target="section-3.2.7"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-domain-own
er">Domain Owner</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.8">
<t indent="0" pn="section-toc.1-1.3.2.2.2.8.1"><xref derived
Content="3.2.8" format="counter" sectionFormat="of" target="section-3.2.8"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-domain-own
er-assessment-pol">Domain Owner Assessment Policy</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.9">
<t indent="0" pn="section-toc.1-1.3.2.2.2.9.1"><xref derived
Content="3.2.9" format="counter" sectionFormat="of" target="section-3.2.9"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-enforcemen
t">Enforcement</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.10">
<t indent="0" pn="section-toc.1-1.3.2.2.2.10.1"><xref derive
dContent="3.2.10" format="counter" sectionFormat="of" target="section-3.2.10"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-identifi
er-alignment">Identifier Alignment</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.11">
<t indent="0" pn="section-toc.1-1.3.2.2.2.11.1"><xref derive
dContent="3.2.11" format="counter" sectionFormat="of" target="section-3.2.11"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-mail-rec
eiver">Mail Receiver</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.12">
<t indent="0" pn="section-toc.1-1.3.2.2.2.12.1"><xref derive
dContent="3.2.12" format="counter" sectionFormat="of" target="section-3.2.12"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-monitori
ng-mode">Monitoring Mode</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.13">
<t indent="0" pn="section-toc.1-1.3.2.2.2.13.1"><xref derive
dContent="3.2.13" format="counter" sectionFormat="of" target="section-3.2.13"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-non-exis
tent-domains">Non-Existent Domains</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.14">
<t indent="0" pn="section-toc.1-1.3.2.2.2.14.1"><xref derive
dContent="3.2.14" format="counter" sectionFormat="of" target="section-3.2.14"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-organiza
tional-domain">Organizational Domain</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.15">
<t indent="0" pn="section-toc.1-1.3.2.2.2.15.1"><xref derive
dContent="3.2.15" format="counter" sectionFormat="of" target="section-3.2.15"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-public-s
uffix-domain-psd">Public Suffix Domain (PSD)</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.16">
<t indent="0" pn="section-toc.1-1.3.2.2.2.16.1"><xref derive
dContent="3.2.16" format="counter" sectionFormat="of" target="section-3.2.16"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-public-s
uffix-operator-pso">Public Suffix Operator (PSO)</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.17">
<t indent="0" pn="section-toc.1-1.3.2.2.2.17.1"><xref derive
dContent="3.2.17" format="counter" sectionFormat="of" target="section-3.2.17"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-pso-cont
rolled-domain-names">PSO-Controlled Domain Names</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.18">
<t indent="0" pn="section-toc.1-1.3.2.2.2.18.1"><xref derive
dContent="3.2.18" format="counter" sectionFormat="of" target="section-3.2.18"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-report-c
onsumer">Report Consumer</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-overview-and-key-concepts">Overvie
w and Key Concepts</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-dmarc-basics">DMARC Ba
sics</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-use-of-rfc5322from">Us
e of RFC5322.From</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-authentication-mechani
sms">Authentication Mechanisms</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4">
<t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent=
"4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-identifier-alignment-e
xplai">Identifier Alignment Explained</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.4.2">
<li pn="section-toc.1-1.4.2.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.4.2.1.1"><xref derived
Content="4.4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-dkim-authe
nticated-identifi">DKIM-Authenticated Identifiers</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.4.2.2.1"><xref derived
Content="4.4.2" format="counter" sectionFormat="of" target="section-4.4.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-spf-authen
ticated-identifie">SPF-Authenticated Identifiers</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.4.2.3.1"><xref derived
Content="4.4.3" format="counter" sectionFormat="of" target="section-4.4.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-alignment-
and-extension-tec">Alignment and Extension Technologies</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.5">
<t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent=
"4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-dmarc-policy-record-ex
plain">DMARC Policy Record Explained</xref></t>
</li>
<li pn="section-toc.1-1.4.2.6">
<t indent="0" pn="section-toc.1-1.4.2.6.1"><xref derivedContent=
"4.6" format="counter" sectionFormat="of" target="section-4.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-dmarc-reporting-uris">
DMARC Reporting URIs</xref></t>
</li>
<li pn="section-toc.1-1.4.2.7">
<t indent="0" pn="section-toc.1-1.4.2.7.1"><xref derivedContent=
"4.7" format="counter" sectionFormat="of" target="section-4.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-dmarc-policy-record-fo
rmat">DMARC Policy Record Format</xref></t>
</li>
<li pn="section-toc.1-1.4.2.8">
<t indent="0" pn="section-toc.1-1.4.2.8.1"><xref derivedContent=
"4.8" format="counter" sectionFormat="of" target="section-4.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-formal-definition">For
mal Definition</xref></t>
</li>
<li pn="section-toc.1-1.4.2.9">
<t indent="0" pn="section-toc.1-1.4.2.9.1"><xref derivedContent=
"4.9" format="counter" sectionFormat="of" target="section-4.9"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-flow-diagram">Flow Dia
gram</xref></t>
</li>
<li pn="section-toc.1-1.4.2.10">
<t indent="0" pn="section-toc.1-1.4.2.10.1"><xref derivedContent
="4.10" format="counter" sectionFormat="of" target="section-4.10"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-dns-tree-walk">DNS T
ree Walk</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.10.2">
<li pn="section-toc.1-1.4.2.10.2.1">
<t indent="0" pn="section-toc.1-1.4.2.10.2.1.1"><xref derive
dContent="4.10.1" format="counter" sectionFormat="of" target="section-4.10.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-dmarc-p
olicy-discovery">DMARC Policy Discovery</xref></t>
</li>
<li pn="section-toc.1-1.4.2.10.2.2">
<t indent="0" pn="section-toc.1-1.4.2.10.2.2.1"><xref derive
dContent="4.10.2" format="counter" sectionFormat="of" target="section-4.10.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-identif
ier-alignment-evalua">Identifier Alignment Evaluation</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-dmarc-participation">DMARC Partici
pation</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-domain-owner-actions">
Domain Owner Actions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.1.2">
<li pn="section-toc.1-1.5.2.1.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derived
Content="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-publish-an
-spf-record-for-a">Publish an SPF Record for an Aligned Domain</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.2">
<t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derived
Content="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-configure-
sending-system-fo">Configure Sending System for DKIM Signing Using an Aligned Do
main</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.3">
<t indent="0" pn="section-toc.1-1.5.2.1.2.3.1"><xref derived
Content="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-set-up-a-m
ailbox-to-receive">Set Up a Mailbox to Receive Aggregate Reports</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.4">
<t indent="0" pn="section-toc.1-1.5.2.1.2.4.1"><xref derived
Content="5.1.4" format="counter" sectionFormat="of" target="section-5.1.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-publish-a-
dmarc-policy-reco">Publish a DMARC Policy Record for the Author Domain and Organ
izational Domain</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.5">
<t indent="0" pn="section-toc.1-1.5.2.1.2.5.1"><xref derived
Content="5.1.5" format="counter" sectionFormat="of" target="section-5.1.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-collect-an
d-analyze-reports">Collect and Analyze Reports</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.6">
<t indent="0" pn="section-toc.1-1.5.2.1.2.6.1"><xref derived
Content="5.1.6" format="counter" sectionFormat="of" target="section-5.1.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-remediate-
unaligned-or-unau">Remediate Unaligned or Unauthenticated Mail Streams</xref></t
>
</li>
<li pn="section-toc.1-1.5.2.1.2.7">
<t indent="0" pn="section-toc.1-1.5.2.1.2.7.1"><xref derived
Content="5.1.7" format="counter" sectionFormat="of" target="section-5.1.7"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-decide-whe
ther-to-update-do">Decide Whether to Update Domain Owner Assessment Policy to En
forcement</xref></t>
</li>
<li pn="section-toc.1-1.5.2.1.2.8">
<t indent="0" pn="section-toc.1-1.5.2.1.2.8.1"><xref derived
Content="5.1.8" format="counter" sectionFormat="of" target="section-5.1.8"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-a-note-on-
large-complex-org">A Note on Large, Complex Organizations and Decentralized DNS
Management</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-pso-actions">PSO Actio
ns</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-mail-receiver-actions"
>Mail Receiver Actions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.3.2">
<li pn="section-toc.1-1.5.2.3.2.1">
<t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derived
Content="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-extract-au
thor-domain">Extract Author Domain</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.2">
<t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derived
Content="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-determine-
if-the-dmarc-mech">Determine If the DMARC Mechanism Applies</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.2.3.1"><xref derived
Content="5.3.3" format="counter" sectionFormat="of" target="section-5.3.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-determine-
if-authenticated-">Determine If Authenticated Identifiers Exist</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.4">
<t indent="0" pn="section-toc.1-1.5.2.3.2.4.1"><xref derived
Content="5.3.4" format="counter" sectionFormat="of" target="section-5.3.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-conduct-id
entifier-alignmen">Conduct Identifier Alignment Checks If Necessary</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.5">
<t indent="0" pn="section-toc.1-1.5.2.3.2.5.1"><xref derived
Content="5.3.5" format="counter" sectionFormat="of" target="section-5.3.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-determine-
dmarc-pass-or-fai">Determine DMARC "Pass" or "Fail"</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.6">
<t indent="0" pn="section-toc.1-1.5.2.3.2.6.1"><xref derived
Content="5.3.6" format="counter" sectionFormat="of" target="section-5.3.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-apply-poli
cy-if-appropriate">Apply Policy If Appropriate</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.7">
<t indent="0" pn="section-toc.1-1.5.2.3.2.7.1"><xref derived
Content="5.3.7" format="counter" sectionFormat="of" target="section-5.3.7"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-store-resu
lts-of-dmarc-proc">Store Results of DMARC Processing</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.8">
<t indent="0" pn="section-toc.1-1.5.2.3.2.8.1"><xref derived
Content="5.3.8" format="counter" sectionFormat="of" target="section-5.3.8"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-send-aggre
gate-reports">Send Aggregate Reports</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.9">
<t indent="0" pn="section-toc.1-1.5.2.3.2.9.1"><xref derived
Content="5.3.9" format="counter" sectionFormat="of" target="section-5.3.9"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-optionally
-send-failure-rep">Optionally Send Failure Reports</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5.2.4">
<t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent=
"5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-policy-enforcement-con
sider">Policy Enforcement Considerations</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-dmarc-feedback">DMARC Feedback</xr
ef></t>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-other-topics">Other Topics</xref><
/t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-issues-specific-to-spf
">Issues Specific to SPF</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rejecting-messages">Re
jecting Messages</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent=
"7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-interoperability-issue
s">Interoperability Issues</xref></t>
</li>
<li pn="section-toc.1-1.7.2.4">
<t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent=
"7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-interoperability-consi
derat">Interoperability
Considerations</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-conformance-requirements-fo">Confo
rmance Requirements for Full DMARC Participation</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-email-authentication-m
ethod">Email Authentication Methods Registry Update</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-email-authentication-r
esult">Email Authentication Result Names Registry Update</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3">
<t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent=
"9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-dmarc-tags-registry-up
date">DMARC Tags Registry Update</xref></t>
</li>
<li pn="section-toc.1-1.9.2.4">
<t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent=
"9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-dmarc-report-formats-r
egist">DMARC Report Formats Registry Update</xref></t>
</li>
<li pn="section-toc.1-1.9.2.5">
<t indent="0" pn="section-toc.1-1.9.2.5.1"><xref derivedContent=
"9.5" format="counter" sectionFormat="of" target="section-9.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-underscored-and-global
ly-sc">Underscored and Globally Scoped DNS Node Names Registry Update</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-privacy-considerations">Privacy
Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent
="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-aggregate-report-co
nsiderat">Aggregate Report Considerations</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2">
<t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent
="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-failure-report-cons
ideratio">Failure Report Considerations</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.11.2">
<li pn="section-toc.1-1.11.2.1">
<t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent
="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-authentication-meth
ods">Authentication Methods</xref></t>
</li>
<li pn="section-toc.1-1.11.2.2">
<t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent
="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-attacks-on-reportin
g-uris">Attacks on Reporting URIs</xref></t>
</li>
<li pn="section-toc.1-1.11.2.3">
<t indent="0" pn="section-toc.1-1.11.2.3.1"><xref derivedContent
="11.3" format="counter" sectionFormat="of" target="section-11.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-dns-security">DNS S
ecurity</xref></t>
</li>
<li pn="section-toc.1-1.11.2.4">
<t indent="0" pn="section-toc.1-1.11.2.4.1"><xref derivedContent
="11.4" format="counter" sectionFormat="of" target="section-11.4"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-display-name-attack
s">Display Name Attacks</xref></t>
</li>
<li pn="section-toc.1-1.11.2.5">
<t indent="0" pn="section-toc.1-1.11.2.5.1"><xref derivedContent
="11.5" format="counter" sectionFormat="of" target="section-11.5"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-denial-of-dmarc-pro
cessing-">Denial of DMARC Processing Attacks</xref></t>
</li>
<li pn="section-toc.1-1.11.2.6">
<t indent="0" pn="section-toc.1-1.11.2.6.1"><xref derivedContent
="11.6" format="counter" sectionFormat="of" target="section-11.6"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-external-reporting-
addresse">External Reporting Addresses</xref></t>
</li>
<li pn="section-toc.1-1.11.2.7">
<t indent="0" pn="section-toc.1-1.11.2.7.1"><xref derivedContent
="11.7" format="counter" sectionFormat="of" target="section-11.7"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-secure-protocols">S
ecure Protocols</xref></t>
</li>
<li pn="section-toc.1-1.11.2.8">
<t indent="0" pn="section-toc.1-1.11.2.8.1"><xref derivedContent
="11.8" format="counter" sectionFormat="of" target="section-11.8"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-relaxed-alignment-c
onsidera">Relaxed Alignment Considerations</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent
="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.12.2.2">
<t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent
="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-technology-cons
iderations">Technology Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.13.2">
<li pn="section-toc.1-1.13.2.1">
<t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent
="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-s-mime">S/MI
ME</xref></t>
</li>
<li pn="section-toc.1-1.13.2.2">
<t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent
="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-method-exclu
sion">Method Exclusion</xref></t>
</li>
<li pn="section-toc.1-1.13.2.3">
<t indent="0" pn="section-toc.1-1.13.2.3.1"><xref derivedContent
="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-sender-heade
r-field">Sender Header Field</xref></t>
</li>
<li pn="section-toc.1-1.13.2.4">
<t indent="0" pn="section-toc.1-1.13.2.4.1"><xref derivedContent
="A.4" format="counter" sectionFormat="of" target="section-appendix.a.4"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-domain-exist
ence-test">Domain Existence Test</xref></t>
</li>
<li pn="section-toc.1-1.13.2.5">
<t indent="0" pn="section-toc.1-1.13.2.5.1"><xref derivedContent
="A.5" format="counter" sectionFormat="of" target="section-appendix.a.5"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-organization
al-domain-disco">Organizational Domain Discovery Issues</xref></t>
</li>
<li pn="section-toc.1-1.13.2.6">
<t indent="0" pn="section-toc.1-1.13.2.6.1"><xref derivedContent
="A.6" format="counter" sectionFormat="of" target="section-appendix.a.6"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-removal-of-t
he-pct-tag">Removal of the "pct" Tag</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="Append
ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-examples">Examp
les</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.14.2">
<li pn="section-toc.1-1.14.2.1">
<t indent="0" pn="section-toc.1-1.14.2.1.1"><xref derivedContent
="B.1" format="counter" sectionFormat="of" target="section-appendix.b.1"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-identifier-a
lignment-exampl">Identifier Alignment Examples</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.14.2.1.2">
<li pn="section-toc.1-1.14.2.1.2.1">
<t indent="0" pn="section-toc.1-1.14.2.1.2.1.1"><xref derive
dContent="B.1.1" format="counter" sectionFormat="of" target="section-appendix.b.
1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
spf">SPF</xref></t>
</li>
<li pn="section-toc.1-1.14.2.1.2.2">
<t indent="0" pn="section-toc.1-1.14.2.1.2.2.1"><xref derive
dContent="B.1.2" format="counter" sectionFormat="of" target="section-appendix.b.
1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
dkim">DKIM</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14.2.2">
<t indent="0" pn="section-toc.1-1.14.2.2.1"><xref derivedContent
="B.2" format="counter" sectionFormat="of" target="section-appendix.b.2"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-domain-owner
-example">Domain Owner Example</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.14.2.2.2">
<li pn="section-toc.1-1.14.2.2.2.1">
<t indent="0" pn="section-toc.1-1.14.2.2.2.1.1"><xref derive
dContent="B.2.1" format="counter" sectionFormat="of" target="section-appendix.b.
2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
entire-domain-monitoring-mo">Entire Domain, Monitoring Mode</xref></t>
</li>
<li pn="section-toc.1-1.14.2.2.2.2">
<t indent="0" pn="section-toc.1-1.14.2.2.2.2.1"><xref derive
dContent="B.2.2" format="counter" sectionFormat="of" target="section-appendix.b.
2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
entire-domain-monitoring-mod">Entire Domain, Monitoring Mode, Per-Message Failur
e Reports</xref></t>
</li>
<li pn="section-toc.1-1.14.2.2.2.3">
<t indent="0" pn="section-toc.1-1.14.2.2.2.3.1"><xref derive
dContent="B.2.3" format="counter" sectionFormat="of" target="section-appendix.b.
2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
per-message-failure-reports">Per-Message Failure Reports Directed to Third Party
</xref></t>
</li>
<li pn="section-toc.1-1.14.2.2.2.4">
<t indent="0" pn="section-toc.1-1.14.2.2.2.4.1"><xref derive
dContent="B.2.4" format="counter" sectionFormat="of" target="section-appendix.b.
2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
overriding-destination-addr">Overriding Destination Addresses</xref></t>
</li>
<li pn="section-toc.1-1.14.2.2.2.5">
<t indent="0" pn="section-toc.1-1.14.2.2.2.5.1"><xref derive
dContent="B.2.5" format="counter" sectionFormat="of" target="section-appendix.b.
2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
subdomain-testing-and-multi">Subdomain, Testing, and Multiple Aggregate Report U
RIs</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14.2.3">
<t indent="0" pn="section-toc.1-1.14.2.3.1"><xref derivedContent
="B.3" format="counter" sectionFormat="of" target="section-appendix.b.3"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-mail-receive
r-example">Mail Receiver Example</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.14.2.3.2">
<li pn="section-toc.1-1.14.2.3.2.1">
<t indent="0" pn="section-toc.1-1.14.2.3.2.1.1"><xref derive
dContent="B.3.1" format="counter" sectionFormat="of" target="section-appendix.b.
3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
smtp-session-example">SMTP Session Example</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14.2.4">
<t indent="0" pn="section-toc.1-1.14.2.4.1"><xref derivedContent
="B.4" format="counter" sectionFormat="of" target="section-appendix.b.4"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-organization
al-and-policy-d">Organizational and Policy Domain Tree Walk Examples</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.14.2.4.2">
<li pn="section-toc.1-1.14.2.4.2.1">
<t indent="0" pn="section-toc.1-1.14.2.4.2.1.1"><xref derive
dContent="B.4.1" format="counter" sectionFormat="of" target="section-appendix.b.
4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
simple-organizational-and-p">Simple Organizational and Policy Example</xref></t>
</li>
<li pn="section-toc.1-1.14.2.4.2.2">
<t indent="0" pn="section-toc.1-1.14.2.4.2.2.1"><xref derive
dContent="B.4.2" format="counter" sectionFormat="of" target="section-appendix.b.
4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
deep-tree-walk-example">Deep Tree Walk Example</xref></t>
</li>
<li pn="section-toc.1-1.14.2.4.2.3">
<t indent="0" pn="section-toc.1-1.14.2.4.2.3.1"><xref derive
dContent="B.4.3" format="counter" sectionFormat="of" target="section-appendix.b.
4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
example-with-a-psd-dmarc-po">Example with a PSD DMARC Policy Record</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14.2.5">
<t indent="0" pn="section-toc.1-1.14.2.5.1"><xref derivedContent
="B.5" format="counter" sectionFormat="of" target="section-appendix.b.5"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-utilization-
of-aggregate-fe">Utilization of Aggregate Feedback: Example</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="Append
ix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-changes-from-rf
c-7489">Changes from RFC 7489</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.15.2">
<li pn="section-toc.1-1.15.2.1">
<t indent="0" pn="section-toc.1-1.15.2.1.1"><xref derivedContent
="C.1" format="counter" sectionFormat="of" target="section-appendix.c.1"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-informationa
l-vs-standards-">Informational vs. Standards Track</xref></t>
</li>
<li pn="section-toc.1-1.15.2.2">
<t indent="0" pn="section-toc.1-1.15.2.2.1"><xref derivedContent
="C.2" format="counter" sectionFormat="of" target="section-appendix.c.2"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-changes-to-t
erminology-and-">Changes to Terminology and Definitions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.15.2.2.2">
<li pn="section-toc.1-1.15.2.2.2.1">
<t indent="0" pn="section-toc.1-1.15.2.2.2.1.1"><xref derive
dContent="C.2.1" format="counter" sectionFormat="of" target="section-appendix.c.
2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
terms-added">Terms Added</xref></t>
</li>
<li pn="section-toc.1-1.15.2.2.2.2">
<t indent="0" pn="section-toc.1-1.15.2.2.2.2.1"><xref derive
dContent="C.2.2" format="counter" sectionFormat="of" target="section-appendix.c.
2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
definitions-updated">Definitions Updated</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.15.2.3">
<t indent="0" pn="section-toc.1-1.15.2.3.1"><xref derivedContent
="C.3" format="counter" sectionFormat="of" target="section-appendix.c.3"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-policy-disco
very-and-organi">Policy Discovery and Organizational Domain Determination</xref>
</t>
</li>
<li pn="section-toc.1-1.15.2.4">
<t indent="0" pn="section-toc.1-1.15.2.4.1"><xref derivedContent
="C.4" format="counter" sectionFormat="of" target="section-appendix.c.4"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-reporting">R
eporting</xref></t>
</li>
<li pn="section-toc.1-1.15.2.5">
<t indent="0" pn="section-toc.1-1.15.2.5.1"><xref derivedContent
="C.5" format="counter" sectionFormat="of" target="section-appendix.c.5"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-tags">Tags</
xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.15.2.5.2">
<li pn="section-toc.1-1.15.2.5.2.1">
<t indent="0" pn="section-toc.1-1.15.2.5.2.1.1"><xref derive
dContent="C.5.1" format="counter" sectionFormat="of" target="section-appendix.c.
5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
tags-added">Tags Added</xref></t>
</li>
<li pn="section-toc.1-1.15.2.5.2.2">
<t indent="0" pn="section-toc.1-1.15.2.5.2.2.1"><xref derive
dContent="C.5.2" format="counter" sectionFormat="of" target="section-appendix.c.
5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
tags-removed">Tags Removed</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.15.2.6">
<t indent="0" pn="section-toc.1-1.15.2.6.1"><xref derivedContent
="C.6" format="counter" sectionFormat="of" target="section-appendix.c.6"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-expansion-of
-domain-owner-a">Expansion of Domain Owner Actions Section</xref></t>
</li>
<li pn="section-toc.1-1.15.2.7">
<t indent="0" pn="section-toc.1-1.15.2.7.1"><xref derivedContent
="C.7" format="counter" sectionFormat="of" target="section-appendix.c.7"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-report-gener
ator-recommenda">Report Generator Recommendations</xref></t>
</li>
<li pn="section-toc.1-1.15.2.8">
<t indent="0" pn="section-toc.1-1.15.2.8.1"><xref derivedContent
="C.8" format="counter" sectionFormat="of" target="section-appendix.c.8"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-removal-of-r
fc-7489-appendi">Removal of RFC 7489, Appendix A.5</xref></t>
</li>
<li pn="section-toc.1-1.15.2.9">
<t indent="0" pn="section-toc.1-1.15.2.9.1"><xref derivedContent
="C.9" format="counter" sectionFormat="of" target="section-appendix.c.9"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-rfc-7489-err
ata-summary">RFC 7489 Errata Summary</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.15.2.9.2">
<li pn="section-toc.1-1.15.2.9.2.1">
<t indent="0" pn="section-toc.1-1.15.2.9.2.1.1"><xref derive
dContent="C.9.1" format="counter" sectionFormat="of" target="section-appendix.c.
9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
rfc-errata-erratum-id-5365-">RFC Errata, Erratum ID 5365, RFC 7489, Section 7.2.
1.1</xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.2">
<t indent="0" pn="section-toc.1-1.15.2.9.2.2.1"><xref derive
dContent="C.9.2" format="counter" sectionFormat="of" target="section-appendix.c.
9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
rfc-errata-erratum-id-5371-">RFC Errata, Erratum ID 5371, RFC 7489, Section 7.2.
1.1</xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.3">
<t indent="0" pn="section-toc.1-1.15.2.9.2.3.1"><xref derive
dContent="C.9.3" format="counter" sectionFormat="of" target="section-appendix.c.
9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
rfc-errata-erratum-id-5440-">RFC Errata, Erratum ID 5440, RFC 7489, Section 7.1
and Appendices B.2.1, B.2.3, and B.2.4</xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.4">
<t indent="0" pn="section-toc.1-1.15.2.9.2.4.1"><xref derive
dContent="C.9.4" format="counter" sectionFormat="of" target="section-appendix.c.
9.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
rfc-errata-erratum-id-6439-">RFC Errata, Erratum ID 6439, RFC 7489, Section 7.1<
/xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.5">
<t indent="0" pn="section-toc.1-1.15.2.9.2.5.1"><xref derive
dContent="C.9.5" format="counter" sectionFormat="of" target="section-appendix.c.
9.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
rfc-errata-erratum-id-5221-">RFC Errata, Erratum ID 5221, RFC 7489, Appendix C</
xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.6">
<t indent="0" pn="section-toc.1-1.15.2.9.2.6.1"><xref derive
dContent="C.9.6" format="counter" sectionFormat="of" target="section-appendix.c.
9.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
rfc-errata-erratum-id-5229-">RFC Errata, Erratum ID 5229, RFC 7489, Appendix C</
xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.7">
<t indent="0" pn="section-toc.1-1.15.2.9.2.7.1"><xref derive
dContent="C.9.7" format="counter" sectionFormat="of" target="section-appendix.c.
9.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
rfc-errata-erratum-5495-rfc">RFC Errata, Erratum 5495, RFC 7489, Section 6.6.3</
xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.8">
<t indent="0" pn="section-toc.1-1.15.2.9.2.8.1"><xref derive
dContent="C.9.8" format="counter" sectionFormat="of" target="section-appendix.c.
9.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
rfc-errata-erratum-id-6485-">RFC Errata, Erratum ID 6485, RFC 7489, Section 7.2.
1.1</xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.9">
<t indent="0" pn="section-toc.1-1.15.2.9.2.9.1"><xref derive
dContent="C.9.9" format="counter" sectionFormat="of" target="section-appendix.c.
9.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
rfc-errata-erratum-id-6729-">RFC Errata, Erratum ID 6729, RFC 7489, Section 3.2<
/xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.10">
<t indent="0" pn="section-toc.1-1.15.2.9.2.10.1"><xref deriv
edContent="C.9.10" format="counter" sectionFormat="of" target="section-appendix.
c.9.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-rfc-errata-erratum-id-7099-">RFC Errata, Erratum ID 7099, RFC 7489, Section 7.
2.1.1</xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.11">
<t indent="0" pn="section-toc.1-1.15.2.9.2.11.1"><xref deriv
edContent="C.9.11" format="counter" sectionFormat="of" target="section-appendix.
c.9.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-rfc-errata-erratum-id-7100-">RFC Errata, Erratum ID 7100, RFC 7489, Section 7.
2.1.1</xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.12">
<t indent="0" pn="section-toc.1-1.15.2.9.2.12.1"><xref deriv
edContent="C.9.12" format="counter" sectionFormat="of" target="section-appendix.
c.9.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-rfc-errata-erratum-id-7835-">RFC Errata, Erratum ID 7835, RFC 7489, Section 6.
6.3</xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.13">
<t indent="0" pn="section-toc.1-1.15.2.9.2.13.1"><xref deriv
edContent="C.9.13" format="counter" sectionFormat="of" target="section-appendix.
c.9.13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-rfc-errata-erratum-id-7865-">RFC Errata, Erratum ID 7865, RFC 7489, Appendix C
</xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.14">
<t indent="0" pn="section-toc.1-1.15.2.9.2.14.1"><xref deriv
edContent="C.9.14" format="counter" sectionFormat="of" target="section-appendix.
c.9.14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-rfc-errata-erratum-id-5151-">RFC Errata, Erratum ID 5151, RFC 7489, Section 1<
/xref></t>
</li>
<li pn="section-toc.1-1.15.2.9.2.15">
<t indent="0" pn="section-toc.1-1.15.2.9.2.15.1"><xref deriv
edContent="C.9.15" format="counter" sectionFormat="of" target="section-appendix.
c.9.15"/>. <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-rfc-errata-erratum-id-5774-">RFC Errata, Erratum ID 5774, RFC 7489, Appendix C
</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.15.2.10">
<t indent="0" pn="section-toc.1-1.15.2.10.1"><xref derivedConten
t="C.10" format="counter" sectionFormat="of" target="section-appendix.c.10"/>. <
xref derivedContent="" format="title" sectionFormat="of" target="name-general-ed
iting-and-formatt">General Editing and Formatting</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.17">
<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements-rfc-7489">Ackn
owledgements - RFC 7489</xref></t>
</li>
<li pn="section-toc.1-1.18">
<t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.f"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="introduction" numbered="true" removeInRFC="false" toc="incl
ude" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">Abusive email often includes unauthorized a
nd deceptive use of a
domain name in the "From" header field defined in <xref target="RFC5322" section
="3.6.2" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org
/rfc/rfc5322#section-3.6.2" derivedContent="RFC5322"/>
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" format="default" sectionFormat="of
" derivedContent="RFC7208"/> and DomainKeys Identified Mail (DKIM) <xref target=
"RFC6376" format="default" sectionFormat="of" derivedContent="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" for mat="default" sectionFormat="of" derivedContent="Section 3.2.2">Author Domain</x ref>.
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" format="
olicy Records</eref>.</t> default" sectionFormat="of" derivedContent="Section 3.2.6">DMARC Policy Records<
<t>As with SPF and DKIM, DMARC validation results in a verdict of either &quot;p /xref>.</t>
ass&quot; or <t indent="0" pn="section-1-2">As with SPF and DKIM, DMARC validation resu
&quot;fail&quot;. A DMARC result of &quot;pass&quot; requires not only an SPF or lts in a verdict of either "pass" or
DKIM pass verdict for "fail". A DMARC result of "pass" requires not only an SPF or DKIM pass verdict f
the email message, but also and more importantly that the domain associated with or
the SPF or DKIM pass be &quot;aligned&quot; with the Author Domain in one of two the email message but also and more importantly that the domain associated with
modes - &quot;relaxed&quot; or &quot;strict&quot;. Domains are said to be in &qu the SPF or DKIM pass be "aligned" with the Author Domain in one of two
ot;relaxed alignment&quot; modes -- "relaxed" or "strict". Domains are said to be in "relaxed alignment"
if they have the same <eref target="#organizational-domain">Organizational Domai if they have the same <xref target="organizational-domain" format="default" sect
n</eref>; a ionFormat="of" derivedContent="Section 3.2.14">Organizational Domain</xref>; 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 &quot;strict alignment&quot; 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 <xref target="domain-owner" format="default" sectionFormat="of" derivedContent="
ecord.</t> Section 3.2.7">Domain Owner</xref> that publishes a DMARC Policy Record.</t>
<t>A DMARC pass for a message indicates only that the use of the Author Domain h <t indent="0" pn="section-1-3">A DMARC pass for a message indicates only t
as been hat the use of the Author Domain has 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 indent="0" pn="section-1-4">On the other hand, a message that fails thi s validation is not necessarily associated
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
&quot;not necessarily associated&quot; 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" format="default" sectionFormat="of" derivedConte nt="RFC7960"/> and <xref target="other-topics" format="default" sectionFormat="o f" derivedContent="Section 7"/> of this document 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 indent="0" pn="section-1-5">DMARC, in the associated documents <xref ta
xref> and <xref target="I-D.ietf-dmarc-failure-reporting"></xref> rget="RFC9990" format="default" sectionFormat="of" derivedContent="RFC9990"/> an
documents, also specifies a reporting framework. Using it, a mail-receiving d <xref target="RFC9991" format="default" sectionFormat="of" derivedContent="RFC
9991"/>,
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 indent="0" pn="section-1-6">The use of DMARC creates some interoperabil ity 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 can cause mail to be rejected. These are discussed in <xref target="other-topics
"></xref>.</t> " format="default" sectionFormat="of" derivedContent="Section 7"/>.</t>
</section> </section>
<section anchor="requirements" numbered="true" removeInRFC="false" toc="incl
<section anchor="requirements"><name>Requirements</name> ude" pn="section-2">
<t>The following sections describe topics that guide the specification of DMARC. <name slugifiedName="name-requirements">Requirements</name>
</t> <t indent="0" pn="section-2-1">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" numbered="true" removeInRFC="false" toc
<t>DMARC has the following high-level goals:</t> ="include" pn="section-2.1">
<name slugifiedName="name-high-level-goals">High-Level Goals</name>
<ul> <t indent="0" pn="section-2.1-1">DMARC has the following high-level goal
<li><t>Allow <eref target="#domain-owner">Domain Owners</eref> and <eref target= s:</t>
"#public-suffix-operator">Public Suffix Operators (PSOs)</eref> to validate thei <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-2
r email authentication deployments.</t> .1-2">
</li> <li pn="section-2.1-2.1">
<li><t>Allow Domain Owners and PSOs to assert their desired message handling <t indent="0" pn="section-2.1-2.1.1">Allow <xref target="domain-owne
r" format="default" sectionFormat="of" derivedContent="Section 3.2.7">Domain Own
ers</xref> and <xref target="public-suffix-operator" format="default" sectionFor
mat="of" derivedContent="Section 3.2.16">Public Suffix Operators (PSOs)</xref> t
o validate their email authentication deployments.</t>
</li>
<li pn="section-2.1-2.2">
<t indent="0" pn="section-2.1-2.2.1">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 pn="section-2.1-2.3">
</li> <t indent="0" pn="section-2.1-2.3.1">Minimize implementation complex
<li><t>Reduce the amount of successfully delivered spoofed emails.</t> ity for both senders and receivers.</t>
</li> </li>
<li><t>Work at Internet scale.</t> <li pn="section-2.1-2.4">
</li> <t indent="0" pn="section-2.1-2.4.1">Reduce the amount of successful
</ul> ly delivered spoofed emails.</t>
</section> </li>
<li pn="section-2.1-2.5">
<section anchor="anti-phishing"><name>Anti-Phishing</name> <t indent="0" pn="section-2.1-2.5.1">Work at Internet scale.</t>
<t>DMARC is designed to prevent the unauthorized use of the <eref target="#autho </li>
r-domain">Author Domain</eref> </ul>
of an email message, a technique known as &quot;spoofing&quot;. Such unauthorize </section>
d usage can <section anchor="anti-phishing" numbered="true" removeInRFC="false" toc="i
frequently be found in messages impersonating a domain belonging to a business e nclude" pn="section-2.2">
ntity, <name slugifiedName="name-anti-phishing">Anti-Phishing</name>
<t indent="0" pn="section-2.2-1">DMARC is designed to prevent the unauth
orized use of the <xref target="author-domain" format="default" sectionFormat="o
f" derivedContent="Section 3.2.2">Author Domain</xref>
of an email message, a technique known as "spoofing". Such unauthorized usage ca
n
frequently be found in messages impersonating a domain belonging to a business e
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 &quot;phishing&quot;.</t> commonly referred to as "phishing".</t>
<t>DMARC can only be used to combat specific forms of exact-domain spoofing dire <t indent="0" pn="section-2.2-2">DMARC can only be used to combat specif
ctly. DMARC ic forms of exact-domain spoofing directly. 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 RFC5322.From human-readable display name, as defined in <xref target="RFC5322" s
ectionFormat="of" section="3.4"></xref>.</t> ectionFormat="of" section="3.4" format="default" derivedLink="https://rfc-editor
</section> .org/rfc/rfc5322#section-3.4" derivedContent="RFC5322"/>.</t>
</section>
<section anchor="scalability"><name>Scalability</name> <section anchor="scalability" numbered="true" removeInRFC="false" toc="inc
<t>Scalability is a significant issue for systems that need to operate in lude" pn="section-2.3">
<name slugifiedName="name-scalability">Scalability</name>
<t indent="0" pn="section-2.3-1">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 indent="0" pn="section-2.3-2">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" numbered="true" removeInRFC="false" toc="in
<section anchor="out-of-scope"><name>Out of Scope</name> clude" pn="section-2.4">
<t>Several topics and issues are specifically out of scope of this <name slugifiedName="name-out-of-scope">Out of Scope</name>
<t indent="0" pn="section-2.4-1">Several topics and issues are specifica
lly out of scope of this
work. These include the following:</t> work. These include the following:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-2
<ul> .4-2">
<li><t>Different treatment of messages that are not authenticated (e.g., <li pn="section-2.4-2.1">
those that have no DKIM signature or those sent using an <eref target="#author-d <t indent="0" pn="section-2.4-2.1.1">Different treatment of messages
omain">Author that are not authenticated (e.g.,
Domain</eref> for which no <eref target="#dmarc-policy-record">DMARC Policy Reco those that have no DKIM signature or those sent using an <xref target="author-do
rd</eref> main" format="default" sectionFormat="of" derivedContent="Section 3.2.2">Author
exists) versus those that fail validation;</t> Domain</xref> for which no <xref target="dmarc-policy-record" format="default" s
</li> ectionFormat="of" derivedContent="Section 3.2.6">DMARC Policy Record</xref>
<li><t>Evaluation of anything other than RFC5322.From header field;</t> exists versus those that fail validation;</t>
</li> </li>
<li><t>Multiple reporting formats;</t> <li pn="section-2.4-2.2">
</li> <t indent="0" pn="section-2.4-2.2.1">Evaluation of anything other th
<li><t>Publishing policy other than via the DNS;</t> an the RFC5322.From header field;</t>
</li> </li>
<li><t>Reporting or otherwise evaluating other than the last-hop IP <li pn="section-2.4-2.3">
<t indent="0" pn="section-2.4-2.3.1">Multiple reporting formats;</t>
</li>
<li pn="section-2.4-2.4">
<t indent="0" pn="section-2.4-2.4.1">Publishing policy other than vi
a the DNS;</t>
</li>
<li pn="section-2.4-2.5">
<t indent="0" pn="section-2.4-2.5.1">Reporting or otherwise evaluati
ng 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 pn="section-2.4-2.6">
also known as &quot;display name&quot; attacks;</t> <t indent="0" pn="section-2.4-2.6.1">Attacks in the display name por
</li> tions of the RFC5322.From header field,
<li><t>Authentication of entities other than domains, since DMARC is also known as "display name" attacks;</t>
</li>
<li pn="section-2.4-2.7">
<t indent="0" pn="section-2.4-2.7.1">Authentication of entities othe
r 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 pn="section-2.4-2.8">
</li> <t indent="0" pn="section-2.4-2.8.1">Content analysis.</t>
</ul> </li>
</section> </ul>
</section> </section>
</section>
<section anchor="terminology"><name>Terminology and Definitions</name> <section anchor="terminology" numbered="true" removeInRFC="false" toc="inclu
<t>This section defines terms used in the rest of the document.</t> de" pn="section-3">
<name slugifiedName="name-terminology-and-definitions">Terminology and Def
<section anchor="conventions-used-in-this-document"><name>Conventions Used in Th initions</name>
is Document</name> <t indent="0" pn="section-3-1">This section defines terms used in the rest
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, & of the document.</t>
quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, <section anchor="conventions-used-in-this-document" numbered="true" remove
&quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &q InRFC="false" toc="include" pn="section-3.1">
uot;MAY&quot;, and &quot;OPTIONAL&quot; in this <name slugifiedName="name-conventions-used-in-this-do">Conventions Used
document are to be interpreted as described in BCP 14 <xref target="RFC2119"></x in This Document</name>
ref> <xref target="RFC8174"></xref> <t indent="0" pn="section-3.1-1">
when, and only when, they appear in all capitals, as shown here.</t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<t>Readers are encouraged to be familiar with the contents of IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
<xref target="RFC5598"></xref>. In particular, that document D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t indent="0" pn="section-3.1-2">Readers are encouraged to be familiar w
ith the contents of
<xref target="RFC5598" format="default" sectionFormat="of" derivedContent="RFC55
98"/>. 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" form at="default" sectionFormat="of" derivedContent="Section 3.2.7">Domain Owner</xre f> 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" numbered="true" removeInRFC="false" toc="inc
<section anchor="definitions"><name>Definitions</name> lude" pn="section-3.2">
<t>The following sections define the terms used in this document.</t> <name slugifiedName="name-definitions">Definitions</name>
<t indent="0" pn="section-3.2-1">The following sections define the terms
<section anchor="authenticated-identifiers"><name>Authenticated Identifiers</nam used in this document.</t>
e> <section anchor="authenticated-identifiers" numbered="true" removeInRFC=
<t>Authenticated Identifiers are those domain-level identifiers for which author "false" toc="include" pn="section-3.2.1">
ized <name slugifiedName="name-authenticated-identifiers">Authenticated Ide
use is validated using a supported <eref target="#authentication-mechanisms">aut ntifiers</name>
hentication mechanism</eref>.</t> <t indent="0" pn="section-3.2.1-1">Authenticated Identifiers are those
</section> domain-level identifiers for which authorized
use is validated using a supported <xref target="authentication-mechanisms" form
<section anchor="author-domain"><name>Author Domain</name> at="default" sectionFormat="of" derivedContent="Section 4.3">authentication mech
<t>The domain name of the apparent author as extracted from the RFC5322.From hea anism</xref>.</t>
der field.</t> </section>
</section> <section anchor="author-domain" numbered="true" removeInRFC="false" toc=
"include" pn="section-3.2.2">
<section anchor="dkim-signing-domain"><name>DKIM Signing Domain</name> <name slugifiedName="name-author-domain">Author Domain</name>
<t>The domain name that is the value of the &quot;d&quot; tag in a validated DKI <t indent="0" pn="section-3.2.2-1">The Author Domain is the domain nam
M-Signature header e of the apparent author as extracted from the RFC5322.From header field.</t>
</section>
<section anchor="dkim-signing-domain" numbered="true" removeInRFC="false
" toc="include" pn="section-3.2.3">
<name slugifiedName="name-dkim-signing-domain">DKIM Signing Domain</na
me>
<t indent="0" pn="section-3.2.3-1">The DKIM Signing Domain is the doma
in name that is the value of the "d" tag in a validated DKIM-Signature header
field in an email message.</t> field in an email message.</t>
</section> </section>
<section anchor="spf-domain" numbered="true" removeInRFC="false" toc="in
<section anchor="spf-domain"><name>SPF Domain</name> clude" pn="section-3.2.4">
<t>SPF, <xref target="RFC7208"></xref>, can validate the uses of both the domain <name slugifiedName="name-spf-domain">SPF Domain</name>
found in an SMTP <xref target="RFC5321"></xref> <t indent="0" pn="section-3.2.4-1">SPF <xref target="RFC7208" format="
default" sectionFormat="of" derivedContent="RFC7208"/> can validate the uses of
both the domain found in an SMTP <xref target="RFC5321" format="default" section
Format="of" derivedContent="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" format="default" sectionFormat="of" derived Link="https://rfc-editor.org/rfc/rfc7208#section-2.4" derivedContent="RFC7208"/> describes the determination of the MAIL FROM 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 &quot;postmaster&quot; and the HELO identity.</t> the local-part "postmaster" and the HELO identity.</t>
<t>The term &quot;SPF Domain&quot; when used in this document refers to an SPF v <t indent="0" pn="section-3.2.4-2">The term "SPF Domain" when used in
alidated MAIL FROM this document refers to an SPF-validated MAIL FROM
identity.</t> identity.</t>
</section> </section>
<section anchor="dmarc-policy-domain" numbered="true" removeInRFC="false
<section anchor="dmarc-policy-domain"><name>DMARC Policy Domain</name> " toc="include" pn="section-3.2.5">
<t>The domain name at which an applicable <eref target="#dmarc-policy-record">DM <name slugifiedName="name-dmarc-policy-domain">DMARC Policy Domain</na
ARC Policy Record</eref> is discovered me>
for the <eref target="#author-domain">Author Domain</eref> of an email message.< <t indent="0" pn="section-3.2.5-1">The DMARC Policy Domain is the doma
/t> in name at which an applicable <xref target="dmarc-policy-record" format="defaul
</section> t" sectionFormat="of" derivedContent="Section 3.2.6">DMARC Policy Record</xref>
is discovered
<section anchor="dmarc-policy-record"><name>DMARC Policy Record</name> for the <xref target="author-domain" format="default" sectionFormat="of" derived
<t>A DNS TXT record published by a <eref target="#domain-owner">Domain Owner</er Content="Section 3.2.2">Author Domain</xref> of an email message.</t>
ef> or <eref target="#public-suffix-operator">Public Suffix </section>
Operator (PSO)</eref> to enable validation of an <eref target="#author-domain">A <section anchor="dmarc-policy-record" numbered="true" removeInRFC="false
uthor " toc="include" pn="section-3.2.6">
Domain's</eref> use, to indicate the Domain Owner's or PSO's message <name slugifiedName="name-dmarc-policy-record">DMARC Policy Record</na
me>
<t indent="0" pn="section-3.2.6-1">A DMARC Policy Record is a DNS TXT
record published by a <xref target="domain-owner" format="default" sectionFormat
="of" derivedContent="Section 3.2.7">Domain Owner</xref> or <xref target="public
-suffix-operator" format="default" sectionFormat="of" derivedContent="Section 3.
2.16">Public Suffix
Operator (PSO)</xref> to enable validation of an <xref target="author-domain" fo
rmat="default" sectionFormat="of" derivedContent="Section 3.2.2">Author
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" numbered="true" removeInRFC="false" toc="
<section anchor="domain-owner"><name>Domain Owner</name> include" pn="section-3.2.7">
<t>An entity or organization that has control of a given DNS domain, <name slugifiedName="name-domain-owner">Domain Owner</name>
<t indent="0" pn="section-3.2.7-1">A Domain Owner is an entity or orga
nization that has control of a given DNS domain,
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" fo
t can also rmat="default" sectionFormat="of" derivedContent="RFC5598"/>. 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" numbered="true" removeInRFC="false
<section anchor="domain-owner-policy"><name>Domain Owner Assessment Policy</name " toc="include" pn="section-3.2.8">
> <name slugifiedName="name-domain-owner-assessment-pol">Domain Owner As
<t>The message handling preference expressed in a <eref target="#dmarc-policy-re sessment Policy</name>
cord">DMARC Policy Record</eref> <t indent="0" pn="section-3.2.8-1">The Domain Owner Assessment Policy
by the <eref target="#domain-owner">Domain Owner</eref> regarding failed validat is the message handling preference expressed in a <xref target="dmarc-policy-rec
ion of the <eref target="#author-domain">Author Domain</eref> is called the &quo ord" format="default" sectionFormat="of" derivedContent="Section 3.2.6">DMARC Po
t;Domain Owner Assessment Policy&quot;. Possible values are described in licy Record</xref>
<xref target="policy-record-format"></xref>.</t> by the <xref target="domain-owner" format="default" sectionFormat="of" derivedCo
</section> ntent="Section 3.2.7">Domain Owner</xref> regarding failed validation of the <xr
ef target="author-domain" format="default" sectionFormat="of" derivedContent="Se
<section anchor="enforcement"><name>Enforcement</name> ction 3.2.2">Author Domain</xref>. Possible values are described in
<t>Enforcement describes a state where the existing <eref target="#domain-owner- <xref target="policy-record-format" format="default" sectionFormat="of" derivedC
policy">Domain Owner Assessment Policy</eref> ontent="Section 4.7"/>.</t>
for an <eref target="#organizational-domain">Organizational Domain</eref> and al </section>
l subdomains below it <section anchor="enforcement" numbered="true" removeInRFC="false" toc="i
is not &quot;p=none&quot;. This state means that the Organizational Domain and i nclude" pn="section-3.2.9">
ts subdomains <name slugifiedName="name-enforcement">Enforcement</name>
can only be used as <eref target="#author-domain">Author Domains</eref> if they <t indent="0" pn="section-3.2.9-1">Enforcement describes a state where
are properly validated the existing <xref target="domain-owner-policy" format="default" sectionFormat=
"of" derivedContent="Section 3.2.8">Domain Owner Assessment Policy</xref>
for an <xref target="organizational-domain" format="default" sectionFormat="of"
derivedContent="Section 3.2.14">Organizational Domain</xref> and all subdomains
below it
is not "p=none". This state means that the Organizational Domain and its subdoma
ins
can only be used as <xref target="author-domain" format="default" sectionFormat=
"of" derivedContent="Section 3.2.2">Author Domains</xref> if they are properly v
alidated
using the DMARC mechanism.</t> using the DMARC mechanism.</t>
<t>Historically, Domain Owner Assessment Policies of &quot;p=quarantine&quot; or <t indent="0" pn="section-3.2.9-2">Historically, Domain Owner Assessme
&quot;p=reject&quot; nt Policies of "p=quarantine" or "p=reject"
have been higher value signals to <eref target="#mail-receiver">Mail Receivers</ have been higher value signals to <xref target="mail-receiver" format="default"
eref>. Messages with Author sectionFormat="of" derivedContent="Section 3.2.11">Mail Receivers</xref>. Messag
es 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" numbered="true" removeInRFC="fals
<section anchor="identifier-alignment"><name>Identifier Alignment</name> e" toc="include" pn="section-3.2.10">
<t>DMARC describes the concept of alignment between the <eref target="#author-do <name slugifiedName="name-identifier-alignment">Identifier Alignment</
main">Author Domain</eref> name>
and an <eref target="#authenticated-identifiers">Authenticated Identifier</eref> <t indent="0" pn="section-3.2.10-1">DMARC describes the concept of ali
, and requires gnment between the <xref target="author-domain" format="default" sectionFormat="
of" derivedContent="Section 3.2.2">Author Domain</xref>
and an <xref target="authenticated-identifiers" format="default" sectionFormat="
of" derivedContent="Section 3.2.1">Authenticated Identifier</xref> 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" numbered="true" removeInRFC="false
<section anchor="relaxed-alignment"><name>Relaxed Alignment</name> " toc="exclude" pn="section-3.2.10.1">
<t>When the <eref target="#author-domain">Author Domain</eref> has the same <ere <name slugifiedName="name-relaxed-alignment">Relaxed Alignment</name
f target="#organizational-domain">Organizational Domain</eref> >
as an <eref target="#authenticated-identifier">Authenticated Identifier</eref>, <t indent="0" pn="section-3.2.10.1-1">When the <xref target="author-
the two are said to be domain" format="default" sectionFormat="of" derivedContent="Section 3.2.2">Autho
r Domain</xref> has the same <xref target="organizational-domain" format="defaul
t" sectionFormat="of" derivedContent="Section 3.2.14">Organizational Domain</xre
f>
as an <xref target="authenticated-identifiers" format="default" sectionFormat="o
f" derivedContent="Section 3.2.1">Authenticated Identifier</xref>, the two are s
aid to be
in relaxed alignment.</t> in relaxed alignment.</t>
</section> </section>
<section anchor="strict-alignment" numbered="true" removeInRFC="false"
<section anchor="strict-alignment"><name>Strict Alignment</name> toc="exclude" pn="section-3.2.10.2">
<t>When the <eref target="#author-domain">Author Domain</eref> is identical to a <name slugifiedName="name-strict-alignment">Strict Alignment</name>
n <eref target="#authenticated-identifier">Authenticated Identifier</eref>, the <t indent="0" pn="section-3.2.10.2-1">When the <xref target="author-
two are said to be in strict alignment.</t> domain" format="default" sectionFormat="of" derivedContent="Section 3.2.2">Autho
</section> r Domain</xref> is identical to an <xref target="authenticated-identifiers" form
</section> at="default" sectionFormat="of" derivedContent="Section 3.2.1">Authenticated Ide
ntifier</xref>, the two are said to be in strict alignment.</t>
<section anchor="mail-receiver"><name>Mail Receiver</name> </section>
<t>The entity or organization that receives and processes email. Mail </section>
<section anchor="mail-receiver" numbered="true" removeInRFC="false" toc=
"include" pn="section-3.2.11">
<name slugifiedName="name-mail-receiver">Mail Receiver</name>
<t indent="0" pn="section-3.2.11-1">The Mail Receiver is the entity or
organization that receives and processes email. 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" numbered="true" removeInRFC="false" to
<section anchor="monitoring-mode"><name>Monitoring Mode</name> c="include" pn="section-3.2.12">
<t>Monitoring Mode describes a state where the existing <eref target="#domain-ow <name slugifiedName="name-monitoring-mode">Monitoring Mode</name>
ner-policy">Domain Owner Assessment Policy</eref> for an <t indent="0" pn="section-3.2.12-1">Monitoring Mode describes a state
<eref target="#organizational-domain">Organizational Domain</eref> and all subdo where the existing <xref target="domain-owner-policy" format="default" sectionFo
mains below it rmat="of" derivedContent="Section 3.2.8">Domain Owner Assessment Policy</xref> f
is &quot;p=none&quot;, and the <eref target="#domain-owner">Domain Owner</eref> or an
is receiving aggregate reports <xref target="organizational-domain" format="default" sectionFormat="of" derived
Content="Section 3.2.14">Organizational Domain</xref> and all subdomains below i
t
is "p=none", and the <xref target="domain-owner" format="default" sectionFormat=
"of" derivedContent="Section 3.2.7">Domain Owner</xref> is receiving aggregate r
eports
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" format="default" sectionFormat="o
be validated by a <eref target="#mail-receiver">Mail Receiver</eref> deploying t f" derivedContent="Section 3.2.2">Author Domains</xref> can still be validated b
he DMARC mechanism, the Domain Owner expresses no handling y a <xref target="mail-receiver" format="default" sectionFormat="of" derivedCont
preference for messages that fail DMARC validation. The Domain Owner is, howeve ent="Section 3.2.11">Mail Receiver</xref> deploying the DMARC mechanism, the Dom
r, using ain Owner expresses no handling
preference for messages that fail DMARC validation. However, the Domain Owner i
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" numbered="true" removeInRFC="fals
<section anchor="non-existent-domains"><name>Non-existent Domains</name> e" toc="include" pn="section-3.2.13">
<t>For DMARC purposes, a non-existent domain is consistent with the term's meani <name slugifiedName="name-non-existent-domains">Non-Existent Domains</
ng name>
as described in <xref target="RFC8020"></xref>. That is, if the response code re <t indent="0" pn="section-3.2.13-1">For DMARC purposes, a non-existent
ceived for a query domain is consistent with the term's meaning
as described in <xref target="RFC8020" format="default" sectionFormat="of" deriv
edContent="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" numbered="true" removeInRFC="fal
<section anchor="organizational-domain"><name>Organizational Domain</name> se" toc="include" pn="section-3.2.14">
<t>The Organizational Domain for any domain is akin to the ADMD described in <name slugifiedName="name-organizational-domain">Organizational Domain
<xref target="RFC5598"></xref>. A domain's Organizational Domain is the domain a </name>
t the top of <t indent="0" pn="section-3.2.14-1">The Organizational Domain for any
domain is akin to the ADMD described in
<xref target="RFC5598" format="default" sectionFormat="of" derivedContent="RFC55
98"/>. 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" format="default" sectionForm
</section> at="of" derivedContent="Section 4.10"/>.</t>
</section>
<section anchor="public-suffix-domain"><name>Public Suffix Domain (PSD)</name> <section anchor="public-suffix-domain" numbered="true" removeInRFC="fals
<t>Some domains allow the registration of subdomains that are e" toc="include" pn="section-3.2.15">
&quot;owned&quot; by independent organizations. Real-world examples of <name slugifiedName="name-public-suffix-domain-psd">Public Suffix Doma
these domains are &quot;.com&quot;, &quot;.org&quot;, &quot;.us&quot;, and &quot in (PSD)</name>
;.co.uk&quot;, to name just a few. <t indent="0" pn="section-3.2.15-1">Some domains allow the registratio
These domains are called &quot;Public Suffix Domains&quot; (PSDs). n of subdomains that are
For example, &quot;ietf.org&quot; is a registered domain name, and &quot;.org&qu "owned" by independent organizations. Real-world examples of
ot; is its PSD.</t> these domains are ".com", ".org", ".us", and ".co.uk", to name just a few.
</section> These domains are called "Public Suffix Domains" (PSDs).
For example, "ietf.org" is a registered domain name, and ".org" is its PSD.</t>
<section anchor="public-suffix-operator"><name>Public Suffix Operator (PSO)</nam </section>
e> <section anchor="public-suffix-operator" numbered="true" removeInRFC="fa
<t>A Public Suffix Operator is an organization that manages operations lse" toc="include" pn="section-3.2.16">
<name slugifiedName="name-public-suffix-operator-pso">Public Suffix Op
erator (PSO)</name>
<t indent="0" pn="section-3.2.16-1">A PSO is an organization that mana
ges 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" numbered="true" removeInRF
<section anchor="pso-controlled-domain-names"><name>PSO Controlled Domain Names< C="false" toc="include" pn="section-3.2.17">
/name> <name slugifiedName="name-pso-controlled-domain-names">PSO-Controlled
<t>PSO-Controlled Domain Names are names in the DNS that are managed by Domain Names</name>
a PSO. PSO-controlled Domain Names may have one label (e.g., &quot;.com&quot;) o <t indent="0" pn="section-3.2.17-1">PSO-Controlled Domain Names are na
r more mes in the DNS that are managed by
(e.g., &quot;.co.uk&quot;), depending on the PSD's policy.</t> a PSO. PSO-Controlled Domain Names may have one label (e.g., ".com") or more
</section> (e.g., ".co.uk"), depending on the PSO's policy.</t>
</section>
<section anchor="report-consumer"><name>Report Consumer</name> <section anchor="report-consumer" numbered="true" removeInRFC="false" to
<t>A Report Consumer is an operator that receives reports from another operator c="include" pn="section-3.2.18">
implementing the reporting mechanisms described in the documents <name slugifiedName="name-report-consumer">Report Consumer</name>
<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref> and <xref target="I-D. <t indent="0" pn="section-3.2.18-1">A Report Consumer is an operator t
ietf-dmarc-failure-reporting"></xref>. hat receives reports from another operator
implementing the reporting mechanisms described in
<xref target="RFC9990" format="default" sectionFormat="of" derivedContent="RFC99
90"/> and <xref target="RFC9991" format="default" sectionFormat="of" derivedCont
ent="RFC9991"/>.
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>
<t>Report Consumers can receive reports concerning domains for which the Report <t indent="0" pn="section-3.2.18-2">Report Consumers can receive repor
Consumer is also the <eref target="#domain-owner">Domain Owner</eref> or <eref t ts concerning domains for which the Report
arget="#public-suffix-operator">PSO</eref>, Consumer is also the <xref target="domain-owner" format="default" sectionFormat=
"of" derivedContent="Section 3.2.7">Domain Owner</xref> or <xref target="public-
suffix-operator" format="default" sectionFormat="of" derivedContent="Section 3.2
.16">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 a third party to act as a Report Consumer. See <xref target="external- report-addresses" format="default" sectionFormat="of" derivedContent="Section 11 .6"/> for further
discussion of such designation.</t> discussion of such designation.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="overview-and-key-concepts" numbered="true" removeInRFC="fal
<section anchor="overview-and-key-concepts"><name>Overview and Key Concepts</nam se" toc="include" pn="section-4">
e> <name slugifiedName="name-overview-and-key-concepts">Overview and Key Conc
<t>This section provides a general overview of the design and operation epts</name>
<t indent="0" pn="section-4-1">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" numbered="true" removeInRFC="false" toc="in
<section anchor="dmarc-basics"><name>DMARC Basics</name> clude" pn="section-4.1">
<t>DMARC permits a <eref target="#domain-owner">Domain Owner</eref> or <eref tar <name slugifiedName="name-dmarc-basics">DMARC Basics</name>
get="#public-suffix-operator">PSO</eref> to enable <t indent="0" pn="section-4.1-1">DMARC permits a <xref target="domain-ow
validation of an <eref target="#author-domain">Author Domain's</eref> use in an ner" format="default" sectionFormat="of" derivedContent="Section 3.2.7">Domain O
email message, to indicate wner</xref> or <xref target="public-suffix-operator" format="default" sectionFor
mat="of" derivedContent="Section 3.2.16">PSO</xref> to enable
validation of an <xref target="author-domain" format="default" sectionFormat="of
" derivedContent="Section 3.2.2">Author Domain's</xref> use in an email 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" format="default" sectionFormat="of" derivedContent="Section 3.2
cord at the name created by prepending .6">DMARC Policy Record</xref> is published in the DNS as a TXT record at the na
the label &quot;_dmarc&quot; to the domain name and is retrieved through normal me created by prepending
DNS queries.</t> the label "_dmarc" to the domain name and is retrieved through normal DNS querie
<t>DMARC's validation mechanism produces a &quot;pass&quot; result if a DMARC Po s.</t>
licy Record exists for <t indent="0" pn="section-4.1-2">DMARC's validation mechanism produces a
the Author Domain of an email message and the Author Domain is <eref target="#id "pass" result if a DMARC Policy Record exists for
entifier-alignment">aligned</eref> the Author Domain of an email message and the Author Domain is <xref target="ide
with an <eref target="#authenticated-identifiers">Authenticated Identifier</eref ntifier-alignment" format="default" sectionFormat="of" derivedContent="Section 3
> from that message. .2.10">aligned</xref>
with an <xref target="authenticated-identifiers" format="default" sectionFormat=
"of" derivedContent="Section 3.2.1">Authenticated Identifier</xref> from that me
ssage.
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 &quot;pass&quot; result, the <eref target="#mail-receiver">Mail Receiv produce a "pass" result, the <xref target="mail-receiver" format="default" secti
er's</eref> handling of that message onFormat="of" derivedContent="Section 3.2.11">Mail Receiver's</xref> handling of
can be influenced by the <eref target="#domain-owner-policy">Domain Owner Assess that message
ment Policy</eref> expressed can be influenced by the <xref target="domain-owner-policy" format="default" sec
tionFormat="of" derivedContent="Section 3.2.8">Domain Owner Assessment Policy</x
ref> 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 indent="0" pn="section-4.1-3">It is important to note that the authen tication 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 indent="0" pn="section-4.1-4">DMARC's reporting component involves th e 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" format="default" sectionFormat="of" derivedC
<t>A Mail Receiver participating in DMARC might also generate per-message failur ontent="RFC9990"/>.</t>
e <t indent="0" pn="section-4.1-5">A Mail Receiver participating in DMARC
might also generate per-message failure
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 <xref target="RFC6591" format="default" sectionFormat="of" derivedContent="RFC65
g"></xref></t> 91"/> and <xref target="RFC9991" format="default" sectionFormat="of" derivedCont
</section> ent="RFC9991"/>.</t>
</section>
<section anchor="use-of-rfc5322-from"><name>Use of RFC5322.From</name> <section anchor="use-of-rfc5322-from" numbered="true" removeInRFC="false"
<t>One of the most obvious points of security scrutiny for DMARC is the toc="include" pn="section-4.2">
<name slugifiedName="name-use-of-rfc5322from">Use of RFC5322.From</name>
<t indent="0" pn="section-4.2-1">One of the most obvious points of secur
ity 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 <xref target="RFC5322" format="default" sectionFormat="of" derivedContent="RFC53
ope of this specification.</t> 22"/>, and handling such a message is outside of the scope of this specification
</section> .</t>
</section>
<section anchor="authentication-mechanisms"><name>Authentication Mechanisms</nam <section anchor="authentication-mechanisms" numbered="true" removeInRFC="f
e> alse" toc="include" pn="section-4.3">
<t>The following mechanisms for determining <eref target="#authenticated-identif <name slugifiedName="name-authentication-mechanisms">Authentication Mech
iers">Authenticated Identifiers</eref> are supported in this version of DMARC:</ anisms</name>
t> <t indent="0" pn="section-4.3-1">The following mechanisms for determinin
g <xref target="authenticated-identifiers" format="default" sectionFormat="of" d
<ul> erivedContent="Section 3.2.1">Authenticated Identifiers</xref> are supported in
<li><t>DKIM, <xref target="RFC6376"></xref>. The <eref target="#dkim-signing-dom this version of DMARC:</t>
ain">DKIM Signing Domain</eref> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4
from a validated DKIM-Signature header field is an Authenticated Identifier.</t> .3-2">
</li> <li pn="section-4.3-2.1">DKIM <xref target="RFC6376" format="default"
<li><t>SPF, <xref target="RFC7208"></xref>. The validated <eref target="#spf-dom sectionFormat="of" derivedContent="RFC6376"/>: The <xref target="dkim-signing-do
ain">SPF Domain</eref> from the email main" format="default" sectionFormat="of" derivedContent="Section 3.2.3">DKIM Si
message is the Authenticated Identifier.</t> gning Domain</xref>
</li> from a validated DKIM-Signature header field is an Authenticated Identifier.</li
</ul> >
</section> <li pn="section-4.3-2.2">SPF <xref target="RFC7208" format="default" s
ectionFormat="of" derivedContent="RFC7208"/>: The validated <xref target="spf-do
<section anchor="identifier-alignment-explained"><name>Identifier Alignment Expl main" format="default" sectionFormat="of" derivedContent="Section 3.2.4">SPF Dom
ained</name> ain</xref> from the email
<t>DMARC validates the authorized use of the <eref target="#author-domain">Autho message is the Authenticated Identifier.</li>
r Domain</eref> by requiring </ul>
either that it have the same <eref target="#organizational-domain">Organizationa </section>
l Domain</eref> as an <section anchor="identifier-alignment-explained" numbered="true" removeInR
<eref target="#authenticated-identifier">Authenticated Identifier</eref> (a cond FC="false" toc="include" pn="section-4.4">
ition known as &quot;<eref target="#relaxed-alignment">Relaxed <name slugifiedName="name-identifier-alignment-explai">Identifier Alignm
Alignment</eref>&quot;) or that it be identical to the Authenticated Identifier ent Explained</name>
(a condition known as &quot;<eref target="#strict-alignment">Strict Alignment</ <t indent="0" pn="section-4.4-1">DMARC validates the authorized use of t
eref>&quot;). The choice of relaxed he <xref target="author-domain" format="default" sectionFormat="of" derivedConte
or strict alignment is left to the <eref target="#domain-owner">Domain Owner</er nt="Section 3.2.2">Author Domain</xref> by requiring
ef> and is expressed in either that it have the same <xref target="organizational-domain" format="defaul
the domain's <eref target="#dmarc-policy-record">DMARC Policy Record</eref>. In t" sectionFormat="of" derivedContent="Section 3.2.14">Organizational Domain</xre
practice, nearly all Domain f> as an
<xref target="authenticated-identifiers" format="default" sectionFormat="of" der
ivedContent="Section 3.2.1">Authenticated Identifier</xref> (a condition known a
s <xref target="relaxed-alignment" format="default" sectionFormat="of" derivedCo
ntent="Section 3.2.10.1">"relaxed
alignment"</xref>) or that it be identical to the Authenticated Identifier
(a condition known as <xref target="strict-alignment" format="default" sectionF
ormat="of" derivedContent="Section 3.2.10.2">"strict alignment"</xref>). The cho
ice of relaxed
or strict alignment is left to the <xref target="domain-owner" format="default"
sectionFormat="of" derivedContent="Section 3.2.7">Domain Owner</xref> and is exp
ressed in
the domain's <xref target="dmarc-policy-record" format="default" sectionFormat="
of" derivedContent="Section 3.2.6">DMARC Policy Record</xref>. In practice, near
ly 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" format="default
<t>The following table is meant to illustrate possible alignment conditions.</t> " sectionFormat="of" derivedContent="RFC4343"/>.</t>
<table align="left"><name>&quot;Alignment Examples&quot; <t indent="0" pn="section-4.4-2">The following table is meant to illustr
ate possible alignment conditions.</t>
<table align="center" pn="table-1">
<name slugifiedName="name-alignment-examples">Alignment Examples
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Authenticated Identifier</th> <th align="left" colspan="1" rowspan="1">Authenticated Identifier<
<th>Author Domain</th> /th>
<th>Identifier Alignment</th> <th align="left" colspan="1" rowspan="1">Author Domain</th>
</tr> <th align="left" colspan="1" rowspan="1">Identifier Alignment</th>
</thead> </tr>
</thead>
<tbody> <tbody>
<tr> <tr>
<td>foo.example.com</td> <td align="left" colspan="1" rowspan="1">foo.example.com</td>
<td>news.example.com</td> <td align="left" colspan="1" rowspan="1">news.example.com</td>
<td>relaxed; the two have the same Organizational Domain, example.com</td> <td align="left" colspan="1" rowspan="1">relaxed; the two have the
</tr> same Organizational Domain, example.com</td>
</tr>
<tr> <tr>
<td>news.example.com</td> <td align="left" colspan="1" rowspan="1">news.example.com</td>
<td>news.example.com</td> <td align="left" colspan="1" rowspan="1">news.example.com</td>
<td>strict; the two are identical</td> <td align="left" colspan="1" rowspan="1">strict; the two are ident
</tr> ical</td>
</tr>
<tr> <tr>
<td>foo.example.net</td> <td align="left" colspan="1" rowspan="1">foo.example.net</td>
<td>news.example.com</td> <td align="left" colspan="1" rowspan="1">news.example.com</td>
<td>none; the two do not share a common Organizational Domain</td> <td align="left" colspan="1" rowspan="1">none; the two do not shar
</tr> e a common Organizational Domain</td>
</tbody> </tr>
</table><t>It is important to note that Identifier Alignment cannot occur with a </tbody>
message that is not valid per <xref target="RFC5322"></xref>, particularly one w </table>
ith a <t indent="0" pn="section-4.4-4">It is important to note that Identifier
malformed, absent, or repeated RFC5322.From header field, since in that case Alignment cannot occur with a
there is no reliable way to determine a <eref target="#dmarc-policy-record">DMAR message that is not valid per <xref target="RFC5322" format="default" sectionFor
C Policy Record</eref> mat="of" derivedContent="RFC5322"/>, particularly one with a
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" forma
t="default" sectionFormat="of" derivedContent="Section 3.2.6">DMARC Policy Recor
d</xref>
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" format="default" sectionForm at="of" derivedContent="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" format="default" sectionF
ormat="of" derivedContent="Section 11.5"/>.</t>
<section anchor="dkim-identifiers"><name>DKIM-Authenticated Identifiers</name> <section anchor="dkim-identifiers" numbered="true" removeInRFC="false" t
<t>DKIM permits a Domain Owner to claim some responsibility for a message by oc="include" pn="section-4.4.1">
<name slugifiedName="name-dkim-authenticated-identifi">DKIM-Authentica
ted Identifiers</name>
<t indent="0" pn="section-4.4.1-1">DKIM permits a Domain Owner to clai
m 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 &quot;d&quot; 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 indent="0" pn="section-4.4.1-2">There is currently no generally acc epted mechanism by which a Domain Owner may
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 indent="0" pn="section-4.4.1-3">A single email can contain multiple
produce a DMARC &quot;pass&quot; result if any DKIM-Authenticated Identifier ali DKIM signatures, and it is considered to
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" numbered="true" removeInRFC="false" to
<section anchor="spf-identifiers"><name>SPF-Authenticated Identifiers</name> c="include" pn="section-4.4.2">
<t>SPF can validate the uses of both the domain found in an SMTP HELO/EHLO comma <name slugifiedName="name-spf-authenticated-identifie">SPF-Authenticat
nd ed Identifiers</name>
<t indent="0" pn="section-4.4.2-1">SPF can validate the uses of both t
he domain found in an SMTP HELO/EHLO command
(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 indent="0" pn="section-4.4.2-2">There is currently no generally acc epted mechanism by which a Domain Owner may
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" numbered="true" r
<section anchor="alignment-and-extension-technologies"><name>Alignment and Exten emoveInRFC="false" toc="include" pn="section-4.4.3">
sion Technologies</name> <name slugifiedName="name-alignment-and-extension-tec">Alignment and E
<t>If in the future DMARC is extended to include the use of other authentication xtension Technologies</name>
<t indent="0" pn="section-4.4.3-1">In the future, if DMARC is extended
to include the use of other authentication
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" numbered="true" removeInRF
<section anchor="dmarc-policy-record-explained"><name>DMARC Policy Record Explai C="false" toc="include" pn="section-4.5">
ned</name> <name slugifiedName="name-dmarc-policy-record-explain">DMARC Policy Reco
<t>A <eref target="#domain-owner">Domain Owner</eref> or <eref target="#public-s rd Explained</name>
uffix-operator">PSO</eref> advertises <t indent="0" pn="section-4.5-1">A <xref target="domain-owner" format="d
DMARC participation of one or more of its domains by publishing <eref target="#d efault" sectionFormat="of" derivedContent="Section 3.2.7">Domain Owner</xref> or
marc-policy-record">DMARC Policy Records</eref> that will apply to those domains <xref target="public-suffix-operator" format="default" sectionFormat="of" deriv
. In doing so, Domain Owners edContent="Section 3.2.16">PSO</xref> advertises
DMARC participation of one or more of its domains by publishing <xref target="dm
arc-policy-record" format="default" sectionFormat="of" derivedContent="Section 3
.2.6">DMARC Policy Records</xref> that will apply to those domains. 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 indent="0" pn="section-4.5-2">DMARC Policy Records are stored as DNS
the label &quot;_dmarc&quot;. For example, the Domain Owner of &quot;example.co TXT records with names starting with
m&quot; would publish the label "_dmarc". For example, the Domain Owner of "example.com" would publis
a DMARC Policy Record at the name &quot;_dmarc.example.com&quot;, and a <eref ta h
rget="#mail-receiver">Mail Receiver</eref> a DMARC Policy Record at the name "_dmarc.example.com", and a <xref target="mail
wishing to find the DMARC Policy Record for mail with an <eref target="#author-d -receiver" format="default" sectionFormat="of" derivedContent="Section 3.2.11">M
omain">Author Domain</eref> ail Receiver</xref>
of &quot;example.com&quot; would issue a TXT query to the DNS for the name &quot wishing to find the DMARC Policy Record for mail with an <xref target="author-do
;_dmarc.example.com&quot;. main" format="default" sectionFormat="of" derivedContent="Section 3.2.2">Author
Domain</xref>
of "example.com" would issue a TXT query to the DNS for the name "_dmarc.example
.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>
<t>DMARC Policy Records can also apply to subdomains of the name at which they <t indent="0" pn="section-4.5-3">DMARC Policy Records can also apply to
are published in the DNS, if the record is published at an <eref target="#organi subdomains of the name at which they
zational-domain">Organizational are published in the DNS if the record is published at an <xref target="organiza
Domain</eref> for the subdomains. The <eref target="#domain-owner-policy">Domain tional-domain" format="default" sectionFormat="of" derivedContent="Section 3.2.1
Owner Assessment Policy</eref> that applies to the subdomains can be identical 4">Organizational
to the Domain Domain</xref> for the subdomains. The <xref target="domain-owner-policy" format=
Owner Assessment Policy that applies to the Organizational Domain or different, "default" sectionFormat="of" derivedContent="Section 3.2.8">Domain Owner Assessm
depending ent Policy</xref> that applies to the subdomains can be identical to the Domain
on the presence or absence of certain values in the DMARC Policy Record. See <xr Owner Assessment Policy that applies to the Organizational Domain but it does no
ef target="policy-record-format"></xref> t have to
be identical. Whether or not it is identical depends
on the presence or absence of certain values in the DMARC Policy Record. See <xr
ef target="policy-record-format" format="default" sectionFormat="of" derivedCont
ent="Section 4.7"/>
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 indent="0" pn="section-4.5-4">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 &quot; character-string&quot; objects. <t indent="0" pn="section-4.5-5">Per <xref target="RFC1035" format="defa ult" sectionFormat="of" derivedContent="RFC1035"/>, a TXT record can comprise mu ltiple "character-string" 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 indent="0" pn="section-4.5-6">A Domain Owner can choose not to have s ome underlying authentication mechanisms
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 indent="0" pn="section-4.5-7">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" format="
</t> default" sectionFormat="of" derivedContent="Section 5.4"/>.</t>
</section> </section>
<section anchor="dmarc-uris" numbered="true" removeInRFC="false" toc="incl
<section anchor="dmarc-uris"><name>DMARC Reporting URIs</name> ude" pn="section-4.6">
<t><xref target="RFC3986"></xref> defines a syntax for identifying a resource. T <name slugifiedName="name-dmarc-reporting-uris">DMARC Reporting URIs</na
he DMARC me>
mechanism uses this as the format by which a <eref target="#domain-owner">Domain <t indent="0" pn="section-4.6-1"><xref target="RFC3986" format="default"
Owner</eref> sectionFormat="of" derivedContent="RFC3986"/> defines a syntax for identifying
or <eref target="#public-suffix-organization">PSO</eref> specifies the destinati a resource. The DMARC
on(s) for the two mechanism uses this as the format by which a <xref target="domain-owner" format=
report types that are supported. The <eref target="#policy-record-format">DMARC "default" sectionFormat="of" derivedContent="Section 3.2.7">Domain Owner</xref>
Policy Record format</eref> or <xref target="public-suffix-operator" format="default" sectionFormat="of" der
allows for a list of these URIs to be provided, with each URI separated by comma ivedContent="Section 3.2.16">PSO</xref> specifies the destination(s) for the two
s (ASCII 0x2c).</t> report types that are supported.</t>
<t>A formal definition is provided in <xref target="formal-definition"></xref>.< <t indent="0" pn="section-4.6-2">The <xref target="policy-record-format"
/t> format="default" sectionFormat="of" derivedContent="Section 4.7">DMARC Policy R
</section> ecord format</xref>
allows for a list of these URIs to be provided, with each URI separated by comma
<section anchor="policy-record-format"><name>DMARC Policy Record Format</name> s (ASCII 0x2c).
<t>DMARC Policy Records follow the extensible &quot;tag-value&quot; syntax for D A report SHOULD be sent to each listed URI provided in the DMARC Policy Record.<
NS-based /t>
key records defined in DKIM <xref target="RFC6376"></xref>.</t> <t indent="0" pn="section-4.6-3">A formal definition is provided in <xre
<t><xref target="iana-considerations"></xref> creates a registry for known DMARC f target="formal-definition" format="default" sectionFormat="of" derivedContent=
tags and "Section 4.8"/>.</t>
</section>
<section anchor="policy-record-format" numbered="true" removeInRFC="false"
toc="include" pn="section-4.7">
<name slugifiedName="name-dmarc-policy-record-format">DMARC Policy Recor
d Format</name>
<t indent="0" pn="section-4.7-1">DMARC Policy Records follow the extensi
ble "tag-value" syntax for DNS-based
key records defined in DKIM <xref target="RFC6376" format="default" sectionForma
t="of" derivedContent="RFC6376"/>.</t>
<t indent="0" pn="section-4.7-2"><xref target="iana-considerations" form
at="default" sectionFormat="of" derivedContent="Section 9"/> creates a registry
for known DMARC 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 indent="0" pn="section-4.7-3">The following tags are valid DMARC tags
:</t>
<dl> <dl indent="3" newline="false" spacing="normal" pn="section-4.7-4">
<dt>adkim:</dt> <dt pn="section-4.7-4.1">adkim:</dt>
<dd><t>(plain-text; <bcp14>OPTIONAL</bcp14>; default is &quot;r&quot;.) Indicate <dd pn="section-4.7-4.2">
s whether <t indent="0" pn="section-4.7-4.2.1">(plain-text; <bcp14>OPTIONAL</b
the <eref target="#domain-owner">Domain Owner</eref> or <eref target="#public-su cp14>; default is "r".) Indicates whether
ffix-organization">PSO</eref> requires the <xref target="domain-owner" format="default" sectionFormat="of" derivedConte
strict or relaxed DKIM Identifier Alignment mode. See <xref target="dkim-identif nt="Section 3.2.7">Domain Owner</xref> or <xref target="public-suffix-operator"
iers"></xref> for details. format="default" sectionFormat="of" derivedContent="Section 3.2.16">PSO</xref> r
equires
strict or relaxed DKIM Identifier Alignment mode. See <xref target="dkim-identif
iers" format="default" sectionFormat="of" derivedContent="Section 4.4.1"/> for d
etails.
Valid values are as follows:</t> Valid values are as follows:</t>
<dl spacing="compact" indent="3" newline="false" pn="section-4.7-4.2
<dl spacing="compact"> .2">
<dt>r:</dt> <dt pn="section-4.7-4.2.2.1">r:</dt>
<dd>relaxed mode</dd> <dd pn="section-4.7-4.2.2.2">relaxed mode</dd>
<dt>s:</dt> <dt pn="section-4.7-4.2.2.3">s:</dt>
<dd>strict mode</dd> <dd pn="section-4.7-4.2.2.4">strict mode</dd>
</dl></dd> </dl>
<dt>aspf:</dt> </dd>
<dd><t>(plain-text; <bcp14>OPTIONAL</bcp14>; default is &quot;r&quot;.) Indicat <dt pn="section-4.7-4.3">aspf:</dt>
es whether <dd pn="section-4.7-4.4">
<t indent="0" pn="section-4.7-4.4.1">(plain-text; <bcp14>OPTIONAL</b
cp14>; 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 mode. See <xref target="spf-identifiers" format="default" sectionFormat="of" der
s follows:</t> ivedContent="Section 4.4.2"/> for details. Valid values are as follows:</t>
<dl spacing="compact" indent="3" newline="false" pn="section-4.7-4.4
<dl spacing="compact"> .2">
<dt>r:</dt> <dt pn="section-4.7-4.4.2.1">r:</dt>
<dd>relaxed mode</dd> <dd pn="section-4.7-4.4.2.2">relaxed mode</dd>
<dt>s:</dt> <dt pn="section-4.7-4.4.2.3">s:</dt>
<dd>strict mode</dd> <dd pn="section-4.7-4.4.2.4">strict mode</dd>
</dl></dd> </dl>
<dt>fo:</dt> </dd>
<dd><t>Failure reporting options (plain-text; <bcp14>OPTIONAL</bcp14>; default i <dt pn="section-4.7-4.5">fo:</dt>
s &quot;0&quot;) Provides <dd pn="section-4.7-4.6">
<t indent="0" pn="section-4.7-4.6.1">Failure reporting options (plai
n-text; <bcp14>OPTIONAL</bcp14>; default is "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 &quot;ruf&quot; 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 &quot;0&quot; and
&quot;1&quot; 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="normal" indent="3" newline="false" pn="section-4.7-4.6.
<dl spacing="compact"> 2">
<dt>0:</dt> <dt pn="section-4.7-4.6.2.1">0:</dt>
<dd>Generate a DMARC failure report if all underlying authentication <dd pn="section-4.7-4.6.2.2">Generate a DMARC failure report if al
mechanisms fail to produce an aligned &quot;pass&quot; result.</dd> l underlying authentication
<dt>1:</dt> mechanisms fail to produce an aligned "pass" result.</dd>
<dd>Generate a DMARC failure report if any underlying authentication <dt pn="section-4.7-4.6.2.3">1:</dt>
mechanism fails to produce an aligned &quot;pass&quot; result.</dd> <dd pn="section-4.7-4.6.2.4">Generate a DMARC failure report if an
<dt>d:</dt> y underlying authentication
<dd>Generate a DKIM failure report if the message had a signature mechanism fails to produce an aligned "pass" result.</dd>
<dt pn="section-4.7-4.6.2.5">d:</dt>
<dd pn="section-4.7-4.6.2.6">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" format="default" sectionFormat=
<dt>s:</dt> "of" derivedContent="RFC6651"/>.</dd>
<dd>Generate an SPF failure report if the message failed SPF <dt pn="section-4.7-4.6.2.7">s:</dt>
<dd pn="section-4.7-4.6.2.8">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" format="default" sectionFormat=
</dl></dd> "of" derivedContent="RFC6652"/>.</dd>
<dt>np:</dt> </dl>
<dd><t><eref target="#domain-owner-policy">Domain Owner Assessment Policy</eref> </dd>
for non-existent subdomains <dt pn="section-4.7-4.7">np:</dt>
<dd pn="section-4.7-4.8">
<t indent="0" pn="section-4.7-4.8.1"><xref target="domain-owner-poli
cy" format="default" sectionFormat="of" derivedContent="Section 3.2.8">Domain Ow
ner 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 &quot;non-existent subdomain&quot; is the same as that used for &quot;Non-exi stent Domains&quot; 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" format="default" sectionFormat="of" deriv edContent="Section 3.2.13"/>.
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
&quot;p&quot; "p"
tag defined below. If the &quot;np&quot; tag is absent, the policy specified by tag defined below. If the "np" tag is absent, the policy specified by the "sp" t
the &quot;sp&quot; tag (if ag (if
the &quot;sp&quot; tag is present) or the policy specified by the &quot;p&quot; the "sp" tag is present) or the policy specified by the "p" tag (if the "sp"
tag, if the &quot;sp&quot; 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 pn="section-4.7-4.9">p:</dt>
<dt>p:</dt> <dd pn="section-4.7-4.10">
<dd><t><eref target="#domain-owner-policy">Domain Owner Assessment Policy</eref> <t indent="0" pn="section-4.7-4.10.1"><xref target="domain-owner-pol
(plain-text; <bcp14>RECOMMENDED</bcp14> icy" format="default" sectionFormat="of" derivedContent="Section 3.2.8">Domain O
wner 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 &quot;sp&quot; or &quot;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 &quot;p=none&quot; ( Policy Record, then the record is treated as if it included "p=none" (see
see <xref target="dmarc-policy-discovery" format="default" sectionFormat="of" derive
<xref target="dmarc-policy-discovery"></xref>). This tag is not applicable for t dContent="Section 4.10.1"/>). This tag is not applicable for third-party
hird-party reporting records (see <xref target="RFC9990" format="default" sectionFormat="of
reporting records (see <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref> " derivedContent="RFC9990"/> and <xref target="RFC9991" format="default" section
and <xref target="I-D.ietf-dmarc-failure-reporting"></xref>). Format="of" derivedContent="RFC9991"/>).
Possible values are as follows:</t> Possible values are as follows:</t>
<dl spacing="normal" indent="3" newline="false" pn="section-4.7-4.10
<dl spacing="compact"> .2">
<dt>none:</dt> <dt pn="section-4.7-4.10.2.1">none:</dt>
<dd>The Domain Owner offers no expression of preference.</dd> <dd pn="section-4.7-4.10.2.2">The Domain Owner offers no expressio
<dt>quarantine:</dt> n of preference.</dd>
<dd>The Domain Owner considers such mail to be suspicious. It is possible <dt pn="section-4.7-4.10.2.3">quarantine:</dt>
<dd pn="section-4.7-4.10.2.4">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 pn="section-4.7-4.10.2.5">reject:</dt>
<dd>The Domain Owner considers all such failures to be a clear indication <dd pn="section-4.7-4.10.2.6">The Domain Owner considers all such
that the use of the domain name is not valid. See <xref target="rejecting-messag failures to be a clear indication
es"></xref> that the use of the domain name is not valid. See <xref target="rejecting-messag
es" format="default" sectionFormat="of" derivedContent="Section 7.2"/>
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>
<dt>psd:</dt> </dd>
<dd><t>A flag indicating whether the domain is a PSD. (plain-text; <bcp14>OPTION <dt pn="section-4.7-4.11">psd:</dt>
AL</bcp14>; <dd pn="section-4.7-4.12">
default is &quot;u&quot;). Possible values are:</t> <t indent="0" pn="section-4.7-4.12.1">A flag indicating whether the
domain is a PSD (plain-text; <bcp14>OPTIONAL</bcp14>;
<dl spacing="compact"> default is "u"). Possible values are as follows:</t>
<dt>y:</dt> <dl spacing="normal" indent="3" newline="false" pn="section-4.7-4.12
<dd>PSOs include this tag with a value of &quot;y&quot; to indicate that the dom .2">
ain <dt pn="section-4.7-4.12.2.1">y:</dt>
is a PSD. If a record containing this tag with a value of &quot;y&quot; is found <dd pn="section-4.7-4.12.2.2">PSOs include this tag with a value o
during f "y" to indicate that the domain
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 pn="section-4.7-4.12.2.3">n:</dt>
<dd>The DMARC Policy Record is published for a domain that is not a PSD, but it <dd pn="section-4.7-4.12.2.4">The DMARC Policy Record is published
is 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 pn="section-4.7-4.12.2.5">u:</dt>
<dd>The default indicates that the DMARC Policy Record is published for a domain <dd pn="section-4.7-4.12.2.6">The default indicates that the DMARC
that is not a PSD, and may or may not be an Organizational Domain for itself and Policy Record is published for a domain
its subdomains. Use the mechanism described in <xref target="dns-tree-walk"></xr that is not a PSD and may or may not be an Organizational Domain for itself and
ef> for determining its subdomains. Use the mechanism described in <xref target="dns-tree-walk" form
at="default" sectionFormat="of" derivedContent="Section 4.10"/> for determining
the Organizational Domain for this domain.</dd> the Organizational Domain for this domain.</dd>
</dl></dd> </dl>
<dt>rua:</dt> </dd>
<dd><t>Addresses to which aggregate feedback reports are to be sent (comma-separ <dt pn="section-4.7-4.13">rua:</dt>
ated plain-text <dd pn="section-4.7-4.14">
<t indent="0" pn="section-4.7-4.14.1">Addresses to which aggregate f
eedback reports are to be sent (comma-separated 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" format="default" sectionFormat="of" derivedContent="RFC9990"/>
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 &quot;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" format="default" section Format="of" derivedContent="RFC9990"/> also discusses considerations 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.< <xref target="external-report-addresses" format="default" sectionFormat="of" der
/t> ivedContent="Section 11.6"/> for additional considerations.</t>
</dd> </dd>
<dt>ruf:</dt> <dt pn="section-4.7-4.15">ruf:</dt>
<dd><t>Addresses to which message-specific failure information is to be reported <dd pn="section-4.7-4.16">
<t indent="0" pn="section-4.7-4.16.1">Addresses to which message-spe
cific 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 &quot;fo&quot; 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 &quot;fo&quot; 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" format="default" sectionFormat="of" deriv
arget="RFC6651"></xref>, or <xref target="RFC6652"></xref>. Any edContent="RFC9991"/>, <xref target="RFC6651" format="default" sectionFormat="of
" derivedContent="RFC6651"/>, and <xref target="RFC6652" format="default" sectio
nFormat="of" derivedContent="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 &quot;mailto:&quot; 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" format="default" section Format="of" derivedContent="RFC9990"/> discusses considerations
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 policy. See <xref target="external-report-addresses" format="default" sectionFo
siderations.</t> rmat="of" derivedContent="Section 11.6"/> for additional considerations.</t>
</dd> </dd>
<dt>sp:</dt> <dt pn="section-4.7-4.17">sp:</dt>
<dd><t>Domain Owner Assessment Policy for all subdomains of the given Organizati <dd pn="section-4.7-4.18">
onal Domain <t indent="0" pn="section-4.7-4.18.1">Domain Owner Assessment Policy
for all subdomains of the given Organizational 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
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 &quot;p&quot; tag defined above. If both Its syntax is identical to that of the "p" tag defined above. If both the "sp" t
the &quot;sp&quot; tag is ag is
absent, and the &quot;np&quot; 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 &quot;p&quot; tag <bcp14>MUST</bcp14> be applied for subdomains. Note that the "p" tag <bcp14>MUST</bcp14> be applied for subdomains. Note that "sp" will
&quot;sp&quot; 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 to the effect of the <xref target="dmarc-policy-discovery" format="default" sect
ry</eref>.</t> ionFormat="of" derivedContent="Section 4.10.1">DMARC policy discovery</xref>.</t
</dd> >
<dt>t:</dt> </dd>
<dd><t>DMARC policy test mode (plain-text; <bcp14>OPTIONAL</bcp14>; default is & <dt pn="section-4.7-4.19">t:</dt>
quot;n&quot;). For <dd pn="section-4.7-4.20">
the Author Domain to which the DMARC Policy Record applies, the &quot;t&quot; ta <t indent="0" pn="section-4.7-4.20.1">DMARC policy test mode (plain-
g serves text; <bcp14>OPTIONAL</bcp14>; default is "n"). For
the Author Domain to which the DMARC Policy Record applies, the "t" tag 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&quot;, "sp", and/or "np" tags to actually be applied. This tag does not affect the
&quot;sp&quot;, and/or &quot;np&quot; 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 (&quot;p&quot;, that is "none". See <xref target="removal-of-the-pct-tag" format="default" sect
&quot;sp&quot;, or &quot;np&quot;) ionFormat="of" derivedContent="Appendix A.6"/> for further discussion of the use
that is &quot;none&quot;. 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="normal" indent="3" newline="false" pn="section-4.7-4.20
<dl spacing="compact"> .2">
<dt>y:</dt> <dt pn="section-4.7-4.20.2.1">y:</dt>
<dd>A request that the actor performing the DMARC validation check not <dd pn="section-4.7-4.20.2.2">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" format="default" sectionFormat="of" derivedContent="Appendi
The Domain Owner is currently testing its specified DMARC assessment policy, and x A.6"/>).
has The Domain Owner is currently testing its specified DMARC assessment policy and
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 &quot;quarantine&quot; and the value specified policy. That is, if the policy is "quarantine" and the value of the "t
of the &quot;t&quot; "
tag is &quot;y&quot;, a policy of &quot;none&quot; 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 &quot;reject&quot; and the value of the &quot;t&quot; tag is &quot;y&quot;, a is "reject" and the value of the "t" tag is "y", a policy of "quarantine" will b
policy of &quot;quarantine&quot; 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 &quot;t&quot; tag having a value of &quot;y&quot;.</dd might be triggered by the "t" tag having a value of "y".</dd>
> <dt pn="section-4.7-4.20.2.3">n:</dt>
<dt>n:</dt> <dd pn="section-4.7-4.20.2.4">The default is a request to apply th
<dd>The default is a request to apply the Domain Owner Assessment Policy as spec e Domain Owner Assessment Policy as specified
ified to any message that produces a DMARC "fail" result.</dd>
to any message that produces a DMARC &quot;fail&quot; result.</dd> </dl>
</dl></dd> </dd>
<dt>v:</dt> <dt pn="section-4.7-4.21">v:</dt>
<dd><t>Version (plain-text; <bcp14>REQUIRED</bcp14>). Identifies the record ret <dd pn="section-4.7-4.22">
rieved <t indent="0" pn="section-4.7-4.22.1">Version (plain-text; <bcp14>RE
QUIRED</bcp14>). Identifies the record retrieved
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 &quot;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>
&quot;DMARC1&quot;, then the entire record <bcp14>MUST</bcp14> be ignored.</t> </dd>
</dd> </dl>
</dl> </section>
</section> <section anchor="formal-definition" numbered="true" removeInRFC="false" to
c="include" pn="section-4.8">
<section anchor="formal-definition"><name>Formal Definition</name> <name slugifiedName="name-formal-definition">Formal Definition</name>
<t>A DMARC Policy Record <bcp14>MUST</bcp14> comply with the formal definition o <t indent="0" pn="section-4.8-1">A DMARC Policy Record <bcp14>MUST</bcp1
f same 4> comply with the formal definition
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 indent="0" pn="section-4.8-2">Because unknown tags <bcp14>MUST</bcp14 > be ignored, the addition of a new tag 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 &quot;v&quot; 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 indent="0" pn="section-4.8-3">The formal definition of the DMARC Poli
RFC5234"></xref> cy Record format, using ABNF syntax as described in <xref target="RFC5234" forma
and <xref target="RFC7405"></xref>, is as follows:</t> t="default" sectionFormat="of" derivedContent="RFC5234"/>
and <xref target="RFC7405" format="default" sectionFormat="of" derivedContent="R
<artwork><![CDATA[ dmarc-uri = URI FC7405"/>, is as follows:</t>
<sourcecode type="abnf" markers="false" pn="section-4.8-4">
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 = 1*ALPHA equals 1*dmarc-value dmarc-tag = 1*ALPHA equals 1*dmarc-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 dmarc-urilist = (dmarc-uri / obs-dmarc-uri)
marc-uri)) *(*WSP "," *WSP (dmarc-uri / obs-dmarc-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" dmarc-afrf = "d" / "s"
; each may appear at most once in dmarc-fo ; each may appear at most once in dmarc-fo</sourcecode>
]]></artwork> <t indent="0" pn="section-4.8-5">In each dmarc-tag, the dmarc-value has
<t>In each dmarc-tag, the dmarc-value has a syntax that depends on the tag name. 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>&quot;Tag Names and Values&quot; <table align="center" pn="table-2">
<name slugifiedName="name-tag-names-and-values">Tag Names and Values
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Tag Name</th> <th align="left" colspan="1" rowspan="1">Tag Name</th>
<th>Value Rule</th> <th align="left" colspan="1" rowspan="1">Value Rule</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">p</td>
<td>p</td> <td align="left" colspan="1" rowspan="1">dmarc-request</td>
<td>dmarc-request</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">t</td>
<tr> <td align="left" colspan="1" rowspan="1">dmarc-yorn</td>
<td>t</td> </tr>
<td>dmarc-yorn</td> <tr>
</tr> <td align="left" colspan="1" rowspan="1">psd</td>
<td align="left" colspan="1" rowspan="1">dmarc-psd</td>
<tr> </tr>
<td>psd</td> <tr>
<td>dmarc-psd</td> <td align="left" colspan="1" rowspan="1">np</td>
</tr> <td align="left" colspan="1" rowspan="1">dmarc-request</td>
</tr>
<tr> <tr>
<td>np</td> <td align="left" colspan="1" rowspan="1">sp</td>
<td>dmarc-request</td> <td align="left" colspan="1" rowspan="1">dmarc-request</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">adkim</td>
<td>sp</td> <td align="left" colspan="1" rowspan="1">dmarc-rors</td>
<td>dmarc-request</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">aspf</td>
<tr> <td align="left" colspan="1" rowspan="1">dmarc-rors</td>
<td>adkim</td> </tr>
<td>dmarc-rors</td> <tr>
</tr> <td align="left" colspan="1" rowspan="1">rua</td>
<td align="left" colspan="1" rowspan="1">dmarc-urilist</td>
<tr> </tr>
<td>aspf</td> <tr>
<td>dmarc-rors</td> <td align="left" colspan="1" rowspan="1">ruf</td>
</tr> <td align="left" colspan="1" rowspan="1">dmarc-urilist</td>
</tr>
<tr> <tr>
<td>rua</td> <td align="left" colspan="1" rowspan="1">fo</td>
<td>dmarc-urilist</td> <td align="left" colspan="1" rowspan="1">dmarc-fo</td>
</tr> </tr>
</tbody>
<tr> </table>
<td>ruf</td> </section>
<td>dmarc-urilist</td> <section anchor="flow-diagram" numbered="true" removeInRFC="false" toc="in
</tr> clude" pn="section-4.9">
<name slugifiedName="name-flow-diagram">Flow Diagram</name>
<tr> <artwork align="left" pn="section-4.9-1">
<td>fo</td> +---------------+ +--------------------+
<td>dmarc-fo</td> | Author Domain |&lt; . . . . . . . . . . . . | Return-Path Domain |
</tr>
</tbody>
</table></section>
<section anchor="flow-diagram"><name>Flow Diagram</name>
<sourcecode type="ascii-art"><![CDATA[ +---------------+
+--------------------+
| Author Domain |< . . . . . . . . . . . . | Return-Path Domain |
+---------------+ . +--------------------+ +---------------+ . +--------------------+
| . ^ | . ^
V V . V V .
+-----------+ +--------+ +----------+ v +-----------+ +--------+ +----------+ v
| MSA |<***>| DKIM | | DMARC | +----------+ | MSA |&lt;***&gt;| DKIM | | DMARC | +----------+
| Service | | Signer | | Validator|<***>| SPF | | Service | | Signer | | Validator|&lt;***&gt;| SPF |
+-----------+ +--------+ +----------+ * | Validator| +-----------+ +--------+ +----------+ * | Validator|
| ^ * +----------+ | ^ * +----------+
| * * | * *
V v * V v *
+------+ (~~~~~~~~~~~~) +------+ * +----------+ +------+ (~~~~~~~~~~~~) +------+ * +----------+
| sMTA |------->( other MTAs )----->| rMTA | **&gt;| DKIM | | sMTA |------->( other MTAs )-----&gt;| rMTA | **&gt;| DKIM |
+------+ (~~~~~~~~~~~~) +------+ | Validator| +------+ (~~~~~~~~~~~~) +------+ | Validator|
| +----------+ | +----------+
| ^ | ^
V . V .
+-----------+ . +-----------+ .
+---------+ | MDA | v +---------+ | MDA | v
| User |<--| Filtering | +-----------+ | User |&lt;--| 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> sMTA = sending MTA
<t>The above diagram shows a typical flow of messages through a rMTA = receiving MTA
</artwork>
<t indent="0" pn="section-4.9-2">The above diagram shows a typical flow
of messages through a
DMARC-aware system. Dashed lines (e.g., --&gt;) denote the actual message DMARC-aware system. Dashed lines (e.g., --&gt;) denote the actual message
flow, dotted lines (e.g., &lt; . . &gt;) represent DNS queries used to retrieve flow, dotted lines (e.g., &lt; . . &gt;) 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., &lt;**&gt;) indicate data exchange between message-hand ling and starred lines (e.g., &lt;**&gt;) indicate data exchange between message-hand ling
modules and message authentication modules. &quot;sMTA&quot; is the sending MTA, modules and message authentication modules.</t>
and <t indent="0" pn="section-4.9-3">Put simply, when a message reaches a DM
&quot;rMTA&quot; is the receiving MTA.</t> ARC-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 indent="0" pn="section-4.9-4">More details on specific actions for th
found in <xref target="domain-owner-actions"></xref> and <xref target="mail-rece e parties involved can be
iver-actions"></xref>.</t> found in Sections <xref target="domain-owner-actions" format="counter" sectionFo
</section> rmat="of" derivedContent="5.1"/> and <xref target="mail-receiver-actions" format
="counter" sectionFormat="of" derivedContent="5.3"/>.</t>
<section anchor="dns-tree-walk"><name>DNS Tree Walk</name> </section>
<t>An <eref target="#organizational-domain">Organizational Domain</eref> serves <section anchor="dns-tree-walk" numbered="true" removeInRFC="false" toc="i
two different purposes, nclude" pn="section-4.10">
<name slugifiedName="name-dns-tree-walk">DNS Tree Walk</name>
<t indent="0" pn="section-4.10-1">An <xref target="organizational-domain
" format="default" sectionFormat="of" derivedContent="Section 3.2.14">Organizati
onal Domain</xref> serves two different purposes,
depending on the context:</t> depending on the context:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4
<ul> .10-2">
<li><t>The Organizational Domain of the <eref target="#author-domain">Author Dom <li pn="section-4.10-2.1">
ain</eref> establishes <t indent="0" pn="section-4.10-2.1.1">The Organizational Domain of t
the <eref target="#dmarc-policy-record">DMARC Policy Record</eref> for that doma he <xref target="author-domain" format="default" sectionFormat="of" derivedConte
in when no DMARC Policy nt="Section 3.2.2">Author Domain</xref> establishes
Record is published specifically for the Author Domain. (see <xref target="dmarc the <xref target="dmarc-policy-record" format="default" sectionFormat="of" deriv
-policy-discovery"></xref>)</t> edContent="Section 3.2.6">DMARC Policy Record</xref> for that domain when no DMA
</li> RC Policy
<li><t>The Organizational Domains of an <eref target="#authenticated-identifiers Record is published specifically for the Author Domain (see <xref target="dmarc-
">Authenticated Identifier</eref> policy-discovery" format="default" sectionFormat="of" derivedContent="Section 4.
and the Author Domain are used in determining Identifier Alignment between the t 10.1"/>).</t>
wo. (see </li>
<xref target="identifier-alignment-evaluation"></xref>).</t> <li pn="section-4.10-2.2">
</li> <t indent="0" pn="section-4.10-2.2.1">The Organizational Domains of
</ul> an <xref target="authenticated-identifiers" format="default" sectionFormat="of"
<t><xref target="RFC7489"></xref> defined an Organizational Domain as &quot;The derivedContent="Section 3.2.1">Authenticated Identifier</xref>
domain that was registered with a domain and the Author Domain are used in determining Identifier Alignment between the t
name registrar.&quot; RFC 7489 discussed using a &quot;public suffix&quot; list wo (see
(PSL) as the authoritative <xref target="identifier-alignment-evaluation" format="default" sectionFormat="o
list of the parent domains for Organizational Domains, and further described a m f" derivedContent="Section 4.10.2"/>).</t>
ethod for </li>
</ul>
<t indent="0" pn="section-4.10-3"><xref target="RFC7489" format="default
" sectionFormat="of" derivedContent="RFC7489"/> defined an Organizational Domain
as "The domain that was registered with a domain
name registrar". <xref target="RFC7489" format="default" sectionFormat="of" deri
vedContent="RFC7489"/> discussed using a Public Suffix List (PSL) as the authori
tative
list of the parent domains for Organizational Domains and further described a me
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" format="default" sectionFormat="of" derivedConte
to use nt="RFC7489"/> mandated no requirement for a specific PSL for Mail Receivers to
(though it did suggest the one found at <eref target="https://publicsuffix.org/" use
>https://publicsuffix.org/</eref>) nor did it provide (though it did suggest the one found at <eref target="https://publicsuffix.org/"
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" format="default" sectionFormat="of" derivedCont
d by Mail ent="RFC7489"/> acknowledged the possibility of interoperability issues caused b
Receivers choosing different PSLs, and even suggested that if a more reliable an y Mail
d secure Receivers choosing different PSLs and even suggested that if a more reliable and
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 <t indent="0" pn="section-4.10-4">This update to DMARC offers more flexi
se with large, bility to Domain Owners, especially those 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 PSL to help identify
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 &quot;DNS Tree Walk&quot;. 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 indent="0" pn="section-4.10-5">However, this flexibility comes at a p ossible 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.< future expansion of the namespace that did not require updating this document.</
/t> t>
<t>The generic steps for a DNS Tree Walk are as follows:</t> <t indent="0" pn="section-4.10-6">The generic steps for a DNS Tree Walk
are as follows:</t>
<ol> <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4.
<li><t>Query the DNS for a TXT record that matches the format of a DMARC Policy 10-7">
Record at <li pn="section-4.10-7.1" derivedCounter="1.">
<t indent="0" pn="section-4.10-7.1.1">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" sectionFormat="of" derivedContent="4.10.1"/>
<xref target="identifier-alignment-evaluation"></xref> describe the possible sta and
rting points. A possibly <xref target="identifier-alignment-evaluation" format="counter" sectionFormat="o
f" derivedContent="4.10.2"/> describe the possible 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 &quot;v&quot; tag that identifies the cu <li pn="section-4.10-7.2" derivedCounter="2.">
rrent <t indent="0" pn="section-4.10-7.2.1">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 &quot;psd=n&quot; or &quot;psd=y&quot; 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 pn="section-4.10-7.3" derivedCounter="3.">
the count of labels to &quot;x&quot;, and number the labels from right to left; <t indent="0" pn="section-4.10-7.3.1">Break the subject DNS domain n
e.g., ame into a set of ordered labels. Assign
for &quot;a.mail.example.com&quot;, &quot;x&quot; would be assigned the value 4, the count of labels to "x", and number the labels from right to left, e.g.,
&quot;com&quot; would be for "a.mail.example.com", "x" would be assigned the value 4, "com" would be
label 1, &quot;example&quot; would be label 2, &quot;mail&quot; would be label 3 label 1, "example" would be label 2, "mail" would be label 3, and so forth.</t>
, and so forth.</t> </li>
</li> <li pn="section-4.10-7.4" derivedCounter="4.">
<li><t>If x &lt; 8, remove the left-most (highest-numbered) label from the subje <t indent="0" pn="section-4.10-7.4.1">If x &lt; 8, remove the left-m
ct ost (highest-numbered) label from the subject
domain. If x &gt;= 8, remove the left-most (highest-numbered) labels from the domain. If x &gt;= 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 <li pn="section-4.10-7.5" derivedCounter="5.">
his <t indent="0" pn="section-4.10-7.5.1">Query the DNS for a DMARC Poli
cy Record at the DNS domain name matching this
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 &quot;v&quot; tag that identifies the cu <li pn="section-4.10-7.6" derivedCounter="6.">
rrent <t indent="0" pn="section-4.10-7.6.1">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 &quot;psd=n&quot; or &quot;psd=y&quot; 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 pn="section-4.10-7.7" derivedCounter="7.">
<t indent="0" pn="section-4.10-7.7.1">Determine the target for the n
ext 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 indent="0" pn="section-4.10-8">To illustrate, for a message with the
&quot;a.b.c.d.e.f.g.h.i.j.mail.example.com&quot;, a full DNS Tree Walk would req arbitrary Author Domain of
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="normal" bare="false" empty="false" indent="3" pn="section-4
<ul spacing="compact"> .10-9">
<li>_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com</li> <li pn="section-4.10-9.1">_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com<
<li>_dmarc.g.h.i.j.mail.example.com</li> /li>
<li>_dmarc.h.i.j.mail.example.com</li> <li pn="section-4.10-9.2">_dmarc.g.h.i.j.mail.example.com</li>
<li>_dmarc.i.j.mail.example.com</li> <li pn="section-4.10-9.3">_dmarc.h.i.j.mail.example.com</li>
<li>_dmarc.j.mail.example.com</li> <li pn="section-4.10-9.4">_dmarc.i.j.mail.example.com</li>
<li>_dmarc.mail.example.com</li> <li pn="section-4.10-9.5">_dmarc.j.mail.example.com</li>
<li>_dmarc.example.com</li> <li pn="section-4.10-9.6">_dmarc.mail.example.com</li>
<li>_dmarc.com</li> <li pn="section-4.10-9.7">_dmarc.example.com</li>
</ul> <li pn="section-4.10-9.8">_dmarc.com</li>
</ul>
<section anchor="dmarc-policy-discovery"><name>DMARC Policy Discovery</name> <section anchor="dmarc-policy-discovery" numbered="true" removeInRFC="fa
<t>The DMARC Policy Record to be applied to an email message will be the record lse" toc="include" pn="section-4.10.1">
found at any <name slugifiedName="name-dmarc-policy-discovery">DMARC Policy Discove
ry</name>
<t indent="0" pn="section-4.10.1-1">The DMARC Policy Record to be appl
ied 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="normal" bare="false" empty="false" indent="3" pn="section
<ul spacing="compact"> -4.10.1-2">
<li>The Author Domain</li> <li pn="section-4.10.1-2.1">The Author Domain</li>
<li>The Organizational Domain of the Author Domain</li> <li pn="section-4.10.1-2.2">The Organizational Domain of the Author
<li>The Public Suffix Domain of the Author Domain</li> Domain</li>
</ul> <li pn="section-4.10.1-2.3">The PSD of the Author Domain</li>
<t>Policy discovery starts first with a query for a valid DMARC Policy Record at </ul>
the <t indent="0" pn="section-4.10.1-3">Policy discovery first starts with
name created by prepending the label &quot;_dmarc&quot; to the Author Domain of a query for a valid DMARC Policy Record at the
the name created by prepending the label "_dmarc" to the Author Domain of 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 &quot;psd&quot; 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" format="default" sectionFormat="o
<xref target="identifier-alignment-evaluation"></xref>.</t> f" derivedContent="Section 4.10.2"/>.</t>
<t>If no valid DMARC Policy Record is found by the first query, then perform a D <t indent="0" pn="section-4.10.1-4">If no valid DMARC Policy Record is
NS found by the first query, then perform a DNS
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="normal" bare="false" empty="false" indent="3" pn="section
<ul spacing="compact"> -4.10.1-5">
<li>If the Author Domain has eight or fewer labels, the starting point will be <li pn="section-4.10.1-5.1">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 <li pn="section-4.10.1-5.2">Otherwise, the starting point will be th
thor e name produced by shortening the Author
Domain as described starting in step 3 of <xref target="dns-tree-walk"></xref>.< Domain as described starting in step 3 of <xref target="dns-tree-walk" format="d
/li> efault" sectionFormat="of" derivedContent="Section 4.10"/>.</li>
</ul> </ul>
<t>If the DMARC Policy Record to be applied is that of the Author Domain, then t <t indent="0" pn="section-4.10.1-6">If the DMARC Policy Record to be a
he pplied is that of the Author Domain, then the
Domain Owner Assessment Policy is taken from the &quot;p&quot; tag of the record Domain Owner Assessment Policy is taken from the "p" tag of the record.</t>
.</t> <t indent="0" pn="section-4.10.1-7">If the DMARC Policy Record to be a
<t>If the DMARC Policy Record to be applied is that of either the Organizational pplied is that of either the Organizational Domain or the
Domain or the PSD and the Author Domain is a subdomain of that domain, then the Domain
Public Suffix Domain and the Author Domain is a subdomain of that domain, then t Owner Assessment Policy is taken from the "sp" tag (if any) if the Author Domain
he Domain exists
Owner Assessment Policy is taken from the &quot;sp&quot; tag (if any) if the Aut or the "np" tag (if any) if the Author Domain does not exist. In the absence of
hor Domain exists, applicable "sp" or "np" tags, the "p" tag policy is used for subdomains.</t>
or the &quot;np&quot; tag (if any) if the Author Domain does not exist. In the a <t indent="0" pn="section-4.10.1-8">If a retrieved DMARC Policy Record
bsence of does not contain a valid "p" tag, or contains an "sp" or
applicable &quot;sp&quot; or &quot;np&quot; tags, the &quot;p&quot; tag policy i "np" tag that is not valid, then:</t>
s used for subdomains.</t> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section
<t>If a retrieved DMARC Policy Record does not contain a valid &quot;p&quot; tag -4.10.1-9">
, or contains an &quot;sp&quot; or <li pn="section-4.10.1-9.1">
&quot;np&quot; tag that is not valid, then:</t> <t indent="0" pn="section-4.10.1-9.1.1">If a "rua" tag is present
and contains at least one syntactically valid reporting
<ul> URI, the Mail Receiver <bcp14>MUST</bcp14> act as if a record containing "p=none
<li><t>If a &quot;rua&quot; tag is present and contains at least one syntactical " was
ly valid reporting retrieved and continue processing.</t>
URI, the Mail Receiver <bcp14>MUST</bcp14> act as if a record containing &quot;p </li>
=none&quot; was <li pn="section-4.10.1-9.2">
retrieved and continue processing;</t> <t indent="0" pn="section-4.10.1-9.2.1">Otherwise, the Mail Receiv
</li> er applies no DMARC processing to this message.</t>
<li><t>Otherwise, the Mail Receiver applies no DMARC processing to this message. </li>
</t> </ul>
</li> <t indent="0" pn="section-4.10.1-10">If the set produced by the DNS Tr
</ul> ee 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 indent="0" pn="section-4.10.1-11">Handling of DNS errors when query ing 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 (&quot;fail open&quot;), 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 (&quot;fail cleared, allowing a definite DMARC conclusion to be reached ("fail
closed&quot;).</t> closed").</t>
<t>Note: PSD policy is not used for Organizational Domains that have <aside pn="section-4.10.1-12">
<t indent="0" pn="section-4.10.1-12.1">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> </aside>
</section>
<section anchor="identifier-alignment-evaluation"><name>Identifier Alignment Eva <section anchor="identifier-alignment-evaluation" numbered="true" remove
luation</name> InRFC="false" toc="include" pn="section-4.10.2">
<t>It may be necessary to perform multiple DNS Tree Walks to determine if an <name slugifiedName="name-identifier-alignment-evalua">Identifier Alig
nment Evaluation</name>
<t indent="0" pn="section-4.10.2-1">It may be necessary to perform mul
tiple 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="normal" bare="false" empty="false" indent="3" pn="section
<ul spacing="compact"> -4.10.2-2">
<li>The Author Domain of the message being evaluated.</li> <li pn="section-4.10.2-2.1">The Author Domain of the message being e
<li>The SPF-Authenticated Identifier if there is an SPF pass result for the mess valuated.</li>
age <li pn="section-4.10.2-2.2">The SPF-Authenticated Identifier if ther
e is an SPF "pass" result for the message
being evaluated.</li> being evaluated.</li>
<li>Any DKIM-Authenticated Identifier if one or more DKIM pass results exist for <li pn="section-4.10.2-2.3">Any DKIM-Authenticated Identifier if one or more DKIM "pass" results exist for
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 <t indent="0" pn="section-4.10.2-3">There is no need to perform Identi
of fier Alignment Evaluations under any of
the following conditions:</t> the following conditions:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<ul spacing="compact"> -4.10.2-4">
<li>The Author Domain and the Authenticated Identifier(s) are all the <li pn="section-4.10.2-4.1">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 &quot;mail.example.com&quot;, 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 &quot;_dmarc.mail.example.com& then "mail.example.com" is the Organizational Domain.</li>
quot;, <li pn="section-4.10.2-4.2">No applicable DMARC Policy Record is dis
then &quot;mail.example.com&quot; is the Organizational Domain.</li> covered 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 pn="section-4.10.2-4.3">The DMARC Policy Record for the Author D omain 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 indent="0" pn="section-4.10.2-5">To discover the Organizational Dom
described in <xref target="dns-tree-walk"></xref> as needed for any of the domai ain for a domain, perform the DNS Tree Walk
ns in question.</t> described in <xref target="dns-tree-walk" format="default" sectionFormat="of" de
<t>For each Tree Walk that retrieved valid DMARC Policy Records, select the Orga rivedContent="Section 4.10"/> as needed for any of the domains in question.</t>
nizational <t indent="0" pn="section-4.10.2-6">For each Tree Walk that retrieved
valid DMARC Policy Records, select the Organizational
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 indent="adaptive" spacing="normal" start="1" type="1" pn="section-
<ol> 4.10.2-7">
<li><t>If a valid DMARC Policy Record contains the &quot;psd&quot; tag set to &q <li pn="section-4.10.2-7.1" derivedCounter="1.">
uot;n&quot; (&quot;psd=n&quot;), this is the <t indent="0" pn="section-4.10.2-7.1.1">If a valid DMARC Policy Re
cord 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 pn="section-4.10.2-7.2" derivedCounter="2.">
he tree <t indent="0" pn="section-4.10.2-7.2.1">If a valid DMARC Policy Re
walk started, contains the &quot;psd&quot; tag set to &quot;y&quot; (&quot;psd=y cord, other than the one for the domain where the Tree
&quot;), the Organizational Walk started, contains the "psd" tag set to "y" ("psd=y"), 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 &quot;_dmarc.mail.example.com&quot; and th Policy Record is queried for at first "_dmarc.mail.example.com" and then "_dmarc
en &quot;_dmarc.example.com&quot;, .example.com",
and a valid DMARC Policy Record containing the &quot;psd&quot; tag set to &quot; and a valid DMARC Policy Record containing the "psd" tag set to "y" is found at
y&quot; is found at "_dmarc.example.com", then "mail.example.com" is the domain one label below "exa
&quot;_dmarc.example.com&quot;, then &quot;mail.example.com&quot; is the domain mple.com"
one label below &quot;example.com&quot;
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 <li pn="section-4.10.2-7.3" derivedCounter="3.">
st number <t indent="0" pn="section-4.10.2-7.3.1">Otherwise, select the DMAR
C Policy Record found at the name with the fewest 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 <t indent="0" pn="section-4.10.2-8">If this process does not determine
l target the Organizational Domain, then the initial target
domain is the Organizational Domain.</t> domain is the Organizational Domain.</t>
<t>For example, given the starting domain &quot;a.mail.example.com&quot;, a sear ch <t indent="0" pn="section-4.10.2-9">For example, given the starting do main "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 &quot;_dmarc.a.mail.example.com&quot; and finishing with & Records starting with "_dmarc.a.mail.example.com" and finishing with "_dmarc.com
quot;_dmarc.com&quot;. ".
If there are DMARC Policy Records published at &quot;_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
&quot;_dmarc.example.com&quot;, but not at &quot;_dmarc.a.mail.example.com&quot; "_dmarc.com", then the Organizational Domain for this domain would be
or "example.com".</t>
&quot;_dmarc.com&quot;, then the Organizational Domain for this domain would be <t indent="0" pn="section-4.10.2-10">As another example, given the sta
&quot;example.com&quot;.</t> rting domain "a.mail.example.com", if a
<t>As another example, given the starting domain &quot;a.mail.example.com&quot;, search for the Organizational Domain yields a DMARC Policy Record at "_dmarc.mai
if a l.example.com"
search for the Organizational Domain yields a DMARC Policy Record at &quot;_dmar with the "psd" tag set to "n", then the Organizational Domain for this domain wo
c.mail.example.com&quot; uld
with the &quot;psd&quot; tag set to &quot;n&quot;, then the Organizational Domai be "mail.example.com".</t>
n for this domain would <t indent="0" pn="section-4.10.2-11">As a last example, given the star
be &quot;mail.example.com&quot;.</t> ting domain "a.mail.example.com", if a
<t>As a last example, given the starting domain &quot;a.mail.example.com&quot;, search for the Organizational Domain only yields a DMARC Policy Record at "_dmar
if a c.com"
search for the Organizational Domain only yields a DMARC Policy Record at &quot; and that record contains the tag "psd=y", then the Organizational Domain for
_dmarc.com&quot; this domain would be "example.com".</t>
and that record contains the tag &quot;psd=y&quot;, then the Organizational Doma </section>
in for </section>
this domain would be &quot;example.com&quot;.</t> </section>
</section> <section anchor="dmarc-participation" numbered="true" removeInRFC="false" to
</section> c="include" pn="section-5">
</section> <name slugifiedName="name-dmarc-participation">DMARC Participation</name>
<t indent="0" pn="section-5-1">This section describes the actions for part
<section anchor="dmarc-participation"><name>DMARC Participation</name> icipating 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" numbered="true" removeInRFC="false"
toc="include" pn="section-5.1">
<section anchor="domain-owner-actions"><name>Domain Owner Actions</name> <name slugifiedName="name-domain-owner-actions">Domain Owner Actions</na
<t>A <eref target="#domain-owner">Domain Owner</eref> wishing to fully participa me>
te in DMARC will <t indent="0" pn="section-5.1-1">A <xref target="domain-owner" format="d
publish a <eref target="#dmarc-policy-record">DMARC Policy Record</eref> to cove efault" sectionFormat="of" derivedContent="Section 3.2.7">Domain Owner</xref> wi
r each <eref target="#author-domain">Author Domain</eref> and corresponding <ere shing to fully participate in DMARC will:</t>
f target="#organizational-domain">Organizational Domain</eref> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-5
to which DMARC validation should apply, send email that produces at least one, a .1-2">
nd <li pn="section-5.1-2.1">Publish a <xref target="dmarc-policy-record"
preferably two, <eref target="#authenticated-identifiers">Authenticated Identifi format="default" sectionFormat="of" derivedContent="Section 3.2.6">DMARC Policy
ers</eref> that align Record</xref> to cover each <xref target="author-domain" format="default" sectio
with the Author Domain, will receive and monitor the content of DMARC aggregate nFormat="of" derivedContent="Section 3.2.2">Author Domain</xref> and correspondi
reports, and will correct any authentication shortcomings in mail making authori ng <xref target="organizational-domain" format="default" sectionFormat="of" deri
zed vedContent="Section 3.2.14">Organizational Domain</xref>
use of its domains.</t> to which DMARC validation should apply;</li>
<t>The following sections describe how to achieve this.</t> <li pn="section-5.1-2.2">Send email that produces at least one --
preferably two -- <xref target="authenticated-identifiers" format="default" sect
<section anchor="publish-an-spf-record-for-an-aligned-domain"><name>Publish an S ionFormat="of" derivedContent="Section 3.2.1">Authenticated Identifiers</xref> t
PF Record for an Aligned Domain</name> hat align
<t>To configure SPF for DMARC, the Domain Owner <bcp14>MUST</bcp14> send mail th with the Author Domain;</li>
at has <li pn="section-5.1-2.3">Receive and monitor the content of DMARC aggr
an RFC5321.MailFrom domain that will produce an <eref target="#spf-identifiers"> egate
SPF-Authenticated reports;</li>
Identifier</eref> that has <eref target="#identifier-alignment-explained">Identi <li pn="section-5.1-2.4">Correct authentication shortcomings in mail m
fier Alignment</eref> aking authorized
use of its domains.</li>
</ul>
<t indent="0" pn="section-5.1-3">The following sections describe how to
achieve this.</t>
<section anchor="publish-an-spf-record-for-an-aligned-domain" numbered="
true" removeInRFC="false" toc="include" pn="section-5.1.1">
<name slugifiedName="name-publish-an-spf-record-for-a">Publish an SPF
Record for an Aligned Domain</name>
<t indent="0" pn="section-5.1.1-1">To configure SPF for DMARC, the Dom
ain Owner <bcp14>MUST</bcp14> send mail that has
an RFC5321.MailFrom domain that will produce an <xref target="spf-identifiers" f
ormat="default" sectionFormat="of" derivedContent="Section 4.4.2">SPF-Authentica
ted
Identifier</xref> that has <xref target="identifier-alignment-explained" format=
"default" sectionFormat="of" derivedContent="Section 4.4">Identifier Alignment</
xref>
with the Author Domain.</t> with the Author Domain.</t>
</section> </section>
<section anchor="configure-sending-system-for-dkim-signing-using-an-alig
<section anchor="configure-sending-system-for-dkim-signing-using-an-aligned-doma ned-domain" numbered="true" removeInRFC="false" toc="include" pn="section-5.1.2"
in"><name>Configure Sending System for DKIM Signing Using an Aligned Domain</nam >
e> <name slugifiedName="name-configure-sending-system-fo">Configure Sendi
<t>To configure DKIM for DMARC, the Domain Owner <bcp14>MUST</bcp14> send mail t ng System for DKIM Signing Using an Aligned Domain</name>
hat <t indent="0" pn="section-5.1.2-1">To configure DKIM for DMARC, the Do
has a <eref target="#dkim-signing-domain">DKIM Signing Domain</eref> that will p main Owner <bcp14>MUST</bcp14> send mail that
roduce a has a <xref target="dkim-signing-domain" format="default" sectionFormat="of" der
<eref target="#dkim-identifiers">DKIM-Authenticated Identifier</eref> that ivedContent="Section 3.2.3">DKIM Signing Domain</xref> that will produce a
has <eref target="#identifier-alignment-explained">Identifier Alignment</eref> w <xref target="dkim-identifiers" format="default" sectionFormat="of" derivedConte
ith the Author Domain.</t> nt="Section 4.4.1">DKIM-Authenticated Identifier</xref> that
</section> has <xref target="identifier-alignment-explained" format="default" sectionFormat
="of" derivedContent="Section 4.4">Identifier Alignment</xref> with the Author D
<section anchor="set-up-a-mailbox-to-receive-aggregate-reports"><name>Set Up a M omain.</t>
ailbox to Receive Aggregate Reports</name> </section>
<t>Proper consumption and analysis of DMARC aggregate reports are essential <section anchor="set-up-a-mailbox-to-receive-aggregate-reports" numbered
="true" removeInRFC="false" toc="include" pn="section-5.1.3">
<name slugifiedName="name-set-up-a-mailbox-to-receive">Set Up a Mailbo
x to Receive Aggregate Reports</name>
<t indent="0" pn="section-5.1.3-1">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" format="default" sectionFor mat="of" derivedContent="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
<section anchor="publish-a-dmarc-policy-record-for-the-author-domain-and-organiz -organizational-domain" numbered="true" removeInRFC="false" toc="include" pn="se
ational-domain"><name>Publish a DMARC Policy Record for the Author Domain and Or ction-5.1.4">
ganizational Domain</name> <name slugifiedName="name-publish-a-dmarc-policy-reco">Publish a DMARC
<t>Once SPF, DKIM, and the aggregate reports mailbox are all in place, Policy Record for the Author Domain and Organizational Domain</name>
<t indent="0" pn="section-5.1.4-1">Once SPF, DKIM, and the aggregate r
eports 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 &quot;p=none&quot;, (see <xref target="collect-and-analyze">< usually start with "p=none" (see <xref target="collect-and-analyze" format="defa
/xref>) ult" sectionFormat="of" derivedContent="Section 5.1.5"/>)
with the &quot;rua&quot; tag containing a URI that references the mailbox create with the "rua" tag containing a URI that references the mailbox created
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" format="default" sectionFormat="of" d erivedContent="Section 3.2.12">Monitoring Mode</xref>. If the Organizational Dom ain
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" numbered="true" removeInRFC="false
<section anchor="collect-and-analyze"><name>Collect and Analyze Reports</name> " toc="include" pn="section-5.1.5">
<t>The reason for starting at &quot;p=none&quot; is to ensure that nothing's bee <name slugifiedName="name-collect-and-analyze-reports">Collect and Ana
n lyze Reports</name>
<t indent="0" pn="section-5.1.5-1">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 &quot;p=none&quot;, 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 indent="0" pn="section-5.1.5-2">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" nu
<section anchor="remediate-unaligned-or-unauthenticated-mail-streams"><name>Reme mbered="true" removeInRFC="false" toc="include" pn="section-5.1.6">
diate Unaligned or Unauthenticated Mail Streams</name> <name slugifiedName="name-remediate-unaligned-or-unau">Remediate Unali
<t>DMARC aggregate reports can reveal to the Domain Owner mail streams using the gned or Unauthenticated Mail Streams</name>
<t indent="0" pn="section-5.1.6-1">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" format="default" sectionFormat="of"
ef> of derivedContent="Section 3.2.8">Domain Owner Assessment Policy</xref> of
<eref target="#enforcement">Enforcement</eref> for the Author Domain.</t> <xref target="enforcement" format="default" sectionFormat="of" derivedContent="S
</section> ection 3.2.9">Enforcement</xref> for the Author Domain.</t>
</section>
<section anchor="decide-whether-to-update-domain-owner-assessment-policy-to-enfo <section anchor="decide-whether-to-update-domain-owner-assessment-policy
rcement"><name>Decide Whether to Update Domain Owner Assessment Policy to Enforc -to-enforcement" numbered="true" removeInRFC="false" toc="include" pn="section-5
ement</name> .1.7">
<t>Once the Domain Owner is satisfied that it is properly authenticating <name slugifiedName="name-decide-whether-to-update-do">Decide Whether
to Update Domain Owner Assessment Policy to Enforcement</name>
<t indent="0" pn="section-5.1.7-1">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" format=" default" sectionFormat="of" derivedContent="Section 3.2.9">Enforcement</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 &quot;p&quot; 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 indent="0" pn="section-5.1.7-2">In making this decision, it is impo rtant 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" issues are discussed in detail in <xref target="interoperability-considerations"
></xref></t> format="default" sectionFormat="of" derivedContent="Section 7.4"/></t>
</section> </section>
<section anchor="a-note-on-large-complex-organizations-and-decentralized
<section anchor="a-note-on-large-complex-organizations-and-decentralized-dns-man -dns-management" numbered="true" removeInRFC="false" toc="include" pn="section-5
agement"><name>A Note on Large, Complex Organizations and Decentralized DNS Mana .1.8">
gement</name> <name slugifiedName="name-a-note-on-large-complex-org">A Note on Large
<t>Large, complex organizations frequently adopt a decentralized model for , Complex Organizations and Decentralized DNS Management</name>
DNS management, whereby management of a subtree of the name space is delegated <t indent="0" pn="section-5.1.8-1">Large, complex organizations freque
ntly adopt a decentralized model for
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
&quot;psd&quot; 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 &quot;psd&quot; tag set t o &quot;n&quot;. 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 indent="0" pn="section-5.1.8-2">Such configurations would work in t heory, 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="normal" bare="false" empty="false" indent="3" pn="section
<ul spacing="compact"> -5.1.8-3">
<li>Apex domain (DMARC Policy Record published here): example.com</li> <li pn="section-5.1.8-3.1">Apex domain (DMARC Policy Record publishe
<li>Zone cut domain (DMARC Policy Record with &quot;psd=n&quot; published here): d here): example.com</li>
b.c.d.e.f.g.example.com</li> <li pn="section-5.1.8-3.2">Zone cut domain (DMARC Policy Record with
<li>Author Domain: mail.a.b.c.d.e.f.g.example.com</li> "psd=n" published here): b.c.d.e.f.g.example.com</li>
</ul> <li pn="section-5.1.8-3.3">Author Domain: mail.a.b.c.d.e.f.g.example
<t>However, Domain Owners should be aware that due to the anti-abuse protections .com</li>
built into the <eref target="#dns-tree-walk">DNS Tree Walk</eref>, the DMARC Pol </ul>
icy Record published <t indent="0" pn="section-5.1.8-4">However, Domain Owners should be aw
are that due to the anti-abuse protections
built into the <xref target="dns-tree-walk" format="default" sectionFormat="of"
derivedContent="Section 4.10">DNS Tree Walk</xref>, the DMARC Policy Record publ
ished
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="normal" bare="false" empty="false" indent="3" pn="section
<ul spacing="compact"> -5.1.8-5">
<li>_dmarc.mail.a.b.c.d.e.f.g.example.com</li> <li pn="section-5.1.8-5.1">_dmarc.mail.a.b.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 pn="section-5.1.8-5.2">_dmarc.c.d.e.f.g.example.com</li>
<li>_dmarc.e.f.g.example.com</li> <li pn="section-5.1.8-5.3">_dmarc.d.e.f.g.example.com</li>
<li>_dmarc.f.g.example.com</li> <li pn="section-5.1.8-5.4">_dmarc.e.f.g.example.com</li>
<li>_dmarc.g.example.com</li> <li pn="section-5.1.8-5.5">_dmarc.f.g.example.com</li>
<li>_dmarc.example.com</li> <li pn="section-5.1.8-5.6">_dmarc.g.example.com</li>
<li>_dmarc.com</li> <li pn="section-5.1.8-5.7">_dmarc.example.com</li>
</ul> <li pn="section-5.1.8-5.8">_dmarc.com</li>
<t>To avoid this circumstance, Domain Owners wishing to have a specific DMARC Po </ul>
licy <t indent="0" pn="section-5.1.8-6">To avoid this circumstance, Domain
Record applied to a given <eref target="#author-domain">Author Domain</eref> lon Owners wishing to have a specific DMARC Policy
ger than eight labels Record applied to a given <xref target="author-domain" format="default" sectionF
ormat="of" derivedContent="Section 3.2.2">Author Domain</xref> longer 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 &quot;_dmarc.mail.a.b.c.d.e.f.g.example.com.&quot;.</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" numbered="true" removeInRFC="false" toc="inc
<section anchor="pso-actions"><name>PSO Actions</name> lude" pn="section-5.2">
<t>In addition to the DMARC Domain Owner actions, if a <eref target="#public-suf <name slugifiedName="name-pso-actions">PSO Actions</name>
fix-operator">PSO</eref> <t indent="0" pn="section-5.2-1">In addition to the DMARC Domain Owner a
publishes a DMARC Policy Record it <bcp14>MUST</bcp14> include the &quot;psd&quo ctions, if a <xref target="public-suffix-operator" format="default" sectionForma
t; tag (see <xref target="policy-record-format"></xref>) t="of" derivedContent="Section 3.2.16">PSO</xref>
with a value of &quot;y&quot; (&quot;psd=y&quot;).</t> publishes a DMARC Policy Record, it <bcp14>MUST</bcp14> include the "psd" tag (s
</section> ee <xref target="policy-record-format" format="default" sectionFormat="of" deriv
edContent="Section 4.7"/>)
<section anchor="mail-receiver-actions"><name>Mail Receiver Actions</name> with a value of "y" ("psd=y").</t>
<t><eref target="#mail-receiver">Mail Receivers</eref> wishing to fully particip </section>
ate in DMARC <section anchor="mail-receiver-actions" numbered="true" removeInRFC="false
will apply the DMARC mechanism to inbound email messages when a <eref target="#d " toc="include" pn="section-5.3">
marc-policy-record">DMARC <name slugifiedName="name-mail-receiver-actions">Mail Receiver Actions</
Policy Record</eref> exists that applies to the <eref target="#author-domain">Au name>
thor <t indent="0" pn="section-5.3-1"><xref target="mail-receiver" format="de
Domain</eref>, and will send aggregate feedback reports to Domain fault" sectionFormat="of" derivedContent="Section 3.2.11">Mail Receivers</xref>
wishing to fully participate in DMARC
will apply the DMARC mechanism to inbound email messages when a <xref target="dm
arc-policy-record" format="default" sectionFormat="of" derivedContent="Section 3
.2.6">DMARC
Policy Record</xref> exists that applies to the <xref target="author-domain" for
mat="default" sectionFormat="of" derivedContent="Section 3.2.2">Author
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 indent="0" pn="section-5.3-2">The steps for applying the DMARC mechan
place during the SMTP transaction, and should do so if the Mail Receiver ism to an email message can take
plans to honor <eref target="#domain-owner-policy">Domain Owner Assessment Polic place during the SMTP transaction and should do so if the Mail Receiver
ies</eref> that plans to honor <xref target="domain-owner-policy" format="default" sectionFormat
are at the <eref target="#enforcement">Enforcement</eref> state.</t> ="of" derivedContent="Section 3.2.8">Domain Owner Assessment Policies</xref> tha
<t>Many Mail Receivers perform one or both of the underlying <eref target="#auth t
entication-mechanisms">Authentication are at the <xref target="enforcement" format="default" sectionFormat="of" derive
Mechanisms</eref> on inbound messages even in cases dContent="Section 3.2.9">Enforcement</xref> state.</t>
<t indent="0" pn="section-5.3-3">Many Mail Receivers perform one or both
of the underlying <xref target="authentication-mechanisms" format="default" sec
tionFormat="of" derivedContent="Section 4.3">Authentication
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" numbered="true" removeInRFC="fal
<section anchor="extract-author-domain"><name>Extract Author Domain</name> se" toc="include" pn="section-5.3.1">
<t>Once the email message has been transmitted to the Mail Receiver, the Mail <name slugifiedName="name-extract-author-domain">Extract Author Domain
</name>
<t indent="0" pn="section-5.3.1-1">Once the email message has been tra
nsmitted 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 A-label, as described in <xref section="2.3" target="RFC5890" format="default" s
her processing.</t> ectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc5890#section-2.3" d
<t>If zero or more than one domain is extracted from the RFC5322.From header erivedContent="RFC5890"/>, for further processing.</t>
<t indent="0" pn="section-5.3.1-2">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" format="default" sectionFormat="of" deriv
</section> edContent="Section 11.5"/> for further discussion.</t>
</section>
<section anchor="determine-mechanism-applies"><name>Determine If The DMARC Mecha <section anchor="determine-mechanism-applies" numbered="true" removeInRF
nism Applies</name> C="false" toc="include" pn="section-5.3.2">
<t>If precisely one Author Domain exists for the message, then perform the <name slugifiedName="name-determine-if-the-dmarc-mech">Determine If th
step described in <eref target="#dmarc-policy-discovery">DMARC Policy Discovery< e DMARC Mechanism Applies</name>
/eref> to determine <t indent="0" pn="section-5.3.2-1">If precisely one Author Domain exis
if the DMARC mechanism applies. If a <eref target="#dmarc-policy-record">DMARC P ts for the message, then perform the
olicy Record</eref> is not step described in <xref target="dmarc-policy-discovery" format="default" section
Format="of" derivedContent="Section 4.10.1">"DMARC Policy Discovery"</xref> to d
etermine
if the DMARC mechanism applies. If a <xref target="dmarc-policy-record" format="
default" sectionFormat="of" derivedContent="Section 3.2.6">DMARC Policy 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" numbered="true" re
<section anchor="determine-authenticated-identifiers"><name>Determine If Authent moveInRFC="false" toc="include" pn="section-5.3.3">
icated Identifiers Exist</name> <name slugifiedName="name-determine-if-authenticated-">Determine If Au
<t>For each Authentication Mechanism underlying DMARC, perform the required thenticated Identifiers Exist</name>
check to determine if an <eref target="#authenticated-identifier">Authenticated <t indent="0" pn="section-5.3.3-1">For each authentication mechanism u
Identifier</eref> nderlying DMARC, perform the required
check to determine if an <xref target="authenticated-identifiers" format="defaul
t" sectionFormat="of" derivedContent="Section 3.2.1">Authenticated Identifier</x
ref>
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="normal" bare="false" empty="false" indent="3" pn="section
<ul spacing="compact"> -5.3.3-2">
<li>For SPF, the preserved results <bcp14>MUST</bcp14> include &quot;pass&quot; <li pn="section-5.3.3-2.1">For SPF, the preserved results <bcp14>MUS
or &quot;fail&quot;, and if &quot;fail&quot;, <bcp14>SHOULD</bcp14> T</bcp14> include "pass" or "fail". If the result is "fail", it <bcp14>SHOULD</b
include information about the reasons for failure if available. The results <bcp cp14>
14>MUST</bcp14> further include information about the reasons for failure, if available. The results <bc
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 pn="section-5.3.3-2.2">For DKIM signature validation checks, for
results <bcp14>MUST</bcp14> include &quot;pass&quot; or &quot;fail&quot;, and if each signature checked, the
&quot;fail&quot;, <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 &quot;d&quot; and &quot;s&quot; tags from each checked DKIM sig the value of the "d" and "s" tags from each checked DKIM signature.</li>
nature.</li> </ul>
</ul> </section>
</section> <section anchor="conduct-alignment-checks" numbered="true" removeInRFC="
false" toc="include" pn="section-5.3.4">
<section anchor="conduct-alignment-checks"><name>Conduct Identifier Alignment Ch <name slugifiedName="name-conduct-identifier-alignmen">Conduct Identif
ecks If Necessary</name> ier Alignment Checks If Necessary</name>
<t>For each Authenticated Identifier found in the message, the Mail Receiver che <t indent="0" pn="section-5.3.4-1">For each Authenticated Identifier f
cks ound in the message, the Mail Receiver checks
to see if the Authenticated Identifier is <eref target="#identifier-alignment-ev to see if the Authenticated Identifier is <xref target="identifier-alignment-eva
aluation">aligned</eref> luation" format="default" sectionFormat="of" derivedContent="Section 4.10.2">ali
gned</xref>
with the Author Domain.</t> with the Author Domain.</t>
</section> </section>
<section anchor="pass-or-fail" numbered="true" removeInRFC="false" toc="
<section anchor="pass-or-fail"><name>Determine DMARC &quot;Pass&quot; or &quot;F include" pn="section-5.3.5">
ail&quot;</name> <name slugifiedName="name-determine-dmarc-pass-or-fai">Determine DMARC
<t>If one or more of the Authenticated Identifiers align with the Author Domain, "Pass" or "Fail"</name>
the <t indent="0" pn="section-5.3.5-1">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 indent="0" pn="section-5.3.5-2">If no Authenticated Identifiers exi st for the domain, or none of the Authenticated
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" numbered="true" removeInRFC="false" toc="
<section anchor="apply-policy"><name>Apply Policy If Appropriate</name> include" pn="section-5.3.6">
<t>Email messages that fail the DMARC mechanism check are handled in accordance <name slugifiedName="name-apply-policy-if-appropriate">Apply Policy If
with Appropriate</name>
<t indent="0" pn="section-5.3.6-1">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 indent="0" pn="section-5.3.6-2">If one or more DNS queries required to perform DMARC validation on the message
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 <t indent="0" pn="section-5.3.6-3">See <xref target="rejecting-message
s regarding rejecting messages.</t> s" format="default" sectionFormat="of" derivedContent="Section 7.2"/> for furthe
</section> r discussion of topics regarding rejecting messages.</t>
</section>
<section anchor="store-results-of-dmarc-processing"><name>Store Results of DMARC <section anchor="store-results-of-dmarc-processing" numbered="true" remo
Processing</name> veInRFC="false" toc="include" pn="section-5.3.7">
<t>If the Mail Receiver intends to send aggregate feedback reports and/or failur <name slugifiedName="name-store-results-of-dmarc-proc">Store Results o
e reports, f DMARC Processing</name>
<t indent="0" pn="section-5.3.7-1">If the Mail Receiver intends to sen
d aggregate feedback reports and/or failure 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" format="default" sectionFor mat="of" derivedContent="Section 4.7"/> and <xref target="RFC9990" format="defau lt" sectionFormat="of" derivedContent="RFC9990"/>
discuss aggregate feedback reports.</t> discuss aggregate feedback reports.</t>
</section> </section>
<section anchor="send-aggregate-reports" numbered="true" removeInRFC="fa
<section anchor="send-aggregate-reports"><name>Send Aggregate Reports</name> lse" toc="include" pn="section-5.3.8">
<t>To ensure maximum usefulness for DMARC across the email ecosystem, Mail <name slugifiedName="name-send-aggregate-reports">Send Aggregate Repor
ts</name>
<t indent="0" pn="section-5.3.8-1">To ensure maximum usefulness for DM
ARC 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" format="default" sectionFormat="of" derivedC
forcement">Enforcement</eref>.</t> ontent="Section 3.2.12">Monitoring Mode</xref> to <xref target="enforcement" for
<t>The most common reasons for a Mail Receiver to opt out of sending aggregate mat="default" sectionFormat="of" derivedContent="Section 3.2.9">Enforcement</xre
f>.</t>
<t indent="0" pn="section-5.3.8-2">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" numbered="true" removeInRFC="fals
<section anchor="send-failure-reports"><name>Optionally Send Failure Reports</na e" toc="include" pn="section-5.3.9">
me> <name slugifiedName="name-optionally-send-failure-rep">Optionally Send
<t>Per-message failure reports can be a useful source of information for a Domai Failure Reports</name>
n <t indent="0" pn="section-5.3.9-1">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"></ or not send them at all. See <xref target="RFC9991" format="default" sectionFor
xref> for further information.</t> mat="of" derivedContent="RFC9991"/> for further information.</t>
</section> </section>
</section> </section>
<section anchor="policy-enforcement-considerations" numbered="true" remove
<section anchor="policy-enforcement-considerations"><name>Policy Enforcement Con InRFC="false" toc="include" pn="section-5.4">
siderations</name> <name slugifiedName="name-policy-enforcement-consider">Policy Enforcemen
<t>The final handling of any message is always a matter of local policy and is t Considerations</name>
<t indent="0" pn="section-5.4-1">The final handling of any message is al
ways 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 indent="0" pn="section-5.4-2">A DMARC pass for a message indicates on
author-domain">Author Domain</eref> ly that the use of the <xref target="author-domain" format="default" sectionForm
has been validated for that message as authorized by the <eref target="#domain-o at="of" derivedContent="Section 3.2.2">Author Domain</xref>
wner">Domain Owner</eref>. has been validated for that message as authorized by the <xref target="domain-ow
ner" format="default" sectionFormat="of" derivedContent="Section 3.2.7">Domain O
wner</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 indent="0" pn="section-5.4-3">Mail Receivers <bcp14>MAY</bcp14> choos e 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 &quot;reject&quot;. 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" format="default" sectionFormat="of" derivedContent="RF
ations"></xref> of this document, it is important that Mail C7960"/> and in <xref target="interoperability-considerations" format="default"
Receivers <bcp14>SHOULD NOT</bcp14> reject messages solely because of a publishe sectionFormat="of" derivedContent="Section 7.4"/> of this document, it is import
d policy of &quot;reject&quot;, ant that Mail
Receivers <bcp14>SHOULD NOT</bcp14> reject messages solely because of a publishe
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 indent="0" pn="section-5.4-4">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 <xref target="RFC8601" format="default" sectionFormat="of" derivedContent="RFC86
ering messages that fail the DMARC validation check.</t> 01"/>), and it is <bcp14>RECOMMENDED</bcp14> when delivering messages that fail
<t>When Mail Receivers deviate from a published Domain Owner the DMARC validation check.</t>
Assessment Policy during message processing they <bcp14>SHOULD</bcp14> make <t indent="0" pn="section-5.4-5">When Mail Receivers deviate from a publ
ished Domain Owner
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
&quot;PolicyOverride&quot; 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" format="default" sectionFormat="of" derivedContent="RFC99
<t>To enable Domain Owners to receive DMARC feedback without impacting 90"/>.</t>
existing mail processing, discovered policies of &quot;p=none&quot; <bcp14>MUST <t indent="0" pn="section-5.4-6">To enable Domain Owners to receive DMAR
NOT</bcp14> C feedback without impacting
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" numbered="true" removeInRFC="false" toc="in
<section anchor="dmarc-feedback"><name>DMARC Feedback</name> clude" pn="section-6">
<t>DMARC Feedback is described in <xref target="I-D.ietf-dmarc-aggregate-reporti <name slugifiedName="name-dmarc-feedback">DMARC Feedback</name>
ng"></xref></t> <t indent="0" pn="section-6-1">DMARC feedback is described in <xref target
<t>As an operational note for Public Suffix Operators, feedback for non-existent ="RFC9990" format="default" sectionFormat="of" derivedContent="RFC9990"/>.</t>
<t indent="0" pn="section-6-2">As an operational note for PSOs, feedback f
or 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 &quot;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" format="default" sectionFormat="of" derivedContent="Section 1
cy-considerations"></xref> 0"/>
for discussion of Privacy Considerations.</t> for discussion of privacy considerations.</t>
</section> </section>
<section anchor="other-topics" numbered="true" removeInRFC="false" toc="incl
<section anchor="other-topics"><name>Other Topics</name> ude" pn="section-7">
<t>This section discusses some topics regarding choices made in the <name slugifiedName="name-other-topics">Other Topics</name>
<t indent="0" pn="section-7-1">This section discusses some topics regardin
g 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" numbered="true" removeInRFC="fals
<section anchor="issues-specific-to-spf"><name>Issues Specific to SPF</name> e" toc="include" pn="section-7.1">
<t>Though DMARC does not inherently change the semantics of an SPF <name slugifiedName="name-issues-specific-to-spf">Issues Specific to SPF
</name>
<t indent="0" pn="section-7.1-1">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" format="default" sectionFormat="of" derivedC ontent="Section 3.2.7">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 indent="0" pn="section-7.1-2">SPF was intended to be implemented earl y 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 (&quot;-&quot; 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 &quot;-all&quot;, 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 &quot;-all&quot; 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" for
IM-Authenticated Identifier</eref> could be rejected solely due to an SPF fail. mat="default" sectionFormat="of" derivedContent="Section 4.4.1">DKIM-Authenticat
ed 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" format="def
vers</eref> can consult ault" sectionFormat="of" derivedContent="Section 3.2.11">Mail Receivers</xref> c
<xref target="M3SPF"></xref> and <xref target="M3AUTH"></xref> for more discussi an consult
on of the topic and best practices <xref target="M3SPF" format="default" sectionFormat="of" derivedContent="M3SPF"/
regarding publishing SPF records and when to reject based solely on SPF failure: > and <xref target="M3AUTH" format="default" sectionFormat="of" derivedContent="
</t> M3AUTH"/> for more discussion of the topic and best practices
</section> regarding publishing SPF records and when to reject based solely on SPF failure.
</t>
<section anchor="rejecting-messages"><name>Rejecting Messages</name> </section>
<t>The DMARC mechanism calls for rejection of a message during the SMTP <section anchor="rejecting-messages" numbered="true" removeInRFC="false" t
oc="include" pn="section-7.2">
<name slugifiedName="name-rejecting-messages">Rejecting Messages</name>
<t indent="0" pn="section-7.2-1">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" format="default" sectionFormat="of" derivedContent="RFC34 64"/>, since fraudulent messages caught and rejected using the 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 indent="0" pn="section-7.2-2">This synchronous rejection is typically
done in one of two ways:</t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7
<li><t>Full rejection, wherein the SMTP server issues a 5xy reply code to the .2-3">
<li pn="section-7.2-3.1">
<t indent="0" pn="section-7.2-3.1.1">A "full rejection", wherein the
SMTP server issues a 5xy reply code to the
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">< delivery failed (see <xref target="RFC5321" sectionFormat="of" section="4.2.5" f
/xref>).</t> ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc5321#section-4.2.5" d
</li> erivedContent="RFC5321"/>).</t>
<li><t>A &quot;silent discard&quot;, wherein the SMTP server returns a 2xy reply </li>
code implying to the client that delivery (or, at least, relay) <li pn="section-7.2-3.2">
was successfully completed, but then simply discards the message <t indent="0" pn="section-7.2-3.2.1">A "silent discard", wherein the
SMTP server returns a 2xy reply
code implying to the client that delivery (or at least relay)
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 indent="0" pn="section-7.2-4">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 indent="0" pn="section-7.2-5">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 indent="0" pn="section-7.2-6">In the latter case, when doing an SMTP
hint can be useful in resolving issues. A <eref target="#mail-receiver">Mail Rec rejection, providing a clear
eiver</eref> hint can be useful in resolving issues. A <xref target="mail-receiver" format="d
efault" sectionFormat="of" derivedContent="Section 3.2.11">Mail Receiver</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 &quot;DMARC&quot; somewhere in the reply text. For example:</t> word "DMARC" somewhere in the reply text. For example:</t>
<artwork align="left" pn="section-7.2-7">
<artwork><![CDATA[550 5.7.1 Email rejected per DMARC policy for example.com 550 5.7.1 Email rejected per DMARC policy for example.com</artwork>
]]></artwork> <t indent="0" pn="section-7.2-8">Many systems are able to scan the SMTP
<t>Many systems are able to scan the SMTP reply text to determine the nature 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 indent="0" pn="section-7.2-9">If a Mail Receiver elects to defer deli very 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" numbered="true" removeInRFC="fal
<section anchor="interoperability-issues"><name>Interoperability Issues</name> se" toc="include" pn="section-7.3">
<t>DMARC limits which end-to-end scenarios can achieve a &quot;pass&quot; result <name slugifiedName="name-interoperability-issues">Interoperability Issu
.</t> es</name>
<t>Because DMARC relies on SPF <xref target="RFC7208"></xref> and/or DKIM <xref <t indent="0" pn="section-7.3-1">DMARC limits which end-to-end scenarios
target="RFC6376"></xref> to achieve can achieve a "pass" result.</t>
a &quot;pass&quot;, their limitations also apply.</t> <t indent="0" pn="section-7.3-2">Because DMARC relies on SPF <xref targe
<t>Issues specific to the use of policy mechanisms alongside DKIM are t="RFC7208" format="default" sectionFormat="of" derivedContent="RFC7208"/> and/o
further discussed in <xref target="RFC6377"></xref>, particularly Section 5.2.</ r DKIM <xref target="RFC6376" format="default" sectionFormat="of" derivedContent
t> ="RFC6376"/> to achieve
<t>Mail that is sent by authorized, independent third parties might not be a "pass", their limitations also apply.</t>
sent with Identifier Alignment, also preventing a &quot;pass&quot; result. A Dom <t indent="0" pn="section-7.3-3">Issues specific to the use of policy me
ain chanisms alongside DKIM are
further discussed in <xref target="RFC6377" format="default" sectionFormat="of"
derivedContent="RFC6377"/>, particularly Section <xref target="RFC6377" section=
"5.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/
rfc/rfc6377#section-5.2" derivedContent="RFC6377"/>.</t>
<t indent="0" pn="section-7.3-4">Mail that is sent by authorized, indepe
ndent third parties might not be
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" numbered="true" removeIn
<section anchor="interoperability-considerations"><name>Interoperability Conside RFC="false" toc="include" pn="section-7.4">
rations</name> <name slugifiedName="name-interoperability-considerat">Interoperability
<t>As discussed in &quot;Interoperability Issues between DMARC and Indirect Considerations</name>
Email Flows&quot; <xref target="RFC7960"></xref>, use of &quot;p=reject&quot; ca <t indent="0" pn="section-7.4-1">As discussed in "Interoperability Issue
n be incompatible with and s
between Domain-based Message Authentication, Reporting, and
Conformance (DMARC) and Indirect Email Flows" <xref target="RFC7960" format="def
ault" sectionFormat="of" derivedContent="RFC7960"/>, the use of "p=reject" can b
e incompatible with and
cause interoperability problems to indirect message flows such as cause interoperability problems to indirect message flows such as
&quot;alumni forwarders&quot;, 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 indent="0" pn="section-7.4-2">As an example of this, a bank might sen d 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 &quot;jones@alumni.example.edu&quot; (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
&quot;finance@association.example&quot; (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 &quot;example.edu&quot; or &quot;association.example&quot;, 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 &quot;p=reject <t indent="3" pn="section-7.4-3">It is therefore critical that domains t
&quot; hat 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 indent="0" pn="section-7.4-4">In the case of domains that have genera
email, l users who send routine email,
those that publish a <eref target="#domain-owner-policy">Domain Owner Assessment those that publish a <xref target="domain-owner-policy" format="default" section
Policy</eref> Format="of" derivedContent="Section 3.2.8">Domain Owner Assessment Policy</xref>
of &quot;p=reject&quot; 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" format="default" sectionFormat="of" derivedContent="RF
<blockquote><t>It is therefore critical that domains that host users who might C7960"/>.</t>
<t indent="3" pn="section-7.4-5">It is therefore critical that domains t
hat 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 &quot;p=reject&quot;. Any such domains wishing to publish &quot;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
&quot;p=none&quot; for at least a month, followed by publishing &quot;p=quaranti ne&quot; 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 &quot;p=reject&quot; <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 indent="0" pn="section-7.4-6">As noted in <xref target="policy-enforc ement-considerations" format="default" sectionFormat="of" derivedContent="Sectio n 5.4"/>, <xref target="mail-receiver" format="default" sectionFormat="of" deriv edContent="Section 3.2.11">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 &quot;p=reject&quot; 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" format="
</t> default" derivedLink="https://rfc-editor.org/rfc/rfc6377#section-5.2" derivedCon
<blockquote><t>It is therefore critical that Mail Receivers <bcp14>MUST NOT</bcp tent="RFC6377"/>.</t>
14> reject <t indent="3" pn="section-7.4-7">It is therefore critical that Mail Rece
incoming messages solely on the basis of a &quot;p=reject&quot; policy by ivers <bcp14>MUST NOT</bcp14> reject
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. &quot;Other knowledge and analysis&quot; 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 &quot;p=quarantine&quot; rather than &quot;p=reject&q mail as if the policy were "p=quarantine" rather than "p=reject".</t>
uot;.</t> <t indent="0" pn="section-7.4-8">Failure to understand and abide by thes
</blockquote><t>Failure to understand and abide by these considerations can caus e considerations can cause
e legitimate, sometimes important, email to be rejected; can cause
legitimate, sometimes important email to be rejected, can cause operational damage to mailing lists throughout the Internet; and
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 indent="0" pn="section-7.4-9">In practice, despite this advice, few M ail 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 indent="0" pn="section-7.4-10">In the ten years since large consumer
t mail systems started publishing p=reject
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 indent="0" pn="section-7.4-11">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" format="default" sectionFormat="of" derivedContent="RFC8617"/>. While work continues, as of this 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" numbered="true" removeInRFC="fals
<section anchor="conformance-requirements"><name>Conformance Requirements for Fu e" toc="include" pn="section-8">
ll DMARC Participation</name> <name slugifiedName="name-conformance-requirements-fo">Conformance Require
<t>This document describes the DMARC mechanism, and allows Domain Owners and Mai ments for Full DMARC Participation</name>
l Receivers <t indent="0" pn="section-8-1">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 indent="0" pn="section-8-2">In order to fully participate in DMARC, Dom
ain Owners:</t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-3
<li><bcp14>MUST</bcp14> send mail so it produces an SPF-Authenticated identifier ">
that has Identifier <li pn="section-8-3.1">
Alignment with the Author Domain</li> <bcp14>MUST</bcp14> send mail so it produces an SPF-Authenticated Iden
<li><bcp14>MUST</bcp14> send mail that has a DKIM Signing Domain that will produ tifier that has Identifier
ce a DKIM-Authenticated Alignment with the Author Domain.</li>
Identifier that has Identifier Alignment with the Author Domain</li> <li pn="section-8-3.2">
<li><bcp14>MUST</bcp14> set up a mailbox to receive aggregate reports and collec <bcp14>MUST</bcp14> send mail that has a DKIM Signing Domain that will
t and analyze those reports</li> produce a DKIM-Authenticated
<li><bcp14>MUST</bcp14> publish a DMARC Policy Record for the Author Domain and Identifier that has Identifier Alignment with the Author Domain.</li>
the Organizational Domain, <li pn="section-8-3.3">
if it differs from the Author Domain</li> <bcp14>MUST</bcp14> set up a mailbox to receive aggregate reports and
<li><bcp14>MUST NOT</bcp14> rely solely on SPF for a DMARC pass if the DMARC pol collect and analyze those reports.</li>
icy for the Author Domain <li pn="section-8-3.4">
is &quot;p=reject&quot;</li> <bcp14>MUST</bcp14> publish a DMARC Policy Record for the Author Domai
</ul> n and the Organizational Domain,
<t>In order to fully participate in DMARC, Mail Receivers</t> if it differs from the Author Domain.</li>
<li pn="section-8-3.5">
<ul spacing="compact"> <bcp14>MUST NOT</bcp14> rely solely on SPF for a DMARC pass if the DMA
<li><bcp14>MUST</bcp14> check for the existence of a DMARC Policy Record for the RC policy for the Author Domain
Author Domain of an inbound is "p=reject".</li>
</ul>
<t indent="0" pn="section-8-4">In order to fully participate in DMARC, Mai
l Receivers:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-5
">
<li pn="section-8-5.1">
<bcp14>MUST</bcp14> check for the existence of a DMARC Policy Record f
or 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 <li pn="section-8-5.2">
sage and preserve the results of those <bcp14>MUST</bcp14> determine if Authenticated Identifiers exist for t
checks for future use in reportging if the DMARC mechanism applies to the messag he message and preserve the results of those
e</li> checks for future use in reporting if the DMARC mechanism applies to the message
<li><bcp14>MUST</bcp14> conduct necessary Identifier Alignmeent checks if the DM .</li>
ARC mechanism applies for the message and <li pn="section-8-5.3">
Authenticated Identifiers exist</li> <bcp14>MUST</bcp14> conduct necessary Identifier Alignment checks if t
<li><bcp14>MUST</bcp14> use the information from the checks for Authenticated Id he DMARC mechanism applies for the message and
entifiers to determine if the DMARC Authenticated Identifiers exist.</li>
validation result is &quot;pass&quot; or &quot;fail&quot; for the message.</li> <li pn="section-8-5.4">
<li><bcp14>MUST</bcp14> support the &quot;mailto:&quot; URI for sending requeste <bcp14>MUST</bcp14> use the information from the checks for Authentica
d reports</li> ted Identifiers to determine if the DMARC
<li><bcp14>SHOULD</bcp14> send aggregate reports on at least a daily basis</li> validation result is "pass" or "fail" for the message.</li>
<li><bcp14>MUST NOT</bcp14> reject messages solely on the basis of a &quot;p=rej <li pn="section-8-5.5">
ect&quot; policy for the Author Domain</li> <bcp14>MUST</bcp14> support the "mailto:" URI for sending requested re
</ul> ports.</li>
</section> <li pn="section-8-5.6">
<bcp14>SHOULD</bcp14> send aggregate reports on at least a daily basis
<section anchor="iana-considerations"><name>IANA Considerations</name> .</li>
<t>This section describes actions to be completed by IANA.</t> <li pn="section-8-5.7">
<bcp14>MUST NOT</bcp14> reject messages solely on the basis of a "p=re
<section anchor="email-authentication-methods-registry-update"><name>Email Authe ject" policy for the Author Domain.</li>
ntication Methods Registry Update</name> </ul>
<t>A registry group called &quot;Email Authentication Parameters&quot; exists, a </section>
nd within it a registry group <section anchor="iana-considerations" numbered="true" removeInRFC="false" to
called &quot;Email Authentication Methods&quot; exists and needs to be updated i c="include" pn="section-9">
n the manner specified in <name slugifiedName="name-iana-considerations">IANA Considerations</name>
this section.</t> <t indent="0" pn="section-9-1">This section describes actions completed by
<t>The properties of an email message to be evaluated by an email authentication IANA.</t>
method are registered <section anchor="email-authentication-methods-registry-update" numbered="t
with IANA in this registry. Entries are assigned only for values that have been rue" removeInRFC="false" toc="include" pn="section-9.1">
documented in a manner that <name slugifiedName="name-email-authentication-method">Email Authenticat
satisfies the terms of Specification Required, per <xref target="RFC8126"></xref ion Methods Registry Update</name>
>. Each registration includes the authentication method; <t indent="0" pn="section-9.1-1">The properties of an email message to b
e evaluated by an email authentication method have been registered by IANA in th
e "Email Authentication Methods" registry within the "Email Authentication Param
eters" registry group.
</t>
<t indent="0" pn="section-9.1-2">Each registration includes the authenti
cation 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 &quot;Email Authentication Property Types&quot; 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 &quot;active&quot; or &quot;deprecated&quot;; 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 indent="0" pn="section-9.1-3">IANA has changed the registration proce
<table align="left"><name>&quot;Email Authentication Methods Registry Update&quo dure from Expert Review to Specification Required <xref target="RFC8126" format=
t; "default" sectionFormat="of" derivedContent="RFC8126"/> and has listed this docu
ment as an additional reference for the registry. IANA has updated the registry
as follows:</t>
<table align="center" pn="table-3">
<name slugifiedName="name-email-authentication-methods">Email Authenti
cation Methods Registry Update
</name> </name>
<thead> <thead>
<tr> <tr>
<th align="left">Method</th> <th align="left" colspan="1" rowspan="1">Method</th>
<th align="left">Defined</th> <th align="left" colspan="1" rowspan="1">Definition</th>
<th align="left">ptype</th> <th align="left" colspan="1" rowspan="1">ptype</th>
<th align="left">Property</th> <th align="left" colspan="1" rowspan="1">Property</th>
<th align="left">Value</th> <th align="left" colspan="1" rowspan="1">Value</th>
<th align="left">Status</th> <th align="left" colspan="1" rowspan="1">Status</th>
<th align="left">Version</th> <th align="left" colspan="1" rowspan="1">Version</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">dmarc</td>
<td align="left">dmarc</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">header</td>
<td align="left">header</td> <td align="left" colspan="1" rowspan="1">from</td>
<td align="left">from</td> <td align="left" colspan="1" rowspan="1">The domain portion of the
<td align="left">The domain portion of the RFC5322.From header field</td> RFC5322.From header field</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">1</td> <td align="left" colspan="1" rowspan="1">1</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">dmarc</td>
<td align="left">dmarc</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">policy</td>
<td align="left">policy</td> <td align="left" colspan="1" rowspan="1">dmarc</td>
<td align="left">dmarc</td> <td align="left" colspan="1" rowspan="1">The evaluated DMARC polic
<td align="left">The evaluated DMARC policy applied/to be applied after policy o y applied / to be applied after policy options have been processed. Must be "non
ptions have been processed. Must be &quot;none&quot;, &quot;quarantine&quot;, or e", "quarantine", or "reject".</td>
&quot;reject&quot;.</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">1</td>
<td align="left">1</td> </tr>
</tr> </tbody>
</tbody> </table>
</table></section> </section>
<section anchor="authentication-results-result-registry" numbered="true" r
<section anchor="authentication-results-result-registry"><name>Email Authenticat emoveInRFC="false" toc="include" pn="section-9.2">
ion Result Names Registry Update</name> <name slugifiedName="name-email-authentication-result">Email Authenticat
<t>Also within the registry group &quot;Email Authentication Parameters&quot; a ion Result Names Registry Update</name>
registry called &quot;Email Authentication <t indent="0" pn="section-9.2-1">Result codes for DMARC are registered w
Result Names&quot; exists and should be updated to reference this section of thi ith IANA in the "Email Authentication
s document.</t> Result Names" registry within "Email Authentication Parameters" registry group.
<t>Result codes for DMARC are registered with IANA in this registry. Entries are </t>
assigned only for values that have been documented in a manner that satisfies th <t indent="0" pn="section-9.2-2"> Each registration includes the auth me
e terms thod; the
of Specification Required, per <xref target="RFC8126"></xref>. Each registration code; the specification that defines the code; and the code's status, which is o
includes the auth method; the ne of "active" or
code; the specification that defines the code; and the code's status, which is o "deprecated". Note that the "Description" field is included here solely for the
ne of &quot;active&quot; or reader's reference and
&quot;deprecated&quot;. The &quot;Description&quot; field is included here solel does not appear in the IANA registry. The designated expert needs to confirm tha
y for the reader's reference, and t the provided
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 indent="0" pn="section-9.2-3">IANA has changed the registration proce
<table align="left"><name>&quot;Email Authentication Result Names Registry Updat dure from Expert Review to Specification Required <xref target="RFC8126" format=
e&quot; "default" sectionFormat="of" derivedContent="RFC8126"/> and has listed this docu
ment as an additional reference for the registry. IANA has updated the registry
as follows, replacing references to <xref target="RFC7489" format="default" sect
ionFormat="of" derivedContent="RFC7489"/> with references to this document:</t>
<table align="center" pn="table-4">
<name slugifiedName="name-email-authentication-result-">Email Authenti
cation Result Names Registry Update
</name> </name>
<thead> <thead>
<tr> <tr>
<th align="left">Auth Method</th> <th align="left" colspan="1" rowspan="1">Auth Method(s)</th>
<th align="left">Code</th> <th align="left" colspan="1" rowspan="1">Code</th>
<th align="left">Specification</th> <th align="left" colspan="1" rowspan="1">Specification</th>
<th align="left">Status</th> <th align="left" colspan="1" rowspan="1">Status</th>
<th align="left">Description</th> <th align="left" colspan="1" rowspan="1">Description</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">dmarc</td>
<td align="left">dmarc</td> <td align="left" colspan="1" rowspan="1">fail</td>
<td align="left">fail</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">A DMARC Policy Record exi
<td align="left">A DMARC Policy Record exists for the Author Domain, but no Auth sts for the Author Domain, but no Authenticated Identifier with Identifier Align
enticated Identifier with Identifier Alignment exists</td> ment exists</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">dmarc</td>
<td align="left">dmarc</td> <td align="left" colspan="1" rowspan="1">none</td>
<td align="left">none</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">No DMARC Policy Record ex
<td align="left">No DMARC Policy Record exists for the Author Domain</td> ists for the Author Domain</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">dmarc</td>
<td align="left">dmarc</td> <td align="left" colspan="1" rowspan="1">pass</td>
<td align="left">pass</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">A DMARC Policy Record exi
<td align="left">A DMARC Policy Record exists for the Author Domain, and an Auth sts for the Author Domain, and an Authenticated Identifier with Identifier Align
enticated Identifier with Identifier Alignment exists</td> ment exists</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">dmarc</td>
<td align="left">dmarc</td> <td align="left" colspan="1" rowspan="1">permerror</td>
<td align="left">permerror</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">An error occurred during
<td align="left">An error occurred during DMARC evaluation that is unrecoverable DMARC evaluation that is unrecoverable, such as the retrieval of an improperly f
, such as the retrieval of an improperly formatted DMARC Policy Record. A later ormatted DMARC Policy Record. A later attempt is unlikely to produce a final res
attempt is unlikely to produce a final result</td> ult</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">dmarc</td>
<td align="left">dmarc</td> <td align="left" colspan="1" rowspan="1">temperror</td>
<td align="left">temperror</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">An error occurred during
<td align="left">An error occurred during DMARC evaluation that is likely transi DMARC evaluation that is likely transient in nature, such as a DNS server being
ent in nature, such as a DNS server being temporarily unreachable. A later attem temporarily unreachable. A later attempt might produce a final result</td>
pt might produce a final result</td> </tr>
</tr> </tbody>
</tbody> </table>
</table></section> </section>
<section anchor="dmarc-tag-registry-update" numbered="true" removeInRFC="f
<section anchor="dmarc-tag-registry-update"><name>DMARC Tags Registry Update</na alse" toc="include" pn="section-9.3">
me> <name slugifiedName="name-dmarc-tags-registry-update">DMARC Tags Registr
<t>A registry group called &quot;Domain-based Message Authentication, y Update</name>
Reporting, and Conformance (DMARC)&quot; exists, and within it, a <t indent="0" pn="section-9.3-1">Names of tags used in DMARC Policy Reco
registry called &quot;DMARC Tags&quot; exists. That registry should be updated rds as part of "tag-value" pairs are registered with IANA in the "DMARC Tags" re
as described in this section.</t> gistry within the "Domain-based Message Authentication, Reporting, and Conforman
<t>Names of tags used in DMARC Policy Records as part of &quot;tag-value&quot; p ce (DMARC)" registry group.
airs are registered with IANA </t>
in this registry. Entries are assigned only for values that have been documented <t indent="0" pn="section-9.3-2">Entries are assigned only for values th
in a manner that at have been documented in a manner that
satisfies the terms of Specification Required, per [RFC8126]. Each registration satisfies the terms of Specification Required, per <xref target="RFC8126" format
includes the tag ="default" sectionFormat="of" derivedContent="RFC8126"/>. Each registration incl
udes 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 &quot;status&quot; column is one of the following:</t> Receivers. The "status" column is one of the following:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-9
<ul spacing="compact"> .3-3">
<li>&quot;active&quot;, meaning the tag is in use in current implementations, an <li pn="section-9.3-3.1">"active", meaning the tag is in use in curren
d its specifications is expected t
to be stable</li> implementations, and its specifications is expected to be stable</li>
<li>&quot;experimental&quot;, meaning the tag is relatively new and may be in us <li pn="section-9.3-3.2">"experimental", meaning the tag is relatively
e in some current implementations new and
but not in others, and its specification is not expected to be stable</li> may be in use in some current implementations but not in others, and its
<li>&quot;historic&quot;, meaning the tag is considered deprecated and is not ex specification is not expected to be stable</li>
pected to be in use in any current <li pn="section-9.3-3.3">"historic", meaning the tag is considered dep
implementation</li> recated
</ul> and is not expected to be in use in any current implementation</li>
<t>To avoid version compatibility issues, tags added to the DMARC </ul>
<t indent="0" pn="section-9.3-4">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 indent="0" pn="section-9.3-5">IANA has listed this document (rather t
<table align="left"><name>&quot;DMARC Tags Registry Updatee&quot; han <xref target="RFC7489" format="default" sectionFormat="of" derivedContent="R
FC7489"/>) as the reference for the registry. IANA has updated the registry as f
ollows, including the addition of the new "t" registration:</t>
<table align="center" pn="table-5">
<name slugifiedName="name-dmarc-tags-registry-update-2">DMARC Tags Reg
istry Update
</name> </name>
<thead> <thead>
<tr> <tr>
<th align="left">Tag Name</th> <th align="left" colspan="1" rowspan="1">Tag Name</th>
<th align="left">Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
<th align="left">Status</th> <th align="left" colspan="1" rowspan="1">Status</th>
<th align="left">Description</th> <th align="left" colspan="1" rowspan="1">Description</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">adkim</td>
<td align="left">adkim</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">DKIM Identifier Alignment
<td align="left">DKIM Identifier Alignment mode</td> mode</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">aspf</td>
<td align="left">aspf</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">SPF Identifier Alignment
<td align="left">SPF Identifier Alignment mode</td> mode</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">fo</td>
<td align="left">fo</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">Failure reporting options
<td align="left">Failure reporting options</td> </td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">np</td>
<td align="left">np</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">Requested Domain Owner As
<td align="left">Requested Domain Owner Assessment Policy for non-existent subdo sessment Policy for non-existent subdomains</td>
mains</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">p</td>
<tr> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">p</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">Requested Domain Owner As
<td align="left">active</td> sessment Policy</td>
<td align="left">Requested Domain Owner Assessment Policy</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">pct</td>
<tr> <td align="left" colspan="1" rowspan="1">
<td align="left">pct</td> <xref target="RFC7489" format="default" sectionFormat="of" deriv
<td align="left"><xref target="RFC7489"></xref></td> edContent="RFC7489"/></td>
<td align="left">historic</td> <td align="left" colspan="1" rowspan="1">historic</td>
<td align="left">Sampling rate</td> <td align="left" colspan="1" rowspan="1">Sampling rate</td>
</tr> </tr>
<tr>
<tr> <td align="left" colspan="1" rowspan="1">psd</td>
<td align="left">psd</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">Indicates whether the DMA
<td align="left">Indicates whether the DMARC Policy Record is published by a Pub RC Policy Record is published by a Public Suffix Domain</td>
lic Suffix Domain</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">rf</td>
<tr> <td align="left" colspan="1" rowspan="1">
<td align="left">rf</td> <xref target="RFC7489" format="default" sectionFormat="of" deriv
<td align="left"><xref target="RFC7489"></xref></td> edContent="RFC7489"/></td>
<td align="left">historic</td> <td align="left" colspan="1" rowspan="1">historic</td>
<td align="left">Failure reporting format(s)</td> <td align="left" colspan="1" rowspan="1">Failure reporting format(
</tr> s)</td>
</tr>
<tr> <tr>
<td align="left">ri</td> <td align="left" colspan="1" rowspan="1">ri</td>
<td align="left"><xref target="RFC7489"></xref></td> <td align="left" colspan="1" rowspan="1">
<td align="left">historic</td> <xref target="RFC7489" format="default" sectionFormat="of" deriv
<td align="left">Aggregate Reporting interval</td> edContent="RFC7489"/></td>
</tr> <td align="left" colspan="1" rowspan="1">historic</td>
<td align="left" colspan="1" rowspan="1">Aggregate Reporting inter
<tr> val</td>
<td align="left">rua</td> </tr>
<td align="left">[this document]</td> <tr>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">rua</td>
<td align="left">Reporting URI(s) for DMARC aggregate feedback reports</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
</tr> <td align="left" colspan="1" rowspan="1">active</td>
<td align="left" colspan="1" rowspan="1">Reporting URI(s) for DMAR
<tr> C aggregate feedback reports</td>
<td align="left">ruf</td> </tr>
<td align="left">[this document]</td> <tr>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">ruf</td>
<td align="left">Reporting URI(s) for message-specific DMARC failure reports</td <td align="left" colspan="1" rowspan="1">RFC 9989</td>
> <td align="left" colspan="1" rowspan="1">active</td>
</tr> <td align="left" colspan="1" rowspan="1">Reporting URI(s) for mess
age-specific DMARC failure reports</td>
<tr> </tr>
<td align="left">sp</td> <tr>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">sp</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">Requested Domain Owner Assessment Policy for subdomains</td> <td align="left" colspan="1" rowspan="1">active</td>
</tr> <td align="left" colspan="1" rowspan="1">Requested Domain Owner As
sessment Policy for subdomains</td>
<tr> </tr>
<td align="left">t</td> <tr>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">t</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">DMARC policy test mode</td> <td align="left" colspan="1" rowspan="1">active</td>
</tr> <td align="left" colspan="1" rowspan="1">DMARC policy test mode</t
d>
<tr> </tr>
<td align="left">v</td> <tr>
<td align="left">[this document]</td> <td align="left" colspan="1" rowspan="1">v</td>
<td align="left">active</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td align="left">DMARC specification version</td> <td align="left" colspan="1" rowspan="1">active</td>
</tr> <td align="left" colspan="1" rowspan="1">DMARC specification versi
</tbody> on</td>
</table></section> </tr>
</tbody>
<section anchor="dmarc-report-formats-registry"><name>DMARC Report Formats Regis </table>
try Update</name> </section>
<t>Also within the registry group &quot;Domain-based Message Authentication, Rep <section anchor="dmarc-report-formats-registry" numbered="true" removeInRF
orting, and C="false" toc="include" pn="section-9.4">
Conformance (DMARC)&quot; a registry called &quot;DMARC Report Formats&quot; exi <name slugifiedName="name-dmarc-report-formats-regist">DMARC Report Form
sts and should be updated ats Registry Update</name>
to reference this document.</t> <t indent="0" pn="section-9.4-1">Names of DMARC failure reporting format
<t>Names of DMARC failure reporting formats are registered with IANA in this reg s are registered with IANA in the "DMARC Report Formats" registry within the "Do
istry. Entries main-based Message Authentication, Reporting, and
Conformance (DMARC)" registry group.</t>
<t indent="0" pn="section-9.4-2">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" format="default" sectionForma t="of" derivedContent="RFC8126"/>. In addition to a reference to a permanent spe cification, 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 &quot;status&quot; column is one of the following:</t> and Mail Receivers. The "status" column is one of the following:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-9
<ul spacing="compact"> .4-3">
<li>&quot;active&quot;, meaning the format is in use in current implementations, <li pn="section-9.4-3.1">"active", meaning the format is in use in cur
and its specifications is expected rent
to be stable</li> implementations, and its specifications is expected to be stable</li>
<li>&quot;experimental&quot;, meaning the format is relatively new and may be in <li pn="section-9.4-3.2">"experimental", meaning the format is relativ
use in some current implementations ely new
but not in others, and its specification is not expected to be stable</li> and may be in use in some current implementations but not in others, and its
<li>&quot;historic&quot;, meaning the format is considered deprecated and is not specification is not expected to be stable</li>
expected to be in use in any current <li pn="section-9.4-3.3">"historic", meaning the format is considered
implementation</li> deprecated
</ul> and is not expected to be in use in any current implementation</li>
<t>The entry to be updated in this registry is as follows:</t> </ul>
<table align="left"><name>&quot;DMARC Report Formats Registry Update&quot; <t indent="0" pn="section-9.4-4">IANA has listed this document (rather t
han <xref target="RFC7489" format="default" sectionFormat="of" derivedContent="R
FC7489"/>) as the reference for the registry. IANA has updated the registry as f
ollows:</t>
<table align="center" pn="table-6">
<name slugifiedName="name-dmarc-report-formats-registr">DMARC Report F
ormats Registry Update
</name> </name>
<thead> <thead>
<tr> <tr>
<th>Format Name</th> <th align="left" colspan="1" rowspan="1">Format Name</th>
<th>Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
<th>Status</th> <th align="left" colspan="1" rowspan="1">Status</th>
<th>Description</th> <th align="left" colspan="1" rowspan="1">Description</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">afrf</td>
<td>afrf</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td>[this document]</td> <td align="left" colspan="1" rowspan="1">active</td>
<td>active</td> <td align="left" colspan="1" rowspan="1">Authentication Failure Re
<td>Authentication Failure Reporting Format (see <xref target="RFC6591"></xref>) porting Format (see <xref target="RFC6591" format="default" sectionFormat="of" d
</td> erivedContent="RFC6591"/>)</td>
</tr> </tr>
</tbody> </tbody>
</table></section> </table>
</section>
<section anchor="underscored-and-globally-scoped-dns-node-names-registry-update" <section anchor="underscored-and-globally-scoped-dns-node-names-registry-u
><name>Underscored and Globally Scoped DNS Node Names Registry Update</name> pdate" numbered="true" removeInRFC="false" toc="include" pn="section-9.5">
<t>A registry group called &quot;Domain Name System (DNS) Parameters&quot; exist <name slugifiedName="name-underscored-and-globally-sc">Underscored and G
s, and within it, a registry called lobally Scoped DNS Node Names Registry Update</name>
&quot;Underscored and Globally Scoped DNS Node Names&quot; exists, and that regi <t indent="0" pn="section-9.5-1">The names of DNS Resource Records (RRs)
stry should be updated to reference beginning with an underscore character that are globally scoped (as per <xref t
this document.</t> arget="RFC8552" format="default" sectionFormat="of" derivedContent="RFC8552"/>)
<t>The names of DNS Resource Records beginning with an underscore character that are registered with IANA in the "Underscored and Globally Scoped DNS Node Names"
are globally registry within the "Domain Name System (DNS) Parameters" registry group.</t>
scoped (as per <xref target="RFC8552"></xref>) are registered with IANA in this <t indent="0" pn="section-9.5-2">In addition to a reference to a permane
registry. In addition to a reference to nt specification, each registration contains the DNS RR type and Node Name.
a permanent specification, each registration contains the DNS Resource Record (R The designated expert needs to confirm that the provided specification adequatel
R) type and Node Name. y describes the Node
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 indent="0" pn="section-9.5-3">IANA has updated the reference for foll
<table align="left"><name>&quot;Underscored and Globally Scoped DNS Node Names R owing entry to point to this document (instead of <xref target="RFC7489" format=
egistry Update&quot; "default" sectionFormat="of" derivedContent="RFC7489"/>):</t>
<table align="center" pn="table-7">
<name slugifiedName="name-underscored-and-globally-sco">Underscored an
d Globally Scoped DNS Node Names Registry Update
</name> </name>
<thead> <thead>
<tr> <tr>
<th>RR Type</th> <th align="left" colspan="1" rowspan="1">RR Type</th>
<th>_NODE NAME</th> <th align="left" colspan="1" rowspan="1">_NODE NAME</th>
<th>Reference</th> <th align="left" colspan="1" rowspan="1">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody>
<tbody> <tr>
<tr> <td align="left" colspan="1" rowspan="1">TXT</td>
<td>TXT</td> <td align="left" colspan="1" rowspan="1">_dmarc</td>
<td>_dmarc</td> <td align="left" colspan="1" rowspan="1">RFC 9989</td>
<td>[this document]</td> </tr>
</tr> </tbody>
</tbody> </table>
</table></section> </section>
</section> </section>
<section anchor="privacy-considerations" numbered="true" removeInRFC="false"
<section anchor="privacy-considerations"><name>Privacy Considerations</name> toc="include" pn="section-10">
<t>This section discusses issues specific to private data that may be <name slugifiedName="name-privacy-considerations">Privacy Considerations</
name>
<t indent="0" pn="section-10-1">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" format="default" sectionFormat="of" derivedContent="RFC99
<xref target="I-D.ietf-dmarc-failure-reporting"></xref> respectively.</t> 90"/> and
<xref target="RFC9991" format="default" sectionFormat="of" derivedContent="RFC99
<section anchor="aggregate-report-considerations"><name>Aggregate Report Conside 91"/>, respectively.</t>
rations</name> <section anchor="aggregate-report-considerations" numbered="true" removeIn
<t>Aggregate reports may, particularly for small organizations, provide some RFC="false" toc="include" pn="section-10.1">
<name slugifiedName="name-aggregate-report-considerat">Aggregate Report
Considerations</name>
<t indent="0" pn="section-10.1-1">Aggregate reports may, particularly fo
r 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 &quot;rua&quot; 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 &quot;rua&quot; requests for multi-organizational PSDs, additi onal <t indent="0" pn="section-10.1-2">In the case of "rua" requests for mult i-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 &quot;rua&quot; tag in their DMARC Policy registrant domains if they include the "rua" tag in their DMARC Policy Record.</
Record.</t> t>
</section> </section>
<section anchor="failure-report-considerations" numbered="true" removeInRF
<section anchor="failure-report-considerations"><name>Failure Report Considerati C="false" toc="include" pn="section-10.2">
ons</name> <name slugifiedName="name-failure-report-consideratio">Failure Report Co
<t>Failure reports do provide insight into email sending patterns, including nsiderations</name>
<t indent="0" pn="section-10.2-1">Failure reports do provide insight int
o 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 indent="0" pn="section-10.2-2">Due to the nature of the email content
Reports, most Mail Receivers refuse to send them out of privacy concerns. Out s that may be shared through failure
of band agreements between Report Consumers and Mail Receivers may be required reports, most Mail Receivers refuse to send them out of privacy concerns.
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 <t indent="0" pn="section-10.2-3">DMARC Policy Records for multi-organiz
clude the &quot;ruf&quot; tag.</t> ational PSDs <bcp14>MUST NOT</bcp14> include the "ruf" tag.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations" numbered="true" removeInRFC="false
<section anchor="security-considerations"><name>Security Considerations</name> " toc="include" pn="section-11">
<t>This section discusses security issues and possible remediations <name slugifiedName="name-security-considerations">Security Considerations
</name>
<t indent="0" pn="section-11-1">This section discusses security issues and
possible remediations
(where available) for DMARC.</t> (where available) for DMARC.</t>
<section anchor="authentication-methods" numbered="true" removeInRFC="fals
<section anchor="authentication-methods"><name>Authentication Methods</name> e" toc="include" pn="section-11.1">
<t>Security considerations from the authentication methods used by DMARC <name slugifiedName="name-authentication-methods">Authentication Methods
</name>
<t indent="0" pn="section-11.1-1">Security considerations from the authe
ntication 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 indent="0" pn="section-11.1-2">Both of the email authentication metho
assurance that an email was transmitted by an MTA which is authorized to ds that underlie DMARC provide some
do so. SPF policies map domain names to sets of authorized MTAs (see <xref targe assurance that an email was transmitted by an MTA that is authorized to
t="RFC7208" sectionFormat="of" section="11.4"></xref>). do so. SPF policies map domain names to sets of authorized MTAs (see <xref targe
t="RFC7208" sectionFormat="of" section="11.4" format="default" derivedLink="http
s://rfc-editor.org/rfc/rfc7208#section-11.4" derivedContent="RFC7208"/>).
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 indent="0" pn="section-11.1-3">Whenever mail is sent, there is a risk
may send mail that will receive a DMARC pass result that was not, in fact, that an overly permissive source
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 indent="0" pn="section-11.1-4">To avoid this risk, one must ensure th
DKIM signatures to the domain's mail or transmit mail which will evaluate at no unauthorized source can add
as SPF pass. If, nonetheless, a Domain Owner wishes to include a DKIM signatures to the domain's mail or transmit mail that will evaluate
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 &quot;?&quot; 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 &quot;?&quot; 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" numbered="true" removeInRFC="f
<section anchor="attacks-on-reporting-uris"><name>Attacks on Reporting URIs</nam alse" toc="include" pn="section-11.2">
e> <name slugifiedName="name-attacks-on-reporting-uris">Attacks on Reportin
<t>URIs published in DNS TXT records are well-understood possible g URIs</name>
targets for attack. Specifications such as <xref target="RFC1035"></xref> and <t indent="0" pn="section-11.2-1">URIs published in DNS TXT records are
<xref target="RFC2142"></xref> either expose or cause the exposure of email addr well-understood possible
esses that targets for an attack. Specifications such as <xref target="RFC1035" format="de
fault" sectionFormat="of" derivedContent="RFC1035"/> and
<xref target="RFC2142" format="default" sectionFormat="of" derivedContent="RFC21
42"/> either expose or cause the exposure of email addresses 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 &quot;www&quot; 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 bare="false" empty="false" indent="3" spacing="normal" pn="section-1
<ul> 1.2-2">
<li><t>high-volume denial-of-service attacks;</t> <li pn="section-11.2-2.1">
</li> <t indent="0" pn="section-11.2-2.1.1">high-volume denial-of-service
<li><t>deliberate construction of malformed reports intended to identify attacks;</t>
or exploit parsing or processing vulnerabilities;</t> </li>
</li> <li pn="section-11.2-2.2">
<li><t>deliberate construction of reports containing false claims for the <t indent="0" pn="section-11.2-2.2.1">deliberate construction of mal
formed reports intended to identify
or exploit parsing or processing vulnerabilities; and</t>
</li>
<li pn="section-11.2-2.3">
<t indent="0" pn="section-11.2-2.3.1">deliberate construction of rep
orts 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" numbered="true" removeInRFC="false" toc="in
<section anchor="dns-security"><name>DNS Security</name> clude" pn="section-11.3">
<t>The DMARC mechanism and its underlying Authentication Mechanisms (SPF and DKI <name slugifiedName="name-dns-security">DNS Security</name>
M) <t indent="0" pn="section-11.3-1">The DMARC mechanism and its underlying
authentication mechanisms (SPF and DKIM)
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 bare="false" empty="false" indent="3" spacing="normal" pn="section-1
<ul> 1.3-2">
<li><t>If they can snoop on DNS traffic, they can get an idea of who is <li pn="section-11.3-2.1">
<t indent="0" pn="section-11.3-2.1.1">If they can snoop on DNS traff
ic, 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 pn="section-11.3-2.2">
<t indent="0" pn="section-11.3-2.2.1">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 pn="section-11.3-2.3">
appear unaligned or vice-versa.</t> <t indent="0" pn="section-11.3-2.3.1">If they can send forged respon
</li> se packets, they can make aligned mail
</ul> appear unaligned or vice versa.</t>
<t>None of these threats are unique to DMARC, and they can be addressed using </li>
a variety of techniques, including, but not limited to:</t> </ul>
<t indent="0" pn="section-11.3-3">None of these threats are unique to DM
<ul> ARC, and they can be addressed using
<li><t>Signing DNS records with Domain Name System Security Extensions (DNSSEC) a variety of techniques including, but not limited to, the following:</t>
<xref target="RFC9364"></xref>, <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1
1.3-4">
<li pn="section-11.3-4.1">
<t indent="0" pn="section-11.3-4.1.1">Signing DNS records with Domai
n Name System Security Extensions (DNSSEC) <xref target="RFC9364" format="defaul
t" sectionFormat="of" derivedContent="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 <li pn="section-11.3-4.2">
t="RFC8484"></xref> can mitigate snooping <t indent="0" pn="section-11.3-4.2.1">DNS over TLS <xref target="RFC
7858" format="default" sectionFormat="of" derivedContent="RFC7858"/> or DNS over
HTTPS <xref target="RFC8484" format="default" sectionFormat="of" derivedContent
="RFC8484"/> can mitigate snooping
and forged responses.</t> and forged responses.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="display-name-attacks" numbered="true" removeInRFC="false"
<section anchor="display-name-attacks"><name>Display Name Attacks</name> toc="include" pn="section-11.4">
<t>An increasingly common attack in messaging abuse is the presentation of false <name slugifiedName="name-display-name-attacks">Display Name Attacks</na
information in the display-name portion of the RFC5322.From header field. me>
<t indent="0" pn="section-11.4-1">An increasingly common attack in messa
ging abuse is the presentation of false
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 indent="0" pn="section-11.4-2">Such attacks, known as display name at
</section> tacks, are out of scope for DMARC.</t>
</section>
<section anchor="denial-of-dmarc-attacks"><name>Denial of DMARC Processing Attac <section anchor="denial-of-dmarc-attacks" numbered="true" removeInRFC="fal
ks</name> se" toc="include" pn="section-11.5">
<t>The declaration in <xref target="extract-author-domain"></xref> and elsewhere <name slugifiedName="name-denial-of-dmarc-processing-">Denial of DMARC P
in this document rocessing Attacks</name>
<t indent="0" pn="section-11.5-1">The declaration in <xref target="extra
ct-author-domain" format="default" sectionFormat="of" derivedContent="Section 5.
3.1"/> and elsewhere in this 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 indent="0" pn="section-11.5-2">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" format="default" sectionFormat="of" derivedContent="R FC5322"/> 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 indent="0" pn="section-11.5-3">The case of a syntactically valid mult i-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" format="default" sectionFormat="of" derivedContent="RFC74 89"/> 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 &quot;large&quot; 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" numbered="true" removeInRFC="f
<section anchor="external-report-addresses"><name>External Reporting Addresses</ alse" toc="include" pn="section-11.6">
name> <name slugifiedName="name-external-reporting-addresse">External Reportin
<t>To avoid abuse by bad actors, reporting addresses generally have to g Addresses</name>
<t indent="0" pn="section-11.6-1">To avoid abuse by bad actors, reportin
g 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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9990#sectio
n-3" derivedContent="RFC9990"/> 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 indent="0" pn="section-11.6-2">The obvious consideration here is an i ncreased 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 indent="0" pn="section-11.6-3">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 &quot;ruf&quot; tag receive more <t indent="0" pn="section-11.6-4">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 &quot;rua&quot; 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 prospect. Deployment of DNSSEC <xref target="RFC9364" format="default" sectionFo
is is a concern.</t> rmat="of" derivedContent="RFC9364"/> is advisable if this is a concern.</t>
</section> </section>
<section anchor="secure-protocols" numbered="true" removeInRFC="false" toc
<section anchor="secure-protocols"><name>Secure Protocols</name> ="include" pn="section-11.7">
<t>This document encourages the use of secure transport mechanisms to <name slugifiedName="name-secure-protocols">Secure Protocols</name>
<t indent="0" pn="section-11.7-1">This document encourages the use of se
cure 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 indent="0" pn="section-11.7-2">In particular, a message that was orig inally 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" numbered="true" removeI
<section anchor="relaxed-alignment-considerations"><name>Relaxed Alignment Consi nRFC="false" toc="include" pn="section-11.8">
derations</name> <name slugifiedName="name-relaxed-alignment-considera">Relaxed Alignment
<t>The DMARC mechanism allows both <eref target="#identifier-alignment-explained Considerations</name>
">DKIM- and SPF-Authenticated Identifiers</eref> <t indent="0" pn="section-11.8-1">The DMARC mechanism allows both <xref
to validate authorized use of an <eref target="#author-domain">Author Domain</er target="identifier-alignment-explained" format="default" sectionFormat="of" deri
ef> on behalf of a <eref target="#domain-owner">Domain Owner</eref>. If malicio vedContent="Section 4.4">DKIM- and SPF-Authenticated Identifiers</xref>
us or unaware users can gain control of the SPF record or DKIM selector to validate authorized use of an <xref target="author-domain" format="default" s
ectionFormat="of" derivedContent="Section 3.2.2">Author Domain</xref> on behalf
of a <xref target="domain-owner" format="default" sectionFormat="of" derivedCont
ent="Section 3.2.7">Domain Owner</xref>. If malicious 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 indent="0" pn="section-11.8-2">A scenario such as this could occur un
der the following conditions:</t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>A DMARC Policy Record exists for the domain &quot;example.com&quot;, such th 1.8-3">
at &quot;example.com&quot; is an Organizational Domain</li> <li pn="section-11.8-3.1">A DMARC Policy Record exists for the domain
<li>An attacker controls DNS for the domain &quot;evil.example.com&quot; and pub "example.com", such that "example.com" is an Organizational Domain.</li>
lishes an SPF record for that domain</li> <li pn="section-11.8-3.2">An attacker controls DNS for the domain "evi
<li>The attacker sends email with RFC5322.From header field containing &quot;foo l.example.com" and publishes an SPF record for that domain.</li>
@example.com&quot; and an SPF-Authenticated Identifier of &quot;evil.example.com <li pn="section-11.8-3.3">The attacker sends email with the RFC5322.Fr
&quot;</li> om header field containing "foo@example.com" and an SPF-Authenticated Identifier
</ul> of "evil.example.com".</li>
<t>Although this email was not authorized by the Domain Owner, it can produce a </ul>
DMARC pass because the SPF-Authenticated Identifier <t indent="0" pn="section-11.8-4">Although this email was not authorized
(&quot;evil.example.com&quot;) has Identifier Alignment with the Author Domain ( by the Domain Owner, it can produce a DMARC pass because the SPF-Authenticated
&quot;example.com&quot;).</t> Identifier
<t>The Organizational Domain Owner should be careful not to delegate control of ("evil.example.com") has Identifier Alignment with the Author Domain ("example.c
subdomains if this is an om").</t>
issue, and consider using the <eref target="#strict-alignment">Strict Alignment< <t indent="0" pn="section-11.8-5">The Organizational Domain Owner should
/eref> option if appropriate.</t> be careful not to delegate control of subdomains if this is an
<t>DMARC evaluation for relaxed alignment is also highly sensitive to errors in issue and consider using the <xref target="strict-alignment" format="default" se
ctionFormat="of" derivedContent="Section 3.2.10.2">strict alignment</xref> optio
n if appropriate.</t>
<t indent="0" pn="section-11.8-6">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" format="default" sectionFormat="of" derivedCo ntent="Section 3.2.6">DMARC Policy Record</xref>. If an incorrectly selected Org anizational
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" format="default
rent methods for determining " sectionFormat="of" derivedContent="RFC7489"/> and current methods for determin
the organizational domain, the latter described in <xref target="identifier-alig ing
nment-evaluation"></xref>.</t> the Organizational Domain; the latter is described in <xref target="identifier-a
<t>The following example illustrates this possibility:</t> lignment-evaluation" format="default" sectionFormat="of" derivedContent="Section
4.10.2"/>.</t>
<ul spacing="compact"> <t indent="0" pn="section-11.8-7">The following example illustrates this
<li>Mail is sent with an Author Domain of &quot;a.mail.example.com&quot; and Aut possibility:</t>
henticated Identifiers of &quot;mail.example.com&quot;</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
<li>There is no DMARC Policy Record published at &quot;_dmarc.a.mail.example.com 1.8-8">
&quot;</li> <li pn="section-11.8-8.1">Mail is sent with an Author Domain of "a.mai
<li>There is one published at &quot;_dmarc.mail.example.com&quot; and this is in l.example.com" and Authenticated Identifiers of "mail.example.com".</li>
tended to be the Organizational Domain for this message</li> <li pn="section-11.8-8.2">There is no DMARC Policy Record published at
<li>There is also a DMARC Policy Record published at &quot;_dmarc.example.com&qu "_dmarc.a.mail.example.com".</li>
ot;, with default alignment (relaxed)</li> <li pn="section-11.8-8.3">There is one published at "_dmarc.mail.examp
<li>An attacker is able to send mail with the Author Domain of &quot;evil.exampl le.com" and this is intended to be the Organizational Domain for this message.</
e.com&quot; and an Authenticated Identifier of &quot;mail.example.com&quot;</li> li>
</ul> <li pn="section-11.8-8.4">There is also a DMARC Policy Record publishe
<t>In this scenario, if a Mail Receiver incorrectly determines the Organizationa d at "_dmarc.example.com", with default alignment (relaxed).</li>
l Domain to be &quot;example.com&quot;, <li pn="section-11.8-8.5">An attacker is able to send mail with the Au
thor Domain of "evil.example.com" and an Authenticated Identifier of "mail.examp
le.com".</li>
</ul>
<t indent="0" pn="section-11.8-9">In this scenario, if a Mail Receiver i
ncorrectly determines the Organizational 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 indent="0" pn="section-11.8-10">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 indent="0" pn="section-11.8-11">For cases where strict alignment is n
ted by the Domain ot appropriate, this issue can be mitigated 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" format="default" sectionFormat="of" derivedContent="Section 3.2.15">
above the Organizational Domain in the DNS tree and (for legacy <xref target="RF PSDs</xref>
C7489"></xref> checking that above the Organizational Domain in the DNS tree (and for legacy <xref target="RF
C7489" format="default" sectionFormat="of" derivedContent="RFC7489"/>, 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 &quot;psd=y&quot; tag, Organizational Domain owners can add &quo t;psd=n&quot; 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> <back>
<references pn="section-12">
<back> <name slugifiedName="name-references">References</name>
<references><name>References</name> <references pn="section-12.1">
<references><name>Normative References</name> <name slugifiedName="name-normative-references">Normative References</na
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dma me>
rc-aggregate-reporting.xml"/> <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dma 035" quoteTitle="true" derivedAnchor="RFC1035">
rc-failure-reporting.xml"/> <front>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml" <title>Domain names - implementation and specification</title>
/> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" "/>
/> <date month="November" year="1987"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml" <abstract>
/> <t indent="0">This RFC is the revised specification of the protoco
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4343.xml" l and format used in the implementation of the Domain Name System. It obsoletes
/> RFC-883. This memo documents the details of the domain name client - server comm
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml" unication.</t>
/> </abstract>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml" </front>
/> <seriesInfo name="STD" value="13"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml" <seriesInfo name="RFC" value="1035"/>
/> <seriesInfo name="DOI" value="10.17487/RFC1035"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml" </reference>
/> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml" 119" quoteTitle="true" derivedAnchor="RFC2119">
/> <front>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6377.xml" <title>Key words for use in RFCs to Indicate Requirement Levels</tit
/> le>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6591.xml" <author fullname="S. Bradner" initials="S." surname="Bradner"/>
/> <date month="March" year="1997"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6651.xml" <abstract>
/> <t indent="0">In many standards track documents several words are
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6652.xml" used to signify the requirements in the specification. These words are often cap
/> italized. This document defines these words as they should be interpreted in IET
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7208.xml" F documents. This document specifies an Internet Best Current Practices for the
/> Internet Community, and requests discussion and suggestions for improvements.</t
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml" >
/> </abstract>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8601.xml" </front>
/> <seriesInfo name="BCP" value="14"/>
</references> <seriesInfo name="RFC" value="2119"/>
<references><name>Informative References</name> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
<reference anchor="M3AUTH" target="https://www.m3aawg.org/sites/default/files/m3 </reference>
aawg-email-authentication-recommended-best-practices-09-2020.pdf"> <reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3
<front> 986" quoteTitle="true" derivedAnchor="RFC3986">
<title>M3AAWG Email Authentication Recommended Best Practices</title> <front>
<author></author> <title>Uniform Resource Identifier (URI): Generic Syntax</title>
</front> <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
</reference> "/>
<reference anchor="M3SPF" target="https://www.m3aawg.org/Managing-SPF-Records"> <author fullname="R. Fielding" initials="R." surname="Fielding"/>
<front> <author fullname="L. Masinter" initials="L." surname="Masinter"/>
<title>M3AAWG Best Practices for Managing SPF Records</title> <date month="January" year="2005"/>
<author></author> <abstract>
</front> <t indent="0">A Uniform Resource Identifier (URI) is a compact seq
</reference> uence of characters that identifies an abstract or physical resource. This speci
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2142.xml" fication defines the generic URI syntax and a process for resolving URI referenc
/> es that might be in relative form, along with guidelines and security considerat
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml" ions for the use of URIs on the Internet. The URI syntax defines a grammar that
/> is a superset of all valid URIs, allowing an implementation to parse the common
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3464.xml" components of a URI reference without knowing the scheme-specific requirements o
/> f every possible identifier. This specification does not define a generative gra
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4870.xml" mmar for URIs; that task is performed by the individual specifications of each U
/> RI scheme. [STANDARDS-TRACK]</t>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5598.xml" </abstract>
/> </front>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml" <seriesInfo name="STD" value="66"/>
/> <seriesInfo name="RFC" value="3986"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml" <seriesInfo name="DOI" value="10.17487/RFC3986"/>
/> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7960.xml" <reference anchor="RFC4343" target="https://www.rfc-editor.org/info/rfc4
/> 343" quoteTitle="true" derivedAnchor="RFC4343">
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8020.xml" <front>
/> <title>Domain Name System (DNS) Case Insensitivity Clarification</ti
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml" tle>
/> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" rd"/>
/> <date month="January" year="2006"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml" <abstract>
/> <t indent="0">Domain Name System (DNS) names are "case insensitive
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml" ". This document explains exactly what that means and provides a clear specifica
/> tion of the rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDA
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.xml" RDS-TRACK]</t>
/> </abstract>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8617.xml" </front>
/> <seriesInfo name="RFC" value="4343"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9091.xml" <seriesInfo name="DOI" value="10.17487/RFC4343"/>
/> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml" <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5
/> 234" quoteTitle="true" derivedAnchor="RFC5234">
</references> <front>
</references> <title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
<section anchor="technology-considerations"><name>Technology Considerations</nam rocker"/>
e> <author fullname="P. Overell" initials="P." surname="Overell"/>
<t>This section documents some design decisions made in the <date month="January" year="2008"/>
<abstract>
<t indent="0">Internet technical specifications often need to defi
ne a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF)
, called Augmented BNF (ABNF), has been popular among many Internet specificatio
ns. The current specification documents ABNF. It balances compactness and simpli
city with reasonable representational power. The differences between standard BN
F and ABNF involve naming rules, repetition, alternatives, order-independence, a
nd value ranges. This specification also supplies additional rule definitions an
d encoding for a core lexical analyzer of the type common to several Internet sp
ecifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC5321" target="https://www.rfc-editor.org/info/rfc5
321" quoteTitle="true" derivedAnchor="RFC5321">
<front>
<title>Simple Mail Transfer Protocol</title>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<date month="October" year="2008"/>
<abstract>
<t indent="0">This document is a specification of the basic protoc
ol for Internet electronic mail transport. It consolidates, updates, and clarifi
es several previous documents, making all or parts of most of them obsolete. It
covers the SMTP extension mechanisms and best practices for the contemporary Int
ernet, but does not provide details about particular extensions. Although SMTP w
as designed as a mail transport and delivery protocol, this specification also c
ontains information that is important to its use as a "mail submission" protocol
for "split-UA" (User Agent) mail reading systems and mobile environments. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5321"/>
<seriesInfo name="DOI" value="10.17487/RFC5321"/>
</reference>
<reference anchor="RFC5322" target="https://www.rfc-editor.org/info/rfc5
322" quoteTitle="true" derivedAnchor="RFC5322">
<front>
<title>Internet Message Format</title>
<author fullname="P. Resnick" initials="P." role="editor" surname="R
esnick"/>
<date month="October" year="2008"/>
<abstract>
<t indent="0">This document specifies the Internet Message Format
(IMF), a syntax for text messages that are sent between computer users, within t
he framework of "electronic mail" messages. This specification is a revision of
Request For Comments (RFC) 2822, which itself superseded Request For Comments (R
FC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it t
o reflect current practice and incorporating incremental changes that were speci
fied in other RFCs. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5322"/>
<seriesInfo name="DOI" value="10.17487/RFC5322"/>
</reference>
<reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5
890" quoteTitle="true" derivedAnchor="RFC5890">
<front>
<title>Internationalized Domain Names for Applications (IDNA): Defin
itions and Document Framework</title>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<date month="August" year="2010"/>
<abstract>
<t indent="0">This document is one of a collection that, together,
describe the protocol and usage context for a revision of Internationalized Dom
ain Names for Applications (IDNA), superseding the earlier version. It describes
the document collection and provides definitions and other material that are co
mmon to the set. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5890"/>
<seriesInfo name="DOI" value="10.17487/RFC5890"/>
</reference>
<reference anchor="RFC6376" target="https://www.rfc-editor.org/info/rfc6
376" quoteTitle="true" derivedAnchor="RFC6376">
<front>
<title>DomainKeys Identified Mail (DKIM) Signatures</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker"/>
<author fullname="T. Hansen" initials="T." role="editor" surname="Ha
nsen"/>
<author fullname="M. Kucherawy" initials="M." role="editor" surname=
"Kucherawy"/>
<date month="September" year="2011"/>
<abstract>
<t indent="0">DomainKeys Identified Mail (DKIM) permits a person,
role, or organization that owns the signing domain to claim some responsibility
for a message by associating the domain with the message. This can be an author'
s organization, an operational relay, or one of their agents. DKIM separates the
question of the identity of the Signer of the message from the purported author
of the message. Assertion of responsibility is validated through a cryptographi
c signature and by querying the Signer's domain directly to retrieve the appropr
iate public key. Message transit from author to recipient is through relays that
typically make no substantive change to the message content and thus preserve t
he DKIM signature.</t>
<t indent="0">This memo obsoletes RFC 4871 and RFC 5672. [STANDARD
S-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="76"/>
<seriesInfo name="RFC" value="6376"/>
<seriesInfo name="DOI" value="10.17487/RFC6376"/>
</reference>
<reference anchor="RFC6377" target="https://www.rfc-editor.org/info/rfc6
377" quoteTitle="true" derivedAnchor="RFC6377">
<front>
<title>DomainKeys Identified Mail (DKIM) and Mailing Lists</title>
<author fullname="M. Kucherawy" initials="M." surname="Kucherawy"/>
<date month="September" year="2011"/>
<abstract>
<t indent="0">DomainKeys Identified Mail (DKIM) allows an ADminist
rative Management Domain (ADMD) to assume some responsibility for a message. Bas
ed on deployment experience with DKIM, this document provides guidance for the u
se of DKIM with scenarios that include Mailing List Managers (MLMs). This memo d
ocuments an Internet Best Current Practice.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="167"/>
<seriesInfo name="RFC" value="6377"/>
<seriesInfo name="DOI" value="10.17487/RFC6377"/>
</reference>
<reference anchor="RFC6591" target="https://www.rfc-editor.org/info/rfc6
591" quoteTitle="true" derivedAnchor="RFC6591">
<front>
<title>Authentication Failure Reporting Using the Abuse Reporting Fo
rmat</title>
<author fullname="H. Fontana" initials="H." surname="Fontana"/>
<date month="April" year="2012"/>
<abstract>
<t indent="0">This memo registers an extension report type for the
Abuse Reporting Format (ARF), affecting multiple registries, for use in generat
ing receipt-time reports about messages that fail one or more email message auth
entication checks. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6591"/>
<seriesInfo name="DOI" value="10.17487/RFC6591"/>
</reference>
<reference anchor="RFC6651" target="https://www.rfc-editor.org/info/rfc6
651" quoteTitle="true" derivedAnchor="RFC6651">
<front>
<title>Extensions to DomainKeys Identified Mail (DKIM) for Failure R
eporting</title>
<author fullname="M. Kucherawy" initials="M." surname="Kucherawy"/>
<date month="June" year="2012"/>
<abstract>
<t indent="0">This document presents extensions to the DomainKeys
Identified Mail (DKIM) specification to allow for detailed reporting of message
authentication failures in an on-demand fashion. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6651"/>
<seriesInfo name="DOI" value="10.17487/RFC6651"/>
</reference>
<reference anchor="RFC6652" target="https://www.rfc-editor.org/info/rfc6
652" quoteTitle="true" derivedAnchor="RFC6652">
<front>
<title>Sender Policy Framework (SPF) Authentication Failure Reportin
g Using the Abuse Reporting Format</title>
<author fullname="S. Kitterman" initials="S." surname="Kitterman"/>
<date month="June" year="2012"/>
<abstract>
<t indent="0">This memo presents extensions to the Abuse Reporting
Format (ARF) and Sender Policy Framework (SPF) specifications to allow for deta
iled reporting of message authentication failures in an on-demand fashion.</t>
<t indent="0">This memo updates RFC 4408 by providing an IANA regi
stry for SPF modifiers. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6652"/>
<seriesInfo name="DOI" value="10.17487/RFC6652"/>
</reference>
<reference anchor="RFC7208" target="https://www.rfc-editor.org/info/rfc7
208" quoteTitle="true" derivedAnchor="RFC7208">
<front>
<title>Sender Policy Framework (SPF) for Authorizing Use of Domains
in Email, Version 1</title>
<author fullname="S. Kitterman" initials="S." surname="Kitterman"/>
<date month="April" year="2014"/>
<abstract>
<t indent="0">Email on the Internet can be forged in a number of w
ays. In particular, existing protocols place no restriction on what a sending ho
st can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/
EHLO commands. This document describes version 1 of the Sender Policy Framework
(SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly
authorize the hosts that are allowed to use their domain names, and a receiving
host can check such authorization.</t>
<t indent="0">This document obsoletes RFC 4408.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7208"/>
<seriesInfo name="DOI" value="10.17487/RFC7208"/>
</reference>
<reference anchor="RFC7405" target="https://www.rfc-editor.org/info/rfc7
405" quoteTitle="true" derivedAnchor="RFC7405">
<front>
<title>Case-Sensitive String Support in ABNF</title>
<author fullname="P. Kyzivat" initials="P." surname="Kyzivat"/>
<date month="December" year="2014"/>
<abstract>
<t indent="0">This document extends the base definition of ABNF (A
ugmented Backus-Naur Form) to include a way to specify US-ASCII string literals
that are matched in a case-sensitive manner.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7405"/>
<seriesInfo name="DOI" value="10.17487/RFC7405"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by clari
fying that only UPPERCASE usage of the key words have the defined special meanin
gs.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8601" target="https://www.rfc-editor.org/info/rfc8
601" quoteTitle="true" derivedAnchor="RFC8601">
<front>
<title>Message Header Field for Indicating Message Authentication St
atus</title>
<author fullname="M. Kucherawy" initials="M." surname="Kucherawy"/>
<date month="May" year="2019"/>
<abstract>
<t indent="0">This document specifies a message header field calle
d "Authentication-Results" for use with electronic mail messages to indicate the
results of message authentication efforts. Any receiver-side software, such as
mail filters or Mail User Agents (MUAs), can use this header field to relay that
information in a convenient and meaningful way to users or to make sorting and
filtering decisions.</t>
<t indent="0">This document obsoletes RFC 7601.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8601"/>
<seriesInfo name="DOI" value="10.17487/RFC8601"/>
</reference>
<reference anchor="RFC9990" target="https://www.rfc-editor.org/info/rfc9
990" quoteTitle="true" derivedAnchor="RFC9990">
<front>
<title>Domain-Based Message Authentication, Reporting, and Conforman
ce (DMARC) Aggregate Reporting</title>
<author fullname="Alex Brotman" initials="A." surname="Brotman" role
="editor">
<organization showOnFrontPage="true">Comcast, Inc.</organization>
</author>
<date month="May" year="2026"/>
</front>
<seriesInfo name="RFC" value="9990"/>
<seriesInfo name="DOI" value="10.17487/RFC9990"/>
</reference>
<reference anchor="RFC9991" target="https://www.rfc-editor.org/info/rfc9
991" quoteTitle="true" derivedAnchor="RFC9991">
<front>
<title>Domain-Based Message Authentication, Reporting, and Conforman
ce (DMARC) Failure Reporting</title>
<author fullname="Steven M. Jones" initials="S." surname="Jones" rol
e="editor">
<organization showOnFrontPage="true">DMARC.org</organization>
</author>
<author fullname="Alessandro Vesely" initials="A." surname="Vesely"
role="editor">
<organization showOnFrontPage="true">Tana</organization>
</author>
<date month="May" year="2026"/>
</front>
<seriesInfo name="RFC" value="9991"/>
<seriesInfo name="DOI" value="10.17487/RFC9991"/>
</reference>
</references>
<references pn="section-12.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="M3AUTH" target="https://www.m3aawg.org/sites/default/
files/doc_files/m3aawg-email-authentication-recommended-best-practices-09-2020.p
df" quoteTitle="true" derivedAnchor="M3AUTH">
<front>
<title>M3AAWG Email Authentication Recommended Best Practices</title
>
<author>
<organization showOnFrontPage="true">Messaging Malware Mobile Anti
-Abuse Working Group (M3AAWG)</organization>
</author>
</front>
</reference>
<reference anchor="M3SPF" target="https://www.m3aawg.org/sites/default/f
iles/doc_files/m3aawg_managing-spf_records-2017-08.pdf" quoteTitle="true" derive
dAnchor="M3SPF">
<front>
<title>M3AAWG Best Practices for Managing SPF Records</title>
<author>
<organization showOnFrontPage="true">Messaging Malware Mobile Anti
-Abuse Working Group (M3AAWG)</organization>
</author>
</front>
</reference>
<reference anchor="RFC2142" target="https://www.rfc-editor.org/info/rfc2
142" quoteTitle="true" derivedAnchor="RFC2142">
<front>
<title>Mailbox Names for Common Services, Roles and Functions</title
>
<author fullname="D. Crocker" initials="D." surname="Crocker"/>
<date month="May" year="1997"/>
<abstract>
<t indent="0">This specification enumerates and describes Internet
mail addresses (mailbox name @ host reference) to be used when contacting perso
nnel at an organization. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2142"/>
<seriesInfo name="DOI" value="10.17487/RFC2142"/>
</reference>
<reference anchor="RFC2308" target="https://www.rfc-editor.org/info/rfc2
308" quoteTitle="true" derivedAnchor="RFC2308">
<front>
<title>Negative Caching of DNS Queries (DNS NCACHE)</title>
<author fullname="M. Andrews" initials="M." surname="Andrews"/>
<date month="March" year="1998"/>
<abstract>
<t indent="0">RFC1034 provided a description of how to cache negat
ive responses. It however had a fundamental flaw in that it did not allow a name
server to hand out those cached responses to other resolvers, thereby greatly r
educing the effect of the caching. This document addresses issues raise in the l
ight of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2308"/>
<seriesInfo name="DOI" value="10.17487/RFC2308"/>
</reference>
<reference anchor="RFC3464" target="https://www.rfc-editor.org/info/rfc3
464" quoteTitle="true" derivedAnchor="RFC3464">
<front>
<title>An Extensible Message Format for Delivery Status Notification
s</title>
<author fullname="K. Moore" initials="K." surname="Moore"/>
<author fullname="G. Vaudreuil" initials="G." surname="Vaudreuil"/>
<date month="January" year="2003"/>
<abstract>
<t indent="0">This memo defines a Multipurpose Internet Mail Exten
sions (MIME) content-type that may be used by a message transfer agent (MTA) or
electronic mail gateway to report the result of an attempt to deliver a message
to one or more recipients. This content-type is intended as a machine-processabl
e replacement for the various types of delivery status notifications currently u
sed in Internet electronic mail. Because many messages are sent between the Inte
rnet and other messaging systems (such as X.400 or the so-called "Local Area Net
work (LAN)-based" systems), the Delivery Status Notification (DSN) protocol is d
esigned to be useful in a multi-protocol messaging environment. To this end, the
protocol described in this memo provides for the carriage of "foreign" addresse
s and error codes, in addition to those normally used in Internet mail. Addition
al attributes may also be defined to support "tunneling" of foreign notification
s through Internet mail. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3464"/>
<seriesInfo name="DOI" value="10.17487/RFC3464"/>
</reference>
<reference anchor="RFC4870" target="https://www.rfc-editor.org/info/rfc4
870" quoteTitle="true" derivedAnchor="RFC4870">
<front>
<title>Domain-Based Email Authentication Using Public Keys Advertise
d in the DNS (DomainKeys)</title>
<author fullname="M. Delany" initials="M." surname="Delany"/>
<date month="May" year="2007"/>
<abstract>
<t indent="0">"DomainKeys" creates a domain-level authentication f
ramework for email by using public key technology and the DNS to prove the prove
nance and contents of an email.</t>
<t indent="0">This document defines a framework for digitally sign
ing email on a per-domain basis. The ultimate goal of this framework is to unequ
ivocally prove and protect identity while retaining the semantics of Internet em
ail as it is known today.</t>
<t indent="0">Proof and protection of email identity may assist in
the global control of "spam" and "phishing". This memo defines a Historic Docum
ent for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4870"/>
<seriesInfo name="DOI" value="10.17487/RFC4870"/>
</reference>
<reference anchor="RFC5598" target="https://www.rfc-editor.org/info/rfc5
598" quoteTitle="true" derivedAnchor="RFC5598">
<front>
<title>Internet Mail Architecture</title>
<author fullname="D. Crocker" initials="D." surname="Crocker"/>
<date month="July" year="2009"/>
<abstract>
<t indent="0">Over its thirty-five-year history, Internet Mail has
changed significantly in scale and complexity, as it has become a global infras
tructure service. These changes have been evolutionary, rather than revolutionar
y, reflecting a strong desire to preserve both its installed base and its useful
ness. To collaborate productively on this large and complex system, all particip
ants need to work from a common view of it and use a common language to describe
its components and the interactions among them. But the many differences in per
spective currently make it difficult to know exactly what another participant me
ans. To serve as the necessary common frame of reference, this document describe
s the enhanced Internet Mail architecture, reflecting the current service. This
memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5598"/>
<seriesInfo name="DOI" value="10.17487/RFC5598"/>
</reference>
<reference anchor="RFC7489" target="https://www.rfc-editor.org/info/rfc7
489" quoteTitle="true" derivedAnchor="RFC7489">
<front>
<title>Domain-based Message Authentication, Reporting, and Conforman
ce (DMARC)</title>
<author fullname="M. Kucherawy" initials="M." role="editor" surname=
"Kucherawy"/>
<author fullname="E. Zwicky" initials="E." role="editor" surname="Zw
icky"/>
<date month="March" year="2015"/>
<abstract>
<t indent="0">Domain-based Message Authentication, Reporting, and
Conformance (DMARC) is a scalable mechanism by which a mail-originating organiza
tion can express domain-level policies and preferences for message validation, d
isposition, and reporting, that a mail-receiving organization can use to improve
mail handling.</t>
<t indent="0">Originators of Internet Mail need to be able to asso
ciate reliable and authenticated domain identifiers with messages, communicate p
olicies about messages that use those identifiers, and report about mail using t
hose identifiers. These abilities have several benefits: Receivers can provide f
eedback to Domain Owners about the use of their domains; this feedback can provi
de valuable insight about the management of internal operations and the presence
of external domain name abuse.</t>
<t indent="0">DMARC does not produce or encourage elevated deliver
y privilege of authenticated email. DMARC is a mechanism for policy distribution
that enables increasingly strict handling of messages that fail authentication
checks, ranging from no action, through altered delivery, up to message rejectio
n.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7489"/>
<seriesInfo name="DOI" value="10.17487/RFC7489"/>
</reference>
<reference anchor="RFC7858" target="https://www.rfc-editor.org/info/rfc7
858" quoteTitle="true" derivedAnchor="RFC7858">
<front>
<title>Specification for DNS over Transport Layer Security (TLS)</ti
tle>
<author fullname="Z. Hu" initials="Z." surname="Hu"/>
<author fullname="L. Zhu" initials="L." surname="Zhu"/>
<author fullname="J. Heidemann" initials="J." surname="Heidemann"/>
<author fullname="A. Mankin" initials="A." surname="Mankin"/>
<author fullname="D. Wessels" initials="D." surname="Wessels"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="May" year="2016"/>
<abstract>
<t indent="0">This document describes the use of Transport Layer S
ecurity (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates
opportunities for eavesdropping and on-path tampering with DNS queries in the ne
twork, such as discussed in RFC 7626. In addition, this document specifies two u
sage profiles for DNS over TLS and provides advice on performance considerations
to minimize overhead from using TCP and TLS with DNS.</t>
<t indent="0">This document focuses on securing stub-to-recursive
traffic, as per the charter of the DPRIVE Working Group. It does not prevent fut
ure applications of the protocol to recursive-to-authoritative traffic.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7858"/>
<seriesInfo name="DOI" value="10.17487/RFC7858"/>
</reference>
<reference anchor="RFC7960" target="https://www.rfc-editor.org/info/rfc7
960" quoteTitle="true" derivedAnchor="RFC7960">
<front>
<title>Interoperability Issues between Domain-based Message Authenti
cation, Reporting, and Conformance (DMARC) and Indirect Email Flows</title>
<author fullname="F. Martin" initials="F." role="editor" surname="Ma
rtin"/>
<author fullname="E. Lear" initials="E." role="editor" surname="Lear
"/>
<author fullname="T. Draegen" initials="T." role="editor" surname="D
raegen"/>
<author fullname="E. Zwicky" initials="E." role="editor" surname="Zw
icky"/>
<author fullname="K. Andersen" initials="K." role="editor" surname="
Andersen"/>
<date month="September" year="2016"/>
<abstract>
<t indent="0">Domain-based Message Authentication, Reporting, and
Conformance (DMARC) introduces a mechanism for expressing domain-level policies
and preferences for email message validation, disposition, and reporting. Howeve
r, the DMARC mechanism enables potentially disruptive interoperability issues wh
en messages do not flow directly from the author's administrative domain to the
final Recipients. Collectively, these email flows are referred to as "indirect e
mail flows". This document describes these interoperability issues and presents
possible methods for addressing them.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7960"/>
<seriesInfo name="DOI" value="10.17487/RFC7960"/>
</reference>
<reference anchor="RFC8020" target="https://www.rfc-editor.org/info/rfc8
020" quoteTitle="true" derivedAnchor="RFC8020">
<front>
<title>NXDOMAIN: There Really Is Nothing Underneath</title>
<author fullname="S. Bortzmeyer" initials="S." surname="Bortzmeyer"/
>
<author fullname="S. Huque" initials="S." surname="Huque"/>
<date month="November" year="2016"/>
<abstract>
<t indent="0">This document states clearly that when a DNS resolve
r receives a response with a response code of NXDOMAIN, it means that the domain
name which is thus denied AND ALL THE NAMES UNDER IT do not exist.</t>
<t indent="0">This document clarifies RFC 1034 and modifies a port
ion of RFC 2308: it updates both of them.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8020"/>
<seriesInfo name="DOI" value="10.17487/RFC8020"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" quoteTitle="true" derivedAnchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t indent="0">Many protocols make use of points of extensibility t
hat use constants to identify various protocol parameters. To ensure that the va
lues in these fields do not have conflicting uses and to promote interoperabilit
y, their allocations are often coordinated by a central record keeper. For IETF
protocols, that role is filled by the Internet Assigned Numbers Authority (IANA)
.</t>
<t indent="0">To make assignments in a given registry prudently, g
uidance describing the conditions under which new values should be assigned, as
well as when and how modifications to existing values can be made, is needed. Th
is document defines a framework for the documentation of these guidelines by spe
cification authors, in order to assure that the provided guidance for the IANA C
onsiderations is clear and addresses the various issues that are likely in the o
peration of a registry.</t>
<t indent="0">This is the third edition of this document; it obsol
etes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8
484" quoteTitle="true" derivedAnchor="RFC8484">
<front>
<title>DNS Queries over HTTPS (DoH)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="P. McManus" initials="P." surname="McManus"/>
<date month="October" year="2018"/>
<abstract>
<t indent="0">This document defines a protocol for sending DNS que
ries and getting DNS responses over HTTPS. Each DNS query-response pair is mappe
d into an HTTP exchange.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8484"/>
<seriesInfo name="DOI" value="10.17487/RFC8484"/>
</reference>
<reference anchor="RFC8551" target="https://www.rfc-editor.org/info/rfc8
551" quoteTitle="true" derivedAnchor="RFC8551">
<front>
<title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version
4.0 Message Specification</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<author fullname="B. Ramsdell" initials="B." surname="Ramsdell"/>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<date month="April" year="2019"/>
<abstract>
<t indent="0">This document defines Secure/Multipurpose Internet M
ail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send an
d receive secure MIME data. Digital signatures provide authentication, message i
ntegrity, and non-repudiation with proof of origin. Encryption provides data con
fidentiality. Compression can be used to reduce data size. This document obsolet
es RFC 5751.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8551"/>
<seriesInfo name="DOI" value="10.17487/RFC8551"/>
</reference>
<reference anchor="RFC8552" target="https://www.rfc-editor.org/info/rfc8
552" quoteTitle="true" derivedAnchor="RFC8552">
<front>
<title>Scoped Interpretation of DNS Resource Records through "Unders
cored" Naming of Attribute Leaves</title>
<author fullname="D. Crocker" initials="D." surname="Crocker"/>
<date month="March" year="2019"/>
<abstract>
<t indent="0">Formally, any DNS Resource Record (RR) may occur und
er any domain name. However, some services use an operational convention for def
ining specific interpretations of an RRset by locating the records in a DNS bran
ch under the parent domain to which the RRset actually applies. The top of this
subordinate branch is defined by a naming convention that uses a reserved node n
ame, which begins with the underscore character (e.g., "_name"). The underscored
naming construct defines a semantic scope for DNS record types that are associa
ted with the parent domain above the underscored branch. This specification expl
ores the nature of this DNS usage and defines the "Underscored and Globally Scop
ed DNS Node Names" registry with IANA. The purpose of this registry is to avoid
collisions resulting from the use of the same underscored name for different ser
vices.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="222"/>
<seriesInfo name="RFC" value="8552"/>
<seriesInfo name="DOI" value="10.17487/RFC8552"/>
</reference>
<reference anchor="RFC8617" target="https://www.rfc-editor.org/info/rfc8
617" quoteTitle="true" derivedAnchor="RFC8617">
<front>
<title>The Authenticated Received Chain (ARC) Protocol</title>
<author fullname="K. Andersen" initials="K." surname="Andersen"/>
<author fullname="B. Long" initials="B." role="editor" surname="Long
"/>
<author fullname="S. Blank" initials="S." role="editor" surname="Bla
nk"/>
<author fullname="M. Kucherawy" initials="M." role="editor" surname=
"Kucherawy"/>
<date month="July" year="2019"/>
<abstract>
<t indent="0">The Authenticated Received Chain (ARC) protocol prov
ides an authenticated "chain of custody" for a message, allowing each entity tha
t handles the message to see what entities handled it before and what the messag
e's authentication assessment was at each step in the handling.</t>
<t indent="0">ARC allows Internet Mail Handlers to attach assertio
ns of message authentication assessment to individual messages. As messages trav
erse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attach
ed to messages to form ordered sets of ARC assertions that represent the authent
ication assessment at each step of the message-handling paths.</t>
<t indent="0">ARC-enabled Internet Mail Handlers can process sets
of ARC assertions to inform message disposition decisions, identify Internet Mai
l Handlers that might break existing authentication mechanisms, and convey origi
nal authentication assessments across trust boundaries.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8617"/>
<seriesInfo name="DOI" value="10.17487/RFC8617"/>
</reference>
<reference anchor="RFC9091" target="https://www.rfc-editor.org/info/rfc9
091" quoteTitle="true" derivedAnchor="RFC9091">
<front>
<title>Experimental Domain-Based Message Authentication, Reporting,
and Conformance (DMARC) Extension for Public Suffix Domains</title>
<author fullname="S. Kitterman" initials="S." surname="Kitterman"/>
<author fullname="T. Wicinski" initials="T." role="editor" surname="
Wicinski"/>
<date month="July" year="2021"/>
<abstract>
<t indent="0">Domain-based Message Authentication, Reporting, and
Conformance (DMARC), defined in RFC 7489, permits a domain-controlling organizat
ion to express domain-level policies and preferences for message validation, dis
position, and reporting, which a mail-receiving organization can use to improve
mail handling.</t>
<t indent="0">DMARC distinguishes the portion of a name that is a
Public Suffix Domain (PSD), below which Organizational Domain names are created.
The basic DMARC capability allows Organizational Domains to specify policies th
at apply to their subdomains, but it does not give that capability to PSDs. This
document describes an extension to DMARC to fully enable DMARC functionality fo
r PSDs.</t>
<t indent="0">Some implementations of DMARC consider a PSD to be i
neligible for DMARC enforcement. This specification addresses that case.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9091"/>
<seriesInfo name="DOI" value="10.17487/RFC9091"/>
</reference>
<reference anchor="RFC9364" target="https://www.rfc-editor.org/info/rfc9
364" quoteTitle="true" derivedAnchor="RFC9364">
<front>
<title>DNS Security Extensions (DNSSEC)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="February" year="2023"/>
<abstract>
<t indent="0">This document describes the DNS Security Extensions
(commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as w
ell as a handful of others. One purpose is to introduce all of the RFCs in one p
lace so that the reader can understand the many aspects of DNSSEC. This document
does not update any of those RFCs. A second purpose is to state that using DNSS
EC for origin authentication of DNS data is the best current practice. A third p
urpose is to provide a single reference for other documents that want to refer t
o DNSSEC.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="237"/>
<seriesInfo name="RFC" value="9364"/>
<seriesInfo name="DOI" value="10.17487/RFC9364"/>
</reference>
</references>
</references>
<section anchor="technology-considerations" numbered="true" removeInRFC="fal
se" toc="include" pn="section-appendix.a">
<name slugifiedName="name-technology-considerations">Technology Considerat
ions</name>
<t indent="0" pn="section-appendix.a-1">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" numbered="true" removeInRFC="false" toc="include"
<section anchor="s-mime"><name>S/MIME</name> pn="section-appendix.a.1">
<t>S/MIME, or Secure Multipurpose Internet Mail Extensions <xref target="RFC8551 <name slugifiedName="name-s-mime">S/MIME</name>
"></xref>, <t indent="0" pn="section-appendix.a.1-1">S/MIME, or Secure Multipurpose
Internet Mail Extensions <xref target="RFC8551" format="default" sectionFormat=
"of" derivedContent="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 indent="0" pn="section-appendix.a.1-2">DMARC is focused on authentica tion 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 indent="0" pn="section-appendix.a.1-3">S/MIME also suffers from the h
Infrastructure, which means that distribution of keys used to validate eavyweight problem of Public Key
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 indent="0" pn="section-appendix.a.1-4">S/MIME has extensive deploymen t 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 indent="0" pn="section-appendix.a.1-5">Finally, experiments have show n 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" numbered="true" removeInRFC="false" toc
<section anchor="method-exclusion"><name>Method Exclusion</name> ="include" pn="section-appendix.a.2">
<t>It was suggested that DMARC include a mechanism by which a Domain <name slugifiedName="name-method-exclusion">Method Exclusion</name>
<t indent="0" pn="section-appendix.a.2-1">It was suggested that DMARC in
clude 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., &quot;check DKIM, but not SPF&quot;).</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 indent="0" pn="section-appendix.a.2-2">Specifically, consider a Domai
n 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 &quot;none&quot;, 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 indent="0" pn="section-appendix.a.2-3">The DMARC development team eva luated 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 indent="0" pn="section-appendix.a.2-4">In the scenario described abov
e, the Domain Owner has a few options:</t>
<ol> <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-ap
<li><t>Tighten up its infrastructure to minimize the failure modes of pendix.a.2-5">
<li pn="section-appendix.a.2-5.1" derivedCounter="1.">
<t indent="0" pn="section-appendix.a.2-5.1.1">Tighten up its infrast
ructure 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 pn="section-appendix.a.2-5.2" derivedCounter="2.">
<t indent="0" pn="section-appendix.a.2-5.2.1">Deploy the other suppo
rted 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 pn="section-appendix.a.2-5.3" derivedCounter="3.">
</li> <t indent="0" pn="section-appendix.a.2-5.3.1">Deploy DMARC in a repo
</ol> rting-only mode.</t>
</section> </li>
</ol>
<section anchor="sender-header-field"><name>Sender Header Field</name> </section>
<t>It has been suggested in several message authentication efforts that <section anchor="sender-header-field" numbered="true" removeInRFC="false"
toc="include" pn="section-appendix.a.3">
<name slugifiedName="name-sender-header-field">Sender Header Field</name
>
<t indent="0" pn="section-appendix.a.3-1">It has been suggested in sever
al 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" format="def ault" sectionFormat="of" derivedContent="RFC4870"/>, but on evolution 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 indent="0" pn="section-appendix.a.3-2">The DMARC development team con sidered 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 indent="adaptive" spacing="normal" start="1" type="1" pn="section-ap
<ol> pendix.a.3-3">
<li><t>The main user protection approach is to be concerned with what <li pn="section-appendix.a.3-3.1" derivedCounter="1.">
<t indent="0" pn="section-appendix.a.3-3.1.1">The main user protecti
on 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
the end user might never actually see, which can create a vector the end user might never actually see, which can create a vector
for attack against end users by simply forging a Sender field for attack against end users by simply forging a Sender field
containing some identifier that DMARC will like.</t> containing some identifier that DMARC will like.</t>
</li> </li>
<li><t>Although it is certainly true that this is what the Sender field <li pn="section-appendix.a.3-3.2" derivedCounter="2.">
<t indent="0" pn="section-appendix.a.3-3.2.1">Although it is certain
ly true that this is what the Sender field
is for, its use in this way is also unreliable, making it a poor is for, its use in this way is also unreliable, making it a poor
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 pn="section-appendix.a.3-3.3" derivedCounter="3.">
<t indent="0" pn="section-appendix.a.3-3.3.1">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" numbered="true" removeInRFC="false
<section anchor="domain-existence-test"><name>Domain Existence Test</name> " toc="include" pn="section-appendix.a.4">
<t>The presence of the &quot;np&quot; tag in this specification seemingly implie <name slugifiedName="name-domain-existence-test">Domain Existence Test</
s that name>
<t indent="0" pn="section-appendix.a.4-1">The presence of the "np" tag i
n 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 indent="0" pn="section-appendix.a.4-2">Since the DMARC mechanism is f
definition of &quot;resolvable&quot; in <xref target="RFC5321"></xref> applies. ocused on email, one might think that the
Using that definition, only definition of "resolvable" in <xref target="RFC5321" format="default" sectionFor
names that resolve to MX Resource Records (RRs), A RRs, or AAAA RRs are deemed mat="of" derivedContent="RFC5321"/> applies. Using that definition, only
names that resolve to MX 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 indent="0" pn="section-appendix.a.4-3">The DMARC mechanism makes no s uch requirement for the existence of specific DNS
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" format="de
n &quot;NXDOMAIN&quot; response fault" sectionFormat="of" derivedContent="RFC2308"/>, an "NXDOMAIN" response
(rcode &quot;Name Error&quot;) 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 RR
while a &quot;NODATA&quot; response (rcode &quot;NOERROR&quot;) 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 indent="0" pn="section-appendix.a.4-4">Furthermore, in keeping with < xref target="RFC8020" format="default" sectionFormat="of" derivedContent="RFC802 0"/>, 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" numbered="true" r
<section anchor="organizational-domain-discovery-issues"><name>Organizational Do emoveInRFC="false" toc="include" pn="section-appendix.a.5">
main Discovery Issues</name> <name slugifiedName="name-organizational-domain-disco">Organizational Do
<t>An earlier informational version of the DMARC mechanism <xref target="RFC7489 main Discovery Issues</name>
"></xref> <t indent="0" pn="section-appendix.a.5-1">An earlier informational versi
noted that the DNS does not provide a method by which the &quot;domain of record on of the DMARC mechanism <xref target="RFC7489" format="default" sectionFormat=
&quot;, "of" derivedContent="RFC7489"/>
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 RRs, 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 &quot;climb the tree&quot; to fi <t indent="0" pn="section-appendix.a.5-2">That previous version posited
nd the that one could "climb the tree" to find 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" format="d efault" sectionFormat="of" derivedContent="Section 4.10">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 <t indent="0" pn="section-appendix.a.5-3">Readers curious about the prev
are ious 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" format="defa
</section> ult" derivedLink="https://rfc-editor.org/rfc/rfc7489#section-3.2" derivedContent
="RFC7489"/>.</t>
<section anchor="removal-of-the-pct-tag"><name>Removal of the &quot;pct&quot; Ta </section>
g</name> <section anchor="removal-of-the-pct-tag" numbered="true" removeInRFC="fals
<t>An earlier informational version of the DMARC mechanism <xref target="RFC7489 e" toc="include" pn="section-appendix.a.6">
"></xref> <name slugifiedName="name-removal-of-the-pct-tag">Removal of the "pct" T
included a &quot;pct&quot; tag and specified all integers from 0 to 100 inclusiv ag</name>
e <t indent="0" pn="section-appendix.a.6-1">An earlier informational versi
as valid values for the tag. The intent of the tag was to provide domain on of the DMARC mechanism <xref target="RFC7489" format="default" sectionFormat=
owners with a method to gradually change their preferred Domain Owner Assessment "of" derivedContent="RFC7489"/>
Policy (the &quot;p&quot; tag) from &quot;none&quot; to &quot;quarantine&quot; o included a "pct" tag and specified all integers from 0 to 100 inclusive
r from &quot;quarantine&quot; to &quot;reject&quot; as valid values for the tag. The intent of the tag was to provide Domain
Owners with a method to gradually change their preferred Domain Owner Assessment
Policy (the "p" tag) from "none" to "quarantine" or 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 &quot;fail&quot;.</t> that produced DMARC results of "fail".</t>
<t>Operational experience showed that the pct tag was usually not accurately <t indent="0" pn="section-appendix.a.6-2">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 &quot;pct&quot; tag was set to 0 proved valuabl e to the <t indent="0" pn="section-appendix.a.6-3">These custom actions when the "pct" tag was set to 0 proved valuable 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 &quot;p&quot; value Owner to compare aggregate reports from before and after the "p" value was chang
was changed ed
and &quot;pct=0&quot; 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" for
nitoring Mode</eref> mat="default" sectionFormat="of" derivedContent="Section 3.2.12">Monitoring Mode
to <eref target="#enforcement">Enforcement</eref>. Armed with this knowledge, t </xref>
he Domain Owner could to <xref target="enforcement" format="default" sectionFormat="of" derivedContent
="Section 3.2.9">Enforcement</xref>. Armed with this knowledge, the Domain Owne
r 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 &quot;pct=0&quot; to Domain Owners, it was l ogical <t indent="0" pn="section-appendix.a.6-4">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 &quot;pct&quot; 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 &quot;t&quot; tag as shorthand ing",
for &quot;testing&quot;, with the valid values of "y" and "n", which are meant to be analogous in their
with the valid values of &quot;y&quot; and &quot;n&quot;, 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 &quot;pct&quot; tag v </section>
alues </section>
&quot;0&quot; and &quot;100&quot;, respectively.</t> <section anchor="examples" numbered="true" removeInRFC="false" toc="include"
</section> pn="section-appendix.b">
</section> <name slugifiedName="name-examples">Examples</name>
<t indent="0" pn="section-appendix.b-1">This section illustrates both the
<section anchor="examples"><name>Examples</name> 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" numbered="true" removeInRF
<section anchor="identifier-alignment-examples"><name>Identifier Alignment Examp C="false" toc="include" pn="section-appendix.b.1">
les</name> <name slugifiedName="name-identifier-alignment-exampl">Identifier Alignm
<t>The following examples illustrate the DMARC mechanism's use of ent Examples</name>
<t indent="0" pn="section-appendix.b.1-1">The following examples illustr
ate 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" numbered="true" removeInRFC="false" toc="include"
<section anchor="spf"><name>SPF</name> pn="section-appendix.b.1.1">
<t>The following SPF examples assume that SPF produces a passing result. <name slugifiedName="name-spf">SPF</name>
<t indent="0" pn="section-appendix.b.1.1-1">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 indent="0" pn="section-appendix.b.1.1-2">Example 1: SPF in Strict A
lignment:</t>
<artwork><![CDATA[ MAIL FROM: <sender@example.com> <artwork align="left" pn="section-appendix.b.1.1-3">
MAIL FROM: &lt;sender@example.com&gt;
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 indent="0" pn="section-appendix.b.1.1-4">In this case, the RFC5321.
<t>In this case, the RFC5321.MailFrom domain and the Author Domain are identical 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 indent="0" pn="section-appendix.b.1.1-5">Example 2: SPF in Relaxed
<t>Example 2: SPF in Relaxed Alignment:</t> Alignment:</t>
<artwork align="left" pn="section-appendix.b.1.1-6">
<artwork><![CDATA[ MAIL FROM: <sender@child.example.com> MAIL FROM: &lt;sender@child.example.com&gt;
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 indent="0" pn="section-appendix.b.1.1-7">In this case, the Author D
<t>In this case, the Author Domain (example.com) is a parent of the omain (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 indent="0" pn="section-appendix.b.1.1-8">Example 3: No SPF Identifi
er Alignment:</t>
<artwork><![CDATA[ MAIL FROM: <sender@example.net> <artwork align="left" pn="section-appendix.b.1.1-9">
MAIL FROM: &lt;sender@example.net&gt;
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 indent="0" pn="section-appendix.b.1.1-10">In this case, the RFC5321
<t>In this case, the RFC5321.MailFrom domain that is neither the same as, .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" numbered="true" removeInRFC="false" toc="include"
<section anchor="dkim"><name>DKIM</name> pn="section-appendix.b.1.2">
<t>The examples below assume that the DKIM signatures pass validation. <name slugifiedName="name-dkim">DKIM</name>
<t indent="0" pn="section-appendix.b.1.2-1">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 indent="0" pn="section-appendix.b.1.2-2">Example 1: DKIM in Strict
Alignment:</t>
<artwork><![CDATA[ DKIM-Signature: v=1; ...; d=example.com; ... <artwork align="left" pn="section-appendix.b.1.2-3">
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 indent="0" pn="section-appendix.b.1.2-4">In this case, the DKIM "d"
<t>In this case, the DKIM &quot;d&quot; tag and the Author Domain have 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 indent="0" pn="section-appendix.b.1.2-5">Example 2: DKIM in Relaxed
Alignment:</t>
<artwork><![CDATA[ DKIM-Signature: v=1; ...; d=example.com; ... <artwork align="left" pn="section-appendix.b.1.2-6">
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 indent="0" pn="section-appendix.b.1.2-7">In this case, the DKIM sig
<t>In this case, the DKIM signature's &quot;d&quot; tag includes a DNS nature'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 indent="0" pn="section-appendix.b.1.2-8">Example 3: No DKIM Identif
ier Alignment:</t>
<artwork><![CDATA[ DKIM-Signature: v=1; ...; d=example.net; ... <artwork align="left" pn="section-appendix.b.1.2-9">
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 indent="0" pn="section-appendix.b.1.2-10">In this case, the DKIM si
<t>In this case, the DKIM signature's &quot;d&quot; tag includes a DNS gnature'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" numbered="true" removeInRFC="false"
<section anchor="domain-owner-example"><name>Domain Owner Example</name> toc="include" pn="section-appendix.b.2">
<t>A Domain Owner that wants to use DMARC should have already deployed <name slugifiedName="name-domain-owner-example">Domain Owner Example</na
me>
<t indent="0" pn="section-appendix.b.2-1">A Domain Owner that wants to u
se 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" numbered="true" removeIn
<section anchor="entire-domain-monitoring-mode"><name>Entire Domain, Monitoring RFC="false" toc="include" pn="section-appendix.b.2.1">
Mode</name> <name slugifiedName="name-entire-domain-monitoring-mo">Entire Domain,
<t>The Domain Owner for &quot;example.com&quot; has deployed SPF and DKIM on Monitoring Mode</name>
<t indent="0" pn="section-appendix.b.2.1-1">The Domain Owner for "exam
ple.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 bare="false" empty="false" indent="3" spacing="normal" pn="section
<ul> -appendix.b.2.1-2">
<li><t>Confirm that its legitimate messages are authenticating correctly</t> <li pn="section-appendix.b.2.1-2.1">
</li> <t indent="0" pn="section-appendix.b.2.1-2.1.1">Confirm that its l
<li><t>Validate that all authorized message sources have implemented egitimate messages are authenticating correctly</t>
</li>
<li pn="section-appendix.b.2.1-2.2">
<t indent="0" pn="section-appendix.b.2.1-2.2.1">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 pn="section-appendix.b.2.1-2.3">
<t indent="0" pn="section-appendix.b.2.1-2.3.1">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 indent="0" pn="section-appendix.b.2.1-3">The Domain Owner accomplis
hes this by constructing a DMARC Policy Record
indicating that:</t> indicating that:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section
<ul> -appendix.b.2.1-4">
<li><t>The version of DMARC being used is &quot;DMARC1&quot; (&quot;v=DMARC1;&qu <li pn="section-appendix.b.2.1-4.1">
ot;)</t> <t indent="0" pn="section-appendix.b.2.1-4.1.1">The version of DMA
</li> RC being used is "DMARC1" ("v=DMARC1;")</t>
<li><t>Mail Receivers should not alter how they treat these messages because </li>
of this DMARC Policy Record (&quot;p=none&quot;)</t> <li pn="section-appendix.b.2.1-4.2">
</li> <t indent="0" pn="section-appendix.b.2.1-4.2.1">Mail Receivers sho
<li><t>Aggregate feedback reports are sent via email to the address uld not alter how they treat these messages because
&quot;dmarc-feedback@example.com&quot; of this DMARC Policy Record ("p=none")</t>
<tt>(&quot;rua=mailto:dmarc-feedback@example.com&quot;)</tt></t> </li>
</li> <li pn="section-appendix.b.2.1-4.3">
<li><t>All messages from this Organizational Domain are subject to this <t indent="0" pn="section-appendix.b.2.1-4.3.1">Aggregate feedback
policy (no &quot;t&quot; tag present, so the default of &quot;n&quot; applies).< reports are sent via email to the address
/t> "dmarc-feedback@example.com"
</li> <tt>("rua=mailto:dmarc-feedback@example.com")</tt></t>
</ul> </li>
<t>To publish such a record, the DNS administrator for the Domain Owner <li pn="section-appendix.b.2.1-4.4">
<t indent="0" pn="section-appendix.b.2.1-4.4.1">All messages from
this Organizational Domain are subject to this
policy (no "t" tag present, so the default of "n" applies)</t>
</li>
</ul>
<t indent="0" pn="section-appendix.b.2.1-5">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 align="left" pn="section-appendix.b.2.1-6">
<artwork><![CDATA[ ; DMARC Policy Record for the domain example.com ; 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-repor
ts" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.2.2
<section anchor="entire-domain-monitoring-mode-per-message-failure-reports"><nam ">
e>Entire Domain, Monitoring Mode, Per-Message Failure Reports</name> <name slugifiedName="name-entire-domain-monitoring-mod">Entire Domain,
<t>The Domain Owner from the previous example has used the aggregate Monitoring Mode, Per-Message Failure Reports</name>
<t indent="0" pn="section-appendix.b.2.2-1">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 indent="0" pn="section-appendix.b.2.2-2">Not all Mail Receivers wil l 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 format <xref target="RFC9991" format="default" sectionFormat="of" derivedContent
cenario.</t> ="RFC9991"/> meets the Domain Owner's needs in this scenario.</t>
<t>The Domain Owner accomplishes this by adding the following to its <t indent="0" pn="section-appendix.b.2.2-3">The Domain Owner accomplis
DMARC Policy Record from <xref target="entire-domain-monitoring-mode"></xref>:</ hes this by adding the following to its
t> DMARC Policy Record from <xref target="entire-domain-monitoring-mode" format="de
fault" sectionFormat="of" derivedContent="Appendix B.2.1"/>:</t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>Per-message failure reports are sent via email to the -appendix.b.2.2-4">
address &quot;auth-reports@example.com&quot; <li pn="section-appendix.b.2.2-4.1">Per-message failure reports are
<tt>(&quot;ruf=mailto:auth-reports@example.com&quot;)</tt> </li> sent via email to the
</ul> address "auth-reports@example.com"
<t>To publish such a record, the DNS administrator for the Domain Owner <tt>("ruf=mailto:auth-reports@example.com")</tt> </li>
</ul>
<t indent="0" pn="section-appendix.b.2.2-5">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 align="left" pn="section-appendix.b.2.2-6">
<artwork><![CDATA[ ; DMARC Policy Record for the domain example.com ; 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" nu
mbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.2.3">
<section anchor="per-message-failure-reports-directed-to-third-party"><name>Per- <name slugifiedName="name-per-message-failure-reports">Per-Message Fai
Message Failure Reports Directed to Third Party</name> lure Reports Directed to Third Party</name>
<t>The Domain Owner from the previous example is maintaining the same <t indent="0" pn="section-appendix.b.2.3-1">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 indent="0" pn="section-appendix.b.2.3-2">The Domain Owner needs to alter its DMARC Policy Record from <xref target="entire-domain-monitoring-mode-p er-message-failure-reports" format="default" sectionFormat="of" derivedContent=" Appendix B.2.2"/>
as follows:</t> as follows:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<ul spacing="compact"> -appendix.b.2.3-3">
<li>Per-message failure reports are sent via email to the <li pn="section-appendix.b.2.3-3.1">Per-message failure reports are
address &quot;auth-reports@thirdparty.example.net&quot; sent via email to the
<tt>(&quot;ruf=mailto:auth-reports@thirdparty.example.net&quot;)</tt></li> address "auth-reports@thirdparty.example.net"
</ul> <tt>("ruf=mailto:auth-reports@thirdparty.example.net")</tt></li>
<t>To publish such a record, the DNS administrator for the Domain Owner </ul>
<t indent="0" pn="section-appendix.b.2.3-4">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 align="left" pn="section-appendix.b.2.3-5">
<artwork><![CDATA[ ; DMARC Policy Record for the domain example.com ; 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 indent="0" pn="section-appendix.b.2.3-6">Because the address used i
<t>Because the address used in the &quot;ruf&quot; tag is outside the Organizati n the "ruf" tag is outside the Organizational Domain
onal Domain
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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9990#section -3" derivedContent="RFC9990"/>.
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="normal" bare="false" empty="false" indent="3" pn="section
<ul spacing="compact"> -appendix.b.2.3-7">
<li>Given the DMARC Policy Record published by the Domain Owner at <li pn="section-appendix.b.2.3-7.1">Given the DMARC Policy Record pu
&quot;_dmarc.example.com&quot;, the DNS administrator for the Report Consumer blished by the Domain Owner at
will need to publish a TXT resource record at "_dmarc.example.com", the DNS administrator for the Report Consumer
&quot;example.com._report._dmarc.thirdparty.example.net&quot; with the value will need to publish a TXT RR at
&quot;v=DMARC1;&quot; to authorize receipt of the reports.</li> "example.com._report._dmarc.thirdparty.example.net" with the value
</ul> "v=DMARC1;" to authorize receipt of the reports.</li>
<t>To publish such a record, the DNS administrator for example.net might </ul>
<t indent="0" pn="section-appendix.b.2.3-8">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 align="left" pn="section-appendix.b.2.3-9">
<artwork><![CDATA[ ; zone file for thirdparty.example.net ; 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" numbered="true" remov
eInRFC="false" toc="include" pn="section-appendix.b.2.4">
<section anchor="overriding-destination-addresses"><name>Overriding destination <name slugifiedName="name-overriding-destination-addr">Overriding Dest
addresses</name> ination Addresses</name>
<t>The third party Report Consumer can also publish &quot;rua&quot; and &quot;ru <t indent="0" pn="section-appendix.b.2.4-1">The third-party Report Con
f&quot; tags in order sumer can also publish "rua" and "ruf" tags in order
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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9990#section-3" derivedContent="RFC9990"/>
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 indent="0" pn="section-appendix.b.2.4-2">The third-party Report Con
its sumer accomplishes this by adding the following to 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" format="default" sectionFormat="of" derivedContent="Appendix B.2.3"/
>:</t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>The override address for aggregate reports is -appendix.b.2.4-3">
&quot;aggregate-reports@thirdparty.example.net&quot; <li pn="section-appendix.b.2.4-3.1">The override address for aggrega
<tt>(&quot;rua=mailto:aggregate-reports@thirdparty.example.net&quot;)</tt></li> te reports is
<li>The override address for failure reports is "aggregate-reports@thirdparty.example.net"
&quot;failure-reports@thirdparty.example.net&quot; <tt>("rua=mailto:aggregate-reports@thirdparty.example.net")</tt></li>
<tt>(&quot;ruf=mailto:failure-reports@thirdparty.example.net&quot;)</tt></li> <li pn="section-appendix.b.2.4-3.2">The override address for failure
</ul> reports is
<t>To publish such a record, the DNS administrator for example.net might "failure-reports@thirdparty.example.net"
<tt>("ruf=mailto:failure-reports@thirdparty.example.net")</tt></li>
</ul>
<t indent="0" pn="section-appendix.b.2.4-4">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 align="left" pn="section-appendix.b.2.4-5">
<artwork><![CDATA[ ; zone file for thirdparty.example.net ; 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 indent="0" pn="section-appendix.b.2.4-6">In this case, only the "ru
<t>In this case only the &quot;ruf&quot; tag is actually overridden, because, in f" 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"
<section anchor="subdomain-sampling-and-multiple-aggregate-report-uris"><name>Su numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b.2.5">
bdomain, Testing, and Multiple Aggregate Report URIs</name> <name slugifiedName="name-subdomain-testing-and-multi">Subdomain, Test
<t>The Domain Owner has implemented SPF and DKIM in a subdomain used for ing, and Multiple Aggregate Report URIs</name>
<t indent="0" pn="section-appendix.b.2.5-1">The Domain Owner has imple
mented 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 indent="0" pn="section-appendix.b.2.5-2">As a first step, it will e xpress 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 indent="0" pn="section-appendix.b.2.5-3">The Domain Owner will acco mplish this by constructing a DMARC Policy Record
indicating that:</t> indicating that:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section
<ul> -appendix.b.2.5-4">
<li><t>The version of DMARC being used is &quot;DMARC1&quot; (&quot;v=DMARC1;&qu <li pn="section-appendix.b.2.5-4.1">
ot;)</t> <t indent="0" pn="section-appendix.b.2.5-4.1.1">The version of DMA
</li> RC being used is "DMARC1" ("v=DMARC1;")</t>
<li><t>It is applied only to this subdomain (the DMARC Policy Record is publishe </li>
d at <li pn="section-appendix.b.2.5-4.2">
&quot;_dmarc.test.example.com&quot; and not &quot;_dmarc.example.com&quot;)</t> <t indent="0" pn="section-appendix.b.2.5-4.2.1">It is applied only
</li> to this subdomain (the DMARC Policy Record is published at
<li><t>Mail Receivers are advised that the Domain Owner considers messages "_dmarc.test.example.com" and not "_dmarc.example.com")</t>
that fail to authenticate to be suspicious (&quot;p=quarantine&quot;)</t> </li>
</li> <li pn="section-appendix.b.2.5-4.3">
<li><t>Aggregate feedback reports are sent via email to the <t indent="0" pn="section-appendix.b.2.5-4.3.1">Mail Receivers are
addresses &quot;dmarc-feedback@example.com&quot; and advised that the Domain Owner considers messages
&quot;example-tld-test@thirdparty.example.net&quot; that fail to authenticate to be suspicious ("p=quarantine")</t>
<tt>(&quot;rua=mailto:dmarc-feedback@example.com, </li>
mailto:example-tld-test@thirdparty.example.net&quot;)</tt></t> <li pn="section-appendix.b.2.5-4.4">
</li> <t indent="0" pn="section-appendix.b.2.5-4.4.1">Aggregate feedback
<li><t>The Domain Owner desires only that an actor performing a DMARC reports are sent via email to the
addresses "dmarc-feedback@example.com" and
"example-tld-test@thirdparty.example.net"
<tt>("rua=mailto:dmarc-feedback@example.com,
mailto:example-tld-test@thirdparty.example.net")</tt></t>
</li>
<li pn="section-appendix.b.2.5-4.5">
<t indent="0" pn="section-appendix.b.2.5-4.5.1">The Domain Owner d
esires 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. (&quot;t=y&quot;)</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 indent="0" pn="section-appendix.b.2.5-5">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 align="left" pn="section-appendix.b.2.5-6">
<artwork><![CDATA[ ; DMARC Policy Record for the domain test.example.com ; 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 indent="0" pn="section-appendix.b.2.5-7">Once enough time has passe
<t>Once enough time has passed to allow for collecting enough reports to d 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 (&quot;p=reject&quot;) and removing the testing of its position on such messages ("p=reject") and removing the testing flag ("t=
flag (&quot;t=y&quot;).</t> y").</t>
<t>To publish such a record, the DNS administrator for the Domain Owner <t indent="0" pn="section-appendix.b.2.5-8">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 align="left" pn="section-appendix.b.2.5-9">
<artwork><![CDATA[ ; DMARC Policy Record for the domain test.example.com ; 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" numbered="true" removeInRFC="false
" toc="include" pn="section-appendix.b.3">
<section anchor="mail-receiver-example"><name>Mail Receiver Example</name> <name slugifiedName="name-mail-receiver-example">Mail Receiver Example</
<t>A Mail Receiver that wants to participate in DMARC should already be checking name>
SPF and DKIM, and possess the ability to collect relevant information <t indent="0" pn="section-appendix.b.3-1">A Mail Receiver that wants to
participate in DMARC should already be checking
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" numbered="true" removeInRFC="fals
<section anchor="smtp-session-example"><name>SMTP Session Example</name> e" toc="include" pn="section-appendix.b.3.1">
<t>An optimal DMARC-enabled Mail Receiver performs validation and <name slugifiedName="name-smtp-session-example">SMTP Session Example</
Identifier Alignment checking during the SMTP <xref target="RFC5321"></xref> con name>
versation.</t> <t indent="0" pn="section-appendix.b.3.1-1">An optimal DMARC-enabled M
<t>Before returning a final reply to the DATA command, the Mail ail Receiver performs validation and
Identifier Alignment checking during the SMTP <xref target="RFC5321" format="def
ault" sectionFormat="of" derivedContent="RFC5321"/> conversation.</t>
<t indent="0" pn="section-appendix.b.3.1-2">Before returning a final r
eply to the DATA command, the Mail
Receiver's MTA has performed:</t> Receiver's MTA has performed:</t>
<ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-
<ol> appendix.b.3.1-3">
<li><t>An SPF check to determine an SPF-Authenticated Identifier.</t> <li pn="section-appendix.b.3.1-3.1" derivedCounter="1.">
</li> <t indent="0" pn="section-appendix.b.3.1-3.1.1">An SPF check to de
<li><t>DKIM checks that yield one or more DKIM-Authenticated termine an SPF-Authenticated Identifier.</t>
</li>
<li pn="section-appendix.b.3.1-3.2" derivedCounter="2.">
<t indent="0" pn="section-appendix.b.3.1-3.2.1">DKIM checks that y
ield one or more DKIM-Authenticated
Identifiers.</t> Identifiers.</t>
</li> </li>
<li><t>A DMARC Policy Record lookup.</t> <li pn="section-appendix.b.3.1-3.3" derivedCounter="3.">
</li> <t indent="0" pn="section-appendix.b.3.1-3.3.1">A DMARC Policy Rec
</ol> ord lookup.</t>
<t>The presence of an Author Domain DMARC Policy Record indicates that the Mail </li>
</ol>
<t indent="0" pn="section-appendix.b.3.1-4">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 indent="0" pn="section-appendix.b.3.1-5">Given a DMARC Policy Recor d 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 indent="0" pn="section-appendix.b.3.1-6">For example, the following
piece of email originating from the Domain Owner of &quot;example.com&quot;:</t> sample data is considered to be from a
piece of email originating from the Domain Owner of "example.com":</t>
<artwork><![CDATA[ Author Domain: example.com <artwork align="left" pn="section-appendix.b.3.1-7">
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 indent="0" pn="section-appendix.b.3.1-8">In the above sample, the S
<t>In the above sample, the SPF-Authenticated Identifier and the PF-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 &quot;reject&quot; 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 indent="0" pn="section-appendix.b.3.1-9">If no Authenticated Identi fiers 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 indent="0" pn="section-appendix.b.3.1-10">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 indent="0" pn="section-appendix.b.3.1-11">Before exiting DMARC-spec
see if the Author Domain DMARC Policy Record requests AFRF-based reporting. ific processing, the Mail Receiver checks to
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 indent="0" pn="section-appendix.b.3.1-12">At the exit of DMARC-spec ific 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 &quot;rua&quot; 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" numbered="true" removeInRFC="false" toc
<section anchor="treewalk-example"><name>Organizational and Policy Domain Tree W ="include" pn="section-appendix.b.4">
alk Examples</name> <name slugifiedName="name-organizational-and-policy-d">Organizational an
<t>If an Author Domain has no DMARC Policy Record, a Mail Receiver uses a tree w d Policy Domain Tree Walk Examples</name>
alk <t indent="0" pn="section-appendix.b.4-1">If an Author Domain has no DMA
RC Policy Record, a Mail Receiver uses a Tree Walk
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 <t indent="0" pn="section-appendix.b.4-2">If the DMARC Policy Record all
enticated ows relaxed alignment and the SPF- or DKIM-Authenticated
Identifiers are different from the Author Domain, a Mail Receiver uses a tree wa Identifiers are different from the Author Domain, a Mail Receiver uses a Tree Wa
lk to 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" numbered="tru
<section anchor="simple-organizational-and-policy-example"><name>Simple Organiza e" removeInRFC="false" toc="include" pn="section-appendix.b.4.1">
tional and Policy Example</name> <name slugifiedName="name-simple-organizational-and-p">Simple Organiza
<t>A Mail Receiver receives an email with:</t> tional and Policy Example</name>
<t indent="0" pn="section-appendix.b.4.1-1">A Mail Receiver receives a
<ul spacing="compact"> n email with:</t>
<li>Author Domain: example.com</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>RFC5321.MailFrom Domain: example.com</li> -appendix.b.4.1-2">
<li>DKIM-Authenticated Identifier: signing.example.com</li> <li pn="section-appendix.b.4.1-2.1">Author Domain: example.com</li>
</ul> <li pn="section-appendix.b.4.1-2.2">RFC5321.MailFrom Domain: example
<t>In this example, &quot;_dmarc.example.com&quot; and &quot;_dmarc.signing.exam .com</li>
ple.com&quot; both <li pn="section-appendix.b.4.1-2.3">DKIM-Authenticated Identifier: s
have DMARC Policy Records while &quot;_dmarc.com&quot; does not. If SPF or DKIM igning.example.com</li>
yield pass </ul>
<t indent="0" pn="section-appendix.b.4.1-3">In this example, "_dmarc.e
xample.com" and "_dmarc.signing.example.com" both
have DMARC Policy Records, while "_dmarc.com" does not. If SPF or DKIM yield "pa
ss"
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 indent="0" pn="section-appendix.b.4.1-4">To determine the Organizat
query &quot;_dmarc.example.com&quot; and &quot;_dmarc.com&quot;; &quot;example.c ional Domain for the Author Domain,
om&quot; 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 &quot;example.com&quot;.</t> Domain for "example.com".</t>
<t>For the RFC5321.MailFrom domain, the Organizational Domain already found for <t indent="0" pn="section-appendix.b.4.1-5">For the RFC5321.MailFrom d
&quot;example.com&quot; is &quot;example.com&quot;, so SPF is aligned.</t> omain, the Organizational Domain already found for
<t>To determine the Organizational Domain for the DKIM-Authenticated Identifier, "example.com" is "example.com", so SPF is aligned.</t>
query &quot;_dmarc.signing.example.com&quot;, &quot;_dmarc.example.com&quot;, an <t indent="0" pn="section-appendix.b.4.1-6">To determine the Organizat
d &quot;_dmarc.com&quot;. ional Domain for the DKIM-Authenticated Identifier,
Both &quot;signing.example.com&quot; and &quot;example.com&quot; have DMARC Poli query "_dmarc.signing.example.com", "_dmarc.example.com", and "_dmarc.com".
cy Records, Both "signing.example.com" and "example.com" have DMARC Policy Records,
but &quot;example.com&quot; is the highest element in the tree with a DMARC Poli but "example.com" is the highest element in the tree with a DMARC Policy Record
cy Record (it has the fewest labels), so "example.com" is the Organizational Domain. Since
(it has the fewest labels), so &quot;example.com&quot; 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 indent="0" pn="section-appendix.b.4.1-7">Since both SPF and DKIM ar
message has a DMARC pass result. If the result is not pass, then the policy e aligned, they can be used to determine if the
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" numbered="true" removeInRFC="fa
<section anchor="deep-tree-walk-example"><name>Deep Tree Walk Example</name> lse" toc="include" pn="section-appendix.b.4.2">
<t>A Mail Receiver receives an email with:</t> <name slugifiedName="name-deep-tree-walk-example">Deep Tree Walk Examp
le</name>
<ul spacing="compact"> <t indent="0" pn="section-appendix.b.4.2-1">A Mail Receiver receives a
<li>Author Domain: a.b.c.d.e.f.g.h.i.j.k.example.com</li> n email with:</t>
<li>RFC5321.MailFrom Domain: example.com</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>DKIM-Authenticated Identifier: signing.example.com</li> -appendix.b.4.2-2">
</ul> <li pn="section-appendix.b.4.2-2.1">Author Domain: a.b.c.d.e.f.g.h.i
<t>Both &quot;_dmarc.example.com&quot; and &quot;_dmarc.signing.example.com&quot .j.k.example.com</li>
; have DMARC Policy Records, <li pn="section-appendix.b.4.2-2.2">RFC5321.MailFrom Domain: example
while &quot;_dmarc.com&quot; does not. If SPF or DKIM yield pass results, they s .com</li>
till have <li pn="section-appendix.b.4.2-2.3">DKIM-Authenticated Identifier: s
igning.example.com</li>
</ul>
<t indent="0" pn="section-appendix.b.4.2-3">Both "_dmarc.example.com"
and "_dmarc.signing.example.com" have DMARC Policy Records,
while "_dmarc.com" does not. If SPF or DKIM yield "pass" results, they still hav
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 indent="0" pn="section-appendix.b.4.2-4">To determine the Organizat
&quot;_dmarc.a.b.c.d.e.f.g.h.i.j.k.example.com&quot;, then query &quot;_dmarc.g. ional Domain for the Author Domain, query
h.i.j.k.example.com&quot; (skipping "_dmarc.a.b.c.d.e.f.g.h.i.j.k.example.com"; then query "_dmarc.g.h.i.j.k.example
the intermediate names), then query &quot;_dmarc.h.i.j.k.example.com&quot;, .com" (skipping
&quot;_dmarc.i.j.k.example.com&quot;, &quot;_dmarc.j.k.example.com&quot;, &quot; the intermediate names); then query "_dmarc.h.i.j.k.example.com",
_dmarc.k.example.com&quot;, "_dmarc.i.j.k.example.com", "_dmarc.j.k.example.com", "_dmarc.k.example.com",
&quot;_dmarc.example.com&quot;, and &quot;_dmarc.com&quot;. None of "_dmarc.example.com", and "_dmarc.com". None of
&quot;a.b.c.d.e.f.g.h.i.j.k.example.com&quot;, &quot;g.h.i.j.k.example.com&quot; "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
, &quot;h.i.j.k.example.com&quot;, om",
&quot;i.j.k.example.com&quot;, &quot;j.k.example.com&quot;, or &quot;k.example.c "i.j.k.example.com", "j.k.example.com", or "k.example.com" have a DMARC Policy R
om&quot; have a DMARC Policy Record.</t> ecord.</t>
<t>Since &quot;example.com&quot; is the last element of the DNS tree with a DMAR <t indent="0" pn="section-appendix.b.4.2-5">Since "example.com" is the
C Policy Record, last element of the DNS tree with a DMARC Policy Record,
it is the Organizational Domain for &quot;a.b.c.d.e.f.g.h.i.j.k.example.com&quot it is the Organizational Domain for "a.b.c.d.e.f.g.h.i.j.k.example.com".</t>
;.</t> <t indent="0" pn="section-appendix.b.4.2-6">For the RFC5321.MailFrom d
<t>For the RFC5321.MailFrom domain, the Organizational domain already found omain, the Organizational Domain already found
for &quot;example.com&quot; is &quot;example.com&quot;. SPF is aligned.</t> for "example.com" is "example.com". SPF is aligned.</t>
<t>For the DKIM-Authenticated Identifier, query &quot;_dmarc.signing.example.com <t indent="0" pn="section-appendix.b.4.2-7">For the DKIM-Authenticated
&quot;, &quot;_dmarc.example.com&quot;, Identifier, query "_dmarc.signing.example.com", "_dmarc.example.com",
and &quot;_dmarc.com&quot;. Both &quot;signing.example.com&quot; and &quot;examp and "_dmarc.com". Both "signing.example.com" and "example.com" have DMARC Policy
le.com&quot; have DMARC Policy Records, Records,
but &quot;example.com&quot; is the highest element in the tree with a DMARC Poli but "example.com" is the highest element in the tree with a DMARC Policy Record,
cy Record, so so
&quot;example.com&quot; is the Organizational Domain. Since this is also the Org "example.com" is the Organizational Domain. Since this is also the Organizationa
anizational Domain l 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 indent="0" pn="section-appendix.b.4.2-8">Since both SPF and DKIM ar
message has a DMARC pass result. If the results for both are not pass, then e aligned, they can be used to determine if the
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" numbered="true"
<section anchor="example-with-a-psd-dmarc-policy-record"><name>Example with a PS removeInRFC="false" toc="include" pn="section-appendix.b.4.3">
D DMARC Policy Record</name> <name slugifiedName="name-example-with-a-psd-dmarc-po">Example with a
<t>In rare cases, a PSD publishes a DMARC Policy Record with a psd tag, which th PSD DMARC Policy Record</name>
e tree <t indent="0" pn="section-appendix.b.4.3-1">In rare cases, a PSD publi
walk must take into account.</t> shes a DMARC Policy Record with a "psd" tag, which the Tree
<t>A Mail Receiver receives an email with:</t> Walk must take into account.</t>
<t indent="0" pn="section-appendix.b.4.3-2">A Mail Receiver receives a
<ul spacing="compact"> n email with:</t>
<li>Author Domain: giant.bank.example</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>RFC5321.MailFrom Domain: mail.giant.bank.example</li> -appendix.b.4.3-3">
<li>DKIM-Authenticated Identifier: mail.mega.bank.example</li> <li pn="section-appendix.b.4.3-3.1">Author Domain: giant.bank.exampl
</ul> e</li>
<t>In this case, &quot;_dmarc.bank.example&quot; has a DMARC Policy Record which <li pn="section-appendix.b.4.3-3.2">RFC5321.MailFrom Domain: mail.gi
includes the ant.bank.example</li>
&quot;psd=y&quot; tag, and &quot;_dmarc.example&quot; does not have a DMARC Poli <li pn="section-appendix.b.4.3-3.3">DKIM-Authenticated Identifier: m
cy Record. ail.mega.bank.example</li>
While &quot;_dmarc.giant.bank.example&quot; has a DMARC Policy Record without a </ul>
&quot;psd&quot; tag, <t indent="0" pn="section-appendix.b.4.3-4">In this case, "_dmarc.bank
&quot;_dmarc.mega.bank.example&quot; and &quot;_dmarc.mail.mega.bank.example&quo .example" has a DMARC Policy Record that includes the
t; have no DMARC Policy Records.</t> "psd=y" tag, and "_dmarc.example" does not have a DMARC Policy Record.
<t>Since the three domains are all different, tree walks find their Organization While "_dmarc.giant.bank.example" has a DMARC Policy Record without a "psd" tag,
al Domains "_dmarc.mega.bank.example" and "_dmarc.mail.mega.bank.example" have no DMARC Pol
icy Records.</t>
<t indent="0" pn="section-appendix.b.4.3-5">Since the three domains ar
e all different, Tree Walks find their Organizational Domains
to see which are aligned.</t> to see which are aligned.</t>
<t>For the Author Domain &quot;giant.bank.example&quot;, the tree walk finds the <t indent="0" pn="section-appendix.b.4.3-6">For the Author Domain "gia
DMARC Policy Record nt.bank.example", the Tree Walk finds both the DMARC Policy Record
at &quot;_dmarc.giant.bank.example&quot;, then the DMARC Policy Record at &quot; at "_dmarc.giant.bank.example" and then the DMARC Policy Record at "_dmarc.bank.
_dmarc.bank.example&quot;, and example" and
stops because of the &quot;psd=y&quot; flag. The Organizational Domain is &quot stops because of the "psd=y" flag. The Organizational Domain is "giant.bank.exa
;giant.bank.example&quot; because mple" because
it is the domain directly below the one with &quot;psd=y&quot;. 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 &quot;mail.giant.bank.example&quot;, the tree <t indent="0" pn="section-appendix.b.4.3-7">For the RFC5321.MailFrom d
walk finds no DMARC Policy omain "mail.giant.bank.example", the Tree Walk finds no DMARC Policy
Record at &quot;_dmarc.mail.giant.bank.example&quot;, 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
&quot;_dmarc.giant.bank.example&quot; and then the DMARC Policy Record at &quot; "_dmarc.giant.bank.example" and then the DMARC Policy Record at "_dmarc.bank.exa
_dmarc.bank.example&quot;, and mple" and
stops because of the &quot;psd=y&quot; flag. Again the Organizational Domain is stops because of the "psd=y" flag. Again, the Organizational Domain is "giant.b
&quot;giant.bank.example&quot; because ank.example" because
it is the domain directly below the one with &quot;psd=y&quot;. 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 &quot;mail.mega.bank.example&quot;, the <t indent="0" pn="section-appendix.b.4.3-8">For the DKIM-Authenticated
tree walk finds no DMARC Policy Identifier "mail.mega.bank.example", the Tree Walk finds no DMARC Policy
Records at &quot;_dmarc.mail.mega.bank.example&quot; or &quot;_dmarc.mega.bank.e Records at "_dmarc.mail.mega.bank.example" or "_dmarc.mega.bank.example", then f
xample&quot;, then finds the DMARC inds the DMARC
Policy Record at &quot;_dmarc.bank.example&quot; and stops because of the &quot; Policy Record at "_dmarc.bank.example", and stops because of the "psd=y" flag.
psd=y&quot; flag. The Organizational Domain is "mega.bank.example", so DKIM is not aligned.</t>
The Organizational Domain is &quot;mega.bank.example&quot;, so DKIM is not align <t indent="0" pn="section-appendix.b.4.3-9">Since SPF is aligned, it c
ed.</t> an be used to determine if the message has a DMARC "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" numbered="true
<section anchor="utilization-of-aggregate-feedback-example"><name>Utilization of " removeInRFC="false" toc="include" pn="section-appendix.b.5">
Aggregate Feedback: Example</name> <name slugifiedName="name-utilization-of-aggregate-fe">Utilization of Ag
<t>Aggregate feedback is consumed by Domain Owners to enable their gregate Feedback: Example</name>
<t indent="0" pn="section-appendix.b.5-1">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 indent="0" pn="section-appendix.b.5-2">Data on email that only partia lly 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 indent="0" pn="section-appendix.b.5-3">Data on email that fails all u nderlying 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" numbered="true" removeInRFC="false" toc="i
<section anchor="rfc7849-changes"><name>Changes from RFC 7489</name> nclude" pn="section-appendix.c">
<t>This document is intended to render <xref target="RFC7489"></xref> obsolete. <name slugifiedName="name-changes-from-rfc-7489">Changes from RFC 7489</na
As one might guess, me>
that means there are significant differences between RFC 7489 and this <t indent="0" pn="section-appendix.c-1">This document is intended to rende
r <xref target="RFC7489" format="default" sectionFormat="of" derivedContent="RFC
7489"/> obsolete. As one might guess,
that means there are significant differences between <xref target="RFC7489" form
at="default" sectionFormat="of" derivedContent="RFC7489"/> and this
document. This section will summarize those changes.</t> document. This section will summarize those changes.</t>
<section anchor="informational-vs-standards-track" numbered="true" removeI
<section anchor="informational-vs-standards-track"><name>Informational vs. Stand nRFC="false" toc="include" pn="section-appendix.c.1">
ards Track</name> <name slugifiedName="name-informational-vs-standards-">Informational vs.
<t>RFC 7489 was not the product of any IETF work stream, but was instead publish Standards Track</name>
ed into <t indent="0" pn="section-appendix.c.1-1"><xref target="RFC7489" format=
the RFC series by the Independent Submissions Editor and is classified as an Inf "default" sectionFormat="of" derivedContent="RFC7489"/> was not the product of a
ormational ny IETF work stream but was instead published into
the RFC Series by the Independent Submissions Editor and classified as an Inform
ational
RFC.</t> RFC.</t>
<t>This document, by contrast, is intended to be Internet Standards Track.</t> <t indent="0" pn="section-appendix.c.1-2">This document, by contrast, is
</section> an Internet Standards Track document.</t>
</section>
<section anchor="changes-to-terminology-and-definitions"><name>Changes to Termin <section anchor="changes-to-terminology-and-definitions" numbered="true" r
ology and Definitions</name> emoveInRFC="false" toc="include" pn="section-appendix.c.2">
<t>The following changes were made to the Terminology and Definitions section.</ <name slugifiedName="name-changes-to-terminology-and-">Changes to Termin
t> ology and Definitions</name>
<t indent="0" pn="section-appendix.c.2-1">The following changes were mad
<section anchor="terms-added"><name>Terms Added</name> e to the "Terminology and Definitions" section.</t>
<t>These terms were added:</t> <section anchor="terms-added" numbered="true" removeInRFC="false" toc="i
nclude" pn="section-appendix.c.2.1">
<ul spacing="compact"> <name slugifiedName="name-terms-added">Terms Added</name>
<li>Domain Owner Assessment Policy</li> <t indent="0" pn="section-appendix.c.2.1-1">These terms were added:</t
<li>Enforcement</li> >
<li>Monitoring Mode</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>Non-existent Domains</li> -appendix.c.2.1-2">
<li>Public Suffix Domain (PSD)</li> <li pn="section-appendix.c.2.1-2.1">Domain Owner Assessment Policy</
<li>Public Suffix Operator (PSO)</li> li>
<li>PSO Controlled Domain Names</li> <li pn="section-appendix.c.2.1-2.2">Enforcement</li>
</ul> <li pn="section-appendix.c.2.1-2.3">Monitoring Mode</li>
</section> <li pn="section-appendix.c.2.1-2.4">Non-existent Domains</li>
<li pn="section-appendix.c.2.1-2.5">Public Suffix Domain (PSD)</li>
<section anchor="definitions-updated"><name>Definitions Updated</name> <li pn="section-appendix.c.2.1-2.6">Public Suffix Operator (PSO)</li
<t>These definitions were updated:</t> >
<li pn="section-appendix.c.2.1-2.7">PSO-Controlled Domain Names</li>
<ul spacing="compact"> </ul>
<li>Organizational Domain</li> </section>
<li>Report Receiver (renamed to Report Consumer)</li> <section anchor="definitions-updated" numbered="true" removeInRFC="false
</ul> " toc="include" pn="section-appendix.c.2.2">
</section> <name slugifiedName="name-definitions-updated">Definitions Updated</na
</section> me>
<t indent="0" pn="section-appendix.c.2.2-1">These definitions were upd
<section anchor="policy-determination"><name>Policy Discovery and Organizational ated:</t>
Domain Determination</name> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<t>The algorithms for DMARC policy discovery and for determining the Organizatio -appendix.c.2.2-2">
nal Domain <li pn="section-appendix.c.2.2-2.1">Organizational Domain</li>
have been changed. Specifically, reliance on a Public Suffix List (PSL) has been <li pn="section-appendix.c.2.2-2.2">Report Receiver (renamed to Repo
replaced rt Consumer)</li>
by a technique called a &quot;DNS Tree Walk&quot;, and the methodology for the D </ul>
NS Tree Walk is explained </section>
</section>
<section anchor="policy-determination" numbered="true" removeInRFC="false"
toc="include" pn="section-appendix.c.3">
<name slugifiedName="name-policy-discovery-and-organi">Policy Discovery
and Organizational Domain Determination</name>
<t indent="0" pn="section-appendix.c.3-1">The algorithms for DMARC polic
y discovery and for determining the Organizational Domain
have been changed. Specifically, reliance on a PSL has been replaced
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 <t indent="0" pn="section-appendix.c.3-2">The DNS Tree Walk also incorpo
d in rates PSD policy discovery, which was introduced in
<xref target="RFC9091"></xref>. That RFC was an Experimental RFC, and the result <xref target="RFC9091" format="default" sectionFormat="of" derivedContent="RFC90
s of that experiment were 91"/>. That RFC was an Experimental RFC, and the results of that 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" for mat="default" sectionFormat="of" derivedContent="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" format="default"
<t>These algorithm changes introduce the possibility of interoperability issues sectionFormat="of" derivedContent="RFC9091"/> an Experimental RFC.</t>
where a <t indent="0" pn="section-appendix.c.3-3">These algorithm changes introd
uce 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" format="default" sectionFormat="of" derivedContent="
DMARC and relying on a PSL might arrive at a different answer.</t> RFC7489"/>
<t>This issue is entirely avoided by the use of Strict Alignment and publishing and relying on a PSL might arrive at a different answer.</t>
explicit <t indent="0" pn="section-appendix.c.3-4">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>
</section> </section>
<section anchor="reporting" numbered="true" removeInRFC="false" toc="inclu
<section anchor="reporting"><name>Reporting</name> de" pn="section-appendix.c.4">
<t>Discussion of both aggregate and failure reporting have been moved to separat <name slugifiedName="name-reporting">Reporting</name>
e documents <t indent="0" pn="section-appendix.c.4-1">Discussion of both aggregate a
nd 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 <t indent="0" pn="section-appendix.c.4-2">In addition, the ability to sp
s been removed.</t> ecify a maximum report size in the DMARC URI has been removed.</t>
</section> </section>
<section anchor="tags" numbered="true" removeInRFC="false" toc="include" p
<section anchor="tags"><name>Tags</name> n="section-appendix.c.5">
<t>Several tags have been added to the &quot;DMARC Policy Record Format&quot; se <name slugifiedName="name-tags">Tags</name>
ction of this document since <t indent="0" pn="section-appendix.c.5-1">Several tags have been added t
RFC 7489 was published, and at the same time, several others were removed.</t> o the "DMARC Policy Record Format" section of this document since
<xref target="RFC7489" format="default" sectionFormat="of" derivedContent="RFC74
<section anchor="tags-added"><name>Tags Added</name> 89"/> was published, and at the same time, several others were removed.</t>
<section anchor="tags-added" numbered="true" removeInRFC="false" toc="in
<ul spacing="compact"> clude" pn="section-appendix.c.5.1">
<li>np - Policy for non-existent domains (Imported from <xref target="RFC9091">< <name slugifiedName="name-tags-added">Tags Added</name>
/xref>)</li> <dl spacing="normal" newline="false" indent="3" pn="section-appendix.c
<li>psd - Flag indicating whether a domain is a Public Suffix Domain</li> .5.1-1">
<li>t - Replacement for some pct tag functionality. See <xref target="removal-of <dt pn="section-appendix.c.5.1-1.1">np:</dt>
-the-pct-tag"></xref> for further discussion</li> <dd pn="section-appendix.c.5.1-1.2">Policy for non-existent domains
</ul> (imported from <xref target="RFC9091" format="default" sectionFormat="of" derive
</section> dContent="RFC9091"/>).</dd>
<dt pn="section-appendix.c.5.1-1.3">psd:</dt>
<section anchor="tags-removed"><name>Tags Removed</name> <dd pn="section-appendix.c.5.1-1.4">Flag indicating whether a domain
is a PSD.</dd>
<ul spacing="compact"> <dt pn="section-appendix.c.5.1-1.5">t:</dt>
<li>pct - Tag requesting application of DMARC policy to only a percentage of mes <dd pn="section-appendix.c.5.1-1.6">Replacement for some "pct" tag f
sages. See <xref target="removal-of-the-pct-tag"></xref> for discussion</li> unctionality. See <xref target="removal-of-the-pct-tag" format="default" section
<li>rf - Tag specifying requested format of failure reports</li> Format="of" derivedContent="Appendix A.6"/> for further discussion.</dd>
<li>ri - Tag specifying requested interval between aggregate reports</li> </dl>
</ul> </section>
</section> <section anchor="tags-removed" numbered="true" removeInRFC="false" toc="
</section> include" pn="section-appendix.c.5.2">
<name slugifiedName="name-tags-removed">Tags Removed</name>
<section anchor="expansion-of-domain-owner-actions-section"><name>Expansion of D <dl spacing="normal" newline="false" indent="3" pn="section-appendix.c
omain Owner Actions Section</name> .5.2-1">
<t>RFC 7489 had just two paragraphs in its Domain Owner Actions section, and whi <dt pn="section-appendix.c.5.2-1.1">pct:</dt>
le <dd pn="section-appendix.c.5.2-1.2">Tag requesting application of th
e DMARC policy to only a percentage of messages. See <xref target="removal-of-th
e-pct-tag" format="default" sectionFormat="of" derivedContent="Appendix A.6"/> f
or discussion.</dd>
<dt pn="section-appendix.c.5.2-1.3">rf:</dt>
<dd pn="section-appendix.c.5.2-1.4">Tag specifying requested format
of failure reports.</dd>
<dt pn="section-appendix.c.5.2-1.5">ri</dt>
<dd pn="section-appendix.c.5.2-1.6">Tag specifying requested interva
l between aggregate reports.</dd>
</dl>
</section>
</section>
<section anchor="expansion-of-domain-owner-actions-section" numbered="true
" removeInRFC="false" toc="include" pn="section-appendix.c.6">
<name slugifiedName="name-expansion-of-domain-owner-a">Expansion of Doma
in Owner Actions Section</name>
<t indent="0" pn="section-appendix.c.6-1"><xref target="RFC7489" format=
"default" sectionFormat="of" derivedContent="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 <t indent="0" pn="section-appendix.c.6-2">This document provides much mo
r, re detail and explanatory text to a Domain Owner,
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 indent="0" pn="section-appendix.c.6-3">In particular, this document m
email <bcp14>SHOULD NOT</bcp14> deploy a DMARC policy of p=reject. See <xref tar akes explicit that domains for general-purpose
get="interoperability-considerations"></xref> email <bcp14>SHOULD NOT</bcp14> deploy a DMARC policy of "p=reject". See <xref t
arget="interoperability-considerations" format="default" sectionFormat="of" deri
vedContent="Section 7.4"/>
for further discussion of this topic.</t> for further discussion of this topic.</t>
</section> </section>
<section anchor="report-generator-recommendations" numbered="true" removeI
<section anchor="report-generator-recommendations"><name>Report Generator Recomm nRFC="false" toc="include" pn="section-appendix.c.7">
endations</name> <name slugifiedName="name-report-generator-recommenda">Report Generator
<t>In the cases where a DMARC Policy Record specifies multiple destinations for Recommendations</name>
either aggregate <t indent="0" pn="section-appendix.c.7-1">In the cases where a DMARC Pol
reports or failure reports, RFC 7489 stated:</t> icy Record specifies multiple destinations for either aggregate
reports or failure reports, <xref target="RFC7489" format="default" sectionForma
<artwork><![CDATA[ Receivers **MAY** impose a limit on the number of URIs to wh t="of" derivedContent="RFC7489"/> stated:</t>
ich they <blockquote pn="section-appendix.c.7-2">Receivers <bcp14>MAY</bcp14> imp
will send reports but **MUST** support the ability to send to at least ose a limit on the number of URIs to which they
two. will send reports but <bcp14>MUST</bcp14> support the ability to send to at le
]]></artwork> ast
<t>This document in <xref target="dmarc-uris"></xref> says:</t> two.</blockquote>
<t indent="0" pn="section-appendix.c.7-3"><xref target="dmarc-uris" form
<artwork><![CDATA[ A report **SHOULD** be sent to each listed URI provided in t at="default" sectionFormat="of" derivedContent="Section 4.6"/> of this document
he DMARC includes this text:</t>
Policy Record. <blockquote pn="section-appendix.c.7-4">A report <bcp14>SHOULD</bcp14> b
]]></artwork> e sent to each listed URI provided in the DMARC
</section> Policy Record.</blockquote>
</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" numbered="true" removeI
endix A.5</name> nRFC="false" toc="include" pn="section-appendix.c.8">
<t>One of the appendices in RFC 7489, specifically <xref target="RFC7489" sectio <name slugifiedName="name-removal-of-rfc-7489-appendi">Removal of RFC 74
nFormat="bare" section="Appendix A.5"></xref>, 89, Appendix A.5</name>
<t indent="0" pn="section-appendix.c.8-1">One of the appendices in <xref
target="RFC7489" format="default" sectionFormat="of" derivedContent="RFC7489"/>
, specifically Appendix <xref target="RFC7489" sectionFormat="bare" section="A.5
" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7489#appendix-A.5"
derivedContent="RFC7489"/>,
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
&quot;Issues with ADSP in Operation&quot; 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 &quot;Historic&quot; 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" numbered="true" removeInRFC="fal
<section anchor="rfc-7489-errata-summary"><name>RFC 7489 Errata Summary</name> se" toc="include" pn="section-appendix.c.9">
<t>This document and its companion documents (<xref target="I-D.ietf-dmarc-aggre <name slugifiedName="name-rfc-7489-errata-summary">RFC 7489 Errata Summa
gate-reporting"></xref> ry</name>
and <xref target="I-D.ietf-dmarc-failure-reporting"></xref>) address the followi <t indent="0" pn="section-appendix.c.9-1">This document and its companio
ng errata n documents (<xref target="RFC9990" format="default" sectionFormat="of" derivedC
filed against <xref target="RFC7489"></xref> since that document's publication i ontent="RFC9990"/>
n March, and <xref target="RFC9991" format="default" sectionFormat="of" derivedContent="R
FC9991"/>) address the following errata
filed against <xref target="RFC7489" format="default" sectionFormat="of" derived
Content="RFC7489"/> since that document's publication in 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 <eref brackets="angle" target="https://www.rfc-editor.org/errata_search.php?rfc=
.rfc-editor.org/errata_search.php?rfc=7489</eref></t> 7489"/>.</t>
<section anchor="rfc-errata-erratum-id-5365-rfc-7489-section-7-2-1-1-htt
<section anchor="rfc-errata-erratum-id-5365-rfc-7489-section-7-2-1-1-https-www-r ps-www-rfc-editor-org-errata-eid5365" numbered="true" removeInRFC="false" toc="i
fc-editor-org-errata-eid5365"><name><eref target="https://www.rfc-editor.org/err nclude" pn="section-appendix.c.9.1">
ata/eid5365">RFC Errata, Erratum ID 5365, RFC 7489, Section 7.2.1.1</eref></name <name slugifiedName="name-rfc-errata-erratum-id-5365-">RFC Errata, Err
> atum ID 5365, RFC 7489, Section 7.2.1.1</name>
<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t> <t indent="0" pn="section-appendix.c.9.1-1">See <eref target="https://
</section> www.rfc-editor.org/errata/eid5365" brackets="angle"/>. This erratum is addressed
in <xref target="RFC9990" format="default" sectionFormat="of" derivedContent="R
<section anchor="rfc-errata-erratum-id-5371-rfc-7489-section-7-2-1-1-https-www-r FC9990"/>.</t>
fc-editor-org-errata-eid5371"><name><eref target="https://www.rfc-editor.org/err </section>
ata/eid5371">RFC Errata, Erratum ID 5371, RFC 7489, Section 7.2.1.1</eref></name <section anchor="rfc-errata-erratum-id-5371-rfc-7489-section-7-2-1-1-htt
> ps-www-rfc-editor-org-errata-eid5371" numbered="true" removeInRFC="false" toc="i
<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t> nclude" pn="section-appendix.c.9.2">
</section> <name slugifiedName="name-rfc-errata-erratum-id-5371-">RFC Errata, Err
atum ID 5371, RFC 7489, Section 7.2.1.1</name>
<section anchor="rfc-errata-erratum-id-5440-rfc-7489-sections-7-1-b-2-1-b-2-3-an <t indent="0" pn="section-appendix.c.9.2-1">See <eref target="https://
d-b-2-4-https-www-rfc-editor-org-errata-eid5440"><name><eref target="https://www www.rfc-editor.org/errata/eid5371" brackets="angle"/>. This erratum is addressed
.rfc-editor.org/errata/eid5440">RFC Errata, Erratum ID 5440, RFC 7489, Sections in <xref target="RFC9990" format="default" sectionFormat="of" derivedContent="R
7.1, B.2.1, B.2.3, and B.2.4</eref></name> FC9990"/>.</t>
<t>This erratum references several mentions in RFC 7489 of the &quot;v=&quot; ta </section>
g from the Domain Owner Assessment <section anchor="rfc-errata-erratum-id-5440-rfc-7489-sections-7-1-b-2-1-
Policy and/or its value, specifically mentions that were not, but should have be b-2-3-and-b-2-4-https-www-rfc-editor-org-errata-eid5440" numbered="true" removeI
en, &quot;v=DMARC1;&quot;. Some nRFC="false" toc="include" pn="section-appendix.c.9.3">
of those mentions are preserved in this document and those mentions have been ad <name slugifiedName="name-rfc-errata-erratum-id-5440-">RFC Errata, Err
dressed as per the atum ID 5440, RFC 7489, Section 7.1 and Appendices B.2.1, B.2.3, and B.2.4</name
erratum. The rest have moved to <xref target="I-D.ietf-dmarc-aggregate-reporting >
"></xref> and are addressed there.</t> <t indent="0" pn="section-appendix.c.9.3-1">See <eref target="https://
</section> www.rfc-editor.org/errata/eid5440" brackets="angle"/>. This erratum references s
everal mentions in <xref target="RFC7489" format="default" sectionFormat="of" de
<section anchor="rfc-errata-erratum-id-6439-rfc-7489-section-7-1-https-www-rfc-e rivedContent="RFC7489"/> of the "v=" tag from the Domain Owner Assessment
ditor-org-errata-eid6439"><name><eref target="https://www.rfc-editor.org/errata/ Policy and/or its value, specifically mentions that were not, but should have be
eid6439">RFC Errata, Erratum ID 6439, RFC 7489, Section 7.1</eref></name> en, "v=DMARC1;". Some
<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t> of those mentions are preserved in this document, and those mentions have been a
</section> ddressed as per the
erratum. The rest have moved to <xref target="RFC9990" format="default" sectionF
<section anchor="rfc-errata-erratum-id-5221-rfc-7489-appendix-c-https-www-rfc-ed ormat="of" derivedContent="RFC9990"/> and are addressed there.</t>
itor-org-errata-eid5221"><name><eref target="https://www.rfc-editor.org/errata/e </section>
id5221">RFC Errata, Erratum ID 5221, RFC 7489, Appendix C</eref></name> <section anchor="rfc-errata-erratum-id-6439-rfc-7489-section-7-1-https-w
<t>The regular expression pattern for IP addresses has been removed from this do ww-rfc-editor-org-errata-eid6439" numbered="true" removeInRFC="false" toc="inclu
cument and from de" pn="section-appendix.c.9.4">
<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t> <name slugifiedName="name-rfc-errata-erratum-id-6439-">RFC Errata, Err
</section> atum ID 6439, RFC 7489, Section 7.1</name>
<t indent="0" pn="section-appendix.c.9.4-1">See <eref target="https://
<section anchor="rfc-errata-erratum-id-5229-rfc-7489-appendix-c-https-www-rfc-ed www.rfc-editor.org/errata/eid6439" brackets="angle"/>. This erratum is addressed
itor-org-errata-eid5229"><name><eref target="https://www.rfc-editor.org/errata/e in <xref target="RFC9990" format="default" sectionFormat="of" derivedContent="R
id5229">RFC Errata, Erratum ID 5229, RFC 7489, Appendix C</eref></name> FC9990"/>.</t>
<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t> </section>
</section> <section anchor="rfc-errata-erratum-id-5221-rfc-7489-appendix-c-https-ww
w-rfc-editor-org-errata-eid5221" numbered="true" removeInRFC="false" toc="includ
<section anchor="rfc-errata-erratum-5495-rfc-7489-section-6-6-3-https-www-rfc-ed e" pn="section-appendix.c.9.5">
itor-org-errata-eid5495"><name><eref target="https://www.rfc-editor.org/errata/e <name slugifiedName="name-rfc-errata-erratum-id-5221-">RFC Errata, Err
id5495">RFC Errata, Erratum 5495, RFC 7489, Section 6.6.3</eref></name> atum ID 5221, RFC 7489, Appendix C</name>
<t>This erratum is in reference to the description of the process documented <t indent="0" pn="section-appendix.c.9.5-1">See <eref target="https://
in RFC 7489 for the applicable DMARC policy for an email message. The process www.rfc-editor.org/errata/eid5221" brackets="angle"/>. The regular expression pa
for doing this has drastically changed in DMARCbis, and so the text identified i ttern for IP addresses has been removed from this document and from
n <xref target="RFC9990" format="default" sectionFormat="of" derivedContent="RFC99
90"/>.</t>
</section>
<section anchor="rfc-errata-erratum-id-5229-rfc-7489-appendix-c-https-ww
w-rfc-editor-org-errata-eid5229" numbered="true" removeInRFC="false" toc="includ
e" pn="section-appendix.c.9.6">
<name slugifiedName="name-rfc-errata-erratum-id-5229-">RFC Errata, Err
atum ID 5229, RFC 7489, Appendix C</name>
<t indent="0" pn="section-appendix.c.9.6-1">See <eref target="https://
www.rfc-editor.org/errata/eid5229" brackets="angle"/>. This erratum is addressed
in <xref target="RFC9990" format="default" sectionFormat="of" derivedContent="R
FC9990"/>.</t>
</section>
<section anchor="rfc-errata-erratum-5495-rfc-7489-section-6-6-3-https-ww
w-rfc-editor-org-errata-eid5495" numbered="true" removeInRFC="false" toc="includ
e" pn="section-appendix.c.9.7">
<name slugifiedName="name-rfc-errata-erratum-5495-rfc">RFC Errata, Err
atum 5495, RFC 7489, Section 6.6.3</name>
<t indent="0" pn="section-appendix.c.9.7-1">See <eref target="https://
www.rfc-editor.org/errata/eid5495" brackets="angle"/>. This erratum is in refere
nce to the description of the process documented
in <xref target="RFC7489" format="default" sectionFormat="of" derivedContent="RF
C7489"/> for the applicable DMARC policy for an email message. 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-htt
<section anchor="rfc-errata-erratum-id-6485-rfc-7489-section-7-2-1-1-https-www-r ps-www-rfc-editor-org-errata-eid6485" numbered="true" removeInRFC="false" toc="i
fc-editor-org-errata-eid6485"><name><eref target="https://www.rfc-editor.org/err nclude" pn="section-appendix.c.9.8">
ata/eid6485">RFC Errata, Erratum ID 6485, RFC 7489, Section 7.2.1.1</eref></name <name slugifiedName="name-rfc-errata-erratum-id-6485-">RFC Errata, Err
> atum ID 6485, RFC 7489, Section 7.2.1.1</name>
<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t> <t indent="0" pn="section-appendix.c.9.8-1">See <eref target="https://
</section> www.rfc-editor.org/errata/eid6485" brackets="angle"/>. This erratum is addressed
in <xref target="RFC9990" format="default" sectionFormat="of" derivedContent="R
<section anchor="rfc-errata-erratum-id-6729-rfc-7489-section-3-2-https-www-rfc-e FC9990"/>.</t>
ditor-org-errata-eid6729"><name><eref target="https://www.rfc-editor.org/errata/ </section>
eid6729">RFC Errata, Erratum ID 6729, RFC 7489, Section 3.2</eref></name> <section anchor="rfc-errata-erratum-id-6729-rfc-7489-section-3-2-https-w
<t>This erratum is in reference to a search of the Public Suffix List (PSL) as p ww-rfc-editor-org-errata-eid6729" numbered="true" removeInRFC="false" toc="inclu
art of finding a DMARC de" pn="section-appendix.c.9.9">
<name slugifiedName="name-rfc-errata-erratum-id-6729-">RFC Errata, Err
atum ID 6729, RFC 7489, Section 3.2</name>
<t indent="0" pn="section-appendix.c.9.9-1">See <eref target="https://
www.rfc-editor.org/errata/eid6729" brackets="angle"/>. This erratum is in refere
nce to a search of the 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-htt
<section anchor="rfc-errata-erratum-id-7099-rfc-7489-section-7-2-1-1-https-www-r ps-www-rfc-editor-org-errata-eid7099" numbered="true" removeInRFC="false" toc="i
fc-editor-org-errata-eid7099"><name><eref target="https://www.rfc-editor.org/err nclude" pn="section-appendix.c.9.10">
ata/eid7099">RFC Errata, Erratum ID 7099, RFC 7489, Section 7.2.1.1</eref></name <name slugifiedName="name-rfc-errata-erratum-id-7099-">RFC Errata, Err
> atum ID 7099, RFC 7489, Section 7.2.1.1</name>
<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t> <t indent="0" pn="section-appendix.c.9.10-1">See <eref target="https:/
</section> /www.rfc-editor.org/errata/eid7099" brackets="angle"/>. This erratum is addresse
d in <xref target="RFC9990" format="default" sectionFormat="of" derivedContent="
<section anchor="rfc-errata-erratum-id-7100-rfc-7489-section-7-2-1-1-https-www-r RFC9990"/>.</t>
fc-editor-org-errata-eid7100"><name><eref target="https://www.rfc-editor.org/err </section>
ata/eid7100">RFC Errata, Erratum ID 7100, RFC 7489, Section 7.2.1.1</eref></name <section anchor="rfc-errata-erratum-id-7100-rfc-7489-section-7-2-1-1-htt
> ps-www-rfc-editor-org-errata-eid7100" numbered="true" removeInRFC="false" toc="i
<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t> nclude" pn="section-appendix.c.9.11">
</section> <name slugifiedName="name-rfc-errata-erratum-id-7100-">RFC Errata, Err
atum ID 7100, RFC 7489, Section 7.2.1.1</name>
<section anchor="rfc-errata-erratum-id-7835-rfc-7489-section-6-6-3-https-www-rfc <t indent="0" pn="section-appendix.c.9.11-1">See <eref target="https:/
-editor-org-errata-eid7835"><name><eref target="https://www.rfc-editor.org/errat /www.rfc-editor.org/errata/eid7100" brackets="angle"/>. This erratum is addresse
a/eid7835">RFC Errata, Erratum ID 7835, RFC 7489, Section 6.6.3</eref></name> d in <xref target="RFC9990" format="default" sectionFormat="of" derivedContent="
<t>This erratum is in reference to the description of the process documented RFC9990"/>.</t>
in RFC 7489 for the applicable DMARC policy for an email message. The process </section>
for doing this has drastically changed in DMARCbis, and so the text identified i <section anchor="rfc-errata-erratum-id-7835-rfc-7489-section-6-6-3-https
n -www-rfc-editor-org-errata-eid7835" numbered="true" removeInRFC="false" toc="inc
lude" pn="section-appendix.c.9.12">
<name slugifiedName="name-rfc-errata-erratum-id-7835-">RFC Errata, Err
atum ID 7835, RFC 7489, Section 6.6.3</name>
<t indent="0" pn="section-appendix.c.9.12-1">See <eref target="https:/
/www.rfc-editor.org/errata/eid7835" brackets="angle"/>. This erratum is in refer
ence to the description of the process documented
in <xref target="RFC7489" format="default" sectionFormat="of" derivedContent="RF
C7489"/> for the applicable DMARC policy for an email message. 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-ww
<section anchor="rfc-errata-erratum-id-7865-rfc-7489-appendix-c-https-www-rfc-ed w-rfc-editor-org-errata-eid7865" numbered="true" removeInRFC="false" toc="includ
itor-org-errata-eid7865"><name><eref target="https://www.rfc-editor.org/errata/e e" pn="section-appendix.c.9.13">
id7865">RFC Errata, Erratum ID 7865, RFC 7489, Appendix C</eref></name> <name slugifiedName="name-rfc-errata-erratum-id-7865-">RFC Errata, Err
<t>The regular expression pattern for IP addresses has been removed from this do atum ID 7865, RFC 7489, Appendix C</name>
cument and from <t indent="0" pn="section-appendix.c.9.13-1">See <eref target="https:/
<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t> /www.rfc-editor.org/errata/eid7865" brackets="angle"/>. The regular expression p
</section> attern for IP addresses has been removed from this document and from
<xref target="RFC9990" format="default" sectionFormat="of" derivedContent="RFC99
<section anchor="rfc-errata-erratum-id-5151-rfc-7489-section-1-https-www-rfc-edi 90"/>.</t>
tor-org-errata-eid5151"><name><eref target="https://www.rfc-editor.org/errata/ei </section>
d5151">RFC Errata, Erratum ID 5151, RFC 7489, Section 1</eref></name> <section anchor="rfc-errata-erratum-id-5151-rfc-7489-section-1-https-www
<t>This erratum is in reference to the Introduction section of RFC 7489. -rfc-editor-org-errata-eid5151" numbered="true" removeInRFC="false" toc="include
That section has been substantially rewritten in DMARCbis, and the text " pn="section-appendix.c.9.14">
<name slugifiedName="name-rfc-errata-erratum-id-5151-">RFC Errata, Err
atum ID 5151, RFC 7489, Section 1</name>
<t indent="0" pn="section-appendix.c.9.14-1">See <eref target="https:/
/www.rfc-editor.org/errata/eid5151" brackets="angle"/>. This erratum is in refer
ence to the Introduction section of <xref target="RFC7489" format="default" sect
ionFormat="of" derivedContent="RFC7489"/>.
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-ww
<section anchor="rfc-errata-erratum-id-5774-rfc-7489-appendix-c-https-www-rfc-ed w-rfc-editor-org-errata-eid5774" numbered="true" removeInRFC="false" toc="includ
itor-org-errata-eid5774"><name><eref target="https://www.rfc-editor.org/errata/e e" pn="section-appendix.c.9.15">
id5774">RFC Errata, Erratum ID 5774, RFC 7489, Appendix C</eref></name> <name slugifiedName="name-rfc-errata-erratum-id-5774-">RFC Errata, Err
<t>Addressed in <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t> atum ID 5774, RFC 7489, Appendix C</name>
</section> <t indent="0" pn="section-appendix.c.9.15-1">See <eref target="https:/
</section> /www.rfc-editor.org/errata/eid5774" brackets="angle"/>. This erratum is addresse
d in <xref target="RFC9990" format="default" sectionFormat="of" derivedContent="
<section anchor="general-editing-and-formatting"><name>General Editing and Forma RFC9990"/>.</t>
tting</name> </section>
<t>A great deal of the content from RFC 7489 was preserved in this document, but </section>
much <section anchor="general-editing-and-formatting" numbered="true" removeInR
of it was subject to either minor editing, re-ordering of sections, and/or both. FC="false" toc="include" pn="section-appendix.c.10">
</t> <name slugifiedName="name-general-editing-and-formatt">General Editing a
</section> nd Formatting</name>
</section> <t indent="0" pn="section-appendix.c.10-1">A great deal of the content f
rom <xref target="RFC7489" format="default" sectionFormat="of" derivedContent="R
<section anchor="acknowledgements" numbered="false"><name>Acknowledgements</name FC7489"/> was preserved in this document, but much
> of it was subject to minor editing and the reordering of sections, or both.</t>
<t>This reworking of the DMARC mechanism specified in <xref target="RFC7489"></x </section>
ref> is the </section>
result of contributions from many participants in the IETF Working Group <section anchor="acknowledgements" numbered="false" removeInRFC="false" toc=
dedicated to this effort. Although the contributors are too numerous to "include" pn="section-appendix.d">
mention, significant contributions were made by Kurt Andersen, Laura Atkins, <name slugifiedName="name-acknowledgements">Acknowledgements</name>
Seth Blank, Alex Brotman, Dave Crocker, Douglas E. Foster, Ned Freed, <t indent="0" pn="section-appendix.d-1">The reworking of the DMARC mechani
Mike Hammer, Steven M. Jones, Scott Kitterman, Murray S. Kucherawy, sm specified in <xref target="RFC7489" format="default" sectionFormat="of" deriv
Barry Leiba, Alessandro Vesely, and Tim Wicinski.</t> edContent="RFC7489"/>
<t>The authors and contributors also recognize that this document would not is the result of contributions from many participants in the DMARC Working
Group. Although the contributors are too numerous to
mention, significant contributions were made by <contact fullname="Kurt Andersen
"/>, <contact fullname="Laura Atkins"/>, <contact fullname="Seth Blank"/>, <cont
act fullname="Alex Brotman"/>, <contact fullname="Dave Crocker"/>, <contact full
name="Douglas E. Foster"/>, <contact fullname="Ned Freed"/>, <contact fullname="
Mike Hammer"/>, <contact fullname="Steven M. Jones"/>, <contact fullname="Scott
Kitterman"/>, <contact fullname="Murray S. Kucherawy"/>, <contact fullname="Barr
y Leiba"/>, <contact fullname="Alessandro Vesely"/>, and <contact fullname="Tim
Wicinski"/>.</t>
<t indent="0" pn="section-appendix.d-2">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" format="default" sectionFormat="of" derivedContent="RFC74 89"/>. The Acknowledgements section from that document is preserved
in full below.</t> in full below.</t>
</section> </section>
<section anchor="acknowledgements-rfc7489" numbered="false" removeInRFC="fal
<section anchor="acknowledgements-rfc7489" numbered="false"><name>Acknowledgemen se" toc="include" pn="section-appendix.e">
ts - RFC 7489</name> <name slugifiedName="name-acknowledgements-rfc-7489">Acknowledgements - RF
<t>DMARC and the draft version of this document submitted to the C 7489</name>
Independent Submission Editor were the result of lengthy efforts by <t indent="0" pn="section-appendix.e-1">DMARC and the draft version of thi
an informal industry consortium: DMARC.org (see <eref target="https://dmarc.org" s document submitted to the Independent
>https://dmarc.org</eref>). Submission Editor were the result of lengthy efforts by an informal industry
Participating companies included Agari, American Greetings, AOL, Bank consortium: DMARC.org (see <eref target="https://dmarc.org" brackets="angle"/>).
of America, Cloudmark, Comcast, Facebook, Fidelity Investments, Participating companies included Agari, American
Google, JPMorgan Chase &amp; Company, LinkedIn, Microsoft, Netease, Greetings, AOL, Bank of America, Cloudmark, Comcast, Facebook, Fidelity
PayPal, ReturnPath, The Trusted Domain Project, and Yahoo!. Although Investments, Google, JPMorgan Chase &amp; Company, LinkedIn, Microsoft,
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 Midgen"/>. The
<t>Additional contributions within the IETF context were made by Kurt 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 fullname="J.D. Falk"/>.</t>
J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, <t indent="0" pn="section-appendix.e-2">Additional contributions within th
S. Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull.</t> e IETF context were made by <contact fullname="Kurt Andersen"/>, <contact fullna
</section> me="Michael Jack Assels"/>,
<contact fullname="Les Barstow"/>, <contact fullname="Anne Bennett"/>,
</back> <contact fullname="Jim Fenton"/>, <contact fullname="J. Gomez"/>, <contact fulln
ame="Mike Jones"/>, <contact fullname="Scott Kitterman"/>, <contact fullname="El
iot Lear"/>, <contact fullname="John Levine"/>, <contact fullname="S. Moonesamy"
/>, <contact fullname="Rolf Sonneveld"/>, <contact fullname="Henry Timmes"/>, an
d <contact fullname="Stephen J. Turnbull"/>.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.f">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author initials="T." surname="Herr" fullname="Todd M. Herr" role="editor"
>
<organization showOnFrontPage="true">Valimail</organization>
<address>
<email>todd@someguyinva.com</email>
</address>
</author>
<author initials="J." surname="Levine" fullname="John Levine" role="editor
">
<organization showOnFrontPage="true">Standcore LLC</organization>
<address>
<email>standards@standcore.com</email>
</address>
</author>
</section>
</back>
</rfc> </rfc>
 End of changes. 464 change blocks. 
2988 lines changed or deleted 5467 lines changed or added

This html diff was produced by rfcdiff 1.48.