<?xml version="1.0"encoding="utf-8"?> <!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc version="3" ipr="trust200902" docName="draft-ietf-dmarc-dmarcbis-41" number="9989" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" obsoletes="7489, 9091"indexInclude="true">updates="" consensus="true" tocInclude="true" symRefs="true" sortRefs="true"> <front> <!--[rfced] Note that we have updated the document title and the short title that appears in the running header in the PDF output as follows. Original (Document Title): Domain-based Message Authentication, Reporting, and Conformance (DMARC) Current: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) ... Original (Short title): DMARCbis Current: DMARC --> <titleabbrev="DMARCbis">Domain-basedabbrev="DMARC">Domain-Based Message Authentication, Reporting, and Conformance(DMARC)</title><seriesInfo value="draft-ietf-dmarc-dmarcbis-41" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo>(DMARC)</title> <seriesInfo name="RFC" value="9989"/> <author initials="T."surname="Herr (ed)"surname="Herr" fullname="Todd M.Herr"><organization>Valimail</organization><address><postal><street></street> </postal><email>todd@someguyinva.com</email> </address></author><authorHerr" role="editor"> <organization>Valimail</organization> <address> <email>todd@someguyinva.com</email> </address> </author> <author initials="J."surname="Levine (ed)"surname="Levine" fullname="JohnLevine"><organization>Standcore LLC</organization><address><postal><street></street> </postal><email>standards@standcore.com</email> </address></author><date/> <area>Application</area> <workgroup>DMARC</workgroup>Levine" role="editor"> <organization>Standcore LLC</organization> <address> <email>standards@standcore.com</email> </address> </author> <date month="May" year="2026"/> <area>ART</area> <workgroup>dmarc</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t>This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol.</t> <t>DMARC permits the owner of an email's Author Domain to enable validation of the domain'suse,use to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failedvalidation,validation and to request reports about the use of the domain name.Mail receivingMail-receiving organizations can use this information when evaluating handling choices for incoming mail.</t> <t>This document obsoletes RFCs 7489 and 9091.</t> </abstract> </front> <middle> <section anchor="introduction"><name>Introduction</name><t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: The source for this draft is maintained on GitHub at: <eref target="https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis">https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis</eref></t><t>Abusive email often includes unauthorized and deceptive use of a domain name in the"From""From" header field defined insection 3.6.2 of<xreftarget="RFC5322"></xref>target="RFC5322" section="3.6.2"/> 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 Policy Framework (SPF) <xreftarget="RFC7208"></xref>target="RFC7208"/> and DomainKeys Identified Mail (DKIM) <xreftarget="RFC6376"></xref>target="RFC6376"/> protocols provide domain-level authentication but are not directly associated with the RFC5322.From domain, also known as the<eref target="#author-domain">Author Domain</eref>.<xref target="author-domain">Author Domain</xref>. DMARC leverages these two protocols, providing a method for Domain Owners to publish a DNS TXT record describing the email authentication policies for the Author Domain and to request specific handling for messages using that domain that fail validation checks. These DNS records are called<eref target="#dmarc-policy-record">DMARC<xref target="dmarc-policy-record">DMARC PolicyRecords</eref>.</t>Records</xref>.</t> <t>As with SPF and DKIM, DMARC validation results in a verdict of either"pass""pass" or"fail"."fail". A DMARC result of"pass""pass" requires not only an SPF or DKIM pass verdict for the emailmessage,message but also and more importantly that the domain associated with the SPF or DKIM pass be"aligned""aligned" with the Author Domain in one of two modes- "relaxed"-- "relaxed" or"strict"."strict". Domains are said to be in"relaxed alignment""relaxed alignment" if they have the same<eref target="#organizational-domain">Organizational Domain</eref>;<xref target="organizational-domain">Organizational Domain</xref>; a domain's Organizational Domain is the domain at the top of the namespace hierarchy for that domain while having the same administrative authority as that domain. On the other hand, domains are in"strict alignment""strict alignment" if and only if they are identical. The choice of required alignment mode is left to the<eref target="#domain-owner">Domain Owner</eref><xref target="domain-owner">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 has been validated for that message as authorized by the Domain Owner. Such authorization does not carry an explicit or implicit value assertion about that message or about the Domain Owner, and so a DMARC pass by itself does not guarantee that delivery to the recipient'sInboxinbox would be safe or desirable. For a mail-receiving organization participating in DMARC, a message that passes DMARC validation is part of a message stream reliably associated with the Author Domain. Therefore, reputation assessment of that stream by the mail-receiving organization can assume the use of that Author Domain is authorized by the Domain Owner.</t> <t>On the other hand, a message that fails this validation is not necessarily associated with the Author Domain and so should not affect the Author Domain's reputation. The phrase"not"not necessarilyassociated"associated" was purposely chosen here, as it isimportatntimportant to understand that some messages making authorized use of the Author Domain can still fail DMARC validation checks. <xreftarget="RFC7960"></xref>target="RFC7960"/> and <xreftarget="other-topics"></xref>target="other-topics"/> of this document both discuss reasons why such failures may happen. Because of this, a mail-receiving organization that performs DMARC validation can choose to honor the Domain Owner's requested message handling for validation failures, but it is not required to do so. DMARC is commonly used as one input to more complex filtering decisions, and so the mail-receiving organization might choose different actions entirely.</t> <t>DMARC, in the associated documents <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>target="RFC9990"/> and <xreftarget="I-D.ietf-dmarc-failure-reporting"></xref> documents,target="RFC9991"/>, also specifies a reporting framework. Using it, a mail-receiving organization can generate regular reports about messages that use Author 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 Owners can use these reports, especially the aggregate reports, not only to identify sources of mail attempting to fraudulently use theirdomain,domain but also (and perhaps more importantly) to flag and fix gaps in their own authentication practices. However, as with honoring the Domain Owner's stated mail handling preference, a mail-receiving organization supporting DMARC is under no obligation to send requestedreports, althoughreports; although, it is recommended that they do send aggregate reports.</t> <t>The use of DMARC creates some interoperability challenges that require due consideration before deployment, particularly with configurations that can cause mail to be rejected. These are discussed in <xreftarget="other-topics"></xref>.</t>target="other-topics"/>.</t> </section> <section anchor="requirements"><name>Requirements</name> <t>The following sections describe topics that guide the specification of DMARC.</t> <section anchor="high-level-goals"><name>High-Level Goals</name> <t>DMARC has the following high-level goals:</t> <ul> <li><t>Allow<eref target="#domain-owner">Domain Owners</eref><xref target="domain-owner">Domain Owners</xref> and<eref target="#public-suffix-operator">Public<xref target="public-suffix-operator">Public Suffix Operators(PSOs)</eref>(PSOs)</xref> to validate their email authentication deployments.</t> </li> <li><t>Allow Domain Owners and PSOs to assert their desired message handling for validation failures on messages purporting to have authorship within the domain.</t> </li> <li><t>Minimize implementation complexity for both senders and receivers.</t> </li> <li><t>Reduce the amount of successfully delivered spoofed emails.</t> </li> <li><t>Work at Internet scale.</t> </li> </ul> </section> <section anchor="anti-phishing"><name>Anti-Phishing</name> <t>DMARC is designed to prevent the unauthorized use of the<eref target="#author-domain">Author Domain</eref><xref target="author-domain">Author Domain</xref> of an email message, a technique known as"spoofing"."spoofing". Such unauthorized usage can frequently be found in messages impersonating a domain belonging to a business entity, i.e., messages that are meant to entice the recipient to provide sensitive information, such as usernames, passwords, and financial account information. These spoofed messages are commonly referred to as"phishing".</t>"phishing".</t> <t>DMARC can only be used to combat specific forms of exact-domain spoofing directly. DMARC does not attempt to solve all problems with spoofed or otherwise fraudulent emails. In particular, it does not address the use of visually similar domain names or abuse of the RFC5322.From human-readabledisplay-name,display name, as defined in <xref target="RFC5322" sectionFormat="of"section="3.4"></xref>.</t>section="3.4"/>.</t> </section> <section anchor="scalability"><name>Scalability</name> <t>Scalability is a significant issue for systems that need to operate in an environment as widely deployed as current SMTP email. For this reason, DMARC seeks to avoid the need for third parties or pre-sending agreements between senders and receivers. This preserves the positive aspects of the current email infrastructure.</t> <t>Although DMARC does not introduce third-party senders (namely external agents authorized to send on behalf of an operator) to the email-handling flow, it also does not preclude them. Such third parties are free to provide services in conjunction with DMARC.</t> </section> <section anchor="out-of-scope"><name>Out of Scope</name> <t>Several topics and issues are specifically out of scope of this work. These include the following:</t> <ul> <li><t>Different treatment of messages that are not authenticated (e.g., those that have no DKIM signature or those sent using an<eref target="#author-domain">Author Domain</eref><xref target="author-domain">Author Domain</xref> for which no<eref target="#dmarc-policy-record">DMARC<xref target="dmarc-policy-record">DMARC PolicyRecord</eref> exists)Record</xref> exists versus those that fail validation;</t> </li> <li><t>Evaluation of anything other than the RFC5322.From header field;</t> </li> <li><t>Multiple reporting formats;</t> </li> <li><t>Publishing policy other than via the DNS;</t> </li> <li><t>Reporting or otherwise evaluating other than the last-hop IP address;</t> </li> <li><t>Attacks in thedisplay-namedisplay name portions of the RFC5322.From header field, also known as"display name""display name" attacks;</t> </li> <li><t>Authentication of entities other than domains, since DMARC is built upon SPF and DKIM, which authenticate domains; and</t> </li> <li><t>Content analysis.</t> </li> </ul> </section> </section> <section anchor="terminology"><name>Terminology and Definitions</name> <t>This section defines terms used in the rest of the document.</t> <section anchor="conventions-used-in-this-document"><name>Conventions Used in This Document</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"></xref>target="RFC2119"/> <xreftarget="RFC8174"></xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>Readers are encouraged to be familiar with the contents of <xreftarget="RFC5598"></xref>.target="RFC5598"/>. In particular, that document defines various roles in the messaging infrastructure that can appear the same or separate in various contexts. For example, a<eref target="#domain-owner">Domain Owner</eref><xref target="domain-owner">Domain Owner</xref> could, 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 another role. This document does not address the distinctions among such roles; the reader is encouraged to become familiar with that material before continuing.</t> </section> <section anchor="definitions"><name>Definitions</name> <t>The following sections define the terms used in this document.</t> <section anchor="authenticated-identifiers"><name>Authenticated Identifiers</name> <t>Authenticated Identifiers are those domain-level identifiers for which authorized use is validated using a supported<eref target="#authentication-mechanisms">authentication mechanism</eref>.</t><xref target="authentication-mechanisms">authentication mechanism</xref>.</t> </section> <section anchor="author-domain"><name>Author Domain</name> <t>The Author Domain is the domain name of the apparent author as extracted from the RFC5322.From header field.</t> </section> <section anchor="dkim-signing-domain"><name>DKIM Signing Domain</name> <t>The DKIM Signing Domain is the domain name that is the value of the"d""d" tag in a validated DKIM-Signature header field in an email message.</t> </section> <section anchor="spf-domain"><name>SPF Domain</name><t>SPF,<t>SPF <xreftarget="RFC7208"></xref>,target="RFC7208"/> can validate the uses of both the domain found in an SMTP <xreftarget="RFC5321"></xref>target="RFC5321"/> HELO/EHLO command (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.Section 2.4 of<xreftarget="RFC7208"></xref>section="2.4" target="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 the local-part"postmaster""postmaster" and the HELO identity.</t> <t>The term"SPF Domain""SPF Domain" when used in this document refers to anSPF validatedSPF-validated MAIL FROM identity.</t> </section> <section anchor="dmarc-policy-domain"><name>DMARC Policy Domain</name> <t>The DMARC Policy Domain is the domain name at which an applicable<eref target="#dmarc-policy-record">DMARC<xref target="dmarc-policy-record">DMARC PolicyRecord</eref>Record</xref> is discovered for the<eref target="#author-domain">Author Domain</eref><xref target="author-domain">Author Domain</xref> of an email message.</t> </section> <section anchor="dmarc-policy-record"><name>DMARC Policy Record</name> <t>A DMARC Policy Record is a DNS TXT record published by a<eref target="#domain-owner">Domain Owner</eref><xref target="domain-owner">Domain Owner</xref> or<eref target="#public-suffix-operator">Public<xref target="public-suffix-operator">Public Suffix Operator(PSO)</eref>(PSO)</xref> to enable validation of an<eref target="#author-domain">Author Domain's</eref><xref target="author-domain">Author Domain's</xref> use, to indicate the Domain Owner's or PSO's message handling preference regarding failed validation, and optionally to request reports about the use of the Author Domain.</t> </section> <section anchor="domain-owner"><name>Domain Owner</name><t>An<t>A Domain Owner is an entity or organization that has control of a given DNS domain, usually by holding its registration. Domain Owners range from complex, globally distributed organizations to service providers working on behalf of non-technical clients to individuals responsible for maintaining personal domains. This specification uses this term as analogous to an Administrative Management Domain (ADMD), as defined in <xreftarget="RFC5598"></xref>.target="RFC5598"/>. It can also refer to delegates, such as ReportConsumersConsumers, when those are outside of their immediate management domain.</t> </section> <section anchor="domain-owner-policy"><name>Domain Owner Assessment Policy</name> <t>The Domain Owner Assessment Policy is the message handling preference expressed in a<eref target="#dmarc-policy-record">DMARC<xref target="dmarc-policy-record">DMARC PolicyRecord</eref>Record</xref> by the<eref target="#domain-owner">Domain Owner</eref><xref target="domain-owner">Domain Owner</xref> regarding failed validation of the<eref target="#author-domain">Author Domain</eref> is called the "Domain Owner Assessment Policy".<xref target="author-domain">Author Domain</xref>. Possible values are described in <xreftarget="policy-record-format"></xref>.</t>target="policy-record-format"/>.</t> </section> <section anchor="enforcement"><name>Enforcement</name> <t>Enforcement describes a state where the existing<eref target="#domain-owner-policy">Domain<xref target="domain-owner-policy">Domain Owner AssessmentPolicy</eref>Policy</xref> for an<eref target="#organizational-domain">Organizational Domain</eref><xref target="organizational-domain">Organizational Domain</xref> and all subdomains below it is not"p=none"."p=none". This state means that the Organizational Domain and its subdomains can only be used as<eref target="#author-domain">Author Domains</eref><xref target="author-domain">Author Domains</xref> if they are properly validated using the DMARC mechanism.</t> <t>Historically, Domain Owner Assessment Policies of"p=quarantine""p=quarantine" or"p=reject""p=reject" have been higher value signals to<eref target="#mail-receiver">Mail Receivers</eref>.<xref target="mail-receiver">Mail Receivers</xref>. Messages with Author Domains for which such policies exist that are not validated using the DMARC mechanism will not reach the inbox at Mail Receivers that participate in DMARC and honor the Domain Owner's expressed handling preference.</t> </section> <section anchor="identifier-alignment"><name>Identifier Alignment</name> <t>DMARC describes the concept of alignment between the<eref target="#author-domain">Author Domain</eref><xref target="author-domain">Author Domain</xref> and an<eref target="#authenticated-identifiers">Authenticated Identifier</eref>,<xref target="authenticated-identifiers">Authenticated Identifier</xref> and requires such Identifier Alignment between the two for a message to achieve a DMARC pass. DMARC defines two states for alignment.</t> <section anchor="relaxed-alignment"><name>Relaxed Alignment</name> <t>When the<eref target="#author-domain">Author Domain</eref><xref target="author-domain">Author Domain</xref> has the same<eref target="#organizational-domain">Organizational Domain</eref><xref target="organizational-domain">Organizational Domain</xref> as an<eref target="#authenticated-identifier">Authenticated Identifier</eref>,<xref target="authenticated-identifiers">Authenticated Identifier</xref>, the two are said to be in relaxed alignment.</t> </section> <section anchor="strict-alignment"><name>Strict Alignment</name> <t>When the<eref target="#author-domain">Author Domain</eref><xref target="author-domain">Author Domain</xref> is identical to an<eref target="#authenticated-identifier">Authenticated Identifier</eref>,<xref target="authenticated-identifiers">Authenticated Identifier</xref>, the two are said to be in strict alignment.</t> </section> </section> <section anchor="mail-receiver"><name>Mail Receiver</name> <t>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> </section> <section anchor="monitoring-mode"><name>Monitoring Mode</name> <t>Monitoring Mode describes a state where the existing<eref target="#domain-owner-policy">Domain<xref target="domain-owner-policy">Domain Owner AssessmentPolicy</eref>Policy</xref> for an<eref target="#organizational-domain">Organizational Domain</eref><xref target="organizational-domain">Organizational Domain</xref> and all subdomains below it is"p=none","p=none", and the<eref target="#domain-owner">Domain Owner</eref><xref target="domain-owner">Domain Owner</xref> is receiving aggregate reports for the Organizational Domain. While the use of the Organizational Domain and all its subdomains as<eref target="#author-domain">Author Domains</eref><xref target="author-domain">Author Domains</xref> can still be validated by a<eref target="#mail-receiver">Mail Receiver</eref><xref target="mail-receiver">Mail Receiver</xref> deploying the DMARC mechanism, the Domain Owner expresses no handling preference for messages that fail DMARC validation.TheHowever, the Domain Owneris, however,is using the content of the DMARC aggregate reports to make any needed adjustments to the authentication practices for its mail streams.</t> </section> <sectionanchor="non-existent-domains"><name>Non-existentanchor="non-existent-domains"><name>Non-Existent Domains</name> <t>For DMARC purposes, a non-existent domain is consistent with the term's meaning as described in <xreftarget="RFC8020"></xref>.target="RFC8020"/>. That is, if the response code received for a query for a domain name is NXDOMAIN, then the domain name and any possible subdomains do not exist.</t> </section> <section anchor="organizational-domain"><name>Organizational Domain</name> <t>The Organizational Domain for any domain is akin to the ADMD described in <xreftarget="RFC5598"></xref>.target="RFC5598"/>. A domain's Organizational Domain is the domain at the top of the namespace hierarchy for that domain while having the same administrative authority as the domain. An Organizational Domain is determined by applying the algorithm found in <xreftarget="dns-tree-walk"></xref>.</t>target="dns-tree-walk"/>.</t> </section> <section anchor="public-suffix-domain"><name>Public Suffix Domain (PSD)</name> <t>Some domains allow the registration of subdomains that are"owned""owned" by independent organizations. Real-world examples of these domains are".com", ".org", ".us",".com", ".org", ".us", and".co.uk",".co.uk", to name just a few. These domains are called"Public"Public SuffixDomains"Domains" (PSDs). For example,"ietf.org""ietf.org" is a registered domain name, and".org"".org" is its PSD.</t> </section> <section anchor="public-suffix-operator"><name>Public Suffix Operator (PSO)</name> <t>A Public Suffix Operator is an organization that manages operations within a PSD, particularly the DNS records published for names at and under that domain name.</t> </section> <sectionanchor="pso-controlled-domain-names"><name>PSO Controlledanchor="pso-controlled-domain-names"><name>PSO-Controlled Domain Names</name> <t>PSO-Controlled Domain Names are names in the DNS that are managed by a PSO.PSO-controlledPSO-Controlled Domain Names may have one label (e.g.,".com")".com") or more (e.g.,".co.uk"),".co.uk"), depending on the PSD's policy.</t> </section> <section anchor="report-consumer"><name>Report Consumer</name> <t>A Report Consumer is an operator that receives reports from another operator implementing the reporting mechanisms described inthe documents<xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>target="RFC9990"/> and <xreftarget="I-D.ietf-dmarc-failure-reporting"></xref>.target="RFC9991"/>. This term applies collectively to the system components that receive and process these reports and the organizations that operate those components.</t> <!--[rfced] To clarify "designated third parties to so act", may we update the text as follows? Original: The DMARC mechanism permits a Domain Owner to act as a Report Consumer for its domain(s) and/or to designate third parties to so act. Perhaps: The DMARC mechanism permits a Domain Owner to act as a Report Consumer for its domain(s) and/or to designate a third party to act as a Report Consumer. --> <t>Report Consumers can receive reports concerning domains for which the Report Consumer is also the<eref target="#domain-owner">Domain Owner</eref><xref target="domain-owner">Domain Owner</xref> or<eref target="#public-suffix-operator">PSO</eref>,<xref target="public-suffix-operator">PSO</xref> or concerning domains that belong to another operator entirely. The DMARC mechanism permits a Domain Owner to act as a Report Consumer for its domain(s) and/or to designate third parties to so act. See <xreftarget="external-report-addresses"></xref>target="external-report-addresses"/> for further discussion of such designation.</t> </section> </section> </section> <section anchor="overview-and-key-concepts"><name>Overview and Key Concepts</name> <t>This section provides a general overview of the design and operation of the DMARC environment.</t> <section anchor="dmarc-basics"><name>DMARC Basics</name> <t>DMARC permits a<eref target="#domain-owner">Domain Owner</eref><xref target="domain-owner">Domain Owner</xref> or<eref target="#public-suffix-operator">PSO</eref><xref target="public-suffix-operator">PSO</xref> to enable validation of an<eref target="#author-domain">Author Domain's</eref><xref target="author-domain">Author Domain's</xref> use in an email message, to indicate the Domain Owner's or PSO's message handling preference regarding failed validation, and to request reports about use of the Author Domain. A domain's<eref target="#dmarc-policy-record">DMARC<xref target="dmarc-policy-record">DMARC PolicyRecord</eref>Record</xref> is published in the DNS as a TXT record at the name created by prepending the label"_dmarc""_dmarc" to the domain name and is retrieved through normal DNS queries.</t> <t>DMARC's validation mechanism produces a"pass""pass" result if a DMARC Policy Record exists for the Author Domain of an email message and the Author Domain is<eref target="#identifier-alignment">aligned</eref><xref target="identifier-alignment">aligned</xref> with an<eref target="#authenticated-identifiers">Authenticated Identifier</eref><xref target="authenticated-identifiers">Authenticated Identifier</xref> from that message. When a DMARC Policy Record exists for the Author Domain and the DMARC mechanism does not produce a"pass""pass" result, the<eref target="#mail-receiver">Mail Receiver's</eref><xref target="mail-receiver">Mail Receiver's</xref> handling of that message can be influenced by the<eref target="#domain-owner-policy">Domain<xref target="domain-owner-policy">Domain Owner AssessmentPolicy</eref>Policy</xref> expressed in the DMARC Policy Record.</t> <t>It is important to note that the authentication mechanisms employed by DMARC only validate the usage of a DNS domain in an email message. They do not validate the local-part of any email address identifier found in that message, nor do such validations carry an explicit or implicit value assertion about that message or about the Domain Owner.</t> <t>DMARC's reporting component involves the collection of information 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 discussed in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> <t>A Mail Receiver participating in DMARC might also generate per-message failure reports that contain information related to individual messages that fail DMARC validation checks. Per-message failure reports areausefulsourcesources of information when debugging deployments (if messages can be determined to be legitimateeven thoughdespite failing validation) or in analyzing attacks. The capability for such services is enabled by DMARC but defined in other referenced material such as <xreftarget="RFC6591"></xref>target="RFC6591"/> and <xreftarget="I-D.ietf-dmarc-failure-reporting"></xref></t>target="RFC9991"/>.</t> </section> <section anchor="use-of-rfc5322-from"><name>Use of RFC5322.From</name> <t>One of the most obvious points of security scrutiny for DMARC is the choice to focus on an identifier, namely the RFC5322.From address, 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 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. 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, properly formed RFC5322.From header field does not comply with <xreftarget="RFC5322"></xref>,target="RFC5322"/>, and handling such a message is outside of the scope of this specification.</t> </section> <section anchor="authentication-mechanisms"><name>Authentication Mechanisms</name> <t>The following mechanisms for determining<eref target="#authenticated-identifiers">Authenticated Identifiers</eref><xref target="authenticated-identifiers">Authenticated Identifiers</xref> are supported in this version of DMARC:</t> <ul><li><t>DKIM,<li>DKIM <xreftarget="RFC6376"></xref>.target="RFC6376"/>: The<eref target="#dkim-signing-domain">DKIM<xref target="dkim-signing-domain">DKIM SigningDomain</eref>Domain</xref> from a validated DKIM-Signature header field is an AuthenticatedIdentifier.</t> </li> <li><t>SPF,Identifier.</li> <li>SPF <xreftarget="RFC7208"></xref>.target="RFC7208"/>: The validated<eref target="#spf-domain">SPF Domain</eref><xref target="spf-domain">SPF Domain</xref> from the email message is the AuthenticatedIdentifier.</t> </li>Identifier.</li> </ul> </section> <section anchor="identifier-alignment-explained"><name>Identifier Alignment Explained</name> <t>DMARC validates the authorized use of the<eref target="#author-domain">Author Domain</eref><xref target="author-domain">Author Domain</xref> by requiring either that it have the same<eref target="#organizational-domain">Organizational Domain</eref><xref target="organizational-domain">Organizational Domain</xref> as an<eref target="#authenticated-identifier">Authenticated Identifier</eref><xref target="authenticated-identifiers">Authenticated Identifier</xref> (a condition known as"<eref target="#relaxed-alignment">Relaxed Alignment</eref>")<xref target="relaxed-alignment">"relaxed alignment"</xref>) or that it be identical to the Authenticated Identifier (a condition known as"<eref target="#strict-alignment">Strict Alignment</eref>").<xref target="strict-alignment">"strict alignment"</xref>). The choice of relaxed or strict alignment is left to the<eref target="#domain-owner">Domain Owner</eref><xref target="domain-owner">Domain Owner</xref> and is expressed in the domain's<eref target="#dmarc-policy-record">DMARC<xref target="dmarc-policy-record">DMARC PolicyRecord</eref>.Record</xref>. In practice, nearly all Domain Owners have found relaxed alignment sufficient to meet their needs. Domain name comparisons in this context are case-insensitive, per <xreftarget="RFC4343"></xref>.</t>target="RFC4343"/>.</t> <t>The following table is meant to illustrate possible alignment conditions.</t> <tablealign="left"><name>"Alignment Examples"align="center"><name>Alignment Examples </name> <thead> <tr> <th>Authenticated Identifier</th> <th>Author Domain</th> <th>Identifier Alignment</th> </tr> </thead> <tbody> <tr> <td>foo.example.com</td> <td>news.example.com</td> <td>relaxed; the two have the same Organizational Domain, example.com</td> </tr> <tr> <td>news.example.com</td> <td>news.example.com</td> <td>strict; the two are identical</td> </tr> <tr> <td>foo.example.net</td> <td>news.example.com</td> <td>none; the two do not share a common Organizational Domain</td> </tr> </tbody> </table><t>It is important to note that Identifier Alignment cannot occur with a message that is not valid per <xreftarget="RFC5322"></xref>,target="RFC5322"/>, particularly one with a malformed, absent, or repeated RFC5322.From header field, since in thatcasecase, there is no reliable way to determine a<eref target="#dmarc-policy-record">DMARC<xref target="dmarc-policy-record">DMARC PolicyRecord</eref>Record</xref> that applies to the message. Accordingly, DMARC operation is predicated on the input being a validRFC5322messageobject.object <xref target="RFC5322"/>. For non-compliant cases, handling is outside of the scope of this specification. Further discussion of this can be found in <xreftarget="denial-of-dmarc-attacks"></xref>.</t>target="denial-of-dmarc-attacks"/>.</t> <section anchor="dkim-identifiers"><name>DKIM-Authenticated Identifiers</name> <t>DKIM permits a Domain Owner to claim some responsibility for a message by associating the domain to the message. This association is done by inserting the domain as the value of the"d""d" tag in a DKIM-Signature header field, and the assertion of responsibility is validated through a cryptographic signature in the header field. If the cryptographic signature validates, then the DKIM Signing Domain is the DKIM-Authenticated Identifier.</t> <t>There is currently no generally accepted mechanism by which a Domain Owner may 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 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 DKIM-Authenticated Identifier that has Identifier Alignment with the Author Domain 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 produce a DMARC"pass""pass" result if any DKIM-Authenticated Identifier aligns with the Author Domain.</t> </section> <section anchor="spf-identifiers"><name>SPF-Authenticated Identifiers</name> <t>SPF can validate the uses of both the domain found in an SMTP HELO/EHLO command (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 the use of the domain in the MAIL FROM identity is validated by SPF, then that domain is the SPF-Authenticated Identifier.</t> <t>There is currently no generally accepted mechanism by which a Domain Owner may assert a list of third-party domains that are authorized for use as the MAIL FROM identity for mail using a given Author Domain. Therefore, DMARC requires that Identifier Alignment 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 an email that will obtain an SPFpass"pass" result. Only an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain.</t> </section> <section anchor="alignment-and-extension-technologies"><name>Alignment and Extension Technologies</name><t>If in<t>In thefuturefuture, if DMARC is extended to include the use of other authentication mechanisms, the extensions <bcp14>MUST</bcp14> allow for the assignment of a domain as an Authenticated Identifier so that alignment with the Author Domain can be validated.</t> </section> </section> <section anchor="dmarc-policy-record-explained"><name>DMARC Policy Record Explained</name> <t>A<eref target="#domain-owner">Domain Owner</eref><xref target="domain-owner">Domain Owner</xref> or<eref target="#public-suffix-operator">PSO</eref><xref target="public-suffix-operator">PSO</xref> advertises DMARC participation of one or more of its domains by publishing<eref target="#dmarc-policy-record">DMARC<xref target="dmarc-policy-record">DMARC PolicyRecords</eref>Records</xref> that will apply to those domains. In doing so, Domain Owners and PSOs indicate their handling preference regarding failed validation for email 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 failure reports.</t> <t>DMARC Policy Records are stored as DNS TXT records with names starting with the label"_dmarc"."_dmarc". For example, the Domain Owner of"example.com""example.com" would publish a DMARC Policy Record at the name"_dmarc.example.com","_dmarc.example.com", and a<eref target="#mail-receiver">Mail Receiver</eref><xref target="mail-receiver">Mail Receiver</xref> wishing to find the DMARC Policy Record for mail with an<eref target="#author-domain">Author Domain</eref><xref target="author-domain">Author Domain</xref> of"example.com""example.com" would issue a TXT query to the DNS for the name"_dmarc.example.com"."_dmarc.example.com". 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> <!--[rfced] In the sentence below, does "or different" mean "or another domain"? If yes, may we update this text for clarity? Original: The Domain Owner Assessment Policy (#domain-owner-policy) that applies to the subdomains can be identical to the Domain Owner Assessment Policy that applies to the Organizational Domain or different, depending on the presence or absence of certain values in the DMARC Policy Record. Perhaps: The Domain Owner Assessment Policy (Section 3.2.8) that applies to the subdomains can be identical to the Domain Owner Assessment Policy that applies to the Organizational Domain or another domain, depending on the presence or absence of certain values in the DMARC Policy Record. --> <t>DMARC Policy Records can also apply to subdomains of the name at which they are published in theDNS,DNS if the record is published at an<eref target="#organizational-domain">Organizational Domain</eref><xref target="organizational-domain">Organizational Domain</xref> for the subdomains. The<eref target="#domain-owner-policy">Domain<xref target="domain-owner-policy">Domain Owner AssessmentPolicy</eref>Policy</xref> that applies to the subdomains can be identical to the Domain Owner Assessment Policy that applies to the Organizational Domain or different, depending on the presence or absence of certain values in the DMARC Policy Record. See <xreftarget="policy-record-format"></xref>target="policy-record-format"/> for more details.</t> <t>DMARC's use of the Domain Name Service is driven by DMARC's use of domain names and the nature of the query it performs. The query requirement matches with the DNS for obtaining simple parametric information. It uses an established 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 DMARC context. Using the DNS as the query service has the benefit of reusing an extremely well-established operations, administration, and management infrastructure, rather than creating a new one.</t> <t>Per <xreftarget="RFC1035"></xref>,target="RFC1035"/>, a TXT record can comprise multiple"character-string""character-string" objects. Where this is the case, the module performing DMARC evaluation <bcp14>MUST</bcp14> concatenate 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 mechanisms apply to DMARC evaluation of its Author Domain(s). For example, if a Domain Owner only wants to use DKIM as the underlying authentication mechanism, then the Domain Owner does not publish an SPF record that can produce Identifier Alignment 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 that have no DKIM-Signature header field that would produce Identifier Alignment between a DKIM-Authenticated Identifier and the Author Domain. However, it is <bcp14>RECOMMENDED</bcp14> 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 PSO's published Domain Owner Assessment Policy and can use it to inform its handling decisions for messages that undergo DMARC validation checks and do not produce a result ofpass."pass". Mail handling considerations based on Domain Owner Assessment Policy enforcement are discussed below in <xreftarget="policy-enforcement-considerations"></xref>.</t>target="policy-enforcement-considerations"/>.</t> </section> <section anchor="dmarc-uris"><name>DMARC Reporting URIs</name> <t><xreftarget="RFC3986"></xref>target="RFC3986"/> defines a syntax for identifying a resource. The DMARC mechanism uses this as the format by which a<eref target="#domain-owner">Domain Owner</eref><xref target="domain-owner">Domain Owner</xref> or<eref target="#public-suffix-organization">PSO</eref><xref target="public-suffix-operator">PSO</xref> specifies the destination(s) for the two report types that are supported. The<eref target="#policy-record-format">DMARC<xref target="policy-record-format">DMARC Policy Recordformat</eref>format</xref> allows for a list of these URIs to be provided, with each URI separated by commas (ASCII 0x2c).</t> <t>A formal definition is provided in <xreftarget="formal-definition"></xref>.</t>target="formal-definition"/>.</t> </section> <section anchor="policy-record-format"><name>DMARC Policy Record Format</name> <t>DMARC Policy Records follow the extensible"tag-value""tag-value" syntax for DNS-based key records defined in DKIM <xreftarget="RFC6376"></xref>.</t>target="RFC6376"/>.</t> <t><xreftarget="iana-considerations"></xref>target="iana-considerations"/> creates a registry for known DMARC tags and registers the initial set defined in this document. Only tags defined in that registry are to be processed; unknown tags <bcp14>MUST</bcp14> be ignored.</t> <t>The following tags are valid DMARC tags:</t> <dl> <dt>adkim:</dt> <dd><t>(plain-text; <bcp14>OPTIONAL</bcp14>; default is"r".)"r".) Indicates whether the<eref target="#domain-owner">Domain Owner</eref><xref target="domain-owner">Domain Owner</xref> or<eref target="#public-suffix-organization">PSO</eref><xref target="public-suffix-operator">PSO</xref> requires strict or relaxed DKIM Identifier Alignment mode. See <xreftarget="dkim-identifiers"></xref>target="dkim-identifiers"/> for details. Valid values are as follows:</t> <dl spacing="compact"> <dt>r:</dt> <dd>relaxed mode</dd> <dt>s:</dt> <dd>strict mode</dd> </dl></dd> <dt>aspf:</dt> <dd><t>(plain-text; <bcp14>OPTIONAL</bcp14>; default is"r".)"r".) Indicates whether the Domain Owner or PSO requires strict or relaxed SPF Identifier Alignment mode. See <xreftarget="spf-identifiers"></xref>target="spf-identifiers"/> for details. Valid values are as follows:</t> <dl spacing="compact"> <dt>r:</dt> <dd>relaxed mode</dd> <dt>s:</dt> <dd>strict mode</dd> </dl></dd> <dt>fo:</dt> <dd><t>Failure reporting options (plain-text; <bcp14>OPTIONAL</bcp14>; default is"0")"0"). Provides 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> be ignored if a"ruf""ruf" tag (below) is not also specified. This tag can include one or more of the values shown here, with the exception that"0""0" and"1""1" are 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 in the list in any order. Valid values and their meaningsare:</t>are as follows:</t> <dlspacing="compact">spacing="normal"> <dt>0:</dt> <dd>Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned"pass""pass" result.</dd> <dt>1:</dt> <dd>Generate a DMARC failure report if any underlying authentication mechanism fails to produce an aligned"pass""pass" result.</dd> <dt>d:</dt> <dd>Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment. DKIM-specific reporting is described in <xreftarget="RFC6651"></xref>.</dd>target="RFC6651"/>.</dd> <dt>s:</dt> <dd>Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment. SPF-specific reporting is described in <xreftarget="RFC6652"></xref>.</dd>target="RFC6652"/>.</dd> </dl></dd> <dt>np:</dt><dd><t><eref target="#domain-owner-policy">Domain<dd><t><xref target="domain-owner-policy">Domain Owner AssessmentPolicy</eref>Policy</xref> for non-existent subdomains of the given Organizational Domain (plain-text; <bcp14>OPTIONAL</bcp14>). For this tag, the definition of"non-existent subdomain""non-existent subdomain" is the same as that used for"Non-existent Domains""non-existent domains" in <xreftarget="non-existent-domains"></xref>.target="non-existent-domains"/>. The policy expressed by this tag indicates the message handling preference of the Domain Owner or PSO for mail using non-existent subdomains of the prevailing Organizational Domain and not passing DMARC validation. It applies 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"p""p" tag defined below. If the"np""np" tag is absent, the policy specified by the"sp""sp" tag (if the"sp""sp" tag is present) or the policy specified by the"p" tag, if"p" tag (if the"sp""sp" tag is notpresent,present) <bcp14>MUST</bcp14> be applied for non-existent subdomains.</t> </dd> <dt>p:</dt><dd><t><eref target="#domain-owner-policy">Domain<dd><t><xref target="domain-owner-policy">Domain Owner AssessmentPolicy</eref>Policy</xref> (plain-text; <bcp14>RECOMMENDED</bcp14> for DMARC Policy Records). Indicates the message handling preference of the Domain Owner or PSO for mail using its domain but not passing DMARC validation. The policy applies to the domain queried and to subdomains, unless the subdomain policy is explicitly described using the"sp""sp" or"np""np" tags. If this tag is not present in an otherwise syntactically valid DMARC Policy Record, then the record is treated as if it included"p=none""p=none" (see <xreftarget="dmarc-policy-discovery"></xref>).target="dmarc-policy-discovery"/>). This tag is not applicable for third-party reporting records (see <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>target="RFC9990"/> and <xreftarget="I-D.ietf-dmarc-failure-reporting"></xref>).target="RFC9991"/>). Possible values are as follows:</t> <dlspacing="compact">spacing="normal"> <dt>none:</dt> <dd>The Domain Owner offers no expression of preference.</dd> <dt>quarantine:</dt> <dd>The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern.</dd> <dt>reject:</dt> <dd>The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid. See <xreftarget="rejecting-messages"></xref>target="rejecting-messages"/> for some discussion of SMTP rejection methods and their implications.</dd> </dl></dd> <dt>psd:</dt> <dd><t>A flag indicating whether the domain is aPSD.PSD (plain-text; <bcp14>OPTIONAL</bcp14>; default is"u")."u"). Possible valuesare:</t>are as follows:</t> <dlspacing="compact">spacing="normal"> <dt>y:</dt> <dd>PSOs include this tag with a value of"y""y" to indicate that the domain is a PSD. If a record containing this tag with a value of"y""y" is found during policy discovery, this information will be used to determine the Organizational Domain and DMARC Policy Domain applicable to the message in question.</dd> <dt>n:</dt> <dd>The DMARC Policy Record is published for a domain that is not a PSD, but it is the Organizational Domain for itself and its subdomains.</dd> <dt>u:</dt> <dd>The default indicates that the DMARC Policy Record is published for a domain that is not aPSD,PSD and may or may not be an Organizational Domain for itself and its subdomains. Use the mechanism described in <xreftarget="dns-tree-walk"></xref>target="dns-tree-walk"/> for determining the Organizational Domain for this domain.</dd> </dl></dd> <dt>rua:</dt> <dd><t>Addresses to which aggregate feedback reports are to be sent (comma-separated plain-text list of DMARC Reporting URIs; <bcp14>OPTIONAL</bcp14>). If present, the Domain Owner is requesting Mail Receivers to send aggregate feedback reports as defined in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>target="RFC9990"/> to the URIs listed. Any valid URI can be specified. A Mail Receiver that sends aggregate feedback reports <bcp14>MUST</bcp14> implement support for a"mailto:""mailto:" URI, i.e., the ability to send a DMARC report via electronic mail. If the tag is not provided, Mail Receivers <bcp14>MUST NOT</bcp14> generate aggregate feedback reports for the domain. URIs involving schemes not supported by Mail Receivers <bcp14>MUST</bcp14> be ignored. <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>target="RFC9990"/> also discusses considerations that apply when the domain name of a URI differs from the domain publishing the DMARC Policy Record. See <xreftarget="external-report-addresses"></xref>target="external-report-addresses"/> for additional considerations.</t> </dd> <dt>ruf:</dt> <dd><t>Addresses to which message-specific failure information is to be reported (comma-separated plain-text list of DMARC URIs; <bcp14>OPTIONAL</bcp14>). If present, the Domain Owner is requesting Mail Receivers to send detailed failure reports about messages that fail the DMARC evaluation in specific ways (see the"fo""fo" tag above) to the URIs listed. Depending on the value of the"fo""fo" tag, the format for such reports is described in <xreftarget="I-D.ietf-dmarc-failure-reporting"></xref>,target="RFC9991"/>, <xreftarget="RFC6651"></xref>, ortarget="RFC6651"/>, and <xreftarget="RFC6652"></xref>.target="RFC6652"/>. Any valid URI can be specified. A Mail Receiver sending failure reports <bcp14>MUST</bcp14> implement support for a"mailto:""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 failure reports for the domain. URIs involving schemes not supported by Mail Receivers <bcp14>MUST</bcp14> be ignored. <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>target="RFC9990"/> discusses considerations that apply when the domain name of a URI differs from that of the domain advertising the policy. See <xreftarget="external-report-addresses"></xref>target="external-report-addresses"/> for additional considerations.</t> </dd> <!--[rfced] We are having difficulty parsing "Organizational Domain for and not passing DMARC validation" in this sentence. May we update it as follows for clarity? Original: Indicates the message handling preference of the Domain Owner or PSO for mail using an existing subdomain of the prevailing Organizational Domain for and not passing DMARC validation. Perhaps: Indicates the message handling preference of the Domain Owner or PSO for mail that uses an existing subdomain of the prevailing Organizational Domain but does not pass DMARC validation. --> <dt>sp:</dt> <dd><t>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 or PSO for mail using an existing subdomain of the prevailing Organizational Domain for 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. Its syntax is identical to that of the"p""p" tag defined above. If both the"sp""sp" tag isabsent,absent and the"np""np" tag is either absent or not applicable, the policy specified by the"p""p" tag <bcp14>MUST</bcp14> be applied for subdomains. Note that"sp""sp" will be ignored for DMARC Policy Records published on subdomains of Organizational Domains and PSDs due to the effect of the<eref target="#dmarc-policy-discovery">DMARC Policy Discovery</eref>.</t><xref target="dmarc-policy-discovery">DMARC policy discovery</xref>.</t> </dd> <dt>t:</dt> <dd><t>DMARC policy test mode (plain-text; <bcp14>OPTIONAL</bcp14>; default is"n")."n"). For the Author Domain to which the DMARC Policy Record applies, the"t""t" tag serves 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"p", "sp","p", "sp", and/or"np""np" tags to actually be applied. This tag does not affect the generation of DMARC reports, and it has no effect on any policy("p", "sp",("p", "sp", or"np")"np") that is"none"."none". See <xreftarget="removal-of-the-pct-tag"></xref>target="removal-of-the-pct-tag"/> for further discussion of the use of this tag. Possible values are as follows:</t> <dlspacing="compact">spacing="normal"> <dt>y:</dt> <dd>A request that the actor performing the DMARC validation check not apply the policy, but instead apply any special handling rules it might have in place, such as rewriting the RFC5322.From header field (see <xreftarget="removal-of-the-pct-tag"></xref>).target="removal-of-the-pct-tag"/>). The Domain Owner is currently testing its specified DMARC assessmentpolicy,policy and has an expectation that the policy applied to any failing messages will be one level below the specified policy. That is, if the policy is"quarantine""quarantine" and the value of the"t""t" tag is"y","y", a policy of"none""none" will be applied to failing messages; if the policy is"reject""reject" and the value of the"t""t" tag is"y","y", a policy of"quarantine""quarantine" will be applied to failing messages, irrespective of any other special handling rules that might be triggered by the"t""t" tag having a value of"y".</dd>"y".</dd> <dt>n:</dt> <dd>The default is a request to apply the Domain Owner Assessment Policy as specified to any message that produces a DMARC"fail""fail" result.</dd> </dl></dd> <dt>v:</dt> <dd><t>Version (plain-text; <bcp14>REQUIRED</bcp14>). Identifies the record retrieved as a DMARC Policy Record. This tag <bcp14>MUST</bcp14> be the first tag in the list. The tag value is case sensitive, and the only possible value is"DMARC1"."DMARC1". If the tag is not the first in the list,orthe tag is absent, or the value is not"DMARC1","DMARC1", then the entire record <bcp14>MUST</bcp14> be ignored.</t> </dd> </dl> </section> <section anchor="formal-definition"><name>Formal Definition</name> <!--[rfced] We are having difficulty understanding how "of same" fits into this sentence. May we remove it? Original: A DMARC Policy Record MUST comply with the formal definition of same found in this section. Perhaps: A DMARC Policy Record MUST comply with the formal definition found in this section. --> <t>A DMARC Policy Record <bcp14>MUST</bcp14> comply with the formal definition of same found in this section. Unknown tags <bcp14>MUST</bcp14> be ignored. Syntax errors in the remainder of the record <bcp14>MUST</bcp14> be discarded in favor of default values (if any) or ignored outright.</t> <t>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 generated (with a corresponding change to the"v""v" tag's value), but a change to any existing tags does require a new version of DMARC.</t> <t>The formal definition of the DMARC Policy Record format, using ABNF syntax as described in <xreftarget="RFC5234"></xref>target="RFC5234"/> and <xreftarget="RFC7405"></xref>,target="RFC7405"/>, is as follows:</t><artwork><![CDATA[<!--[rfced] ABNF in Section 4.8 a) FYI: We moved each description in the DMARC Policy Record over two spaces to the right so that each entry aligns under the first word on the line above (after the equals sign). This also matches the format in the companion document (RFC-to-be 9990). Please let us know of any concerns. b) The following line exceeds the 72-character limit. Please let us know how it can be modified. Original: dmarc-urilist = (dmarc-uri / obs-dmarc-uri) *(*WSP "," *WSP (dmarc-uri / obs-dmarc-uri)) --> <sourcecode type="abnf"><![CDATA[ dmarc-uri = URI ; "URI" is imported from [RFC3986]; ; commas (ASCII 0x2C) and exclamation ; points (ASCII 0x21) MUST be ; encoded obs-dmarc-uri = dmarc-uri obs-dmarc-report-size ; Obsolete syntax, reporters should ignore the ; obs-dmarc-report-size if it is found in a ; DMARC Policy Record. obs-dmarc-report-size = "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] dmarc-sep = *WSP ";" *WSP equals = *WSP "=" *WSP dmarc-record = dmarc-version *(dmarc-sep dmarc-tag) [dmarc-sep] dmarc-tag = 1*ALPHA equals 1*dmarc-value ; any printing characters but semicolon dmarc-value = %x20-3A / %x3C-7E dmarc-version = "v" equals %s"DMARC1" ; case sensitive ; specialized syntax of DMARC values dmarc-request = "none" / "quarantine" / "reject" dmarc-yorn = "y" / "n" dmarc-psd = "y" / "n" / "u" dmarc-rors = "r" / "s" dmarc-urilist = (dmarc-uri / obs-dmarc-uri) *(*WSP "," *WSP (dmarc-uri / obs-dmarc-uri)) dmarc-fo = ("0" / "1") *(":" dmarc-afrf) / dmarc-afrf [":" ("0" / "1")] [":" dmarc-afrf] / *(dmarc-afrf ":") ("0" / "1") dmarc-afrf = "d" / "s" ; each may appear at most once indmarc-fo ]]></artwork>dmarc-fo]]></sourcecode> <t>In each dmarc-tag, the dmarc-value has a syntax that depends on the tag name. The ABNF rule for each dmarc-value is specified in the following table:</t> <tablealign="left"><name>"Tagalign="center"><name>Tag Names andValues"Values </name> <thead> <tr> <th>Tag Name</th> <th>Value Rule</th> </tr> </thead> <tbody> <tr> <td>p</td> <td>dmarc-request</td> </tr> <tr> <td>t</td> <td>dmarc-yorn</td> </tr> <tr> <td>psd</td> <td>dmarc-psd</td> </tr> <tr> <td>np</td> <td>dmarc-request</td> </tr> <tr> <td>sp</td> <td>dmarc-request</td> </tr> <tr> <td>adkim</td> <td>dmarc-rors</td> </tr> <tr> <td>aspf</td> <td>dmarc-rors</td> </tr> <tr> <td>rua</td> <td>dmarc-urilist</td> </tr> <tr> <td>ruf</td> <td>dmarc-urilist</td> </tr> <tr> <td>fo</td> <td>dmarc-fo</td> </tr> </tbody> </table></section> <section anchor="flow-diagram"><name>Flow Diagram</name><sourcecode type="ascii-art"><![CDATA[<!--[rfced] As the <artwork> in Section 4.9 contains a legend defining "MSA" and "MDA", may we move the definitions of "sMTA" and "rMTA" from the succeeding paragraph into the legend? Original: MSA = Mail Submission Agent MDA = Mail Delivery Agent ... "sMTA" is the sending MTA, and "rMTA" is the receiving MTA. Perhaps: MSA = Mail Submission Agent MDA = Mail Delivery Agent sMTA = sending MTA rMTA = receiving MTA --> <artwork><![CDATA[ +---------------+ +--------------------+ | Author Domain |< . . . . . . . . . . . . | Return-Path Domain | +---------------+ . +--------------------+ | . ^ V V . +-----------+ +--------+ +----------+ v | MSA |<***>| DKIM | | DMARC | +----------+ | Service | | Signer | | Validator|<***>| SPF | +-----------+ +--------+ +----------+ * | Validator| | ^ * +----------+ | * * V v * +------+ (~~~~~~~~~~~~) +------+ * +----------+ | sMTA |------->( other MTAs )----->| rMTA | **>| DKIM | +------+ (~~~~~~~~~~~~) +------+ | Validator| | +----------+ | ^ V . +-----------+ . +---------+ | MDA | v | User |<--| Filtering | +-----------+ | Mailbox | | Engine | | DKIM | +---------+ +-----------+ | Signing | | Domain(s) |+-----------++-----------+]]> MSA = Mail Submission Agent MDA = Mail Delivery Agent]]></sourcecode></artwork> <t>The above diagram shows a typical flow of messages through a DMARC-aware system. Dashed lines (e.g., -->) denote the actual message flow, dotted lines (e.g., < . . >) represent DNS queries used to retrieve message policy related to the supported message authentication schemes, and starred lines (e.g., <**>) indicate data exchange between message-handling modules and message authentication modules."sMTA""sMTA" is the sending MTA, and"rMTA""rMTA" is the receiving MTA.</t> <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 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 the DMARC validation status. The DMARC validation status can then factor into the message handling decision made by the recipient's mail system.</t> <t>More details on specific actions for the parties involved can be found in Sections <xreftarget="domain-owner-actions"></xref>target="domain-owner-actions" format="counter"/> and <xreftarget="mail-receiver-actions"></xref>.</t>target="mail-receiver-actions" format="counter"/>.</t> </section> <section anchor="dns-tree-walk"><name>DNS Tree Walk</name> <t>An<eref target="#organizational-domain">Organizational Domain</eref><xref target="organizational-domain">Organizational Domain</xref> serves two different purposes, depending on the context:</t> <ul> <li><t>The Organizational Domain of the<eref target="#author-domain">Author Domain</eref><xref target="author-domain">Author Domain</xref> establishes the<eref target="#dmarc-policy-record">DMARC<xref target="dmarc-policy-record">DMARC PolicyRecord</eref>Record</xref> for that domain when no DMARC Policy Record is published specifically for the AuthorDomain.Domain (see <xreftarget="dmarc-policy-discovery"></xref>)</t>target="dmarc-policy-discovery"/>).</t> </li> <li><t>The Organizational Domains of an<eref target="#authenticated-identifiers">Authenticated Identifier</eref><xref target="authenticated-identifiers">Authenticated Identifier</xref> and the Author Domain are used in determining Identifier Alignment between thetwo.two (see <xreftarget="identifier-alignment-evaluation"></xref>).</t>target="identifier-alignment-evaluation"/>).</t> </li> </ul> <t><xreftarget="RFC7489"></xref>target="RFC7489"/> defined an Organizational Domain as"The"The domain that was registered with a domain nameregistrar." RFC 7489registrar". <xref target="RFC7489"/> discussed using a"public suffix" listPublic Suffix List (PSL) as the authoritative list of the parent domains for OrganizationalDomains,Domains and further described a method for determining the Organizational Domain of an Author Domain or an Authenticated Identifier. However,RFC 7489<xref target="RFC7489"/> mandated no requirement for a specific PSL for Mail Receivers to use (though it did suggest the one found at <ereftarget="https://publicsuffix.org/">https://publicsuffix.org/</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 in DMARC.RFC 7489<xref target="RFC7489"/> acknowledged the possibility of interoperability issues caused by Mail Receivers choosing differentPSLs,PSLs and even suggested that if a more reliable and secure method for determining the Organizational Domain could be created, that method should replace reliance on apublic suffix list.</t>PSL.</t> <t>This update to DMARC offers more flexibility to Domain Owners, especially those with large, complex organizations that might want to apply decentralized management to their DNS and their DMARC Policy Records. Rather than just using apublic suffix listPublic Suffix List to help identify an Organizational Domain, this update defines a discovery technique known colloquially as the"DNS"DNS TreeWalk".Walk". The target of any DNS Tree Walk is discovery of a valid DMARC Policy Record, and its use in determining an Organizational Domain allows for publishing DMARC Policy Records at multiple points in the namespace.</t><t>This<t>However, this flexibility comes at a possiblecost, however.cost. Since the DNS Tree Walk 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 with tens or even hundreds of labels for the purpose of executing aDenial of Service Attackdenial-of-service attack on the Mail Receiver. To guard against such abuse of the 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 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 future expansion of thename spacenamespace that did not require updating this document.</t> <t>The generic steps for a DNS Tree Walk are as follows:</t> <ol> <li><t>Query the DNS for a TXT record that matches the format of a DMARC Policy Record at the starting point for the Tree Walk. The starting point for the DNS Tree Walk will depend on the ultimate target of the DNS Tree Walk. Sections <xreftarget="dmarc-policy-discovery"></xref>target="dmarc-policy-discovery" format="counter"/> and <xreftarget="identifier-alignment-evaluation"></xref>target="identifier-alignment-evaluation" format="counter"/> describe the possible starting points. A possibly empty set of records is returned.</t> </li> <li><t>Records that do not start with a"v""v" tag that identifies the current version of DMARC are discarded. If multiple DMARC Policy Records are returned for a single target, they are all discarded. If a single record remains and it contains a"psd=n""psd=n" or"psd=y""psd=y" tag, stop.</t> </li> <li><t>Break the subject DNS domain name into a set of ordered labels. Assign the count of labels to"x","x", and number the labels from right toleft;left, e.g., for"a.mail.example.com", "x""a.mail.example.com", "x" would be assigned the value 4,"com""com" would be label 1,"example""example" would be label 2,"mail""mail" would be label 3, and so forth.</t> </li> <li><t>If x < 8, remove the left-most (highest-numbered) label from the subject domain. If x >= 8, remove the left-most (highest-numbered) labels from the subject domain until 7 labels remain. The resulting DNS domain name is the new target for the next lookup.</t> </li> <li><t>Query the DNS for a DMARC Policy Record at the DNS domain name matching this new target. A possibly empty set of records is returned.</t> </li> <li><t>Records that do not start with a"v""v" tag that identifies the current version of DMARC are discarded. If multiple DMARC Policy Records are returned for a single target, they are all discarded. If a single record remains and it contains a"psd=n""psd=n" or"psd=y""psd=y" tag, stop.</t> </li> <li><t>Determine the target for the next query by removing the left-most label from the target of the previous query. Repeat steps 5, 6, and 7 until the process stops or there are no more labels remaining.</t> </li> </ol> <t>To illustrate, for a message with the arbitrary Author Domain of"a.b.c.d.e.f.g.h.i.j.mail.example.com","a.b.c.d.e.f.g.h.i.j.mail.example.com", a full DNS Tree Walk would require the following eight queries to potentially locate the DMARC Policy Record or Organizational Domain:</t> <ulspacing="compact">spacing="normal"> <li>_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com</li> <li>_dmarc.g.h.i.j.mail.example.com</li> <li>_dmarc.h.i.j.mail.example.com</li> <li>_dmarc.i.j.mail.example.com</li> <li>_dmarc.j.mail.example.com</li> <li>_dmarc.mail.example.com</li> <li>_dmarc.example.com</li> <li>_dmarc.com</li> </ul> <section anchor="dmarc-policy-discovery"><name>DMARC Policy Discovery</name> <t>The DMARC Policy Record to be applied to an email message will be the record found at any of the following locations, listed from highest preference to lowest:</t> <ulspacing="compact">spacing="normal"> <li>The Author Domain</li> <li>The Organizational Domain of the Author Domain</li> <li>The Public Suffix Domain of the Author Domain</li> </ul> <t>Policy discoverystartsfirst starts with a query for a valid DMARC Policy Record at the name created by prepending the label"_dmarc""_dmarc" to the Author Domain of the message being evaluated. If a valid DMARC Policy Record is found there, then this is the DMARC Policy Record to be applied to the message; however, this does not necessarily mean that the Author Domain is the Organizational Domain to be used in Identifier Alignment checks. Whether this is also the Organizational Domain is dependent on the value of the"psd""psd" tag, if present, or some conditions described in <xreftarget="identifier-alignment-evaluation"></xref>.</t>target="identifier-alignment-evaluation"/>.</t> <t>If no valid DMARC Policy Record is found by the first query, then perform a DNS 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 follows:</t> <ulspacing="compact">spacing="normal"> <li>If the Author Domain has eight or fewer labels, the starting point will be the immediate parent domain of the Author Domain.</li> <li>Otherwise, the starting point will be the name produced by shortening the Author Domain as described starting in step 3 of <xreftarget="dns-tree-walk"></xref>.</li>target="dns-tree-walk"/>.</li> </ul> <t>If the DMARC Policy Record to be applied is that of the Author Domain, then the Domain Owner Assessment Policy is taken from the"p""p" tag of the record.</t> <t>If the DMARC Policy Record to be applied is that of either the Organizational Domain or the Public Suffix Domain and the Author Domain is a subdomain of that domain, then the Domain Owner Assessment Policy is taken from the"sp""sp" tag (if any) if the Author Domainexists,exists or the"np""np" tag (if any) if the Author Domain does not exist. In the absence of applicable"sp""sp" or"np""np" tags, the"p""p" tag policy is used for subdomains.</t> <t>If a retrieved DMARC Policy Record does not contain a valid"p""p" tag, or contains an"sp""sp" or"np""np" tag that is not valid, then:</t> <ul> <li><t>If a"rua""rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver <bcp14>MUST</bcp14> act as if a record containing"p=none""p=none" was retrieved and continueprocessing;</t>processing.</t> </li> <li><t>Otherwise, the Mail Receiver applies no DMARC processing to this message.</t> </li> </ul> <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), 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 left to the discretion of the Mail Receiver. For example, to ensure minimal disruption of mail flow, transient errors could result in delivery of the message("fail open"),("fail open"), or they could result in the message being temporarily rejected (i.e., an SMTP 4yx reply), which invites the sending MTA to try again after the condition has possibly cleared, allowing a definite DMARC conclusion to be reached("fail closed").</t>("fail closed").</t> <t>Note: PSD policy is not used for Organizational Domains that have published a DMARC Policy Record. Specifically, this is not a mechanism to provide feedback addresses (rua/ruf) when an Organizational Domain has declined to do so.</t> </section> <section anchor="identifier-alignment-evaluation"><name>Identifier Alignment Evaluation</name> <t>It may be necessary to perform multiple DNS Tree Walks to determine if an Authenticated Identifier and an Author Domain are in alignment, meaning that they have either the same Organizational Domain (relaxed alignment) or that they're identical (strict alignment). DNS Tree Walks done to discover an Organizational Domain for use in Identifier Alignment Evaluation might start at any of the following locations:</t> <ulspacing="compact">spacing="normal"> <li>The Author Domain of the message being evaluated.</li> <li>The SPF-Authenticated Identifier if there is an SPFpass"pass" result for the message being evaluated.</li> <li>Any DKIM-Authenticated Identifier if one or more DKIMpass"pass" results exist for the message being evaluated.</li> </ul> <t>Note: There is no need to perform Identifier Alignment Evaluations under any of the following conditions:</t> <ulspacing="compact">spacing="normal"> <li>The Author Domain and the Authenticated Identifier(s) are all the same domain, and there is a DMARC Policy Record published for that domain. In this case, this common domain is treated as the Organizational Domain. For example, if the common domain in question is"mail.example.com","mail.example.com", and there is a valid DMARC Policy Record published at"_dmarc.mail.example.com","_dmarc.mail.example.com", then"mail.example.com""mail.example.com" is the Organizational Domain.</li> <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> <li>The DMARC Policy Record for the Author Domain indicates strict alignment. In this case, a simple string comparison of the Author Domain and the Authenticated Identifier(s) is all that is required.</li> </ul> <t>To discover the Organizational Domain for a domain, perform the DNS Tree Walk described in <xreftarget="dns-tree-walk"></xref>target="dns-tree-walk"/> as needed for any of the domains in question.</t> <t>For each Tree Walk that retrieved valid DMARC Policy Records, select the Organizational Domain from the domains for which valid DMARC Policy Records were retrieved from the longest to the shortest:</t> <ol> <li><t>If a valid DMARC Policy Record contains the"psd""psd" tag set to"n" ("psd=n"),"n" ("psd=n"), this is the Organizational Domain, and the selection process is complete.</t> </li> <li><t>If a valid DMARC Policy Record, other than the one for the domain where thetree walkTree Walk started, contains the"psd""psd" tag set to"y" ("psd=y"),"y" ("psd=y"), the Organizational 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 atree walkTree Walk a DMARC Policy Record is queried for at first"_dmarc.mail.example.com""_dmarc.mail.example.com" and then"_dmarc.example.com","_dmarc.example.com", and a valid DMARC Policy Record containing the"psd""psd" tag set to"y""y" is found at"_dmarc.example.com","_dmarc.example.com", then"mail.example.com""mail.example.com" is the domain one label below"example.com""example.com" in the DNS hierarchy and is thus the Organizational Domain.</t> </li> <li><t>Otherwise, select the DMARC Policy Record found at the name with the fewest number of labels. This is the Organizational Domain and the selection process is complete.</t> </li> </ol> <t>If this process does not determine the Organizational Domain, then the initial target domain is the Organizational Domain.</t> <t>For example, given the starting domain"a.mail.example.com","a.mail.example.com", a search for the Organizational Domain would require a series of DNS queries for DMARC Policy Records starting with"_dmarc.a.mail.example.com""_dmarc.a.mail.example.com" and finishing with"_dmarc.com"."_dmarc.com". If there are DMARC Policy Records published at"_dmarc.mail.example.com""_dmarc.mail.example.com" and"_dmarc.example.com","_dmarc.example.com", but not at"_dmarc.a.mail.example.com""_dmarc.a.mail.example.com" or"_dmarc.com","_dmarc.com", then the Organizational Domain for this domain would be"example.com".</t>"example.com".</t> <t>As another example, given the starting domain"a.mail.example.com","a.mail.example.com", if a search for the Organizational Domain yields a DMARC Policy Record at"_dmarc.mail.example.com""_dmarc.mail.example.com" with the"psd""psd" tag set to"n","n", then the Organizational Domain for this domain would be"mail.example.com".</t>"mail.example.com".</t> <t>As a last example, given the starting domain"a.mail.example.com","a.mail.example.com", if a search for the Organizational Domain only yields a DMARC Policy Record at"_dmarc.com""_dmarc.com" and that record contains the tag"psd=y","psd=y", then the Organizational Domain for this domain would be"example.com".</t>"example.com".</t> </section> </section> </section> <section anchor="dmarc-participation"><name>DMARC Participation</name> <t>This section describes the actions for participating in DMARC for each of three unique entities--- Domain Owners, PSOs, and Mail Receivers.</t> <section anchor="domain-owner-actions"><name>Domain Owner Actions</name><t>A <eref target="#domain-owner">Domain Owner</eref><!--[rfced] Please consider if this text should be a list for easier readability. Current: A Domain Owner (Section 3.2.7) wishing to fully participate in DMARC will publish a<eref target="#dmarc-policy-record">DMARCDMARC PolicyRecord</eref>Record (Section 3.2.6) to cover each<eref target="#author-domain">Author Domain</eref>Author Domain (Section 3.2.2) and corresponding<eref target="#organizational-domain">Organizational Domain</eref>Organizational Domain (Section 3.2.14) to which DMARC validation shouldapply,apply; will send email that produces at leastone,one - preferably two - Authenticated Identifiers (Section 3.2.1) that align with the Author Domain; will receive and monitor the content of DMARC aggregate reports; and will correct any authentication shortcomings in mail making authorized use of its domains. Perhaps: A Domain Owner (Section 3.2.7) wishing to fully participate in DMARC will: * Publish a DMARC Policy Record (Section 3.2.6) to cover each Author Domain (Section 3.2.2) and corresponding Organizational Domain (Section 3.2.14) to which DMARC validation should apply; * Send email that produces at least one - preferably two - Authenticated Identifiers (Section 3.2.1) that align with the Author Domain; * Receive and monitor the content of DMARC aggregate reports; and * Correct authentication shortcomings in mail making authorized use of its domains. --> <t>A <xref target="domain-owner">Domain Owner</xref> wishing to fully participate in DMARC will publish a <xref target="dmarc-policy-record">DMARC Policy Record</xref> to cover each <xref target="author-domain">Author Domain</xref> and corresponding <xref target="organizational-domain">Organizational Domain</xref> to which DMARC validation should apply; will send email that produces at least one -- preferablytwo, <eref target="#authenticated-identifiers">Authenticated Identifiers</eref>two -- <xref target="authenticated-identifiers">Authenticated Identifiers</xref> that align with the AuthorDomain,Domain; will receive and monitor the content of DMARC aggregatereports,reports; and will correct any authentication shortcomings in mail making authorized use of its domains.</t> <t>The following sections describe how to achieve this.</t> <section anchor="publish-an-spf-record-for-an-aligned-domain"><name>Publish an SPF Record for an Aligned Domain</name> <t>To configure SPF for DMARC, the Domain Owner <bcp14>MUST</bcp14> send mail that has an RFC5321.MailFrom domain that will produce an<eref target="#spf-identifiers">SPF-Authenticated Identifier</eref><xref target="spf-identifiers">SPF-Authenticated Identifier</xref> that has<eref target="#identifier-alignment-explained">Identifier Alignment</eref><xref target="identifier-alignment-explained">Identifier Alignment</xref> with the Author Domain.</t> </section> <section anchor="configure-sending-system-for-dkim-signing-using-an-aligned-domain"><name>Configure Sending System for DKIM Signing Using an Aligned Domain</name> <t>To configure DKIM for DMARC, the Domain Owner <bcp14>MUST</bcp14> send mail that has a<eref target="#dkim-signing-domain">DKIM<xref target="dkim-signing-domain">DKIM SigningDomain</eref>Domain</xref> that will produce a<eref target="#dkim-identifiers">DKIM-Authenticated Identifier</eref><xref target="dkim-identifiers">DKIM-Authenticated Identifier</xref> that has<eref target="#identifier-alignment-explained">Identifier Alignment</eref><xref target="identifier-alignment-explained">Identifier Alignment</xref> with the Author Domain.</t> </section> <section anchor="set-up-a-mailbox-to-receive-aggregate-reports"><name>Set Up a Mailbox to Receive Aggregate Reports</name> <t>Proper consumption and analysis of DMARC aggregate reports are essential to any successful DMARC deployment for a Domain Owner. DMARC aggregate reports, which are defined in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>,target="RFC9990"/>, contain valuable data for the Domain Owner, showing sources of mail using the Author Domain.</t> </section> <section anchor="publish-a-dmarc-policy-record-for-the-author-domain-and-organizational-domain"><name>Publish a DMARC Policy Record for the Author Domain and Organizational Domain</name> <t>Once SPF, DKIM, and the aggregate reports mailbox are all in place, it's time to publish a DMARC Policy Record. For best results, Domain Owners usually start with"p=none","p=none" (see <xreftarget="collect-and-analyze"></xref>)target="collect-and-analyze"/>) with the"rua""rua" tag containing a URI that references the mailbox created in the previous step. This is commonly referred to as putting the Author Domain into<eref target="#monitoring-mode">Monitoring Mode</eref>.<xref target="monitoring-mode">Monitoring Mode</xref>. If the Organizational Domain is different from the Author Domain, a record also needs to be published for the Organizational Domain.</t> </section> <section anchor="collect-and-analyze"><name>Collect and Analyze Reports</name> <t>The reason for starting at"p=none""p=none" is to ensure that nothing's been 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 of athird partythird-party sending agreement there. Starting at"p=none","p=none", therefore, takes advantage of DMARC's aggregate reporting function, with the Domain Owner using the reports to audit its own mail streams' authentication configurations.</t> <t>While it is possible for a human to read aggregate reports, they are formatted in such a way that it is recommended that they be machine-parsed, so setting up a mailbox involves more than just the physical creation of that mailbox. Many third-party services exist that will process DMARC aggregatereportsreports, or the Domain Owner can create its own set of tools. 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 successful deployment.</t> </section> <section anchor="remediate-unaligned-or-unauthenticated-mail-streams"><name>Remediate Unaligned or Unauthenticated Mail Streams</name> <t>DMARC aggregate reports can reveal to the Domain Owner mail streams using the Author Domain but not passing DMARC validation checks. These mail streams may 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 by an agent of the Domain Owner but onewhichthat is not passingisdue to Authenticated 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 publish a<eref target="#domain-owner-policy">Domain<xref target="domain-owner-policy">Domain Owner AssessmentPolicy</eref>Policy</xref> of<eref target="#enforcement">Enforcement</eref><xref target="enforcement">Enforcement</xref> for the Author Domain.</t> </section> <section anchor="decide-whether-to-update-domain-owner-assessment-policy-to-enforcement"><name>Decide Whether to Update Domain Owner Assessment Policy to Enforcement</name> <t>Once the Domain Owner is satisfied that it is properly authenticating all of its mail, then it is time to decide if it is appropriate to change its Domain Owner Assessment Policy to<eref target="#enforcement">Enforcement</eref>.<xref target="enforcement">Enforcement</xref>. Depending on its cadence for sending mail, it may take many months of consuming DMARC aggregate reports before a Domain Owner reaches the point where it is sure that it is properly authenticating all of its mail, and the decision on which"p""p" value to use will depend on its needs.</t> <t>In making thisdecisiondecision, it is important to understand the interoperability issues involved and problems that can result for mailing lists and for delivery of legitimate mail. Those issues are discussed in detail in <xreftarget="interoperability-considerations"></xref></t>target="interoperability-considerations"/></t> </section> <section anchor="a-note-on-large-complex-organizations-and-decentralized-dns-management"><name>A Note on Large, Complex Organizations and Decentralized DNS Management</name> <t>Large, complex organizations frequently adopt a decentralized model for DNS management, whereby management of a subtree of thename spacenamespace is delegated to a local department by the central IT organization. In such situations, the"psd""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 publishing a DMARC Policy Record at that node with the"psd""psd" tag set to"n"."n". The 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 published for the apex domain.</t> <t>Such configurations would work in theory, and they might involve domain names with many labels, reflecting the structure of the organization, for example:</t> <ulspacing="compact">spacing="normal"> <li>Apex domain (DMARC Policy Record published here): example.com</li> <li>Zone cut domain (DMARC Policy Record with"psd=n""psd=n" published here): b.c.d.e.f.g.example.com</li> <li>Author Domain: mail.a.b.c.d.e.f.g.example.com</li> </ul> <t>However, Domain Owners should be aware that due to the anti-abuse protections built into the<eref target="#dns-tree-walk">DNS<xref target="dns-tree-walk">DNS TreeWalk</eref>,Walk</xref>, the DMARC Policy Record published 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> <ulspacing="compact">spacing="normal"> <li>_dmarc.mail.a.b.c.d.e.f.g.example.com</li> <li>_dmarc.c.d.e.f.g.example.com</li> <li>_dmarc.d.e.f.g.example.com</li> <li>_dmarc.e.f.g.example.com</li> <li>_dmarc.f.g.example.com</li> <li>_dmarc.g.example.com</li> <li>_dmarc.example.com</li> <li>_dmarc.com</li> </ul> <t>To avoid this circumstance, Domain Owners wishing to have a specific DMARC Policy Record applied to a given<eref target="#author-domain">Author Domain</eref><xref target="author-domain">Author Domain</xref> longer than eight labels <bcp14>MUST</bcp14> publish a DMARC Policy Record at that domain's location in the DNS namespace, as such records are always queried by Mail Receivers that participate in DMARC before the Tree Walk begins. In the above example, this would mean publishing a DMARC Policy Record at the name"_dmarc.mail.a.b.c.d.e.f.g.example.com.".</t>"_dmarc.mail.a.b.c.d.e.f.g.example.com.".</t> </section> </section> <section anchor="pso-actions"><name>PSO Actions</name> <t>In addition to the DMARC Domain Owner actions, if a<eref target="#public-suffix-operator">PSO</eref><xref target="public-suffix-operator">PSO</xref> publishes a DMARC PolicyRecordRecord, it <bcp14>MUST</bcp14> include the"psd""psd" tag (see <xreftarget="policy-record-format"></xref>)target="policy-record-format"/>) with a value of"y" ("psd=y").</t>"y" ("psd=y").</t> </section> <section anchor="mail-receiver-actions"><name>Mail Receiver Actions</name><t><eref target="#mail-receiver">Mail Receivers</eref><t><xref target="mail-receiver">Mail Receivers</xref> wishing to fully participate in DMARC will apply the DMARC mechanism to inbound email messages when a<eref target="#dmarc-policy-record">DMARC<xref target="dmarc-policy-record">DMARC PolicyRecord</eref>Record</xref> exists that applies to the<eref target="#author-domain">Author Domain</eref>,<xref target="author-domain">Author Domain</xref> and will send aggregate feedback reports to Domain Owners that request them. Mail Receivers might also send failure reports to Domain Owners that request them. The following sections describe how to achieve this.</t> <t>The steps for applying the DMARC mechanism to an email message can take place during the SMTPtransaction,transaction and should do so if the Mail Receiver plans to honor<eref target="#domain-owner-policy">Domain<xref target="domain-owner-policy">Domain Owner AssessmentPolicies</eref>Policies</xref> that are at the<eref target="#enforcement">Enforcement</eref><xref target="enforcement">Enforcement</xref> state.</t> <t>Many Mail Receivers perform one or both of the underlying<eref target="#authentication-mechanisms">Authentication Mechanisms</eref><xref target="authentication-mechanisms">Authentication Mechanisms</xref> on inbound messages even in cases 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 section is intended to imply that the underlyingAuthentication Mechanismsauthentication mechanisms should only be performed by Mail Receivers participating in DMARC.</t> <section anchor="extract-author-domain"><name>Extract Author Domain</name> <t>Once the email message has been transmitted to the Mail Receiver, the Mail Receiver extracts the domain in the RFC5322.From header field as the Author Domain. If the domain is a U-label, the domain <bcp14>MUST</bcp14> be converted to an A-label, as described inSection 2.3 of<xreftarget="RFC5890"></xref>,section="2.3" target="RFC5890"/>, for further processing.</t> <t>If zero or more than one domain is extracted from the RFC5322.From header field, then DMARC validation is not possible and the process terminates. 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 <xreftarget="denial-of-dmarc-attacks"></xref>target="denial-of-dmarc-attacks"/> for further discussion.</t> </section> <section anchor="determine-mechanism-applies"><name>Determine IfThethe DMARC Mechanism Applies</name> <t>If precisely one Author Domain exists for the message, then perform the step described in<eref target="#dmarc-policy-discovery">DMARC<xref target="dmarc-policy-discovery">"DMARC PolicyDiscovery</eref>Discovery"</xref> to determine if the DMARC mechanism applies. If a<eref target="#dmarc-policy-record">DMARC<xref target="dmarc-policy-record">DMARC PolicyRecord</eref>Record</xref> is not discovered during this step, then the DMARC mechanism does not apply and DMARC validation terminates for the message.</t> </section> <section anchor="determine-authenticated-identifiers"><name>Determine If Authenticated Identifiers Exist</name> <t>For eachAuthentication Mechanismauthentication mechanism underlying DMARC, perform the required check to determine if an<eref target="#authenticated-identifier">Authenticated Identifier</eref><xref target="authenticated-identifiers">Authenticated Identifier</xref> exists for the message if such check has not already been performed. Results from each check must be preserved for later use as follows:</t> <ulspacing="compact">spacing="normal"> <li>For SPF, the preserved results <bcp14>MUST</bcp14> include"pass""pass" or"fail", and if "fail","fail". If the result is "fail", it <bcp14>SHOULD</bcp14> include information about the reasons forfailurefailure, if available. The results <bcp14>MUST</bcp14> further include the domain name used to complete the SPF check.</li> <li>For DKIM signature validation checks, for each signature checked, the results <bcp14>MUST</bcp14> include"pass""pass" or"fail", and if "fail","fail". If the result is "fail", it <bcp14>SHOULD</bcp14> include information about the reasons for failure. The results <bcp14>MUST</bcp14> further include the value of the"d""d" and"s""s" tags from each checked DKIM signature.</li> </ul> </section> <section anchor="conduct-alignment-checks"><name>Conduct Identifier Alignment Checks If Necessary</name> <t>For each Authenticated Identifier found in the message, the Mail Receiver checks to see if the Authenticated Identifier is<eref target="#identifier-alignment-evaluation">aligned</eref><xref target="identifier-alignment-evaluation">aligned</xref> with the Author Domain.</t> </section> <section anchor="pass-or-fail"><name>Determine DMARC"Pass""Pass" or"Fail"</name>"Fail"</name> <t>If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.</t> <t>If no Authenticated Identifiers exist for the domain, or none of the Authenticated Identifiers align with the Author Domain, the message is considered to fail the DMARC mechanism check.</t> </section> <section anchor="apply-policy"><name>Apply Policy If Appropriate</name> <t>Email messages that fail the DMARC mechanism check are handled in accordance with the Mail Receiver's local policies. These local policies may take into account the Domain 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 message 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 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> <t>See <xreftarget="rejecting-messages"></xref>target="rejecting-messages"/> for further discussion of topics regarding rejecting messages.</t> </section> <section anchor="store-results-of-dmarc-processing"><name>Store Results of DMARC Processing</name> <t>If the Mail Receiver intends to send aggregate feedback reports and/or failure reports, then results obtained from the application of the DMARC mechanism by the Mail Receiver <bcp14>MUST</bcp14> be preserved for eventual presentation back to the Domain Owner in the form of such reports. <xreftarget="policy-record-format"></xref>target="policy-record-format"/> and <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>target="RFC9990"/> discuss aggregate feedback reports.</t> </section> <section anchor="send-aggregate-reports"><name>Send Aggregate Reports</name> <t>To ensure maximum usefulness for DMARC across the email ecosystem, Mail Receivers <bcp14>SHOULD</bcp14> generate and send aggregate reports with a frequency 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'scontrol,control and aid the Domain Owner in determining whether and when to transition from<eref target="#monitoring-mode">Monitoring Mode</eref><xref target="monitoring-mode">Monitoring Mode</xref> to<eref target="#enforcement">Enforcement</eref>.</t><xref target="enforcement">Enforcement</xref>.</t> <t>The most common reasons for a Mail Receiver to opt out of sending aggregate reports include resource constraints, local policy against sharing data, and concerns about user privacy.</t> </section> <section anchor="send-failure-reports"><name>Optionally Send Failure Reports</name> <t>Per-message failure reports can beausefulsourcesources of information for a Domain 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 rightly concerned about protecting user privacy have either chosen to heavily redact the information in such reports (which can hinder their usefulness) or not send them at all. See <xreftarget="I-D.ietf-dmarc-failure-reporting"></xref>target="RFC9991"/> for further information.</t> </section> </section> <section anchor="policy-enforcement-considerations"><name>Policy Enforcement Considerations</name> <t>The final handling of any message is always a matter of local policy and is left to the discretion of the Mail Receiver.</t> <t>A DMARC pass for a message indicates only that the use of the<eref target="#author-domain">Author Domain</eref><xref target="author-domain">Author Domain</xref> has been validated for that message as authorized by the<eref target="#domain-owner">Domain Owner</eref>.<xref target="domain-owner">Domain Owner</xref>. 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 to reject or quarantine a message even if it passes the DMARC validation check. Mail Receivers are encouraged to maintain anti-abuse technologies to combat the possibility of DMARC-enabled abuse.</t> <t>Mail Receivers <bcp14>MAY</bcp14> choose to accept email that fails the DMARC validation check even if the published Domain Owner Assessment Policy is"reject"."reject". In particular, because of the considerations discussed in <xreftarget="RFC7960"></xref>target="RFC7960"/> and in <xreftarget="interoperability-considerations"></xref>target="interoperability-considerations"/> of this document, it is important that Mail Receivers <bcp14>SHOULD NOT</bcp14> reject messages solely because of a published policy of"reject","reject" but that they apply other knowledge and analysis to avoid situations such as rejection of legitimate messages sent in ways that DMARC cannot describe, harm to the operation of mailing lists, and similar.</t> <t>If a Mail Receiver chooses not to honor the published Domain Owner Assessment Policy to improve interoperability among mail systems, it may increase the likelihood of accepting abusive mail. At a minimum, Mail Receivers <bcp14>SHOULD</bcp14> add the Authentication-Results header field (see <xreftarget="RFC8601"></xref>),target="RFC8601"/>), and it is <bcp14>RECOMMENDED</bcp14> when delivering messages that fail the DMARC validation check.</t> <t>When Mail Receivers deviate from a published Domain Owner Assessment Policy during messageprocessingprocessing, they <bcp14>SHOULD</bcp14> make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the"PolicyOverride""PolicyOverride" feature of the aggregate report defined in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> <t>To enable Domain Owners to receive DMARC feedback without impacting existing mail processing, discovered policies of"p=none""p=none" <bcp14>MUST NOT</bcp14> modify existing mail handling processes.</t> </section> </section> <section anchor="dmarc-feedback"><name>DMARC Feedback</name> <t>DMARCFeedbackfeedback is described in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref></t>target="RFC9990"/>.</t> <t>As an operational note for Public Suffix Operators, feedback for non-existent domains can be desirable and useful, just as it can be for Organizational Domains. Therefore, both such entities should consider including"rua=""rua=" tags in any DMARC Policy Records they publish for themselves. See <xreftarget="privacy-considerations"></xref>target="privacy-considerations"/> for discussion ofPrivacy Considerations.</t>privacy considerations.</t> </section> <section anchor="other-topics"><name>Other Topics</name> <t>This section discusses some topics regarding choices made in the development of DMARC, largely to commit the history to record.</t> <section anchor="issues-specific-to-spf"><name>Issues Specific to SPF</name> <t>Though DMARC does not inherently change the semantics of an SPF policy record, historically lax enforcement of such policies has led many to publish extremely broad records containing many extensive network ranges.<eref target="#domain-owner">Domain Owners</eref><xref target="domain-owner">Domain Owners</xref> are strongly encouraged to carefully review their SPF records to understand which networks are authorized to send on behalf of the Domain Owner before publishing a DMARC Policy Record. Furthermore, Domain Owners should periodically review their SPF records to ensure that 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 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 advance of any DMARC operations. This means that an SPF hard fail("-")("-") prefix on a sender's SPF mechanism, such as"-all","-all", could cause a message to be rejected early in the SMTP transaction, before any DMARC processing takes place, if the message fails SPF authentication checks. Domain Owners choosing to use"-all""-all" to terminate SPF records should be aware ofthis,this and should understand that messages that might otherwise pass DMARC due to an aligned<eref target="#dkim-identifiers">DKIM-Authenticated Identifier</eref><xref target="dkim-identifiers">DKIM-Authenticated Identifier</xref> could be rejected solely due to an SPF fail. Moreover, messages rejected early in the SMTP transaction will never appear in aggregate DMARC reports, as the transaction will never proceed to the DATAphasephase, 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 Receivers</eref><xref target="mail-receiver">Mail Receivers</xref> can consult <xreftarget="M3SPF"></xref>target="M3SPF"/> and <xreftarget="M3AUTH"></xref>target="M3AUTH"/> for more discussion of the topic and best practices regarding publishing SPF records and when to reject based solely on SPFfailure:</t>failure.</t> </section> <section anchor="rejecting-messages"><name>Rejecting Messages</name> <t>The DMARC mechanism calls for rejection of a message during the SMTP session under certain circumstances. This is preferable to generation of a Delivery Status Notification <xreftarget="RFC3464"></xref>,target="RFC3464"/>, since fraudulent messages caught and rejected using the DMARC mechanism would then result in the annoying generation of such failure reports that go back to the RFC5321.MailFrom address.</t> <t>This synchronous rejection is typically done in one of two ways:</t> <ul><li><t>Full rejection,<li><t>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; the SMTP client is then responsible for generating a notification that delivery failed (see <xref target="RFC5321" sectionFormat="of"section="4.2.5"></xref>).</t>section="4.2.5"/>).</t> </li> <li><t>A"silent discard","silent discard", wherein the SMTP server returns a 2xy reply code implying to the client that delivery(or,(or atleast,least relay) was successfullycompleted,completed but then simply discards the message with no further action.</t> </li> </ul> <t>Each of these has a cost. For instance, a silent discard can help to prevent backscatter, but it also effectively means that the SMTP server has to be programmed to give a false result, which can confound external debugging efforts.</t> <t>Similarly, the text portion of the SMTP reply may be important to consider. For example, when rejecting a message, revealing the reason for the rejection might give an attacker enough information to bypass those efforts on a later attempt, though it might also assist a legitimate client to determine the source of some local issue that caused the rejection.</t> <t>In the latter case, when doing an SMTP rejection, providing a clear hint can be useful in resolving issues. A<eref target="#mail-receiver">Mail Receiver</eref><xref target="mail-receiver">Mail Receiver</xref> might indicate in plain text the reason for the rejection by using the word"DMARC""DMARC" somewhere in the reply text. For example:</t><artwork><![CDATA[550<artwork><![CDATA[ 550 5.7.1 Email rejected per DMARC policy forexample.com ]]></artwork>example.com]]></artwork> <t>Many systems are able to scan the SMTP reply text to determine the nature of the rejection. Thus, providing a machine-detectable reason for rejection allows the problems causing rejections to be properly addressed by automated systems.</t> <t>If a Mail Receiver elects to defer delivery due to the inability to retrieve or apply DMARC policy, this is best done with a 4xy SMTP reply code.</t> </section> <section anchor="interoperability-issues"><name>Interoperability Issues</name> <t>DMARC limits which end-to-end scenarios can achieve a"pass""pass" result.</t> <t>Because DMARC relies on SPF <xreftarget="RFC7208"></xref>target="RFC7208"/> and/or DKIM <xreftarget="RFC6376"></xref>target="RFC6376"/> to achieve a"pass","pass", their limitations also apply.</t> <t>Issues specific to the use of policy mechanisms alongside DKIM are further discussed in <xreftarget="RFC6377"></xref>,target="RFC6377"/>, particularly Section5.2.</t><xref target="RFC6377" section="5.2" sectionFormat="bare"/>.</t> <t>Mail that is sent by authorized, independent third parties might not be sent with Identifier Alignment, also preventing a"pass""pass" result. A Domain Owner can use DMARC aggregate reports to identify this mail and take steps to address authentication shortcomings.</t> </section> <section anchor="interoperability-considerations"><name>Interoperability Considerations</name> <t>As discussed in"Interoperability"Interoperability Issues betweenDMARCDomain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect EmailFlows"Flows" <xreftarget="RFC7960"></xref>,target="RFC7960"/>, the use of"p=reject""p=reject" can be incompatible with and cause interoperability problems to indirect message flows such as"alumni forwarders","alumni forwarders", role-based email aliases, and mailing lists across the Internet.</t> <t>As an example of this, a bank might send only targeted messages to account holders. Those account holders might have given their bank addresses such as"jones@alumni.example.edu""jones@alumni.example.edu" (an address that relays the messages to another address with a real mailbox) or"finance@association.example""finance@association.example" (a role-based address that does similar relaying for the current head of finance at the association). When such mail is delivered to the actual recipient mailbox, it will most likely fail SPF checks unless the RFC5321.MailFrom address is rewritten by the relaying MTA, as the incoming IP address will be that of"example.edu""example.edu" or"association.example","association.example" and not an IP address authorized by the originating RFC5321.MailFrom domain. DKIM signatures will generally remain valid in these relay situations.</t><blockquote><t>It<t indent="3">It is therefore critical that domains that publish"p=reject""p=reject" <bcp14>MUST NOT</bcp14> rely solely on SPF to secure a DMARCpass,pass and <bcp14>MUST</bcp14> apply valid DKIM signatures to their messages.</t></blockquote><t>In<t>In the case of domains that have general users who send routine email, those that publish a<eref target="#domain-owner-policy">Domain<xref target="domain-owner-policy">Domain Owner AssessmentPolicy</eref>Policy</xref> of"p=reject""p=reject" are likely to create significant interoperability issues. In particular, if users in such domains post messages to mailing 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 in <xreftarget="RFC7960"></xref>.</t> <blockquote><t>Ittarget="RFC7960"/>.</t> <t indent="3">It is therefore critical that domains that host users who might post messages to mailing lists <bcp14>SHOULD NOT</bcp14> publish Domain Owner Assessment Policies of"p=reject"."p=reject". Any such domains wishing to publish"p=reject""p=reject" <bcp14>SHOULD</bcp14> first take advantage of DMARC aggregate report data for their domain to determine the possible impact to their users, first by publishing"p=none""p=none" for at least a month, followed by publishing"p=quarantine""p=quarantine" for an equally long period of time, and comparing the message disposition results. Domains that choose to publish"p=reject""p=reject" <bcp14>SHOULD</bcp14>eitherimplement policies that their users not post to Internet mailing lists and/or inform their users that their participation in mailing lists may be hindered.</t></blockquote><t>As<t>As noted in <xreftarget="policy-enforcement-considerations"></xref>, <eref target="#mail-receivers">Mail Receivers</eref>target="policy-enforcement-considerations"/>, <xref target="mail-receiver">Mail Receivers</xref> need to apply more analysis than just DMARC validation in their disposition of incoming messages. An example of the consequences of honoring a Domain Owner Assessment Policy of"p=reject""p=reject" without further analysis 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 canceled 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 longer working, so the address is automatically unsubscribed. An example of this scenario, albeit with DKIM Author Domain Signing Practices (ADSP) rather than DMARC, can be found in <xref target="RFC6377" sectionFormat="of"section="5.2"></xref>.</t> <blockquote><t>Itsection="5.2"/>.</t> <t indent="3">It is therefore critical that Mail Receivers <bcp14>MUST NOT</bcp14> reject incoming messages solely on the basis of a"p=reject""p=reject" policy by the sending domain. Mail Receivers must use the DMARC policy as part of their disposition decision, along with other knowledge and analysis."Other"Other knowledge andanalysis"analysis" here might refer to observed sending patterns forproperly-authenticatedproperly authenticated mail using the sending domain, content filtering, etc. In the absence of other knowledge and analysis, Mail Receivers <bcp14>MUST</bcp14> treat such failing mail as if the policy were"p=quarantine""p=quarantine" rather than"p=reject".</t> </blockquote><t>Failure"p=reject".</t> <t>Failure to understand and abide by these considerations can cause legitimate, sometimesimportantimportant, email to berejected,rejected; can cause operational damage to mailing lists throughout theInternet,Internet; and can result in trouble-desk calls and complaints from the Mail Receiver's employees, customers, and clients.</t> <t>In practice, despite this advice, few Mail Receivers apply any mitigation techniques when receiving indirect mail flows, few organizations consider 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 through mailing lists with unmodified From: header lines is frequently rejected due to ap=reject"p=reject" policy.</t> <t>In the ten years since large consumer mail systems started publishing p=reject 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 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 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 life.</t> <t>Mail developers have been trying for a decade to invent technical methods to allow mailing lists to continue to work without modifying the From: header line, with a prominent example being the Authenticated Received Chain (ARC) protocol described in <xreftarget="RFC8617"></xref>.target="RFC8617"/>. While work continues, as of this document's publication, none of the methods have become widely used. Should such a technical method achieve widespread adoption in the future, this document can be updated to reflect that.</t> </section> </section> <section anchor="conformance-requirements"><name>Conformance Requirements for Full DMARC Participation</name> <t>This document describes the DMARCmechanism,mechanism and allows Domain Owners and Mail Receivers 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> <t>In order to fully participate in DMARC, Domain Owners:</t> <ulspacing="compact">spacing="normal"> <li><bcp14>MUST</bcp14> send mail so it produces an SPF-AuthenticatedidentifierIdentifier that has Identifier Alignment with the AuthorDomain</li>Domain.</li> <li><bcp14>MUST</bcp14> send mail that has a DKIM Signing Domain that will produce a DKIM-Authenticated Identifier that has Identifier Alignment with the AuthorDomain</li>Domain.</li> <li><bcp14>MUST</bcp14> set up a mailbox to receive aggregate reports and collect and analyze thosereports</li>reports.</li> <li><bcp14>MUST</bcp14> publish a DMARC Policy Record for the Author Domain and the Organizational Domain, if it differs from the AuthorDomain</li>Domain.</li> <li><bcp14>MUST NOT</bcp14> rely solely on SPF for a DMARC pass if the DMARC policy for the Author Domain is"p=reject"</li>"p=reject".</li> </ul> <t>In order to fully participate in DMARC, MailReceivers</t>Receivers:</t> <ulspacing="compact">spacing="normal"> <li><bcp14>MUST</bcp14> check for the existence of a DMARC Policy Record for the Author Domain of an inbound mail message to determine if the DMARC mechanism applies to that message.</li> <li><bcp14>MUST</bcp14> determine if Authenticated Identifiers exist for the message and preserve the results of those checks for future use inreportgingreporting if the DMARC mechanism applies to themessage</li>message.</li> <li><bcp14>MUST</bcp14> conduct necessary IdentifierAlignmeentAlignment checks if the DMARC mechanism applies for the message and Authenticated Identifiersexist</li>exist.</li> <li><bcp14>MUST</bcp14> use the information from the checks for Authenticated Identifiers to determine if the DMARC validation result is"pass""pass" or"fail""fail" for the message.</li> <li><bcp14>MUST</bcp14> support the"mailto:""mailto:" URI for sending requestedreports</li>reports.</li> <li><bcp14>SHOULD</bcp14> send aggregate reports on at least a dailybasis</li>basis.</li> <li><bcp14>MUST NOT</bcp14> reject messages solely on the basis of a"p=reject""p=reject" policy for the AuthorDomain</li>Domain.</li> </ul> </section> <section anchor="iana-considerations"><name>IANA Considerations</name> <t>This section describes actionsto becompleted by IANA.</t> <section anchor="email-authentication-methods-registry-update"><name>Email Authentication Methods Registry Update</name><t>A registry group called "Email Authentication Parameters" exists, and within it a registry group called "Email Authentication Methods" exists and needs to be updated in the manner specified in this section.</t><t>The properties of an email message to be evaluated by an email authentication methodare registered with IANA in this registry. Entries are assigned only for values thathave beendocumentedregistered by IANA ina manner that satisfiestheterms of Specification Required, per <xref target="RFC8126"></xref>. Each"Email Authentication Methods" registry within the "Email Authentication Parameters" registry group. </t> <t>Each registration includes the authentication method; the specification that defines the authentication method; the property type (ptype), which is one of the ptype values from the entries in the"Email"Email Authentication PropertyTypes"Types" registry in this same registry group; the property; the value for that property; the status of the property, which is one of"active""active" or"deprecated";"deprecated"; and its version. TheDesignated Expertdesignated expert needs to confirm that the provided specification adequately describes the property and the method for its evaluation and clearly presents how they would be used within the DMARC context by Domain Owners and Mail Receivers.</t><t>The set of entries<t>IANA has changed the registration procedure from Expert Review tobe updated inSpecification Required <xref target="RFC8126"/> and has listed this document as an additional reference for the registry. IANA has updated the registryisas follows:</t> <tablealign="left"><name>"Emailalign="center"><name>Email Authentication Methods RegistryUpdate"Update </name> <thead> <tr> <th align="left">Method</th> <thalign="left">Defined</th>align="left">Definition</th> <th align="left">ptype</th> <th align="left">Property</th> <th align="left">Value</th> <th align="left">Status</th> <th align="left">Version</th> </tr> </thead> <tbody> <tr> <td align="left">dmarc</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">header</td> <td align="left">from</td> <td align="left">The domain portion of the RFC5322.From header field</td> <td align="left">active</td> <td align="left">1</td> </tr> <tr> <td align="left">dmarc</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">policy</td> <td align="left">dmarc</td> <td align="left">The evaluated DMARC policyapplied/toapplied / to be applied after policy options have been processed. Must be"none", "quarantine","none", "quarantine", or"reject".</td>"reject".</td> <td align="left">active</td> <td align="left">1</td> </tr> </tbody> </table></section> <section anchor="authentication-results-result-registry"><name>Email Authentication Result Names Registry Update</name><t>Also within the registry group "Email Authentication Parameters" a registry called "Email Authentication Result Names" exists and should be updated to reference this section of this document.</t><t>Result codes for DMARC are registered with IANA inthis registry. Entries are assigned only for values that have been documented in a manner that satisfiestheterms of Specification Required, per <xref target="RFC8126"></xref>."Email Authentication Result Names" registry within "Email Authentication Parameters" registry group. </t> <t> Each registration includes the auth method; the code; the specification that defines the code; and the code's status, which is one of"active""active" or"deprecated". The "Description""deprecated". Note that the "Description" field is included here solely for the reader'sreference,reference and does not appear in the IANA registry. TheDesignated Expertdesignated expert needs to confirm that the provided specification adequately describes the result code and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers.</t><t>The set of entries<t>IANA has changed the registration procedure from Expert Review tobe updated inSpecification Required <xref target="RFC8126"/> and has listed this document as an additional reference for the registry. IANA has updated the registryisasfollows:</t>follows, replacing references to <xref target="RFC7489"/> with references to this document:</t> <tablealign="left"><name>"Emailalign="center"><name>Email Authentication Result Names RegistryUpdate"Update </name> <thead> <tr> <th align="left">AuthMethod</th>Method(s)</th> <th align="left">Code</th> <th align="left">Specification</th> <th align="left">Status</th> <th align="left">Description</th> </tr> </thead> <tbody> <tr> <td align="left">dmarc</td> <td align="left">fail</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">A DMARC Policy Record exists for the Author Domain, but no Authenticated Identifier with Identifier Alignment exists</td> </tr> <tr> <td align="left">dmarc</td> <td align="left">none</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">No DMARC Policy Record exists for the Author Domain</td> </tr> <tr> <td align="left">dmarc</td> <td align="left">pass</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">A DMARC Policy Record exists for the Author Domain, and an Authenticated Identifier with Identifier Alignment exists</td> </tr> <tr> <td align="left">dmarc</td> <td align="left">permerror</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">An error occurred during DMARC evaluation that is unrecoverable, such as the retrieval of an improperly formatted DMARC Policy Record. A later attempt is unlikely to produce a final result</td> </tr> <tr> <td align="left">dmarc</td> <td align="left">temperror</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">An error occurred during DMARC evaluation that is likely transient in nature, such as a DNS server being temporarily unreachable. A later attempt might produce a final result</td> </tr> </tbody> </table></section> <section anchor="dmarc-tag-registry-update"><name>DMARC Tags Registry Update</name><t>A registry group called "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" exists, and within it, a registry called "DMARC Tags" exists. That registry should be updated as described in this section.</t><t>Names of tags used in DMARC Policy Records as part of"tag-value""tag-value" pairs are registered with IANA inthis registry. Entriesthe "DMARC Tags" registry within the "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" registry group. </t> <t>Entries are assigned only for values that have been documented in a manner that satisfies the terms of Specification Required, per[RFC8126].<xref target="RFC8126"/>. Each registration includes the tag name, the specification that defines the tag, the status of the tag, and a brief description of the tag. TheDesignated Expertdesignated 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 Domain Owners and Mail Receivers. The"status""status" column is one of the following:</t><ul spacing="compact"> <li>"active",<ul> <li>"active", meaning the tag is in use in current implementations, and its specifications is expected to be stable</li><li>"experimental",<li>"experimental", meaning the tag is relatively new and may be in use in some current implementations but not in others, and its specification is not expected to be stable</li><li>"historic",<li>"historic", meaning the tag is considered deprecated and is not expected to be in use in any current implementation</li> </ul> <t>To avoid version compatibility issues, tags added to the DMARC specification are to avoid changing the semantics of existing records when processed by implementations conforming to prior specifications.</t><t>The set of entries to be updated in<t>IANA has listed this document (rather than <xref target="RFC7489"/>) as the reference for the registry. IANA has updated the registryisasfollows:</t>follows, including the addition of the new "t" registration:</t> <tablealign="left"><name>"DMARCalign="center"><name>DMARC Tags RegistryUpdatee"Update </name> <thead> <tr> <th align="left">Tag Name</th> <th align="left">Reference</th> <th align="left">Status</th> <th align="left">Description</th> </tr> </thead> <tbody> <tr> <td align="left">adkim</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">DKIM Identifier Alignment mode</td> </tr> <tr> <td align="left">aspf</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">SPF Identifier Alignment mode</td> </tr> <tr> <td align="left">fo</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">Failure reporting options</td> </tr> <tr> <td align="left">np</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">Requested Domain Owner Assessment Policy for non-existent subdomains</td> </tr> <tr> <td align="left">p</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">Requested Domain Owner Assessment Policy</td> </tr> <tr> <td align="left">pct</td> <td align="left"><xreftarget="RFC7489"></xref></td>target="RFC7489"/></td> <td align="left">historic</td> <td align="left">Sampling rate</td> </tr> <tr> <td align="left">psd</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">Indicates whether the DMARC Policy Record is published by a Public Suffix Domain</td> </tr> <tr> <td align="left">rf</td> <td align="left"><xreftarget="RFC7489"></xref></td>target="RFC7489"/></td> <td align="left">historic</td> <td align="left">Failure reporting format(s)</td> </tr> <tr> <td align="left">ri</td> <td align="left"><xreftarget="RFC7489"></xref></td>target="RFC7489"/></td> <td align="left">historic</td> <td align="left">Aggregate Reporting interval</td> </tr> <tr> <td align="left">rua</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">Reporting URI(s) for DMARC aggregate feedback reports</td> </tr> <tr> <td align="left">ruf</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">Reporting URI(s) for message-specific DMARC failure reports</td> </tr> <tr> <td align="left">sp</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">Requested Domain Owner Assessment Policy for subdomains</td> </tr> <tr> <td align="left">t</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">DMARC policy test mode</td> </tr> <tr> <td align="left">v</td> <tdalign="left">[this document]</td>align="left">RFC 9989</td> <td align="left">active</td> <td align="left">DMARC specification version</td> </tr> </tbody></table></section></table> </section> <section anchor="dmarc-report-formats-registry"><name>DMARC Report Formats Registry Update</name><t>Also within the registry group "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" a registry called "DMARC Report Formats" exists and should be updated to reference this document.</t><t>Names of DMARC failure reporting formats are registered with IANA inthis registry. Entriesthe "DMARC Report Formats" registry within the "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" registry group.</t> <t>Entries are assigned only for values that have been documented in a manner that satisfies the terms of Specification Required, per[RFC8126].<xref target="RFC8126"/>. In addition to a reference to a permanent specification, each registration includes the format name, the format's status, and a brief description of the format. TheDesignated Expertdesignated expert needs to confirm that the provided specification adequately describes the report format and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers. The"status""status" column is one of the following:</t><ul spacing="compact"> <li>"active",<ul> <li>"active", meaning the format is in use in current implementations, and its specifications is expected to be stable</li><li>"experimental",<li>"experimental", meaning the format is relatively new and may be in use in some current implementations but not in others, and its specification is not expected to be stable</li><li>"historic",<li>"historic", meaning the format is considered deprecated and is not expected to be in use in any current implementation</li> </ul><t>The entry to be updated in<t>IANA has listed this document (rather than <xref target="RFC7489"/>) as the reference for the registry. IANA has updated the registryisas follows:</t> <tablealign="left"><name>"DMARCalign="center"><name>DMARC Report Formats RegistryUpdate"Update </name> <thead> <tr> <th>Format Name</th> <th>Reference</th> <th>Status</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td>afrf</td><td>[this document]</td><td>RFC 9989</td> <td>active</td> <td>Authentication Failure Reporting Format (see <xreftarget="RFC6591"></xref>)</td>target="RFC6591"/>)</td> </tr> </tbody> </table></section> <section anchor="underscored-and-globally-scoped-dns-node-names-registry-update"><name>Underscored and Globally Scoped DNS Node Names Registry Update</name><t>A registry group called "Domain Name System (DNS) Parameters" exists, and within it, a registry called "Underscored and Globally Scoped DNS Node Names" exists, and that registry should be updated to reference this document.</t><t>The names of DNS Resource Records (RRs) beginning with an underscore character that are globally scoped (as per <xreftarget="RFC8552"></xref>)target="RFC8552"/>) are registered with IANA inthis registry. Inthe "Underscored and Globally Scoped DNS Node Names" registry within the "Domain Name System (DNS) Parameters" registry group.</t> <t>In addition to a reference to a permanent specification, each registration contains the DNS Resource Record (RR) type and Node Name. TheDesignated Expertdesignated expert needs to confirm that the provided specification adequately describes the Node Name and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers.</t><t>The<t>IANA has updated the reference for following entry tobe updated inpoint to thisregistry is as follows:</t>document (instead of <xref target="RFC7489"/>):</t> <tablealign="left"><name>"Underscoredalign="center"><name>Underscored and Globally Scoped DNS Node Names RegistryUpdate"Update </name> <thead> <tr> <th>RR Type</th> <th>_NODE NAME</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>TXT</td> <td>_dmarc</td><td>[this document]</td><td>RFC 9989</td> </tr> </tbody> </table></section> </section> <section anchor="privacy-considerations"><name>Privacy Considerations</name> <t>This section discusses issues specific to private data that may be included if DMARC reports are requested. Issues associated with sending aggregate reports and failure reports are addressed in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>target="RFC9990"/> and <xreftarget="I-D.ietf-dmarc-failure-reporting"></xref>target="RFC9991"/>, respectively.</t> <section anchor="aggregate-report-considerations"><name>Aggregate Report Considerations</name> <t>Aggregate reports may, particularly for small organizations, provide some limited insight into email sending patterns. As an example, in a small organization, an aggregate report from a particular domain may be sufficient to make the Report Consumer aware of sensitive personal or business information. If settingan "rua"a "rua" tag in a DMARC Policy Record, the reporting address needs controls appropriate to the organizational requirements to mitigate any risk associated with receiving and handling reports.</t> <t>In the case of"rua""rua" requests for multi-organizational PSDs, additional information leakage considerations exist. Multi-organizational PSDs that do not mandate DMARC use by registrants risk exposure of private data of registrant domains if they include the"rua""rua" tag in their DMARC Policy Record.</t> </section> <section anchor="failure-report-considerations"><name>Failure Report Considerations</name> <t>Failure reports do provide insight into email sending patterns, including specific users. If requesting failure reports, data management controls are needed to support appropriate management of this information. The additionaldetaildetails available through failure reports (relative to aggregate reports) can drive a need for additional controls. As an example, a company may be legally restricted from receiving data related to a specific subsidiary. Before requesting failure reports, any such data spillage risks have to be addressed through data management controls or publishing DMARC Policy Records for relevant subdomains to prevent reporting on data related to their emails.</t> <t>Due to the nature of the email contentswhichthat may be shared throughFailure Reports,failure reports, most Mail Receivers refuse to send them out of privacy concerns.Out of bandOut-of-band agreements between Report Consumers and Mail Receivers may be required to address these concerns.</t> <t>DMARC Policy Records for multi-organizational PSDs <bcp14>MUST NOT</bcp14> include the"ruf""ruf" tag.</t> </section> </section> <section anchor="security-considerations"><name>Security Considerations</name> <t>This section discusses security issues and possible remediations (where available) for DMARC.</t> <section anchor="authentication-methods"><name>Authentication Methods</name> <t>Security considerations from the authentication methods used by DMARC are incorporated here by reference.</t> <t>Both of the email authentication methods that underlie DMARC provide some assurance that an email was transmitted by an MTAwhichthat is authorized to do so. SPF policies map domain names to sets of authorized MTAs (see <xref target="RFC7208" sectionFormat="of"section="11.4"></xref>).section="11.4"/>). 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> <t>Whenever mail is sent, there is a risk that an overly permissive source may send mail that will receive a DMARCpass"pass" result that was not, in fact, intended by the Domain Owner. These results may lead to issues when systems interpret DMARCpass"pass" results to indicate a message is in some way authentic. They also allow such unauthorized senders to evade the Domain Owner's intended message handling for DMARC validation failures.</t> <t>To avoid thisriskrisk, one must ensure that no unauthorized source can add DKIM signatures to the domain's mail or transmit mailwhichthat will evaluate as an SPFpass. If, nonetheless,"pass" result. Nonetheless, if a Domain Owner wishes to include a permissive source in a domain's SPF record, the source can be excluded from DMARC consideration by using the"?""?" qualifier on the SPF record mechanism associated with that source. The DMARCworking groupWorking Group had a lively discussion about possibly eliminating SPF entirely as an underlyingAuthentication Mechanismauthentication mechanism for DMARC, but consensus was not reached, and the suggestion to use the"?""?" qualifier for permissive sources is presented here instead.</t> </section> <section anchor="attacks-on-reporting-uris"><name>Attacks on Reporting URIs</name> <t>URIs published in DNS TXT records are well-understood possible targets for an attack. Specifications such as <xreftarget="RFC1035"></xref>target="RFC1035"/> and <xreftarget="RFC2142"></xref>target="RFC2142"/> 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 MX, NS, and others advertise potential attack destinations. Common DNSnamesnames, such as"www""www", plainly identify the locations at which particular services can be found, providing destinations for targeted denial-of-service or penetration attacks. This all means that Domain Owners will need to harden these addresses against various attacks, including but not limited to:</t> <ul> <li><t>high-volume denial-of-service attacks;</t> </li> <li><t>deliberate construction of malformed reports intended to identify or exploit parsing or processingvulnerabilities;</t>vulnerabilities; and</t> </li> <li><t>deliberate construction of reports containing false claims for the Submitter or Reported-Domain fields, including the possibility of false data from compromised but known Mail Receivers.</t> </li> </ul> </section> <section anchor="dns-security"><name>DNS Security</name> <t>The DMARC mechanism and its underlyingAuthentication Mechanismsauthentication mechanisms (SPF and DKIM) depend on the security of the DNS. Examples of how hostile parties can have an adverse impact on DNS traffic include:</t> <ul> <li><t>If they can snoop on DNS traffic, they can get an idea of who is receiving mail using the domain(s) in question.</t> </li> <li><t>If they can block outgoing or reply DNS messages, they can prevent systems from discovering senders' DMARC policies.</t> </li> <li><t>If they can send forged response packets, they can make aligned mail appear unaligned orvice-versa.</t>vice versa.</t> </li> </ul> <t>None of these threats are unique to DMARC, and they can be addressed using a variety oftechniques,techniques including, but not limitedto:</t>to, the following:</t> <ul> <li><t>Signing DNS records with Domain Name System Security Extensions (DNSSEC) <xreftarget="RFC9364"></xref>,target="RFC9364"/>, which enables recipients to validate the integrity of DNS data and detect and discard forged responses.</t> </li> <li><t>DNS over TLS <xreftarget="RFC7858"></xref>target="RFC7858"/> or DNS over HTTPS <xreftarget="RFC8484"></xref>target="RFC8484"/> can mitigate snooping and forged responses.</t> </li> </ul> </section> <section anchor="display-name-attacks"><name>Display Name Attacks</name> <t>An increasingly common attack in messaging abuse is the presentation of false information in thedisplay-namedisplay name portion of the RFC5322.From header field. 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 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> <t>Such attacks, known as display name attacks, are out of scope for DMARC.</t> </section> <section anchor="denial-of-dmarc-attacks"><name>Denial of DMARC Processing Attacks</name> <t>The declaration in <xreftarget="extract-author-domain"></xref>target="extract-author-domain"/> and elsewhere in this document 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 taken into consideration.</t> <t>Because such messages are outside the scope of this document, an attacker can craft messages with multiple RFC5322.From domains, including the spoofed domain, in an effort to bypass DMARC validation and get the fraudulent message to be displayed by the victim'sMUAMail User Agent (MUA) with the spoofed domain successfully shown to the victim. In those cases where such messages are not rejected due to other reasons (for example, many such messages would violateRFC5322'sthe requirement described in <xref target="RFC5322"/> that there be precisely one From: header field), care must be taken by the Mail Receiver to recognize such messages as the threats they might be and handle them appropriately.</t> <t>The case of a syntactically valid multi-valued RFC5322.From field presents a particular challenge. Experience has shown that most such messages are abusive and/or unwanted by their recipients, and given this fact, a Mail Receiver may make a 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 that the message be subject to DMARC validation, a recommended approach as per <xreftarget="RFC7489"></xref>target="RFC7489"/> is to apply the DMARC mechanism to each domain found in the RFC5322.From field as the Author Domain and apply the most strict policy selected among the 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 a large number of domains (where"large""large" is defined by each Mail Receiver) will expose the Mail Receiver to a form ofdenial of servicedenial-of-service attack. Limiting the number of Author Domains processed will avoid this risk. If not all Author Domains are processed, then the DMARC evaluation is incomplete.</t> </section> <section anchor="external-report-addresses"><name>External Reporting Addresses</name> <t>To avoid abuse by bad actors, reporting addresses generally have to be inside the domains about which reports are requested. To accommodate specialcasescases, such as a need to get reports about domains that cannot actually receive mail, <xreftarget="I-D.ietf-dmarc-aggregate-reporting"target="RFC9990" sectionFormat="of"section="3"></xref>section="3"/> describes a DNS-based mechanism for validating approved external reporting.</t> <t>The obvious consideration here is an increased DNS load against domains that are claimed as external recipients. Negative caching will mitigate this problem, but only to a limited extent, mostly dependent on the default TTL in the domain's SOA record.</t> <t>Where possible, external reporting is best achieved by having the report be directed to domains that can receive mail and simply having it automatically forwarded to the desired external destination.</t> <t>Note that the addresses shown in the"ruf""ruf" tag receive more information that might be considered private data since it is possible for actual email content to appear in the failure reports. The URIs identified there are thus more attractive targets for intrusion attempts than those found in the"rua""rua" tag. Moreover, attacking the DNS of the subject domain to cause failure data to be routed fraudulently to an attacker's systems may be an attractive prospect. Deployment of DNSSEC <xreftarget="RFC9364"></xref>target="RFC9364"/> is advisable if this is a concern.</t> </section> <section anchor="secure-protocols"><name>Secure Protocols</name> <t>This document encourages the use of secure transport mechanisms to prevent the loss of private data to third parties that may be able to monitor such transmissions. Unencrypted mechanisms <bcp14>SHOULD</bcp14> be avoided.</t> <t>In particular, a message that was originally encrypted or otherwise secured might appear in a report that is not sent securely, which could reveal private information.</t> </section> <section anchor="relaxed-alignment-considerations"><name>Relaxed Alignment Considerations</name> <t>The DMARC mechanism allows both<eref target="#identifier-alignment-explained">DKIM-<xref target="identifier-alignment-explained">DKIM- and SPF-AuthenticatedIdentifiers</eref>Identifiers</xref> to validate authorized use of an<eref target="#author-domain">Author Domain</eref><xref target="author-domain">Author Domain</xref> on behalf of a<eref target="#domain-owner">Domain Owner</eref>.<xref target="domain-owner">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 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> <ulspacing="compact">spacing="normal"> <li>A DMARC Policy Record exists for the domain"example.com","example.com", such that"example.com""example.com" is an OrganizationalDomain</li>Domain.</li> <li>An attacker controls DNS for the domain"evil.example.com""evil.example.com" and publishes an SPF record for thatdomain</li>domain.</li> <li>The attacker sends email with the RFC5322.From header field containing"foo@example.com""foo@example.com" and an SPF-Authenticated Identifier of"evil.example.com"</li>"evil.example.com".</li> </ul> <t>Although this email was not authorized by the Domain Owner, it can produce a DMARC pass because the SPF-Authenticated Identifier("evil.example.com")("evil.example.com") has Identifier Alignment with the Author Domain("example.com").</t>("example.com").</t> <t>The Organizational Domain Owner should be careful not to delegate control of subdomains if this is anissue,issue and consider using the<eref target="#strict-alignment">Strict Alignment</eref><xref target="strict-alignment">strict alignment</xref> option if appropriate.</t> <t>DMARC evaluation for relaxed alignment is also highly sensitive to errors in determining the Organizational Domain if the Author Domain does not have a published<eref target="#dmarc-policy-record">DMARC<xref target="dmarc-policy-record">DMARC PolicyRecord</eref>.Record</xref>. If an incorrectly selected Organizational 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 verdict. This potential exists for both the legacy <xreftarget="RFC7489"></xref>target="RFC7489"/> and current methods for determining theorganizational domain,Organizational Domain; the latter is described in <xreftarget="identifier-alignment-evaluation"></xref>.</t>target="identifier-alignment-evaluation"/>.</t> <t>The following example illustrates this possibility:</t> <ulspacing="compact">spacing="normal"> <li>Mail is sent with an Author Domain of"a.mail.example.com""a.mail.example.com" and Authenticated Identifiers of"mail.example.com"</li>"mail.example.com".</li> <li>There is no DMARC Policy Record published at"_dmarc.a.mail.example.com"</li>"_dmarc.a.mail.example.com".</li> <li>There is one published at"_dmarc.mail.example.com""_dmarc.mail.example.com" and this is intended to be the Organizational Domain for thismessage</li>message.</li> <li>There is also a DMARC Policy Record published at"_dmarc.example.com","_dmarc.example.com", with default alignment(relaxed)</li>(relaxed).</li> <li>An attacker is able to send mail with the Author Domain of"evil.example.com""evil.example.com" and an Authenticated Identifier of"mail.example.com"</li>"mail.example.com".</li> </ul> <t>In this scenario, if a Mail Receiver incorrectly determines the Organizational Domain to be"example.com","example.com", then the attacker's mail will pass DMARC validation checks.</t> <t>This issue is entirely avoided by the use ofStrict Alignmentstrict alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization's email.</t> <t>For cases whereStrict Alignmentstrict alignment is not appropriate, this issue can be mitigated by the Domain Owner periodically checking (perhapsweekly,weekly or whatever frequency might be appropriate for a given organization's operational needs)checkingthe DMARC Policy Records, if any, of<eref target="#public-suffix-domain">PSDs</eref><xref target="public-suffix-domain">PSDs</xref> above the Organizational Domain in the DNS treeand (for(and for legacy <xreftarget="RFC7489"></xref>target="RFC7489"/>, checking that appropriate PSL entries remain present). If a PSD publishes a DMARC Policy Record without the appropriate"psd=y""psd=y" tag, Organizational Domain owners can add"psd=n""psd=n" to their Organizational Domain's DMARC Policy Record so that the PSD's DMARC Policy Record will not be incorrectly interpreted to indicate that the PSD is the Organizational Domain.</t> </section> </section> </middle> <!-- [rfced] References a) [M3AUTH] Please review. The current URL for this reference - https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication- recommended-best-practices-09-2020.pdf - resolves to a page with the right title, but there doesn't appear to be any content at the URL. Is this the correct link for this reference? b) [M3SPF] Please review. The current URL for this reference - https://www.m3aawg.org/Managing-SPF-Records - results in a page with a "Page not found" message. We were unable to find a URL matching the information for this reference. Is there another URL we should use for this reference? --> <back> <references><name>References</name> <references><name>Normative References</name><xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dmarc-aggregate-reporting.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dmarc-failure-reporting.xml"/><!-- draft-ietf-dmarc-aggregate-reporting-32 companion doc RFC YYY1 in EDIT as of 03/30/26 --> <reference anchor="RFC9990" target="https://www.rfc-editor.org/info/rfc9990"> <front> <title>Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting</title> <author fullname="Alex Brotman" initials="A." surname="Brotman" role="editor"> <organization>Comcast, Inc.</organization> </author> <date month="May" year="2026"/> </front> <seriesInfo name="RFC" value="9990"/> <seriesInfo name="DOI" value="10.17487/RFC9990"/> </reference> <!-- draft-ietf-dmarc-failure-reporting-25 companion doc RFC YYY2 in RFC-EDITOR as of 05/08/26 --> <reference anchor="RFC9991" target="https://www.rfc-editor.org/info/rfc9991"> <front> <title>Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting</title> <author fullname="Steven M Jones" initials="S. M." surname="Jones" role="editor"> <organization>DMARC.org</organization> </author> <author fullname="Alessandro Vesely" initials="A." surname="Vesely" role="editor"> <organization>Tana</organization> </author> <date month="May" year="2026"/> </front> <seriesInfo name="RFC" value="9991"/> <seriesInfo name="DOI" value="10.17487/RFC9991"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4343.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6377.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6591.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6651.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6652.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7208.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8601.xml"/> </references> <references><name>Informative References</name> <reference anchor="M3AUTH" target="https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf"> <front> <title>M3AAWG Email Authentication Recommended Best Practices</title><author></author><author> <organization>Messaging Malware Mobile Anti-Abuse Working Group (M3AAWG)</organization> </author> </front> </reference> <reference anchor="M3SPF" target="https://www.m3aawg.org/Managing-SPF-Records"> <front> <title>M3AAWG Best Practices for Managing SPF Records</title><author></author><author> <organization>Messaging Malware Mobile Anti-Abuse Working Group (M3AAWG)</organization> </author> </front> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2142.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3464.xml"/> <xi:includehref="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4870.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4870.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5598.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7960.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8020.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:includehref="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:includehref="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8617.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9091.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/> </references> </references> <section anchor="technology-considerations"><name>Technology Considerations</name> <t>This section documents some design decisions made in the development of DMARC. Specifically addressed here are some suggestions that were considered but not included in the design, with explanatory text regarding the decision.</t> <section anchor="s-mime"><name>S/MIME</name> <t>S/MIME, or Secure Multipurpose Internet Mail Extensions <xreftarget="RFC8551"></xref>,target="RFC8551"/>, is a standard for encrypting and signing MIME data in a message. This was suggested and considered as a third security protocol for authenticating the source of a message.</t> <t>DMARC is focused on authentication at the domain level (i.e., the Domain Owner taking responsibility for the message), while S/MIME is really intended for user-to-user authentication and encryption. This alone appears to make it a bad fit for DMARC's goals.</t> <t>S/MIME also suffers from the heavyweight problem of Public KeyInfrastructure,Infrastructure (PKI), which means that distribution of keys used to validate signatures needs to be incorporated. In many instances, this alone is a showstopper. There have been consistent promises that PKI usability and deployment will improve, but these have yet to materialize. DMARC can revisit this choice after those barriers are addressed.</t> <t>S/MIME has extensive deployment in specific market segments (government, for example) but does not enjoy similar widespread deployment over the general Internet, and this shows no signs of changing. DKIM and SPF are both deployed widely over the general Internet, and their adoption rates continue to be positive.</t> <t>Finally, experiments have shown that including S/MIME support in the initial version of DMARC would neither cause nor enable a substantial increase in the accuracy of the overall mechanism.</t> </section> <section anchor="method-exclusion"><name>Method Exclusion</name> <t>It was suggested that DMARC include a mechanism by which a Domain Owner could instruct Mail Receivers not to attempt validation by one of the supported methods (e.g.,"check"check DKIM, but notSPF").</t>SPF").</t> <t>Specifically, consider a Domain Owner that has deployed one of the technologies and that technology fails for some messages, but such failures don't cause enforcement action. Deploying DMARC would cause enforcement action for policies other than"none","none", which would appear to exclude participation by that Domain Owner.</t> <t>The DMARC development team evaluated the idea of policy exception mechanisms on several occasions and invariably concluded that there 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 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> <ol> <li><t>Tighten up its infrastructure to minimize the failure modes of the single deployed technology.</t> </li> <li><t>Deploy the other supported authenticationmechanism,mechanism to offset the failure modes of the first.</t> </li> <li><t>Deploy DMARC in a reporting-only mode.</t> </li> </ol> </section> <section anchor="sender-header-field"><name>Sender Header Field</name> <t>It has been suggested in several message authentication efforts that the Sender header field be checked for an identifier of interest, as the standards indicate this as the proper way to indicate a re-mailing of content such as through a mailing list. Most recently, it was a protocol-level option for DomainKeys <xreftarget="RFC4870"></xref>,target="RFC4870"/>, but on evolution to DKIM, this property was removed.</t> <t>The DMARC development team considered this and decided not to include support for doing so for the following reasons:</t> <ol> <li><t>The main user protection approach is to be concerned with what the user sees when a message is rendered. There is no consistent behavior among MUAs regarding what to do with the content of the Sender field, if present. Accordingly, supporting the checking of the Sender identifier would mean applying policy to an identifier the end user might never actually see, which can create a vector for attack against end users by simply forging a Sender field containing some identifier that DMARC will like.</t> </li> <li><t>Although it is certainly true that this is what the Sender field is for, its use in this way is also unreliable, making it a poor candidate for inclusion in the DMARC evaluation algorithm.</t> </li> <li><t>Allowing multiple ways to discover policy introduces unacceptable ambiguity into the DMARC validation algorithm in terms of which policy is to be applied and when.</t> </li> </ol> </section> <section anchor="domain-existence-test"><name>Domain Existence Test</name> <t>The presence of the"np""np" tag in this specification seemingly implies that 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 definition of"resolvable""resolvable" in <xreftarget="RFC5321"></xref>target="RFC5321"/> applies. Using that definition, only names that resolve to MX Resource Records (RRs), A RRs, or AAAA RRs are deemed to be resolvable and to exist in the DNS. This is a common practice among Mail Receivers to determine whether or not to accept a mail message before performing other more expensive processing.</t> <t>The DMARC mechanism makes no such requirement for the existence of specific DNS 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 <xreftarget="RFC2308"></xref>,target="RFC2308"/>, an"NXDOMAIN""NXDOMAIN" response (rcode"Name Error")"Name Error") to a DNS query means that the domain name does not exist, while a"NODATA""NODATA" response (rcode"NOERROR")"NOERROR") means that the givenresource recordResource Record type queried for does not exist, but the domain name does.</t> <t>Furthermore, in keeping with <xreftarget="RFC8020"></xref>,target="RFC8020"/>, if a query for a name returns NXDOMAIN, then not only does the name not exist, every name below it in the DNS hierarchy also does not exist.</t> </section> <section anchor="organizational-domain-discovery-issues"><name>Organizational Domain Discovery Issues</name> <t>An earlierinformationalInformational version of the DMARC mechanism <xreftarget="RFC7489"></xref>target="RFC7489"/> noted that the DNS does not provide a method by which the"domain"domain ofrecord",record", or the domain that was actually registered with a domain registrar, can be determined given an arbitrary domain name. That version further mentioned suggestions that have been made that attempt to glean such information from SOA or NSresource records,Resource Records, but these too are not fully reliable, as the partitioning of the DNS is not always done at administrative boundaries.</t> <t>That previous version posited that one could"climb"climb thetree"tree" to find the OrganizationalDomain,Domain but expressed concern that an attacker could exploit this for a denial-of-service attack through sending a high number ofmessagesmessages, 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. This version defines a method for performing a<eref target="#dns-tree-walk">DNS<xref target="dns-tree-walk">DNS TreeWalk</eref>,Walk</xref> and further mitigates the risk of the denial-of-service attack by expressly limiting the number of DNS queries to execute regardless of the number of labels in the domain name.</t> <t>Readers curious about the previous method for Organizational Domain Discovery are directed to <xref target="RFC7489" sectionFormat="of"section="3.2"></xref>.</t>section="3.2"/>.</t> </section> <section anchor="removal-of-the-pct-tag"><name>Removal of the"pct""pct" Tag</name> <t>An earlier informational version of the DMARC mechanism <xreftarget="RFC7489"></xref>target="RFC7489"/> included a"pct""pct" tag and specified all integers from 0 to 100 inclusive as valid values for the tag. The intent of the tag was to providedomain ownersDomain Owners with a method to gradually change their preferred Domain Owner Assessment Policy (the"p""p" tag) from"none""none" to"quarantine""quarantine" or from"quarantine""quarantine" to"reject""reject" by requesting the stricter treatment for just a percentage of messages that produced DMARC results of"fail".</t>"fail".</t> <t>Operational experience showed that thepct"pct" tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another. The default value was easily implemented, as it required no 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 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 avoid DMARC failures downstream.</t> <t>These custom actions when the"pct""pct" tag was set to 0 provedvaluablevalue to the email community. In particular, header field rewriting by an intermediary meant 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 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 Owner to compare aggregate reports from before and after the"p""p" value was changed and"pct=0""pct=0" was included in the DMARC Policy Record, but the data was there. 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 Domain Owner in choosing whether to move from<eref target="#monitoring-mode">Monitoring Mode</eref><xref target="monitoring-mode">Monitoring Mode</xref> to<eref target="#enforcement">Enforcement</eref>.<xref target="enforcement">Enforcement</xref>. Armed with this knowledge, the Domain Owner could make an informed decision regarding subjecting its mail traffic to possible DMARC failures based on the Domain Owner's tolerance for such things.</t> <t>Because of the value provided by"pct=0""pct=0" to Domain Owners, it was logical to keep this functionality in the protocol; at the same time, it didn't make sense to support a tag named"pct""pct" that had only two valid values. This version of the DMARC mechanism, therefore, introduces the"t""t" tag as shorthand for"testing","testing", with the valid values of"y""y" and"n","n", which are meant to be analogous in their application by mailbox providers and intermediaries to the"pct""pct" tag values"0""0" and"100","100", respectively.</t> </section> </section> <section anchor="examples"><name>Examples</name> <t>This section illustrates both the Domain Owner side and the Mail Receiver side of a DMARC exchange.</t> <section anchor="identifier-alignment-examples"><name>Identifier Alignment Examples</name> <t>The following examples illustrate the DMARC mechanism's use of Identifier Alignment. For brevity's sake, only message header fields and relevant SMTP commands are shown, as message bodies are not considered when conducting DMARC checks.</t> <section anchor="spf"><name>SPF</name> <t>The following SPF examples assume that SPF produces a passing result. Alignment cannot exist if SPF does not produce a passing result.</t> <t>Example 1: SPF in Strict Alignment:</t> <artwork><![CDATA[ MAIL FROM: <sender@example.com> From: sender@example.com Date: Fri, Feb 15 2002 16:54:30 -0800 To: receiver@example.org Subject: here's asample ]]></artwork>sample]]></artwork> <t>In this case, the RFC5321.MailFrom domain and the Author Domain are identical. Thus, the identifiers are inStrict Alignment.</t>strict alignment.</t> <t>Example 2: SPF in Relaxed Alignment:</t> <artwork><![CDATA[ MAIL FROM: <sender@child.example.com> From: sender@example.com Date: Fri, Feb 15 2002 16:54:30 -0800 To: receiver@example.org Subject: here's asample ]]></artwork>sample]]></artwork> <t>In this case, the Author Domain (example.com) is a parent of the RFC5321.MailFrom domain. Thus, the identifiers are in relaxed alignment because they both have the same Organizational Domain (example.com).</t> <t>Example 3: No SPF Identifier Alignment:</t> <artwork><![CDATA[ MAIL FROM: <sender@example.net> From: sender@child.example.com Date: Fri, Feb 15 2002 16:54:30 -0800 To: receiver@example.org Subject: here's asample ]]></artwork>sample]]></artwork> <t>In this case, the RFC5321.MailFrom domainthatis neither the same as, a parent of, nor a child of the Author Domain. Thus, the identifiers are not in alignment.</t> </section> <section anchor="dkim"><name>DKIM</name> <t>The examples below assume that the DKIM signatures pass validation. Alignment cannot exist with a DKIM signature that does not validate.</t> <t>Example 1: DKIM in Strict Alignment:</t> <artwork><![CDATA[ DKIM-Signature: v=1; ...; d=example.com; ... From: sender@example.com Date: Fri, Feb 15 2002 16:54:30 -0800 To: receiver@example.org Subject: here's asample ]]></artwork>sample]]></artwork> <t>In this case, the DKIM"d""d" tag and the Author Domain have identical DNS domains. Thus, the identifiers are inStrict Alignment.</t>strict alignment.</t> <t>Example 2: DKIM in Relaxed Alignment:</t> <artwork><![CDATA[ DKIM-Signature: v=1; ...; d=example.com; ... From: sender@child.example.com Date: Fri, Feb 15 2002 16:54:30 -0800 To: receiver@example.org Subject: here's asample ]]></artwork>sample]]></artwork> <t>In this case, the DKIM signature's"d""d" tag includes a DNS domain that is a parent of the Author Domain. Thus, the identifiers are in relaxed alignment, as they have the same Organizational Domain (example.com).</t> <t>Example 3: No DKIM Identifier Alignment:</t> <artwork><![CDATA[ DKIM-Signature: v=1; ...; d=example.net; ... From: sender@child.example.com Date: Fri, Feb 15 2002 16:54:30 -0800 To: receiver@example.org Subject: here's asample ]]></artwork>sample]]></artwork> <t>In this case, the DKIM signature's"d""d" tag includes a DNS 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> </section> </section> <section anchor="domain-owner-example"><name>Domain Owner Example</name> <t>A Domain Owner that wants to use DMARC should have already deployed and tested SPF and DKIM. The next step is to publish a DMARC Policy Record for the Domain Owner's Organizational Domain.</t> <section anchor="entire-domain-monitoring-mode"><name>Entire Domain, Monitoring Mode</name> <t>The Domain Owner for"example.com""example.com" has deployed SPF and DKIM on its messaging infrastructure. The Domain Owner wishes to begin using DMARC with a policy that will solicit aggregate feedback from Mail Receivers without affecting how the messages are processed in order to:</t> <ul> <li><t>Confirm that its legitimate messages are authenticating correctly</t> </li> <li><t>Validate that all authorized message sources have implemented authentication measures</t> </li> <li><t>Determine how many messages from other sources would be affected by publishing a Domain Owner Assessment Policy at Enforcement</t> </li> </ul> <t>The Domain Owner accomplishes this by constructing a DMARC Policy Record indicating that:</t> <ul> <li><t>The version of DMARC being used is"DMARC1" ("v=DMARC1;")</t>"DMARC1" ("v=DMARC1;")</t> </li> <li><t>Mail Receivers should not alter how they treat these messages because of this DMARC Policy Record("p=none")</t>("p=none")</t> </li> <li><t>Aggregate feedback reports are sent via email to the address"dmarc-feedback@example.com" <tt>("rua=mailto:dmarc-feedback@example.com")</tt></t>"dmarc-feedback@example.com" <tt>("rua=mailto:dmarc-feedback@example.com")</tt></t> </li> <li><t>All messages from this Organizational Domain are subject to this policy (no"t""t" tag present, so the default of"n" applies).</t>"n" applies)</t> </li> </ul> <t>To publish such a record, the DNS administrator for the Domain Owner creates an entry like the following in the appropriate zone file (following the conventional zone file format):</t> <artwork><![CDATA[ ; DMARC Policy Record for the domain example.com _dmarc IN TXT ( "v=DMARC1; p=none; " "rua=mailto:dmarc-feedback@example.com") ]]></artwork>)]]></artwork> </section> <section anchor="entire-domain-monitoring-mode-per-message-failure-reports"><name>Entire Domain, Monitoring Mode, Per-Message Failure Reports</name> <t>The Domain Owner from the previous example has used the aggregate reporting to discover some messaging systems that had not yet implemented DKIM correctly, but they are still seeing periodic authentication failures. To diagnose these intermittent problems, they wish to request per-message failure reports when authentication failures occur.</t> <t>Not all Mail Receivers will honor such a request, but the Domain Owner feels that any reports it does receive will be helpful enough to justify publishing this record. The default per-message failure report format(<xref target="RFC6591"></xref>)<xref target="RFC6591"/> meets the Domain Owner's needs in this scenario.</t> <t>The Domain Owner accomplishes this by adding the following to its DMARC Policy Record from <xreftarget="entire-domain-monitoring-mode"></xref>:</t>target="entire-domain-monitoring-mode"/>:</t> <ulspacing="compact">spacing="normal"> <li>Per-message failure reports are sent via email to the address"auth-reports@example.com" <tt>("ruf=mailto:auth-reports@example.com")</tt>"auth-reports@example.com" <tt>("ruf=mailto:auth-reports@example.com")</tt> </li> </ul> <t>To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):</t> <artwork><![CDATA[ ; DMARC Policy Record for the domain example.com _dmarc IN TXT ( "v=DMARC1; p=none; " "rua=mailto:dmarc-feedback@example.com; " "ruf=mailto:auth-reports@example.com") ]]></artwork>)]]></artwork> </section> <section anchor="per-message-failure-reports-directed-to-third-party"><name>Per-Message Failure Reports Directed to Third Party</name> <t>The Domain Owner from the previous example is maintaining the same 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 do <bcp14>MUST</bcp14> implement additional checks to validate that the third party authorizes reception of failure reports on behalf of this domain.</t> <t>The Domain Owner needs to alter its DMARC Policy Record from <xreftarget="entire-domain-monitoring-mode-per-message-failure-reports"></xref>target="entire-domain-monitoring-mode-per-message-failure-reports"/> as follows:</t> <ulspacing="compact">spacing="normal"> <li>Per-message failure reports are sent via email to the address"auth-reports@thirdparty.example.net" <tt>("ruf=mailto:auth-reports@thirdparty.example.net")</tt></li>"auth-reports@thirdparty.example.net" <tt>("ruf=mailto:auth-reports@thirdparty.example.net")</tt></li> </ul> <t>To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):</t> <artwork><![CDATA[ ; DMARC Policy Record for the domain example.com _dmarc IN TXT ( "v=DMARC1; p=none; " "rua=mailto:dmarc-feedback@example.com; " "ruf=mailto:auth-reports@thirdparty.example.net") ]]></artwork>)]]></artwork> <t>Because the address used in the"ruf""ruf" tag is outside the Organizational Domain in which this record is published, conforming Mail Receivers <bcp14>MUST</bcp14> implement additional checks as described in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"target="RFC9990" sectionFormat="of"section="3"></xref>.section="3"/>. To pass these additional checks, the Report Consumer's Domain Owner will need to publish an additional DMARC Policy Record as follows:</t> <ulspacing="compact">spacing="normal"> <li>Given the DMARC Policy Record published by the Domain Owner at"_dmarc.example.com","_dmarc.example.com", the DNS administrator for the Report Consumer will need to publish a TXTresource recordResource Record at"example.com._report._dmarc.thirdparty.example.net""example.com._report._dmarc.thirdparty.example.net" with the value"v=DMARC1;""v=DMARC1;" to authorize receipt of the reports.</li> </ul> <t>To publish such a record, the DNS administrator for example.net might create an entry like the following in the appropriate zone file (following the conventional zone file format):</t> <artwork><![CDATA[ ; zone file for thirdparty.example.net ; Accept DMARC reports on behalf of example.com example.com._report._dmarc IN TXT"v=DMARC1;" ]]></artwork>"v=DMARC1;"]]></artwork> </section> <section anchor="overriding-destination-addresses"><name>Overridingdestination addresses</name>Destination Addresses</name> <t>Thethird partythird-party Report Consumer can also publish"rua""rua" and"ruf""ruf" tags in order to override the specific address published by example.com with a different address in the samethird partythird-party domain. This may be necessary if thethird partythird-party Report Consumer has changed its emailaddress,address orwantwants to guard against typos in the DMARC Policy Record of the Author Domain. Intermediaries and other third parties should refer to <xreftarget="I-D.ietf-dmarc-aggregate-reporting"target="RFC9990" sectionFormat="of"section="3"></xref>section="3"/> for the full details of this mechanism.</t> <t>Thethird partythird-party Report Consumer accomplishes this by adding the following to its DMARC Policy Record from <xreftarget="per-message-failure-reports-directed-to-third-party"></xref>:</t>target="per-message-failure-reports-directed-to-third-party"/>:</t> <ulspacing="compact">spacing="normal"> <li>The override address for aggregate reports is"aggregate-reports@thirdparty.example.net" <tt>("rua=mailto:aggregate-reports@thirdparty.example.net")</tt></li>"aggregate-reports@thirdparty.example.net" <tt>("rua=mailto:aggregate-reports@thirdparty.example.net")</tt></li> <li>The override address for failure reports is"failure-reports@thirdparty.example.net" <tt>("ruf=mailto:failure-reports@thirdparty.example.net")</tt></li>"failure-reports@thirdparty.example.net" <tt>("ruf=mailto:failure-reports@thirdparty.example.net")</tt></li> </ul> <t>To publish such a record, the DNS administrator for example.net might create an entry like the following in the appropriate zone file (following the conventional zone file format):</t> <artwork><![CDATA[ ; zone file for thirdparty.example.net ; Accept DMARC reports on behalf of example.com ; Override destination mailboxes example.com._report._dmarc IN TXT ( "v=DMARC1; " "rua=mailto:aggregate-reports@thirdparty.example.net; " "ruf=mailto:failure-reports@thirdparty.example.net") ]]></artwork>)]]></artwork> <t>In thiscasecase, only the"ruf""ruf" tag is actually overridden,because,because in the previous example, failure reporting is the only reporting type that was directed to thethird partythird-party Report Consumer.</t> </section> <section anchor="subdomain-sampling-and-multiple-aggregate-report-uris"><name>Subdomain, Testing, and Multiple Aggregate Report URIs</name> <t>The Domain Owner has implemented SPF and DKIM in a subdomain used for pre-production testing of messaging services. It now wishes to express a handling preference for messages from this subdomain that fail DMARC validation 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 subdomain that fail DMARC validation to be suspicious. The goal here will be to enable examination of messages sent to mailboxes hosted by participating Mail Receivers as a method for troubleshooting any existing authentication issues. Aggregate feedback reports will be sent to a mailbox within the OrganizationalDomain,Domain and to a mailbox at a Report 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 indicating that:</t> <ul> <li><t>The version of DMARC being used is"DMARC1" ("v=DMARC1;")</t>"DMARC1" ("v=DMARC1;")</t> </li> <li><t>It is applied only to this subdomain (the DMARC Policy Record is published at"_dmarc.test.example.com""_dmarc.test.example.com" and not"_dmarc.example.com")</t>"_dmarc.example.com")</t> </li> <li><t>Mail Receivers are advised that the Domain Owner considers messages that fail to authenticate to be suspicious("p=quarantine")</t>("p=quarantine")</t> </li> <li><t>Aggregate feedback reports are sent via email to the addresses"dmarc-feedback@example.com""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>"example-tld-test@thirdparty.example.net" <tt>("rua=mailto:dmarc-feedback@example.com, mailto:example-tld-test@thirdparty.example.net")</tt></t> </li> <li><t>The Domain Owner desires only that an actor performing a DMARC validation check apply any special handling rules it might have 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 the Domain Owner Assessment Policy to beapplied. ("t=y")</t>applied ("t=y").</t> </li> </ul> <t>To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):</t> <artwork><![CDATA[ ; DMARC Policy Record for the domain test.example.com _dmarc IN TXT ( "v=DMARC1; p=quarantine; " "rua=mailto:dmarc-feedback@example.com," "mailto:tld-test@thirdparty.example.net; " "t=y") ]]></artwork>)]]></artwork> <t>Once enough time has passed to allow for collecting enough reports to give the Domain Owner confidence that all authorized email sent using the subdomain is properly authenticating and passing DMARC validation checks, then the Domain Owner can update the DMARC Policy Record to indicate that it considers 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 of its position on such messages("p=reject")("p=reject") and removing the testing flag("t=y").</t>("t=y").</t> <t>To publish such a record, the DNS administrator for the Domain Owner might create an entry like the following in the appropriate zone file (following the conventional zone file format):</t> <artwork><![CDATA[ ; DMARC Policy Record for the domain test.example.com _dmarc IN TXT ( "v=DMARC1; p=reject; " "rua=mailto:dmarc-feedback@example.com," "mailto:tld-test@thirdparty.example.net") ]]></artwork>)]]></artwork> </section> </section> <section anchor="mail-receiver-example"><name>Mail Receiver Example</name> <t>A Mail Receiver that wants to participate in DMARC should already be checking SPF andDKIM,DKIM and possess the ability to collect relevant information from various email-processing stages to provide feedback to Domain Owners (possibly via Report Consumers).</t> <section anchor="smtp-session-example"><name>SMTP Session Example</name> <t>An optimal DMARC-enabled Mail Receiver performs validation and Identifier Alignment checking during the SMTP <xreftarget="RFC5321"></xref>target="RFC5321"/> conversation.</t> <t>Before returning a final reply to the DATA command, the Mail Receiver's MTA has performed:</t> <ol> <li><t>An SPF check to determine an SPF-Authenticated Identifier.</t> </li> <li><t>DKIM checks that yield one or more DKIM-Authenticated Identifiers.</t> </li> <li><t>A DMARC Policy Record lookup.</t> </li> </ol> <t>The presence of an Author Domain DMARC Policy Record indicates that the Mail Receiver should continue with DMARC-specific processing before returning a reply to the DATA command.</t> <t>Given a DMARC Policy Record and the set of Authenticated Identifiers, the Mail Receiver checks to see if the Authenticated Identifiers align with the Author Domain (taking into consideration any strict versus relaxed options found in the DMARC Policy Record).</t> <t>For example, the following sample data is considered to be from a piece of email originating from the Domain Owner of"example.com":</t>"example.com":</t> <artwork><![CDATA[ Author Domain: example.com SPF-authenticated Identifier: mail.example.com DKIM-authenticated Identifier: example.com DMARC Policy Record: "v=DMARC1; p=reject; aspf=r;rua=mailto:dmarc-feedback@example.com" ]]></artwork>rua=mailto:dmarc-feedback@example.com"]]></artwork> <t>In the above sample, the SPF-Authenticated Identifier and the DKIM-Authenticated Identifier both align with the Author Domain. The Mail Receiver considers the above email to pass the DMARC check, avoiding the"reject""reject" policy that is requested to be applied to email that fails the DMARC validation check.</t> <t>If no Authenticated Identifiers align with the Author Domain, then the Mail Receiver applies the Domain Owner Assessment Policy. However, before this action is taken, the Mail Receiver can consult external information to override the Domain Owner Assessment Policy. For example, if the Mail Receiver knows that this particular email came from a known and trusted forwarder (that happens to break both SPF and DKIM), then the Mail Receiver may choose to ignore the Domain Owner Assessment Policy.</t> <t>The Mail Receiver is now ready to reply to the DATA command. If the DMARC check yields that the message is to be rejected, then the Mail Receiver replies with a 5xy code to inform the sender of failure. If the DMARC check cannot be resolved due to transient network errors, 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 yields a passing message, then the Mail Receiver continues with email processing, perhaps using the result of the DMARC check as an input to additional processing modules such as a domain reputation query.</t> <t>Before exiting DMARC-specific processing, the Mail Receiver checks to see if the Author Domain DMARC Policy Record requestsAFRF-based reporting.reporting based on an Authentication Failure Reporting Format (AFRF). If so, then the Mail Receiver can emit an AFRF to the reporting address supplied in the DMARC Policy Record.</t> <t>At the exit of DMARC-specific processing, the Mail Receiver captures (through logging or direct insertion into a data store) the result of DMARC processing. Captured information is used to build feedback for Domain Owner consumption. This is unnecessary if the Domain Owner has not requested aggregate reports, i.e., no"rua""rua" tag was found in the policy record.</t> </section> </section> <section anchor="treewalk-example"><name>Organizational and Policy Domain Tree Walk Examples</name> <t>If an Author Domain has no DMARC Policy Record, a Mail Receiver uses atree walkTree Walk to find the DMARC Policy.</t> <t>If the DMARC Policy Record allows relaxed alignment and the SPF- or DKIM-Authenticated Identifiers are different from the Author Domain, a Mail Receiver uses atree walkTree Walk to discover the respective Organizational Domains to determine Identifier Alignment.</t> <section anchor="simple-organizational-and-policy-example"><name>Simple Organizational and Policy Example</name> <t>A Mail Receiver receives an email with:</t> <ulspacing="compact">spacing="normal"> <li>Author Domain: example.com</li> <li>RFC5321.MailFrom Domain: example.com</li> <li>DKIM-Authenticated Identifier: signing.example.com</li> </ul> <t>In this example,"_dmarc.example.com""_dmarc.example.com" and"_dmarc.signing.example.com""_dmarc.signing.example.com" both have DMARC PolicyRecordsRecords, while"_dmarc.com""_dmarc.com" does not. If SPF or DKIM yieldpass"pass" results, they still have to be aligned to support a DMARC pass. Since not all domains are the same, if the alignment isrelaxedrelaxed, then thetree walkTree Walk is performed to determine the Organizational Domain for each.</t> <t>To determine the Organizational Domain for the Author Domain, query"_dmarc.example.com""_dmarc.example.com" and"_dmarc.com"; "example.com""_dmarc.com"; "example.com" is the last element of the DNS tree with a DMARC Policy Record, so it is the Organizational Domain for"example.com".</t>"example.com".</t> <t>For the RFC5321.MailFrom domain, the Organizational Domain already found for"example.com""example.com" is"example.com","example.com", so SPF is aligned.</t> <t>To determine the Organizational Domain for the DKIM-Authenticated Identifier, query"_dmarc.signing.example.com", "_dmarc.example.com","_dmarc.signing.example.com", "_dmarc.example.com", and"_dmarc.com"."_dmarc.com". Both"signing.example.com""signing.example.com" and"example.com""example.com" have DMARC Policy Records, but"example.com""example.com" is the highest element in the tree with a DMARC Policy Record (it has the fewest labels), so"example.com""example.com" is the Organizational Domain. Since this is also the Organizational Domain 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 message has a DMARCpass"pass" result. If the result is notpass,"pass", then the policy domain's DMARC Policy Record is used to determine the appropriate policy. In this case, since the RFC5322.From domain has a DMARC Policy Record, that is the policy domain.</t> </section> <section anchor="deep-tree-walk-example"><name>Deep Tree Walk Example</name> <t>A Mail Receiver receives an email with:</t> <ulspacing="compact">spacing="normal"> <li>Author Domain: a.b.c.d.e.f.g.h.i.j.k.example.com</li> <li>RFC5321.MailFrom Domain: example.com</li> <li>DKIM-Authenticated Identifier: signing.example.com</li> </ul> <t>Both"_dmarc.example.com""_dmarc.example.com" and"_dmarc.signing.example.com""_dmarc.signing.example.com" have DMARC Policy Records, while"_dmarc.com""_dmarc.com" does not. If SPF or DKIM yieldpass"pass" results, they still have to be aligned to support a DMARC pass. Since not all domains are the same, if the alignment isrelaxedrelaxed, then thetree walkTree Walk is performed to determine the Organizational Domain for each.</t> <t>To determine the Organizational DomainForfor the Author Domain, query"_dmarc.a.b.c.d.e.f.g.h.i.j.k.example.com","_dmarc.a.b.c.d.e.f.g.h.i.j.k.example.com"; then query"_dmarc.g.h.i.j.k.example.com""_dmarc.g.h.i.j.k.example.com" (skipping the intermediatenames),names); then query"_dmarc.h.i.j.k.example.com", "_dmarc.i.j.k.example.com", "_dmarc.j.k.example.com", "_dmarc.k.example.com", "_dmarc.example.com","_dmarc.h.i.j.k.example.com", "_dmarc.i.j.k.example.com", "_dmarc.j.k.example.com", "_dmarc.k.example.com", "_dmarc.example.com", and"_dmarc.com"."_dmarc.com". None of"a.b.c.d.e.f.g.h.i.j.k.example.com", "g.h.i.j.k.example.com", "h.i.j.k.example.com", "i.j.k.example.com", "j.k.example.com","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.com", "i.j.k.example.com", "j.k.example.com", or"k.example.com""k.example.com" have a DMARC Policy Record.</t> <t>Since"example.com""example.com" is the last element of the DNS tree with a DMARC Policy Record, it is the Organizational Domain for"a.b.c.d.e.f.g.h.i.j.k.example.com".</t>"a.b.c.d.e.f.g.h.i.j.k.example.com".</t> <t>For the RFC5321.MailFrom domain, the OrganizationaldomainDomain already found for"example.com""example.com" is"example.com"."example.com". SPF is aligned.</t> <t>For the DKIM-Authenticated Identifier, query"_dmarc.signing.example.com", "_dmarc.example.com","_dmarc.signing.example.com", "_dmarc.example.com", and"_dmarc.com"."_dmarc.com". Both"signing.example.com""signing.example.com" and"example.com""example.com" have DMARC Policy Records, but"example.com""example.com" is the highest element in the tree with a DMARC Policy Record, so"example.com""example.com" is the Organizational Domain. Since this is also the Organizational Domain 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 message has a DMARCpass"pass" result. If the results for both are notpass,"pass", then the policy domain's DMARC Policy Record is used to determine the appropriate policy. 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, example.com.</t> </section> <section anchor="example-with-a-psd-dmarc-policy-record"><name>Example with a PSD DMARC Policy Record</name> <t>In rare cases, a PSD publishes a DMARC Policy Record with apsd"psd" tag, which thetree walkTree Walk must take into account.</t> <t>A Mail Receiver receives an email with:</t> <ulspacing="compact">spacing="normal"> <li>Author Domain: giant.bank.example</li> <li>RFC5321.MailFrom Domain: mail.giant.bank.example</li> <li>DKIM-Authenticated Identifier: mail.mega.bank.example</li> </ul> <t>In this case,"_dmarc.bank.example""_dmarc.bank.example" has a DMARC Policy Recordwhichthat includes the"psd=y""psd=y" tag, and"_dmarc.example""_dmarc.example" does not have a DMARC Policy Record. While"_dmarc.giant.bank.example""_dmarc.giant.bank.example" has a DMARC Policy Record without a"psd""psd" tag,"_dmarc.mega.bank.example""_dmarc.mega.bank.example" and"_dmarc.mail.mega.bank.example""_dmarc.mail.mega.bank.example" have no DMARC Policy Records.</t> <t>Since the three domains are all different,tree walksTree Walks find their Organizational Domains to see which are aligned.</t> <t>For the Author Domain"giant.bank.example","giant.bank.example", thetree walkTree Walk finds both the DMARC Policy Record at"_dmarc.giant.bank.example","_dmarc.giant.bank.example" and then the DMARC Policy Record at"_dmarc.bank.example","_dmarc.bank.example" and stops because of the"psd=y""psd=y" flag. The Organizational Domain is"giant.bank.example""giant.bank.example" because it is the domain directly below the one with"psd=y"."psd=y". Since the Organizational Domain has a DMARC Policy Record, it is also the policy domain.</t> <t>For the RFC5321.MailFrom domain"mail.giant.bank.example","mail.giant.bank.example", thetree walkTree Walk finds no DMARC Policy Record at"_dmarc.mail.giant.bank.example","_dmarc.mail.giant.bank.example" but does find both the DMARC Policy Record at"_dmarc.giant.bank.example""_dmarc.giant.bank.example" and then the DMARC Policy Record at"_dmarc.bank.example","_dmarc.bank.example" and stops because of the"psd=y""psd=y" flag.AgainAgain, the Organizational Domain is"giant.bank.example""giant.bank.example" because it is the domain directly below the one with"psd=y"."psd=y". Since this is the same Organizational Domain as the Author Domain, SPF is aligned.</t> <t>For the DKIM-Authenticated Identifier"mail.mega.bank.example","mail.mega.bank.example", thetree walkTree Walk finds no DMARC Policy Records at"_dmarc.mail.mega.bank.example""_dmarc.mail.mega.bank.example" or"_dmarc.mega.bank.example","_dmarc.mega.bank.example", then finds the DMARC Policy Record at"_dmarc.bank.example""_dmarc.bank.example", and stops because of the"psd=y""psd=y" flag. The Organizational Domain is"mega.bank.example","mega.bank.example", so DKIM is not aligned.</t> <t>Since SPF is aligned, it can be used to determine if the message has a DMARCpass"pass" result. If the result is notpass,"pass", then the policy domain's DMARC Policy Record is used to determine the appropriate policy.</t> </section> </section> <section anchor="utilization-of-aggregate-feedback-example"><name>Utilization of Aggregate Feedback: Example</name> <t>Aggregate feedback is consumed by Domain Owners to enable their understanding of how a given domain is being processed by the Mail Receiver. Aggregate reporting data on emails that pass all underlying authentication checks is used by Domain Owners to validate that their authentication practices remain accurate. For example, if a third party 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> <t>Data on email that only partially passes underlying authentication checks provides visibility into problems that need to be addressed by the Domain Owner. For example, if either SPF or DKIM fails to produce an Authenticated Identifier, the Domain Owner is provided with enough information to either directly correct the problem or understand where authentication-breaking changes are being introduced in the email transmission path. If authentication-breaking changes due to the email transmission path cannot be directly corrected, then the Domain Owner at least maintains an understanding of the effect of DMARC-based policies upon the Domain Owner's email.</t> <t>Data on email that fails all underlying authentication checks provides baseline visibility on how the Domain Owner's domain is being received at the Mail Receiver. Based on this visibility, the Domain Owner can begin deployment of authentication technologies across uncovered emailsources,sources if the mail that is failing the checks was generated by or on behalf of the Domain Owner. Data regarding failing authentication checks can also allow the Domain Owner to come to an understanding of how its domain is being misused.</t> </section> </section> <section anchor="rfc7849-changes"><name>Changes from RFC 7489</name> <t>This document is intended to render <xreftarget="RFC7489"></xref>target="RFC7489"/> obsolete. As one might guess, that means there are significant differences betweenRFC 7489<xref target="RFC7489"/> and this document. This section will summarize those changes.</t> <section anchor="informational-vs-standards-track"><name>Informational vs. Standards Track</name><t>RFC 7489<t><xref target="RFC7489"/> was not the product of any IETF workstream,stream but was instead published into the RFCseriesSeries by the Independent Submissions Editor andisclassified as an Informational RFC.</t> <t>This document, by contrast, isintended to bean Internet StandardsTrack.</t>Track document.</t> </section> <section anchor="changes-to-terminology-and-definitions"><name>Changes to Terminology and Definitions</name> <t>The following changes were made to theTerminology"Terminology andDefinitionsDefinitions" section.</t> <section anchor="terms-added"><name>Terms Added</name> <t>These terms were added:</t> <ulspacing="compact">spacing="normal"> <li>Domain Owner Assessment Policy</li> <li>Enforcement</li> <li>Monitoring Mode</li> <li>Non-existent Domains</li> <li>Public Suffix Domain (PSD)</li> <li>Public Suffix Operator (PSO)</li><li>PSO Controlled<li>PSO-Controlled Domain Names</li> </ul> </section> <section anchor="definitions-updated"><name>Definitions Updated</name> <t>These definitions were updated:</t> <ulspacing="compact">spacing="normal"> <li>Organizational Domain</li> <li>Report Receiver (renamed to Report Consumer)</li> </ul> </section> </section> <section anchor="policy-determination"><name>Policy Discovery and Organizational Domain Determination</name> <t>The algorithms for DMARC policy discovery and for determining the Organizational Domain have been changed. Specifically, reliance on a Public Suffix List (PSL) has been replaced by a technique called a"DNS"DNS TreeWalk",Walk", and the methodology for the DNS Tree Walk is explained in detail in this document.</t> <t>The DNS Tree Walk also incorporates PSD policy discovery, which was introduced in <xreftarget="RFC9091"></xref>.target="RFC9091"/>. 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 the algorithm for PSD policydiscovery,discovery and thus obsoletes <xreftarget="RFC9091"></xref>.target="RFC9091"/>. Specifically, the DNS Tree Walk defined in this document obviates the need for a PSD DMARC registry, and that PSD DMARC registry is what madeRFC 9091<xref target="RFC9091"/> an Experimental RFC.</t> <t>These algorithm changes introduce the possibility of interoperability issues where a Domain Owner expects a DMARC Policy Record or an Organizational Domain to be identified by the Tree Walk process, but a Mail Receiver using anRFC 7489-basedimplementation of DMARC based on <xref target="RFC7489"/> and relying on a PSL might arrive at a different answer.</t> <t>This issue is entirely avoided by the use ofStrict Alignmentstrict alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization's email.</t> </section> <section anchor="reporting"><name>Reporting</name> <t>Discussion of both aggregate and failure reportinghavehas been moved to separate documents dedicated to the topics.</t> <t>In addition, the ability to specify a maximum report size in the DMARC URI has been removed.</t> </section> <section anchor="tags"><name>Tags</name> <t>Several tags have been added to the"DMARC"DMARC Policy RecordFormat"Format" section of this document sinceRFC 7489<xref target="RFC7489"/> was published, and at the same time, several others were removed.</t> <section anchor="tags-added"><name>Tags Added</name><ul spacing="compact"> <li>np - Policy<dl spacing="normal" newline="false"> <dt>np:</dt> <dd>Policy for non-existent domains(Imported(imported from <xreftarget="RFC9091"></xref>)</li> <li>psd - Flagtarget="RFC9091"/>).</dd> <dt>psd:</dt> <dd>Flag indicating whether a domain is a Public SuffixDomain</li> <li>t - ReplacementDomain.</dd> <dt>t:</dt> <dd>Replacement for somepct"pct" tag functionality. See <xreftarget="removal-of-the-pct-tag"></xref>target="removal-of-the-pct-tag"/> for furtherdiscussion</li> </ul>discussion.</dd> </dl> </section> <section anchor="tags-removed"><name>Tags Removed</name><ul spacing="compact"> <li>pct - Tag<dl spacing="normal" newline="false"> <dt>pct:</dt> <dd>Tag requesting application of the DMARC policy to only a percentage of messages. See <xreftarget="removal-of-the-pct-tag"></xref>target="removal-of-the-pct-tag"/> fordiscussion</li> <li>rf - Tagdiscussion.</dd> <dt>rf:</dt> <dd>Tag specifying requested format of failurereports</li> <li>ri - Tagreports.</dd> <dt>ri</dt> <dd>Tag specifying requested interval between aggregatereports</li> </ul>reports.</dd> </dl> </section> </section> <section anchor="expansion-of-domain-owner-actions-section"><name>Expansion of Domain Owner Actions Section</name><t>RFC 7489<t><xref target="RFC7489"/> only hadjusttwo paragraphs in itsDomain"Domain OwnerActionsActions" section, and while the content of those paragraphs was correct, it was minimalist in its approach to providing guidance todomain ownersDomain Owners on just how to implement DMARC.</t> <t>This document provides much more detail and explanatory text to a Domain Owner, focusing not just on what to do to implementDMARC,DMARC but also on the reasons for each step and the repercussions of each decision.</t> <t>In particular, this document makes explicit that domains for general-purpose email <bcp14>SHOULD NOT</bcp14> deploy a DMARC policy ofp=reject."p=reject". See <xreftarget="interoperability-considerations"></xref>target="interoperability-considerations"/> for further discussion of this topic.</t> </section> <section anchor="report-generator-recommendations"><name>Report Generator Recommendations</name> <t>In the cases where a DMARC Policy Record specifies multiple destinations for either aggregate reports or failure reports,RFC 7489<xref target="RFC7489"/> stated:</t><artwork><![CDATA[ Receivers **MAY**<blockquote>Receivers <bcp14>MAY</bcp14> impose a limit on the number of URIs to which they will send reports but**MUST**<bcp14>MUST</bcp14> support the ability to send to at leasttwo. ]]></artwork> <t>This documenttwo.</blockquote> <!-- [rfced] Appendix C.7 cites and quotes Section 4.6 of this document; however the quoted text does not appear in<xref target="dmarc-uris"></xref> says:</t> <artwork><![CDATA[this document. Please review and let us know if this text should be added to Section 4.6. Current: Section 4.6 of this document says: A report**SHOULD**SHOULD be sent to each listed URI provided in the DMARC Policy Record.]]></artwork>--> <t><xref target="dmarc-uris"/> of this document says:</t> <blockquote>A report <bcp14>SHOULD</bcp14> be sent to each listed URI provided in the DMARC Policy Record.</blockquote> </section> <section anchor="removal-of-rfc-7489-appendix-a-5"><name>Removal of RFC74897489, Appendix A.5</name> <t>One of the appendices inRFC 7489,<xref target="RFC7489"/>, specifically Appendix <xref target="RFC7489" sectionFormat="bare"section="Appendix A.5"></xref>,section="A.5"/>, has been removed from the text with this update. The appendix was titled"Issues"Issues with ADSP inOperation"Operation", and it contained a list of issues associated with ADSP that influenced the direction of DMARC. The ADSP protocol was moved to"Historic""Historic" status in 2013 and working group consensus was that such a discussion of ADSP's influence on DMARC was no longer relevant.</t> </section> <section anchor="rfc-7489-errata-summary"><name>RFC 7489 Errata Summary</name> <t>This document and its companion documents (<xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>target="RFC9990"/> and <xreftarget="I-D.ietf-dmarc-failure-reporting"></xref>)target="RFC9991"/>) address the following errata filed against <xreftarget="RFC7489"></xref>target="RFC7489"/> since that document's publication in March, 2015. More details on each of these can be found at <ereftarget="https://www.rfc-editor.org/errata_search.php?rfc=7489">https://www.rfc-editor.org/errata_search.php?rfc=7489</eref></t>brackets="angle" target="https://www.rfc-editor.org/errata_search.php?rfc=7489"/>.</t> <sectionanchor="rfc-errata-erratum-id-5365-rfc-7489-section-7-2-1-1-https-www-rfc-editor-org-errata-eid5365"><name><eref target="https://www.rfc-editor.org/errata/eid5365">RFCanchor="rfc-errata-erratum-id-5365-rfc-7489-section-7-2-1-1-https-www-rfc-editor-org-errata-eid5365"><name>RFC Errata, Erratum ID 5365, RFC 7489, Section7.2.1.1</eref></name> <t>Addressed7.2.1.1</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid5365" brackets="angle"/>. This erratum is addressed in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> </section> <sectionanchor="rfc-errata-erratum-id-5371-rfc-7489-section-7-2-1-1-https-www-rfc-editor-org-errata-eid5371"><name><eref target="https://www.rfc-editor.org/errata/eid5371">RFCanchor="rfc-errata-erratum-id-5371-rfc-7489-section-7-2-1-1-https-www-rfc-editor-org-errata-eid5371"><name>RFC Errata, Erratum ID 5371, RFC 7489, Section7.2.1.1</eref></name> <t>Addressed7.2.1.1</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid5371" brackets="angle"/>. This erratum is addressed in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> </section> <sectionanchor="rfc-errata-erratum-id-5440-rfc-7489-sections-7-1-b-2-1-b-2-3-and-b-2-4-https-www-rfc-editor-org-errata-eid5440"><name><eref target="https://www.rfc-editor.org/errata/eid5440">RFCanchor="rfc-errata-erratum-id-5440-rfc-7489-sections-7-1-b-2-1-b-2-3-and-b-2-4-https-www-rfc-editor-org-errata-eid5440"><name>RFC Errata, Erratum ID 5440, RFC 7489,Sections 7.1,Section 7.1 and Appendices B.2.1, B.2.3, andB.2.4</eref></name> <t>ThisB.2.4</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid5440" brackets="angle"/>. This erratum references several mentions inRFC 7489<xref target="RFC7489"/> of the"v=""v=" tag from the Domain Owner Assessment Policy and/or its value, specifically mentions that were not, but should have been,"v=DMARC1;"."v=DMARC1;". Some of those mentions are preserved in thisdocumentdocument, and those mentions have been addressed as per the erratum. The rest have moved to <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>target="RFC9990"/> and are addressed there.</t> </section> <sectionanchor="rfc-errata-erratum-id-6439-rfc-7489-section-7-1-https-www-rfc-editor-org-errata-eid6439"><name><eref target="https://www.rfc-editor.org/errata/eid6439">RFCanchor="rfc-errata-erratum-id-6439-rfc-7489-section-7-1-https-www-rfc-editor-org-errata-eid6439"><name>RFC Errata, Erratum ID 6439, RFC 7489, Section7.1</eref></name> <t>Addressed7.1</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid6439" brackets="angle"/>. This erratum is addressed in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> </section> <sectionanchor="rfc-errata-erratum-id-5221-rfc-7489-appendix-c-https-www-rfc-editor-org-errata-eid5221"><name><eref target="https://www.rfc-editor.org/errata/eid5221">RFCanchor="rfc-errata-erratum-id-5221-rfc-7489-appendix-c-https-www-rfc-editor-org-errata-eid5221"><name>RFC Errata, Erratum ID 5221, RFC 7489, AppendixC</eref></name> <t>TheC</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid5221" brackets="angle"/>. The regular expression pattern for IP addresses has been removed from this document and from <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> </section> <sectionanchor="rfc-errata-erratum-id-5229-rfc-7489-appendix-c-https-www-rfc-editor-org-errata-eid5229"><name><eref target="https://www.rfc-editor.org/errata/eid5229">RFCanchor="rfc-errata-erratum-id-5229-rfc-7489-appendix-c-https-www-rfc-editor-org-errata-eid5229"><name>RFC Errata, Erratum ID 5229, RFC 7489, AppendixC</eref></name> <t>AddressedC</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid5229" brackets="angle"/>. This erratum is addressed in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> </section> <sectionanchor="rfc-errata-erratum-5495-rfc-7489-section-6-6-3-https-www-rfc-editor-org-errata-eid5495"><name><eref target="https://www.rfc-editor.org/errata/eid5495">RFCanchor="rfc-errata-erratum-5495-rfc-7489-section-6-6-3-https-www-rfc-editor-org-errata-eid5495"><name>RFC Errata, Erratum 5495, RFC 7489, Section6.6.3</eref></name> <t>This6.6.3</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid5495" brackets="angle"/>. This erratum is in reference to the description of the process documented inRFC 7489<xref target="RFC7489"/> for the applicable DMARC policy for an email message. The process for doing this has drastically changed inDMARCbis,this document, and so the text identified in this erratum no longer exists.</t> </section> <sectionanchor="rfc-errata-erratum-id-6485-rfc-7489-section-7-2-1-1-https-www-rfc-editor-org-errata-eid6485"><name><eref target="https://www.rfc-editor.org/errata/eid6485">RFCanchor="rfc-errata-erratum-id-6485-rfc-7489-section-7-2-1-1-https-www-rfc-editor-org-errata-eid6485"><name>RFC Errata, Erratum ID 6485, RFC 7489, Section7.2.1.1</eref></name> <t>Addressed7.2.1.1</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid6485" brackets="angle"/>. This erratum is addressed in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> </section> <sectionanchor="rfc-errata-erratum-id-6729-rfc-7489-section-3-2-https-www-rfc-editor-org-errata-eid6729"><name><eref target="https://www.rfc-editor.org/errata/eid6729">RFCanchor="rfc-errata-erratum-id-6729-rfc-7489-section-3-2-https-www-rfc-editor-org-errata-eid6729"><name>RFC Errata, Erratum ID 6729, RFC 7489, Section3.2</eref></name> <t>This3.2</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid6729" brackets="angle"/>. This erratum is in reference to a search of the Public Suffix List (PSL) as part of finding a DMARC Policy Record (a.k.a., Domain Owner Assessment Policy). The PSL is no longer relied upon for this practice, and the text at issue has been removed from this document.</t> </section> <sectionanchor="rfc-errata-erratum-id-7099-rfc-7489-section-7-2-1-1-https-www-rfc-editor-org-errata-eid7099"><name><eref target="https://www.rfc-editor.org/errata/eid7099">RFCanchor="rfc-errata-erratum-id-7099-rfc-7489-section-7-2-1-1-https-www-rfc-editor-org-errata-eid7099"><name>RFC Errata, Erratum ID 7099, RFC 7489, Section7.2.1.1</eref></name> <t>Addressed7.2.1.1</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid7099" brackets="angle"/>. This erratum is addressed in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> </section> <sectionanchor="rfc-errata-erratum-id-7100-rfc-7489-section-7-2-1-1-https-www-rfc-editor-org-errata-eid7100"><name><eref target="https://www.rfc-editor.org/errata/eid7100">RFCanchor="rfc-errata-erratum-id-7100-rfc-7489-section-7-2-1-1-https-www-rfc-editor-org-errata-eid7100"><name>RFC Errata, Erratum ID 7100, RFC 7489, Section7.2.1.1</eref></name> <t>Addressed7.2.1.1</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid7100" brackets="angle"/>. This erratum is addressed in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> </section> <sectionanchor="rfc-errata-erratum-id-7835-rfc-7489-section-6-6-3-https-www-rfc-editor-org-errata-eid7835"><name><eref target="https://www.rfc-editor.org/errata/eid7835">RFCanchor="rfc-errata-erratum-id-7835-rfc-7489-section-6-6-3-https-www-rfc-editor-org-errata-eid7835"><name>RFC Errata, Erratum ID 7835, RFC 7489, Section6.6.3</eref></name> <t>This6.6.3</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid7835" brackets="angle"/>. This erratum is in reference to the description of the process documented inRFC 7489<xref target="RFC7489"/> for the applicable DMARC policy for an email message. The process for doing this has drastically changed inDMARCbis,this document, and so the text identified in this erratum no longer exists.</t> </section> <sectionanchor="rfc-errata-erratum-id-7865-rfc-7489-appendix-c-https-www-rfc-editor-org-errata-eid7865"><name><eref target="https://www.rfc-editor.org/errata/eid7865">RFCanchor="rfc-errata-erratum-id-7865-rfc-7489-appendix-c-https-www-rfc-editor-org-errata-eid7865"><name>RFC Errata, Erratum ID 7865, RFC 7489, AppendixC</eref></name> <t>TheC</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid7865" brackets="angle"/>. The regular expression pattern for IP addresses has been removed from this document and from <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> </section> <sectionanchor="rfc-errata-erratum-id-5151-rfc-7489-section-1-https-www-rfc-editor-org-errata-eid5151"><name><eref target="https://www.rfc-editor.org/errata/eid5151">RFCanchor="rfc-errata-erratum-id-5151-rfc-7489-section-1-https-www-rfc-editor-org-errata-eid5151"><name>RFC Errata, Erratum ID 5151, RFC 7489, Section1</eref></name> <t>This1</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid5151" brackets="angle"/>. This erratum is in reference to the Introduction section ofRFC 7489.<xref target="RFC7489"/>. That section has been substantially rewritten inDMARCbis,this document, and the text at issue for this erratum no longer exists.</t> </section> <sectionanchor="rfc-errata-erratum-id-5774-rfc-7489-appendix-c-https-www-rfc-editor-org-errata-eid5774"><name><eref target="https://www.rfc-editor.org/errata/eid5774">RFCanchor="rfc-errata-erratum-id-5774-rfc-7489-appendix-c-https-www-rfc-editor-org-errata-eid5774"><name>RFC Errata, Erratum ID 5774, RFC 7489, AppendixC</eref></name> <t>AddressedC</name> <t>See <eref target="https://www.rfc-editor.org/errata/eid5774" brackets="angle"/>. This erratum is addressed in <xreftarget="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>target="RFC9990"/>.</t> </section> </section> <section anchor="general-editing-and-formatting"><name>General Editing and Formatting</name> <t>A great deal of the content fromRFC 7489<xref target="RFC7489"/> was preserved in this document, but much of it was subject toeitherminorediting, re-orderingediting and the reordering of sections,and/oror both.</t> </section> </section> <section anchor="acknowledgements" numbered="false"><name>Acknowledgements</name><t>This<t>The reworking of the DMARC mechanism specified in <xreftarget="RFC7489"></xref>target="RFC7489"/> is the result of contributions from many participants in theIETFDMARC WorkingGroup dedicated to this effort.Group. Although the contributors are too numerous to mention, significant contributions were made byKurt Andersen, Laura Atkins, Seth Blank, Alex Brotman, Dave Crocker, Douglas<contact fullname="Kurt Andersen"/>, <contact fullname="Laura Atkins"/>, <contact fullname="Seth Blank"/>, <contact fullname="Alex Brotman"/>, <contact fullname="Dave Crocker"/>, <contact fullname="Douglas E.Foster, Ned Freed, Mike Hammer, StevenFoster"/>, <contact fullname="Ned Freed"/>, <contact fullname="Mike Hammer"/>, <contact fullname="Steven M.Jones, Scott Kitterman, MurrayJones"/>, <contact fullname="Scott Kitterman"/>, <contact fullname="Murray S.Kucherawy, Barry Leiba, Alessandro Vesely, and Tim Wicinski.</t>Kucherawy"/>, <contact fullname="Barry Leiba"/>, <contact fullname="Alessandro Vesely"/>, and <contact fullname="Tim Wicinski"/>.</t> <t>The authors and contributors also recognize that this document would not have been possible without the work done by those who had a hand in producing <xreftarget="RFC7489"></xref>.target="RFC7489"/>. The Acknowledgements section from that document is preserved in full below.</t> </section> <section anchor="acknowledgements-rfc7489" numbered="false"><name>Acknowledgements - RFC 7489</name> <t>DMARC and the earlier draft version of this document that was submitted to the Independent Submission Editor were the result of lengthy efforts by an informal industry consortium: DMARC.org (see <ereftarget="https://dmarc.org">https://dmarc.org</eref>).target="https://dmarc.org" brackets="angle"/>). Participating companies included Agari, American Greetings, AOL, Bank of America, Cloudmark, Comcast, Facebook, Fidelity Investments, Google, JPMorgan Chase & Company, LinkedIn, Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain Project, and Yahoo!. Although the contributors and supporters are too numerous to mention, notable individual contributions were made byJ.<contact fullname="J. TrentAdams, Michael Adkins, Monica Chew, Dave Crocker, Tim Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen.Adams"/>, <contact fullname="Michael Adkins"/>, <contact fullname="Monica Chew"/>, <contact fullname="Dave Crocker"/>, <contact fullname="Tim Draegen"/>, <contact fullname="Steve Jones"/>, <contact fullname="Franck Martin"/>, <contact fullname="Brett McDowell"/>, and <contact fullname="Paul Midgen"/>. The contributors would also like to recognize the invaluable input and guidance that was provided early on byJ.D. Falk.</t><contact fullname="J.D. Falk"/>.</t> <t>Additional contributions within the IETF context were made byKurt Andersen, Michael<contact fullname="Kurt Andersen"/>, <contact fullname="Michael JackAssels, Les Barstow, Anne Bennett, Jim Fenton, J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, S. Moonesamy, Rolf Sonneveld, Henry Timmes,Assels"/>, <contact fullname="Les Barstow"/>, <contact fullname="Anne Bennett"/>, <contact fullname="Jim Fenton"/>, <contact fullname="J. Gomez"/>, <contact fullname="Mike Jones"/>, <contact fullname="Scott Kitterman"/>, <contact fullname="Eliot Lear"/>, <contact fullname="John Levine"/>, <contact fullname="S. Moonesamy"/>, <contact fullname="Rolf Sonneveld"/>, <contact fullname="Henry Timmes"/>, andStephen<contact fullname="Stephen J.Turnbull.</t>Turnbull"/>.</t> </section> </back> <!-- [rfced] Please review whether any of these notes in the document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). Original: Note: PSD policy is not used for Organizational Domains that have published a DMARC Policy Record. Specifically, this is not a mechanism to provide feedback addresses (rua/ruf) when an Organizational Domain has declined to do so. ... Note: There is no need to perform Identifier Alignment Evaluations under any of the following conditions: --> <!--[rfced] Abbreviations a) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Authentication Failure Reporting Format (AFRF) Mail User Agent (MUA) b) Both the expansion and the acronym for the following terms are used throughout the document. Would you like to update to using the expansion upon first usage and the acronym for the rest of the document for consistency? Domain-based Message Authentication, Reporting, and Conformance (DMARC) Public Suffix Domain (PSD) Public Suffix List (PSL) Public Suffix Operator (PSO) Resource Record (RR) --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>