<?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-aggregate-reporting-32" number="9990" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" obsoletes="7489"indexInclude="true" consensus="true">updates="" consensus="true" symRefs="true" sortRefs="true" tocInclude="true"> <front> <title abbrev="DMARC AggregateReporting">Domain-basedReporting">Domain-Based Message Authentication, Reporting, and Conformance (DMARC) AggregateReporting</title><seriesInfo value="draft-ietf-dmarc-aggregate-reporting-32" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo>Reporting</title> <seriesInfo name="RFC" value="9990"/> <author initials="A."surname="Brotman (ed)"surname="Brotman" fullname="AlexBrotman"><organization>Comcast, Inc.</organization><address><postal><street></street> </postal><email>alex_brotman@comcast.com</email> </address></author><date year="2025" month="March" day="17"></date> <area>Application</area> <workgroup>DMARC</workgroup>Brotman" role="editor"> <organization>Comcast, Inc.</organization> <address> <email>alex_brotman@comcast.com</email> </address> </author> <date year="2026" month="May"/> <area>ART</area> <workgroup>dmarc</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <!--[rfced] FYI: We added the following sentence to the end of the Abstract as the Obsolete status was absent (this is now consistent with the companion documents). Current: This document obsoletes RFC 7489. --> <abstract> <t>Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows for Domain Owners to request aggregate reports from receivers. This report is an XMLdocument,document and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted by the receiver to the Domain Owner's specified destination as declared in the associated DNS record.</t> <t>This document obsoletes RFC 7489.</t> </abstract> </front> <middle> <section anchor="introduction"><name>Introduction</name> <t>A key component ofDMARC <xref target="I-D.ietf-dmarc-dmarcbis"></xref> (Domain-basedDomain-based Message Authentication, Reporting, andConformance)Conformance (DMARC) <xref target="RFC9989"/> is the ability for Domain Owners to request that Mail Receivers provide various types of reports. These reports allow Domain Owners to have insight into which IP addresses are sending on theirbehalf,behalf and some insight into whether or not the volume may belegitimate.<br /> Theselegitimate.</t> <t>These reports expose information relating to the DMARC policy, as well as the outcome ofSPF (SenderSender PolicyFramework)Framework (SPF) <xreftarget="RFC7208"></xref> & DKIM (DomainKeystarget="RFC7208"/> and DomainKeys IdentifiedMail)Mail (DKIM) <xreftarget="RFC6376"></xref>target="RFC6376"/> validation.</t> <section anchor="terminology"><name>Terminology</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> <section anchor="notation"><name>Notation</name> <t>Certain properties of mail messages described in this document are referenced using notation found in <xreftarget="RFC5598"></xref>target="RFC5598"/> (e.g., "RFC5322.From").</t> <t>This specification uses the Augmented Backus-Naur Form (ABNF) notation of <xreftarget="RFC5234"></xref>target="RFC5234"/> and <xreftarget="RFC7405"></xref>.</t>target="RFC7405"/>.</t> </section> <section anchor="dmarc-terminology"><name>DMARC Terminology</name> <t>There are a number of terms defined in <xreftarget="I-D.ietf-dmarc-dmarcbis"></xref>target="RFC9989"/> that are used within this document. Understanding those definitions will aid in reading this document. The terms below are of noted interest:</t> <ulspacing="compact">spacing="normal"> <li>Author Domain</li> <li>DMARC Policy Record</li> <li>Domain Owner</li> <li>Mail Receiver</li> <li>Organizational Domain</li> <li>Report Consumer</li> </ul> </section> </section> </section> <!--[rfced] We note that the errata for this document is addressed in RFC-to-be 9989. May we add a sentence in Section 2 ("Document Status") that mentions the errata has been addressed in the companion document? Original: This document, in part, along with RFCs 9989 and 9991, obsoletes and replaces DMARC [RFC7489]. Perhaps: This document, in part, along with [RFC9989] and [RFC9991], obsoletes and replaces DMARC [RFC7489]. Note that errata for this document has been addressed as described in [RFC9989]. --> <section anchor="document-status"><name>Document Status</name> <t>This document, in part, along withDMARCbis<xreftarget="I-D.ietf-dmarc-dmarcbis"></xref> DMARCbis Failure Reportingtarget="RFC9989"/> and <xreftarget="I-D.ietf-dmarc-failure-reporting"></xref>,target="RFC9991"/>, obsoletes and replaces DMARC <xreftarget="RFC7489"></xref>.</t>target="RFC7489"/>.</t> </section> <section anchor="dmarc-feedback"><name>DMARC Feedback</name> <t>Providing Domain Owners with visibility into how Mail Receivers implement and enforce the DMARC mechanism in the form of feedback is critical to establishing and maintaining accurate authentication deployments. When Domain Owners can see what effect their policies and practices are having, they are better willing and able to use quarantine and reject policies.</t> <section anchor="aggregate-reports"><name>Aggregate Reports</name> <t>The DMARC aggregate feedback report is designed to provide Domain Owners with precise insight into:</t> <ulspacing="compact">spacing="normal"> <li>authentication results,</li> <li>corrective action that needs to be taken by Domain Owners, and</li> <li>the effect of Domain Owner DMARC policy on mail streams processed by Mail Receivers.</li> </ul> <t>Aggregate DMARC feedback provides visibility into real-world mail streams that Domain Owners need in order to make informed decisions regarding the publication of a DMARC policy. When Domain Owners know what legitimate mail they are sending, what the authentication results are on that mail, and what forgedmail receiversMail Receivers are getting, they can make better decisions about the policies they need and the steps they need to take to enable those policies. When Domain Owners set policies appropriately and understand their effects, Mail Receivers can act on them confidently.</t> <t>Visibility comes in the form of daily (or more frequent)Mail Receiver-originatedfeedback reports that are originated from Mail Receivers and that contain aggregate data on message streams relevant to the Domain Owner. This information includes data about messages that passed DMARC authentication as well as those that did not.</t> <t>A separate report <bcp14>MUST</bcp14> be generated for each DMARC Policy Domain encountered during the reporting period. See below for further explanation in <xreftarget="handling"></xref>, "Handlingtarget="handling"/> ("Handling Domains inReports".</t>Reports").</t> <t>The report may include the following data:</t> <ulspacing="compact">spacing="normal"> <li>The DMARC policy discovered and applied, if any</li> <li>The selected message disposition</li> <li>The identifier evaluated by SPF and the SPF result, if any</li> <li>The identifier evaluated by DKIM and the DKIM result, if any</li> <li>For both DKIM and SPF, an indication of whether the identifier was in DMARC alignment (see <xreftarget="I-D.ietf-dmarc-dmarcbis"target="RFC9989" sectionFormat="of"relative="#" section="3.2.10"></xref>)</li>section="3.2.10"/>)</li> <li>Sending and receiving domains</li> <li>The number of successful authentications</li> <li>The counts of messages based on all messages received, even if their delivery is ultimately blocked by other filtering agents.</li> </ul> <t>Each report <bcp14>MUST</bcp14> contain data for only one DMARC Policy Domain. A single report <bcp14>MUST</bcp14> contain data for one policy configuration. If multiple configurations were observed during a single reporting period, a reporting entityMAY<bcp14>MAY</bcp14> choose to send multiplereports, otherwisereports; otherwise, the reporting entitySHOULD<bcp14>SHOULD</bcp14> note only the final configuration observed during the period. See below for further information.</t> <section anchor="description-of-the-content-xml-file"><name>Description of thecontentContent of the XMLfile</name> <t>NOTE TO RFC EDITOR: We tried a few various formats for these tables. If you would like to see those other formats, we can send over those attempts at your request. Please remove this comment before publishing.</t>File</name> <t>The format for these reports is defined in the XML Schema Definition (XSD) in <xreftarget="xsd"></xref>.target="xsd"/>. The XSD includes the possible values for some of the elements below. Most of these values have a definition tied to <xreftarget="I-D.ietf-dmarc-dmarcbis"></xref>.</t>target="RFC9989"/>.</t> <t>The format is also described in the following sections. Each section describes a collection of sibling elements in the XML hierarchy. There are pointers to where in the hierarchy each table fits.</t> <t>If a document does not match thethespecified format, the document evaluatorSHOULD<bcp14>SHOULD</bcp14> discard the report. The evaluatorMAY<bcp14>MAY</bcp14> choose to try to utilize some of thedata, thoughdata; however, if the format is in question,sothe data may bethe data.as well. The report evaluatorMAY<bcp14>MAY</bcp14> choose to contact the report generator so that they may be alerted to an issue with the report format.</t> <t>The column "#" specifies how many times an element mayappear,appear -- this is sometimes referred to as multiplicity. The possible values are:</t> <dlspacing="compact">spacing="normal"> <dt>O:</dt> <dd><bcp14>OPTIONAL</bcp14>, zero or one element</dd> <dt>R:</dt> <dd><bcp14>REQUIRED</bcp14>, exactly one element</dd> <dt>*:</dt> <dd><bcp14>OPTIONAL</bcp14>, zero or more elements</dd> <dt>+:</dt> <dd><bcp14>REQUIRED</bcp14>, one or more elements</dd> </dl> <t>Some elements contain text meant for humans and support an optional "lang" attribute whose valueindicateindicates the language of its contents. The default value is "en". Elements supporting this optional attributeisare marked with "[@lang]" at the start of their content description in the following tables.</t> <section anchor="xml-root-element"><name>XMLroot element</name>Root Element</name> <t>DMARC aggregate feedback reports have the root element "feedback" with its XML namespace set to the DMARC namespace.</t> <tablealign="left"><name>Thealign="center"> <name>The XMLroot element. </name>Root Element</name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>feedback</td> <td>R</td> <td>First levelelements,elements; see <xreftarget="xml-first-level"></xref></td>target="xml-first-level"/></td> </tr> </tbody></table></section></table> </section> <section anchor="xml-first-level"><name>First Level Elements</name> <t>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t> <tablealign="left"><name>First level elementsalign="center"><name>First Level Elements of the Aggregate FeedbackReport.Report </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>version</td> <td>O</td> <td><bcp14>MUST</bcp14> have the value 1.0.</td> </tr> <tr> <td>report_metadata</td> <td>R</td> <td>Report generatormetadata,metadata; see <xreftarget="xml-report-metadata"></xref>.</td>target="xml-report-metadata"/>.</td> </tr> <tr> <td>policy_published</td> <td>R</td> <td>The DMARC policy configuration observed by the receivingsystem,system; see <xreftarget="xml-policy-published"></xref>.</td>target="xml-policy-published"/>.</td> </tr> <tr> <td>extension</td> <td>O</td> <td>Allows for futureextensibility,extensibility; see <xreftarget="xml-extension"></xref></td>target="xml-extension"/>.</td> </tr> <tr> <td>record</td> <td>+</td> <td>Record(s) of the feedback from the reportgenerator,generator; see <xreftarget="xml-record"></xref>.</td>target="xml-record"/>.</td> </tr> </tbody></table><t>There</table> <t>There <bcp14>MUST</bcp14> be at least one "record"element, theyelement; these elements contain data statingwhichthat IP addresses were seen to have delivered messages for the Author Domain to the receiving system. For each IP address that is being reported, there will be at least one "record" element.</t> </section> <section anchor="xml-report-metadata"><name>Reportgenerator metadata</name>Generator Metadata</name> <tablealign="left"><name>Report generator metadataalign="center"><name>Report Generator Metadata </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>org_name</td> <td>R</td> <td>Name of the Reporting Organization.</td> </tr> <tr> <td>email</td> <td>R</td> <td>Contact to use when contacting the Reporting Organization.</td> </tr> <tr> <td>extra_contact_info</td> <td>O</td> <td>[@lang] Additional contact details.</td> </tr> <tr> <td>report_id</td> <td>R</td> <td>UniqueReport-ID,Report-ID; see <xreftarget="report-id"></xref>.</td>target="report-id"/>.</td> </tr> <tr> <td>date_range</td> <td>R</td> <td>The reportingperiod,period; see <xreftarget="xml-date-range"></xref>.</td>target="xml-date-range"/>.</td> </tr> <tr> <td>error</td> <td>O</td> <td>[@lang] Error messages encountered when processing the DMARC PolicyRecord,Record; see <xreftarget="error"></xref>.</td>target="error"/>.</td> </tr> <tr> <td>generator</td> <td>O</td> <td>The name and version of the report generator; this can help the Report Consumer find out where to report bugs.</td> </tr> </tbody> </table></section> <section anchor="xml-date-range"><name>Contents of the "date_range"element</name> <t>TheElement</name> <t>This element describes the time range in UTC defining the reporting period of this report.</t> <tablealign="left"><name>Contentsalign="center"><name>Contents of the "date_range"elementElement </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>begin</td> <td>R</td> <td>Start of the reporting period.</td> </tr> <tr> <td>end</td> <td>R</td> <td>End of the reporting period.</td> </tr> </tbody> </table> <ulspacing="compact">spacing="normal"> <li>"begin" and "end" contain the number of seconds since the epoch.</li> </ul> <t>The "begin" and "end" elements are meant to denote the reportingperiod,period and not the first/last observed message from the reporting period. When generating reports, these reporting periodsSHOULD NOT<bcp14>SHOULD NOT</bcp14> overlap. Typically, the reporting period will encompass a single UTC day, beginning at 0000UTC.</t> </section> <section anchor="xml-policy-published"><name>Contents of the "policy_published"element</name> <t>InformationElement</name> <t>This element provides information on the DMARC Policy Record published for the Author Domain. The elements from "p" and onwards contain the discovered or default value for the DMARC policy applied.</t> <t>Unspecified tags have their default values.</t> <tablealign="left"><name>Contentsalign="center"><name>Contents of the "policy_published"elementElement </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>domain</td> <td>R</td> <td>The DMARC Policy Domain.</td> </tr> <tr> <td>discovery_method</td> <td>O</td> <td>The method used to discover the DMARC Policy Record used during evaluation.</td> </tr> <tr> <td>p</td> <td>R</td> <td>A Domain Owner Assessment Policy.</td> </tr> <tr> <td>sp</td> <td>O</td> <td>A Domain Owner Assessment Policy.</td> </tr> <tr> <td>np</td> <td>O</td> <td>A Domain Owner Assessment Policy.</td> </tr> <tr> <td>fo</td> <td>O</td> <td>The value for the failure reporting options.</td> </tr> <tr> <td>adkim</td> <td>O</td> <td>The DKIM Identifier Alignment mode.</td> </tr> <tr> <td>aspf</td> <td>O</td> <td>The SPF Identifier Alignment mode.</td> </tr> <tr> <td>testing</td> <td>O</td> <td>The value of the "t" tag.</td> </tr> </tbody> </table> <!-- [rfced] We note that "psl" is not used in RFC 7489. Please review the citation below and let us know how it may be updated. Current: * "discovery_method" can have the value "psl" or "treewalk", where "psl" is the method from [RFC7489] and "treewalk" is described in [RFC9989]. --> <ul> <li><t>"discovery_method" can have the value "psl" or "treewalk", where "psl" is the method from <xreftarget="RFC7489"></xref>target="RFC7489"/> and "treewalk" is described in <xreftarget="I-D.ietf-dmarc-dmarcbis"></xref>.</t>target="RFC9989"/>.</t> </li> <li><t>Many of the items above (p, sp, etc.) are defined inthe<xreftarget="I-D.ietf-dmarc-dmarcbis"></xref> document.</t>target="RFC9989"/>.</t> </li> </ul> </section> <section anchor="xml-extension"><name>Contents of the "extension"element</name>Element</name> <t>Use of extensions may cause elements to be added here. These elements <bcp14>MUST</bcp14> be namespaced.</t> <tablealign="left"><name>Contentsalign="center"><name>Contents of the "extension"elementElement </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td><any namespaced element></td> <td>*</td> <td>File level elements defined by an extension.</td> </tr> </tbody> </table> <ul><li><t>"<any<li>"<any namespacedelement>"</t> <t>Zeroelement>": Zero or more elements in the namespace of the related extension declared in the XML rootelement.</t> </li>element.</li> </ul> </section> <section anchor="xml-record"><name>Contents of the "record"element</name>Element</name> <t>The report <bcp14>MUST</bcp14> containrecord(s)one or more records stating which IP addresses were seen to have delivered messages for the Author Domain to the receiving system. For each IP address that is being reported, there will be at least one "record" element.</t> <t>This element contains all the authentication results that were evaluated by the receiving system for the given set of messages.</t> <t>An unlimited number of "record" elements may be specified.</t> <t>Use of extensions may cause other elements to be added to the end of therecord,record; such elements <bcp14>MUST</bcp14> be namespaced.</t> <!--[rfced] The following text is not a complete sentence. Please review and let us know how it may be updated. Original: One record per (IP, result, authentication identifiers) tuples. Perhaps: There is one record (IP, result, authentication identifiers) per tuples. --> <t>One record per (IP, result,autheniticationauthentication identifiers) tuples.</t> <t>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t> <tablealign="left"><name>Contentsalign="center"><name>Contents of the "record"elementElement </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>row</td> <td>R</td> <td>See <xreftarget="xml-row"></xref>.</td>target="xml-row"/>.</td> </tr> <tr> <td>identifiers</td> <td>R</td> <td>The data that was used to apply policy for the given"row","row"; see <xreftarget="xml-identifiers"></xref>.</td>target="xml-identifiers"/>.</td> </tr> <tr> <td>auth_results</td> <td>R</td> <td>The data related to authenticating the messages associated with this sending IPaddress,address; see <xreftarget="xml-auth-results"></xref>.</td>target="xml-auth-results"/>.</td> </tr> <tr> <td><any namespaced element></td> <td>*</td> <td>Record level elements defined by an extension.</td> </tr> </tbody> </table> <ul><li><t>"<any<li>"<any namespacedelement>"</t> <t>Zeroelement>": Zero or more elements in the namespace of the related extension declared in the XML rootelement.</t> </li>element.</li> </ul> </section> <section anchor="xml-row"><name>Contents of the "row"element</name>Element</name> <t>A "row" element contains the details of the connecting system, and how manymailsmail messages were received from it, for the particular combination of the policy evaluated.</t> <tablealign="left"><name>Contentsalign="center"><name>Contents of the "row"elementElement </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>source_ip</td> <td>R</td> <td>The connecting IP address. IPv4address or IPv6address as defined in <xref target="RFC3986" sectionFormat="of"relative="#" section="3.2.2"></xref></td>section="3.2.2"/>.</td> </tr> <tr> <td>count</td> <td>R</td> <td>Number of messages for which the "policy_evaluated" was applied.</td> </tr> <tr> <td>policy_evaluated</td> <td>R</td> <td>The DMARC disposition applied to matchingmessages,messages; see <xreftarget="xml-policy-evaluated"></xref>.</td>target="xml-policy-evaluated"/>.</td> </tr> </tbody> </table></section> <section anchor="xml-policy-evaluated"><name>Contents of the "policy_evaluated"element</name> <t>TheElement</name> <t>This element describes the results of applying the DMARC policy. If alignment fails and the policy applied does not match the DMARC Policy Domain's configured policy, the "reason" element <bcp14>MUST</bcp14> be included.</t> <t>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t> <tablealign="left"><name>Contentsalign="center"><name>Contents of the "policy_evaluated"elementElement </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>disposition</td> <td>R</td> <td>The result of applying the DMARC policy.</td> </tr> <tr> <td>dkim</td> <td>R</td> <td>The result of the DKIM DMARC IdentifieralignmentAlignment test.</td> </tr> <tr> <td>spf</td> <td>R</td> <td>The result of the SPF DMARC IdentifieralignmentAlignment test.</td> </tr> <tr> <td>reason</td> <td>*</td> <td>Policy overridereason,reason; see <xreftarget="xml-reason"></xref>.</td>target="xml-reason"/>.</td> </tr> </tbody> </table> <ul> <li><t>"spf" and "dkim" <bcp14>MUST</bcp14> be the evaluated values as they relate to DMARC, not the values the receiver may have used when overriding the policy.</t> </li> <li><t>"reason" elements are meant toincludecontain any notes the reporter might want to include as to why the "disposition" policy does not match the "policy_published", such as a local policy override.</t> </li> </ul> </section> <section anchor="xml-identifiers"><name>Contents of the "identifiers"element</name>Element</name> <tablealign="left"><name>Contentsalign="center"><name>Contents of the "identifiers"elementElement </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>header_from</td> <td>R</td> <td>The RFC5322.From domain from the message.</td> </tr> <tr> <td>envelope_from</td> <td>O</td> <td>The RFC5321.MailFrom domain that the SPF check has been applied to.</td> </tr> <tr> <td>envelope_to</td> <td>O</td> <td>The RFC5321.RcptTo domain from the message.</td> </tr> </tbody> </table> <ulspacing="compact">spacing="normal"> <li>"envelope_from" <bcp14>MAY</bcp14>be existingexist but be empty if the message had a null reverse-path (see <xref target="RFC5321" sectionFormat="of"relative="#" section="4.5.5"></xref>).</li>section="4.5.5"/>).</li> </ul> </section> <section anchor="xml-auth-results"><name>Contents of the "auth_results"element</name> <t>ContainsElement</name> <t>This element contains DKIM and SPF results, uninterpreted with respect to DMARC.</t> <t>If validation is attempted for any DKIM signature, the results <bcp14>MUST</bcp14> be included in the report (withinreason,reason; see <xreftarget="dkim-signatures"></xref>, "DKIMtarget="dkim-signatures"/> ("DKIM Signatures in AggregateReports",Reports") below for handling numerous signatures).</t> <t>The elements in this table <bcp14>MUST</bcp14> appear in the order listed.</t> <tablealign="left"><name>Contentsalign="center"><name>Contents of the "auth_results"elementElement </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>dkim</td> <td>*</td> <td>DKIM authenticationresult,result; see <xreftarget="xml-dkim"></xref>.</td>target="xml-dkim"/>.</td> </tr> <tr> <td>spf</td> <td>O</td> <td>SPF authenticationresult,result; see <xreftarget="xml-spf"></xref>.</td>target="xml-spf"/>.</td> </tr> </tbody> </table></section> <section anchor="xml-dkim"><name>Contents of the "dkim"element</name>Element</name> <tablealign="left"><name>Contentsalign="center"><name>Contents of the "dkim"elementElement </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>domain</td> <td>R</td> <td>The domain that was used during validation (the "d=" tag in the signature).</td> </tr> <tr> <td>selector</td> <td>R</td> <td>The selector that was used during validation (the "s=" tag in the signature).</td> </tr> <tr> <td>result</td> <td>R</td> <td>DKIM verificationresult,result; see below.</td> </tr> <tr> <td>human_result</td> <td>O</td> <td>[@lang] More descriptive information to the Domain Owner relating to evaluation failures.</td> </tr> </tbody> </table> <ulspacing="compact">spacing="normal"> <li>"result" is alower-caselowercase string where the value is one of the results defined in <xref target="RFC8601" sectionFormat="of"relative="#" section="2.7.1"></xref>.</li>section="2.7.1"/>.</li> </ul> </section> <section anchor="xml-spf"><name>Contents of the "spf"element</name>Element</name> <t>Only the "MAIL FROM" identity (see <xref target="RFC7208" sectionFormat="of"relative="#" section="2.4"></xref>)section="2.4"/>) is used in DMARC.</t> <tablealign="left"><name>Contentsalign="center"><name>Contents of the "spf"elementElement </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>domain</td> <td>R</td> <td>The domain that was used during validation.</td> </tr> <tr> <td>scope</td> <td>O</td> <td>The source of the domain used during validation.</td> </tr> <tr> <td>result</td> <td>R</td> <td>SPF verificationresult,result; see below.</td> </tr> <tr> <td>human_result</td> <td>O</td> <td>[@lang] More descriptive information to the Domain Owner relating to evaluation failures.</td> </tr> </tbody> </table> <ul> <li><t>The only valid value for the "scope" element is "mfrom".</t> </li> <li><t>"result" is alower-caselowercase string where the value is one of the results defined in <xref target="RFC8601" sectionFormat="of"relative="#" section="2.7.2"></xref>.</t>section="2.7.2"/>.</t> </li> </ul> </section> <section anchor="xml-reason"><name>Contents of the "reason"element</name>Element</name> <t>The policy override reason consists of a pre-defined override type and free-textcomment,comment; see <xreftarget="policy-override-reason"></xref></t>target="policy-override-reason"/>.</t> <tablealign="left"><name>Contentsalign="center"><name>Contents of the "reason"elementElement </name> <thead> <tr> <th>Element name</th> <th>#</th> <th>Content</th> </tr> </thead> <tbody> <tr> <td>type</td> <td>R</td> <td>The reason the DMARC policy was overridden</td> </tr> <tr> <td>comment</td> <td>O</td> <td>[@lang] Further details, if available.</td> </tr> </tbody> </table></section> </section> <section anchor="handling"><name>Handling Domains in Reports</name> <t>In the same report, there <bcp14>MUST</bcp14> be a single DMARC Policy Domain, though there could be multiple RFC5322.FromDomains.domains. Each RFC5322.From domain will create its own "record" within the report. Consider the case where there are three domains with traffic volume to report: example.com, foo.example.com, and bar.example.com. There will be explicit DMARC Policy Records for example.com and bar.example.com, with distinct policies. There is no explicit DMARC Policy Record for foo.example.com, so it will be reliant on the policy described for example.com. For a report period, there would now be tworeports.<br />reports.</t> <!--[rfced] Please clarify the use of "extensibly". Is the intended meaning perhaps "potentially" or "by extension"? Current: The second report will be for example.com and contain multiple "record" elements, one for example.com and one for foo.example.com (and extensibly, other "record" elements for subdomains that likewise did not have an explicit DMARC Policy Record). --> <t>The first report will be forbar.example.com,bar.example.com and contain only one "record", for bar.example.com. The second reportwouldwill be for example.com and will contain multiple "record" elements, one for example.com and one for foo.example.com (and extensibly, other "record" elements for subdomainswhichthat likewise did not have an explicit DMARC Policy Record).</t> </section> <section anchor="dkim-signatures"><name>DKIM Signatures in Aggregate Reports</name> <t>Within a single message, the possibility exists that there could be multiple DKIM signatures. When validation of the message occurs, some signatures may pass, while some may not. As these pertain to DMARC, and especially to aggregate reporting, reporters may not find it clear which DKIM signatures they should include in a report. Signatures, regardless of outcome, could help the report ingester determine the source of a message. However, there is a preference as to which signatures are included.</t> <olspacing="compact">spacing="normal"> <li>A signature that passes DKIM, in strict alignment with the RFC5322.From domain</li> <li>A signature that passes DKIM, in relaxed alignment with the RFC5322.From domain</li> <li>Any other DKIM signatures that pass</li> <li>DKIM signatures that do not pass</li> </ol> <t>A report <bcp14>SHOULD</bcp14> contain no more than 100 signatures for a given "row", in decreasing priority.</t> </section> <section anchor="unique-identifiers-in-aggregate-reporting"><name>Unique Identifiers in Aggregate Reporting</name> <t>There are a few places where a unique identifier is specified as part of the body of the report, the subject, and so on. These unique identifiers should be consistent per each report. Specified below, the reader will see a "Report-ID" and "unique-id". These are the fields that <bcp14>MUST</bcp14> be identical when used.</t> </section> <section anchor="error"><name>Errorelement</name> <t>AElement</name> <t>Here are a few examples of information contained within the "error" element(s):</t> <ulspacing="compact">spacing="normal"> <li>DMARC Policy Record evaluation errors (invalid"rua" or"rua", "sp", etc.)</li> <li>Multiple DMARC Policy Records at a given location</li> </ul> <t>Be mindful that the "error" element is an unboundedstring,string but should not contain an extremely large body. Provide enough information to assist the Domain Owner with understanding some issues with their authentication or DMARC Policy Record.</t> </section> <section anchor="policy-override-reason"><name>Policy Override Reason</name> <t>The "reason" element, indicating an override of the DMARC policy, consists of a mandatory "type" element and an optional "comment" element. The "type" element <bcp14>MUST</bcp14> have one of the pre-defined values listed below. The "comment" element is an unbounded string for providing further details.</t> <t>Possible values for the policy override type:</t><t>"local_policy": The<dl spacing="normal" newline="false"> <dt>"local_policy":</dt><dd>The Mail Receiver's local policy exempted the message from being subjected to the Domain Owner's requested policyaction.</t> <t>"mailing_list": Localaction.</dd> <dt>"mailing_list":</dt><dd>Local heuristics determined that the message arrived via a mailing list, and thus authentication of the original message was not expected tosucceed.</t> <t>"other": Somesucceed.</dd> <dt>"other":</dt><dd>Some policy exception not covered by the other entries in this list occurred. Additionaldetaildetails can be found in the "comment"element.</t> <t>"policy_test_mode": Theelement.</dd> <dt>"policy_test_mode":</dt><dd>The message was exempted from application of policy by the testing mode ("t" tag) in the DMARC PolicyRecord.</t> <t>"trusted_forwarder": MessageRecord.</dd> <dt>"trusted_forwarder":</dt><dd>Message authentication failure was anticipated by other evidence linking the message to a locally maintained list of known and trustedforwarders.</t>forwarders.</dd> </dl> </section> </section> <section anchor="extensions"><name>Extensions</name> <t>The document format supports optional elements for extensions. The absence or existence of this section <bcp14>SHOULD NOT</bcp14> create an error when processing reports. This will be covered ina separate section, Extensible Reporting,<xreftarget="extensible"></xref>.</t>target="extensible"/> ("Extensible Reporting").</t> </section> <section anchor="changes-in-policy-during-reporting-period"><name>Changes in Policy During a Reporting Period</name> <t>Note that Domain Owners or their agents may change the published DMARC Policy Record for a domain or subdomain at any time. From a Mail Receiver's perspective, this will occur during a reporting period and may be noticed during that period, at the end of that period when reports are generated, or during a subsequent reporting period, all depending on the Mail Receiver's implementation. Under these conditions, it is possible that a Mail Receiver could do any of the following:</t> <ulspacing="compact">spacing="normal"> <li>generate for such a reporting period a single aggregate report that includes message dispositions based on the old policy, or a mix of the two policies, even though the report only contains a single "policy_published"element;</li>element</li> <li>generate multiple reports for the same period, one for each published policy occurring during the reportingperiod;</li>period</li> </ul> <t>Such policy changes are expected to be infrequent for any given domain, whereas more stringent policy monitoring requirements on the Mail Receiver would produce a very large burden at Internet scale. Therefore, it is the responsibility of Report Consumers (i.e., vendors) and Domain Owners to be aware of this situation and expect such mixed reports during the propagation of the new policy to Mail Receivers.</t> </section> <section anchor="report-request-discovery"><name>Report Request Discovery</name> <t>A Mail Receiver discovers reporting requests when it looks up a DMARC Policy Record that corresponds to an RFC5322.From domain on received mail. The presence of the "rua" tag specifies where to send feedback.</t> </section> <section anchor="report-delivery"><name>Report Delivery</name> <t>The Mail Receiver, after preparing a report, <bcp14>MUST</bcp14> evaluate the provided reporting URIs(See(see <xreftarget="I-D.ietf-dmarc-dmarcbis"></xref>)target="RFC9989"/>) in the order given. If any of the URIs are malformed, theySHOULD<bcp14>SHOULD</bcp14> be ignored. An attempt <bcp14>MUST</bcp14> be made to deliver an aggregate report to every remaining URI, up to the Receiver's limits on supported URIs.</t> <t>If delivery is not possible because the services advertised by the published URIs are not able to accept reports (e.g., the URI refers to a service that is unreachable), the Mail Receiver <bcp14>MAY</bcp14> cache that data and try againlater,later or <bcp14>MAY</bcp14> discard data that could not be sent.</t> <t>Where the URI specified in a "rua" tag does not specify otherwise, a Mail Receiver generating a feedback report <bcp14>SHOULD</bcp14> employ a secure transport mechanism, meaning the report should be delivered over a channel employing TLS (SMTP+STARTTLS).</t> <section anchor="report-id"><name>Definition of Report-ID</name> <t>This identifier <bcp14>MUST</bcp14> be unique among reports to the same domain to aid receivers in identifying duplicate reports should they happen. The Report-ID value should be constructed using the following ABNF:</t><artwork><sourcecode type="abnf"><![CDATA[ ridfmt = (dot-atom-text["@"["@" dot-atom-text]) ; from RFC 5322 ridtxt =("<"("<" ridfmt">")">") /ridfmt </artwork>ridfmt]]></sourcecode> <t>The format specified here is not verystrictstrict, as the key goal is uniqueness. In order to create this uniqueness, the Mail Receiver may wish to use elements such as the receiving domain, the sending domain, and a timestamp in combination. An example string might be"1721054318-example.com@example.org"."1721054318-example.com@example.org". An alternate could use a date string such as"2024-03-27_example.com@example.org".</t>"2024-03-27_example.com@example.org".</t> </section> <!--[rfced] How may we rephrase "a [RFC5322] message" to avoid using RFC 5322 as an adjective? Original: The message generated by the Mail Receiver MUST be a [RFC5322] message formatted per [RFC2045]. Perhaps A: The message generated by the Mail Receiver MUST be as described in [RFC5322] and formatted per [RFC2045]. or Perhaps B: The message generated by the Mail Receiver MUST be a message that contains subaddressing [RFC5322] and is formatted per [RFC2045]. --> <section anchor="email"><name>Email</name> <t>The message generated by the Mail Receiver <bcp14>MUST</bcp14> be a <xreftarget="RFC5322"></xref>target="RFC5322"/> message formatted per <xreftarget="RFC2045"></xref>.target="RFC2045"/>. The aggregate report itself <bcp14>MUST</bcp14> be included in one of the parts of the message, as an attachment with a corresponding media type from below. A human-readable annotation <bcp14>MAY</bcp14> be included as a body part (with a human-friendly content-type, such as"text/plain""text/plain" or"text/html").</t>"text/html").</t> <t>The aggregate data <bcp14>MUST</bcp14> be an XML file that <bcp14>SHOULD</bcp14> be subjected to GZIP <xreftarget="RFC1952"></xref>target="RFC1952"/> compression. Declining to apply compression can cause the report to be too large for a receiver to process (the total message size could exceed the receiver SMTP size limit); doing the compression increases the chances of acceptance of the report at some compute cost. The aggregate data <bcp14>MUST</bcp14> be present using the media type"application/gzip""application/gzip" if compressed (see <xreftarget="RFC6713"></xref>),target="RFC6713"/>) and"text/xml""text/xml" otherwise. The attachment filename <bcp14>MUST</bcp14> be constructed using the following ABNF:</t><artwork><sourcecode type="abnf"><![CDATA[ filename = receiver"!""!" policy-domain"!""!" begin-timestamp"!""!" end-timestamp ["!""!" unique-id ]".""." extension receiver = domain-name ; imported from RFC 6376 policy-domain = domain-name begin-timestamp = 1*DIGIT ; seconds since 00:00:00 UTC January 1, 1970 ; indicating start of the time range contained ; in the report end-timestamp = 1*DIGIT ; seconds since 00:00:00 UTC January 1, 1970 ; indicating end of the time range contained ; in the report unique-id = 1*(ALPHA / DIGIT) extension ="xml""xml" /"xml.gz" </artwork>"xml.gz"]]></sourcecode> <t>The following primitive tokens that are used but otherwise unspecified are taken fromthe "Core Rules" of <xref target="RFC5234"></xref>:"Core Rules" (<xref target="RFC5234" sectionFormat="of" section="B.1"/>): DIGIT, ALPHA.</t> <t>The extension <bcp14>MUST</bcp14> be"xml""xml" for a plain XMLfile,file or"xml.gz""xml.gz" for an XML file compressed using GZIP.</t><t>"unique-id"<t>"unique-id" allows an optional unique ID generated by the Mail Receiver to distinguish among multiple reports generated simultaneously by different sources within the same Domain Owner. A viable option may be to exploreUUIDsUniversally Unique Identifiers (UUIDs) <xreftarget="RFC9562"></xref>.</t>target="RFC9562"/>.</t> <t>If a report generator needs to re-send a report, the system <bcp14>MUST</bcp14> use the same filename as the original report. This would allow the receiver to overwrite the data from theoriginal,original or discard the second instance of the report.</t> <t>For example, this is a sample filename for the gzip file of a report to the Domain Owner"example.com""example.com" from the Mail Receiver"mail.receiver.example":</t> <t>mail.receiver.example!example.com!1013662812!1013749130.xml.gz</t>"mail.receiver.example":</t> <t indent="3">mail.receiver.example!example.com!1013662812!1013749130.xml.gz</t> <t>No specific MIME message structure is required for the message body. It is presumed that the aggregate reporting address will be equipped to extract body parts with the prescribed media type and filename and ignore the rest.</t> <t>Mail streams carrying DMARC feedback data <bcp14>MUST</bcp14> conform to the DMARC mechanism, thereby resulting in an aligned"pass""pass" (see <xreftarget="I-D.ietf-dmarc-dmarcbis"target="RFC9989" sectionFormat="of"relative="#" section="4.4"></xref>).section="4.4"/>). This practice minimizes the risk of Report Consumers processing fraudulent reports.</t> <t>The RFC5322.Subject field for individual report submissions <bcp14>MUST</bcp14> conform to the following ABNF:</t><artwork><sourcecode type="abnf"><![CDATA[ ; FWS is imported from RFC 5322 dmarc-subject =%s"Report"%s"Report" 1*FWS%s"Domain:"%s"Domain:" 1*FWS domain-name 1*FWS ; policy domain%s"Submitter:"%s"Submitter:" 1*FWS domain-name 1*FWS ; report generator [%s"Report-ID:"%s"Report-ID:" 1*FWS ridtxt ] ; defined above</artwork>]]></sourcecode> <t>The first domain-name indicates the DNS domain name about which the report was generated. The second domain-name indicates the DNS domain name representing the Mail Receiver generating the report. The purpose of the Report-ID: portion of the field is to enable the Domain Owner to identify and ignore duplicate reports that might be sent by a Mail Receiver.</t> <t>For instance, this is a possible Subject field for a report to the Domain Owner"example.com""example.com" from the Mail Receiver"mail.receiver.example"."mail.receiver.example". It is folded as allowed by <xreftarget="RFC5322"></xref>:</t> <artwork>target="RFC5322"/>:</t> <artwork><![CDATA[ Subject: Report Domain: example.com Submitter: mail.receiver.example Report-ID:<sample-ridtxt@example.com> </artwork><sample-ridtxt@example.com>]]></artwork> <t>This transport mechanism potentially encounters a problem when feedback data size exceeds maximum allowable attachment sizes for either the generator or the consumer.</t> <t>Optionally, the report sender <bcp14>MAY</bcp14> choose to use the same"ridtxt""ridtxt" as a part or whole of the RFC5322.Message-Id header included with the report. Doing so may help receivers distinguish when a message is a re-transmission or duplicate report.</t> </section> <section anchor="other-methods"><name>Other Methods</name> <t>The specification as written allows for the addition of other registered URI schemes to be supported in later versions.</t> </section> <section anchor="handling-of-duplicates"><name>Handling of Duplicates</name> <t>There may be a situation where the report generator attempts to deliver duplicate information to the receiver. This may manifest as an exact duplicate of thereport,report or as duplicate information between two reports. In these situations, the decision of how to handle the duplicate data lies with the receiver. As noted above, the sender <bcp14>MUST</bcp14> use the same unique identifiers when sending the report. This allows the receiver to better understand when duplicates happen.AHere are a few options on how to handle that duplicate information:</t> <ulspacing="compact">spacing="normal"> <li>Reject back to sender, ideally with a permfail error noting the duplicate receipt</li> <li>Discard upon receipt</li> <li>Inspect the contents to evaluate the timestamps and reported data, act as appropriate</li> <li>Accept the duplicate data</li> </ul><t>When<!--[rfced] To improve readability, may we update this sentence as follows? Original: When accepting the data, that's likely in a situation where it's not yet noticed, or a one-off experience.Long term,Perhaps: When accepting the data, it's likely that the duplicate data has not yet been noticed and is a one-off experience. --> <t>When accepting the data, that's likely in a situation where it's not yet noticed or a one-off experience. Long-term duplicate data is not ideal. In the situation of a partial time frame overlap, there is no clear way to distinguish the impact of the overlap. The receiver would need to accept or reject the duplicate data in whole.</t> </section> </section> </section> <section anchor="verifying-external-destinations"><name>Verifying External Destinations</name> <t>It is possible to specify destinations for the different reports that are outside the authority of the Domain Owner making the request. This allows domains that do not operate mail servers to request reports and have them go someplace that is able to receive and process them.</t> <t>Without checks, this would allow a bad actor to publish a DMARC Policy Record that requests that reports be sent to a victimaddress,address and then send a large volume of mail that will fail both DKIM and SPF checks to a wide variety of destinations; the victim will in turn be flooded with unwanted reports. Therefore, a verification mechanism is included.</t> <t>When a Mail Receiver discovers a DMARC Policy Record in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a <xreftarget="RFC3986"></xref>target="RFC3986"/> specified in the"rua""rua" tag, the following verification steps <bcp14>MUST</bcp14> be taken:</t> <ol> <li><t>Extract the host portion of the authority component of the URI. Call this the"destination host","destination host", as it refers to a Report Receiver.</t> </li> <li><t>Prepend the string"_report._dmarc".</t>"_report._dmarc".</t> </li> <li><t>Prepend the domain name from which the policy was retrieved, after conversion to an A-label <xreftarget="RFC5890"></xref>target="RFC5890"/> if needed.</t> </li> <li><t>If the length of the constructed name exceed DNS limits, a positive determination of the external reporting relationship cannot be made; stop.</t> </li> <li><t>Query the DNS for a TXT record at the constructed name. If the result of this request is a temporary DNS error of some kind (e.g., a timeout), the Mail Receiver <bcp14>MAY</bcp14> elect to temporarily fail the delivery so the verification test can be repeated later.</t> </li> <li><t>For each record returned, parse the result as a series of"tag=value""tag=value" pairs, i.e., the same overall format as the DMARC Policy Record (see <xreftarget="I-D.ietf-dmarc-dmarcbis"target="RFC9989" sectionFormat="of"relative="#" section="4.7"></xref>).section="4.7"/>). In particular, the"v=DMARC1""v=DMARC1" tag is mandatory and <bcp14>MUST</bcp14> appear first in the list. Discard any that do not pass this test. A trailing";"";" is optional.</t> </li> <li><t>If the result includes no TXT resource records that pass basic parsing, a positive determination of the external reporting relationship cannot be made; stop.</t> </li> <li><t>If at least one TXT resource record remains in the set after parsing, then the external reporting arrangement was authorized by the Report Consumer.</t> </li> <li><t>If a"rua""rua" tag is thus discovered, replace the corresponding value extracted from the domain's DMARC Policy Record with the one found in this record. This permits the Report Consumer to override the report destination. However, to prevent loops or indirect abuse, the overriding URI <bcp14>MUST</bcp14> use the same destination host from the first step.</t> </li> </ol> <t>For example, if the DMARC Policy Record for"blue.example.com""blue.example.com" contained<tt>"rua=mailto:reports@red.example.net"</tt>,<tt>"rua=mailto:reports@red.example.net"</tt>, the Organizational Domain host extracted from the latter("red.example.net")("red.example.net") does not match"blue.example.com","blue.example.com", so this procedure is enacted. A TXT query for"blue.example.com._report._dmarc.red.example.net""blue.example.com._report._dmarc.red.example.net" is issued. If a single reply comes back containing a tag of"v=DMARC1","v=DMARC1", then the relationship between the two is confirmed. Moreover,"red.example.net""red.example.net" has the opportunity to override the report destination requested by"blue.example.com""blue.example.com" if needed.</t> <t>Where the above algorithm fails to confirm that the external reporting was authorized by the Report Consumer, the URI <bcp14>MUST</bcp14> be ignored by the Mail Receiver generating the report. Further, if the confirming record includes a URI whose host is again different than the domain publishing that override, the Mail Receiver generating the report <bcp14>MUST NOT</bcp14> generate a report to either the original or the override URI. A Report Consumer publishes such a record in its DNS if it wishes to receive reports for other domains.</t> <t>A Report Consumer that is willing to receive reports for any domain can use a wildcard DNS record. For example, a TXT resource record at"*._report._dmarc.example.com""*._report._dmarc.example.com" containing at least"v=DMARC1""v=DMARC1" confirms that example.com is willing to receive DMARC reports for any domain.</t> <t>If the Report Consumer is overcome by volume, it can simply remove the confirming DNS record. However, due to positive caching, the change could take as long as thetime-to-liveTime to Live (TTL) on the record to go into effect.</t> <!--[rfced] Would it be correct to say that the Domain Owner should consider using a shorter "domain name" for clarity? Current: If the length of the DNS query is excessively long (Step 4 above), the Domain Owner may need to reconsider the domain being used to be shorter or reach out to another party that may allow for a shorter DNS label. Perhaps: If the DNS query length is excessively long (see Step 4), the Domain Owner may need to consider using a shorter domain name or coordinate with another party that may allow for a shorter DNS label. --> <t>If the length of the DNS query is excessively long (Step 4 above), the Domain Owner may need to reconsider the domain being used to beshorter,shorter or reach out to another party that may allow for a shorter DNS label.</t> </section> <section anchor="extensible"><name>Extensible Reporting</name> <t>DMARC reports allow for some extensibility, as defined by future documents that utilize DMARC as a foundation. These extensions <bcp14>MUST</bcp14> be properly formatted XML and meant to exist within the structure of a DMARC report. Two positions of type"<any>""<any>" are provided in the existing DMARCstructure,structure: one at filelevel,level in an"<extension>""<extension>" element after"<policy_published>""<policy_published>" and one at recordlevel,level after"<auth_results>"."<auth_results>". In either case, the extensions <bcp14>MUST</bcp14> contain a URI to the definition of the extension so that the receiver understands how to interpret the data.</t> <t>At file level:</t> <!--[rfced] XML snippets a) Should the "</feedback>" closing tag be added after "</extension>" in the first XML example in Section 5 so that the XML parses, or is this meant to be a continuing example? Original: <feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0" xmlns:ext="URI for an extension-supplied name space"> ... <policy_published> <domain>example.com</domain> <p>quarantine</p> <sp>none</sp> <testing>n</testing> </policy_published> <extension> <ext:arc-override>never</ext:arc-override> </extension> Perhaps: <feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0" xmlns:ext="URI for an extension-supplied name space"> ... <policy_published> <domain>example.com</domain> <p>quarantine</p> <sp>none</sp> <testing>n</testing> </policy_published> <extension> <ext:arc-override>never</ext:arc-override> </extension> </feedback> b) Should "<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0" xmlns:ext="URI for an extension-supplied name space">" be added to the following XML snippet? Is a closing tag unnecessary because this is a continuing example, or should one be added? Current: <record> <row> ... </row> <identifiers> ... </identifiers> <auth_results> ... </auth_results> <ext:arc-results> ... </ext:arc-results> </record> <record> ... Perhaps: <feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0" xmlns:ext="URI for an extension-supplied name space"> ... <record> <row> ... </row> <identifiers> ... </identifiers> <auth_results> ... </auth_results> <ext:arc-results> ... </ext:arc-results> </record> --> <sourcecodetype="xml"><feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0" xmlns:ext="URItype="xml"><![CDATA[ <feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0" xmlns:ext="URI for an extension-supplied namespace">space"> ...<policy_published> <domain>example.com</domain> <p>quarantine</p> <sp>none</sp> <testing>n</testing> </policy_published> <extension> <ext:arc-override>never</ext:arc-override> </extension> </sourcecode><policy_published> <domain>example.com</domain> <p>quarantine</p> <sp>none</sp> <testing>n</testing> </policy_published> <extension> <ext:arc-override>never</ext:arc-override> </extension>]]></sourcecode> <t>Within the"record""record" element:</t> <sourcecodetype="xml"> <record> <row>type="xml"><![CDATA[ <feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0" xmlns:ext="URI for an extension-supplied name space"> ...</row> <identifiers><record> <row> ...</identifiers> <auth_results></row> <identifiers> ...</auth_results> <ext:arc-results></identifiers> <auth_results> ...</ext:arc-results> </record> <record></auth_results> <ext:arc-results> ...</sourcecode></ext:arc-results> </record> <record> ...]]></sourcecode> <t>Here"arc-override""arc-override" and"arc-results""arc-results" are hypothetical element names defined in the extension'sname space.</t>namespace.</t> <t>Extension elements are optional. Any number of extensions is allowed. If a processor is unable to handle an extension in a report, it <bcp14>SHOULD</bcp14> ignore the data and continue to the next extension.</t> </section> <section anchor="iana-considerations"><name>IANA Considerations</name> <!--[rfced] FYI: Per IANA's note, we have updated the registrant contact from "IETF" to "IESG" in Sections 6.1 and 6.2. Original: Registrant Contact: Internet Engineering Task Force (iesg@ietf.org) Current: Registrant Contact: The IESG (iesg@ietf.org) --> <t>This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in <xreftarget="RFC3688"></xref>.target="RFC3688"/>. Two URI assignmentswill behave been registered by theIANA.</t>IANA. </t> <section anchor="registration-request-for-the-dmarc-namespace"><name>Registrationrequestfor the DMARCnamespace:</name> <t>URI: urn:ietf:params:xml:ns:dmarc-2.0</t> <t>Registrant Contact: Internet Engineering Task Force (iesg@ietf.org)</t> <t>XML: None. Namespace URIs do not representNamespace</name> <t> IANA has registered the following URI in the "ns" registry within the "IETF XML Registry" group: </t> <dl spacing="compact" newline="false"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:dmarc-2.0</dd> <dt>Registrant Contact:</dt><dd>The IESG (iesg@ietf.org)</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLspecification.</t>namespace.</dd> </dl> </section> <section anchor="registration-request-for-the-dmarc-xml-schema"><name>Registrationrequestfor the DMARC XMLschema:</name> <t>URI: urn:ietf:params:xml:schema:dmarc-2.0</t> <t>Registrant Contact: Internet Engineering Task Force (iesg@ietf.org)</t> <t>XML: See Appendix A.Schema</name> <t> IANA has registered the following URI in the "schema" registry within the "IETF XML Registry" group: </t> <dl spacing="compact" newline="false"> <dt>URI:</dt><dd>urn:ietf:params:xml:schema:dmarc-2.0</dd> <dt>Registrant Contact:</dt><dd>The IESG (iesg@ietf.org)</dd> <dt>XML:</dt><dd>See the DMARC XMLSchema (<xref target="W3C.REC-xmlschema-1"></xref> andschema <xref target="W3C.REC-xmlschema-1"/> <xreftarget="W3C.REC-xmlschema-2"></xref>)target="W3C.REC-xmlschema-2"/> in <xref target="xsd"/> of thisdocument.</t>document.</dd> </dl> </section> </section> <section anchor="privacy-considerations"><name>Privacy Considerations</name> <t>This sectionwill discussdiscusses exposure related to DMARC aggregate reporting.</t> <section anchor="report-recipients"><name>Report Recipients</name> <t>A DMARC Policy Record can specify that reports should be sent to an intermediary operating on behalf of the Domain Owner. This is done when the Domain Owner contracts with an entity to monitor mail streams for abuse and performance issues. Receipt by third parties of such data may or may not be permitted by the Mail Receiver's privacy policy, terms of use, or other similar governing document. Domain Owners and Mail Receivers should both review and understand if their own internal policies constrain the use and transmission of DMARC reporting.</t> <t>Some potential exists for report recipients to perform traffic analysis, making it possible to obtain metadata about the Receiver's traffic. In addition to verifying compliance with policies, Receivers need to consider that before sending reports to a third party.</t> </section> <section anchor="data-contained-within-reports"><name>Data Contained Within Reports</name> <t>Aggregate feedback reports contain aggregated data relating to messages purportedly originating from the Domain Owner. The data does not contain any identifying characteristics about individual users. No personal information such as individual mail addresses, IP addresses of individuals, or the content of anymessages,messages is included in reports.</t> <t>Mail Receivers should have no concerns in sendingreportsreports, as they do not contain personal information. In all cases, the data within the reports relates to the domain-level authentication information provided by mail servers sending messages on behalf of the Domain Owner. This information is necessary to assist Domain Owners in implementing and maintaining DMARC.</t> <t>Domain Owners should have no concerns in receivingreportsreports, as they do not contain personal information. The reports only contain aggregated data related to the domain-level authentication details of messages claiming to originate from their domain. This information is essential for the proper implementation and operation of DMARC. Domain Owners who are unable to receive reports for organizationalreasons,reasons can choose to exclusively direct the reports to an external processor.</t> </section> <section anchor="leakage"><name>Feedback Leakage</name> <t>Providing feedback reporting toPSOs (PublicPublic SuffixOperator)Operators (PSOs) for aPSD (PublicPublic SuffixDomain)Domain (PSD) <xreftarget="I-D.ietf-dmarc-dmarcbis"></xref>target="RFC9989"/> can, in some cases, cause information to leak out of an organization to the PSO. This leakage could potentially be utilized as part of a program of pervasive surveillance (see <xreftarget="RFC7624"></xref>).target="RFC7624"/>). There are roughly three cases to consider:</t><ul> <li><t>Single<dl spacing="normal" newline="true"> <dt>Single Organization PSDs (e.g.,".mil")</t> <t>Aggregate".mil"):</dt> <dd>Aggregate reports based on PSD DMARC have the potential to contain information aboutmailsmail related to entities managed by the organization. Since both the PSO and the Organizational Domain Owners are common, there is no additional privacy risk for either normal or non-existent domain reporting due to PSDDMARC.</t> </li> <li><t>Multi-organizationDMARC.</dd> <dt>Multi-organization PSDs requiring DMARC usage (e.g.,".bank")</t> <t>Aggregate".bank"):</dt> <dd>Aggregate reports based on PSD DMARC will only be generated for domains that do not publish a DMARC Policy Record at the Organizational Domain or host level. For domains that do publish the required DMARC Policy Records, the feedback reporting addresses of the Organizational Domain (or hosts) will be used. The only direct risk of feedback leakage for these PSDs are for Organizational Domains that are out of compliance with PSD policy. Data on non-existent domains would be sent to thePSO.</t> </li> <li><t>Multi-organizationPSO.</dd> <dt>Multi-organization PSDs not requiring DMARC usage (e.g.,".com")</t> <t>Privacy".com"):</dt> <dd>Privacy risks for Organizational Domains that have not deployed DMARC within such PSDs can be significant. For non-DMARC Organizational Domains, all DMARC feedback will be directed to the PSO if that PSO itself has a DMARC Policy Record that specifies a"rua""rua" tag. Any non-DMARC Organizational Domain would have itsFeedback Reportsfeedback reports redirected to the PSO. The content of such reports, particularly for existing domains, is privacysensitive.</t> </li> </ul>sensitive.</dd> </dl> <t>PSOs will receive feedback on non-existent domains, which may be similar to existing Organizational Domains. Feedback related to such domains have a small risk of carrying information related to an actual Organizational Domain. To minimize this potential concern, PSD DMARC feedback <bcp14>MUST</bcp14> be limited to aggregate reports. Failure reports carry more detailed information and present a greater risk.</t> </section> </section> <section anchor="security-considerations"><name>Security Considerations</name> <t>While reviewing this document and itsSecurity Considerations,security considerations, it is ideal that the readerwouldalso review the Privacy Considerations section above, as well as thePrivacy Considerationsprivacy considerations andSecurity Considerationssecurity considerations insectionSections <xreftarget="I-D.ietf-dmarc-dmarcbis"target="RFC9989" sectionFormat="bare"relative="#" section="9"></xref>section="10"/> and <xreftarget="I-D.ietf-dmarc-dmarcbis"target="RFC9989" sectionFormat="bare"relative="#" section="10"></xref>section="11"/> of <xreftarget="I-D.ietf-dmarc-dmarcbis"></xref>.</t>target="RFC9989"/>.</t> <section anchor="report-contents-as-an-attack"><name>ReportContentsContent as an Attack</name> <t>Aggregate reports are supposed to be processed automatically. An attacker might attempt to compromise the integrity or availability of the report processor by sending malformed reports. In particular, the archive decompressor and XML parser are at risk to resource exhaustion attacks (zip bomb or XML bomb).</t> </section> <section anchor="false-information"><name>False Information</name> <t>The data contained within aggregate reports may be forged. An attacker might attempt to interfere with or influence policy decisions by submitting false reports in large volume. The attacker could also be attempting to influence platform architecture decisions. A volume-based attack may also impact the ability for areport receiverReport Receiver to accept reports from other entities.</t> </section> <section anchor="disclosure-of-filtering-information"><name>Disclosure of Filtering Information</name> <t>While not specified in this document itself, the availability of extensions could enable the report generator to disclose information about message placement(Inbox/Spam/etc).(Inbox/Spam/etc.). This is very much discouraged as it could relay this information to a malicious party, allowing them to understand more about filtering methodologies at a receiving entity.</t> </section> </section> <section anchor="operational-considerations"><name>Operational Considerations</name> <section anchor="report-generation"><name>Report Generation</name> <ulspacing="compact">spacing="normal"> <li>The error fields should be reasonably terse and usable.</li> <li>If reports cannot begenerator,generated, the system should ideally log a useful error that helps troubleshoot the issue.</li> </ul> </section> <section anchor="report-evaluation"><name>Report Evaluation</name> <t>As noted above, if a report does not match the specified format, the evaluator will likely find the contents to be in question. Alternately, the evaluator may decide to sideline those reports so they can more easily collaborate with the report generator to identify where the issues are happening.</t> <t>It's quite likely that the data contained within the reports will be extracted and stored in a system that allows for easy reporting, dashboarding, and/or monitoring. The XML reports themselves are not human readable in bulk, and a system such as the above may aid the Domain Owner with identifying issues.</t> </section> <section anchor="report-storage"><name>Report Storage</name> <t>Once a report is accepted and properly parsed by the report evaluator, it is entirely up to that evaluator as to what they wish to do with the XML documents. For some domains, the quantity of reports could be fairly high, or the size of the reports themselves could be large. Once the data from the reports has been extracted and indexed, the reports seemingly have little value in most situations.</t> </section> </section> </middle> <back> <references><name>References</name> <references><name>Normative References</name> <!-- [RFCYYY1] draft-ietf-dmarc-dmarcbis-41 in RFC-EDITOR as of 05/11/26 --> <reference anchor="RFC9989" target="https://www.rfc-editor.org/info/rfc9989"> <front> <title>Domain-Based Message Authentication, Reporting, and Conformance (DMARC)</title> <author initials="T." surname="Herr" fullname="Todd Herr" role="editor"> <organization>Valimail</organization> </author> <author initials="J. R." surname="Levine" fullname="John R. Levine" role="editor"> <organization>Standcore LLC</organization> </author> <date month='May' year='2026'/> </front> <seriesInfo name="RFC" value="9989"/> <seriesInfo name="DOI" value="10.17487/RFC9989"/> </reference> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-dmarc-dmarcbis.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1952.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2045.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1952.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2045.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6713.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5890.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7208.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6713.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7208.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8601.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml-w3c/reference.W3C.REC-xmlschema-1.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml-w3c/reference.W3C.REC-xmlschema-2.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8601.xml"/> <!-- [rfced] FYI: We updated the dates for the W3C reference entries from "2 May 2001" to "28 October 2004" to match the most current version of the two W3C Recommendations. --> <reference anchor="W3C.REC-xmlschema-1" target="https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/"> <front> <title>XML Schema Part 1: Structures Second Edition</title> <author fullname="Henry S. Thompson" role="editor"/> <author fullname="David Beech" role="editor"/> <author fullname="Murray Maloney" role="editor"/> <author fullname="Noah Mendelsohn" role="editor"/> <date day="28" month="October" year="2004" /> </front> <refcontent>W3C Recommendation</refcontent> <annotation>Latest version available at <eref target="https://www.w3.org/TR/xmlschema-1/"/>.</annotation> </reference> <reference anchor="W3C.REC-xmlschema-2" target="https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"> <front> <title>XML Schema Part 2: Datatypes Second Edition</title> <author fullname="Paul V. Biron" role="editor"/> <author fullname="Ashok Malhotra" role="editor"/> <date day="28" month="October" year="2004" /> </front> <refcontent>W3C Recommendation</refcontent> <annotation>Latest version available at <eref target="https://www.w3.org/TR/xmlschema-2/"/>.</annotation> </reference> </references> <references><name>Informative References</name> <!-- [RFCYYY2] RFC 9991 draft-ietf-dmarc-failure-reporting-25 IESG State: in RFC-EDITOR as of 05/11/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 initials="S. M." surname="Jones" fullname="Steven M Jones" role="editor"> <organization>DMARC.org</organization> </author> <author initials="A." surname="Vesely" fullname="Alessandro Vesely" role="editor"> <organization>Tana</organization> </author> <date month="May" year="2026" /> </front> <seriesInfo name="RFC" value="9991"/> <seriesInfo name="DOI" value="10.17487/RFC9991"/> </reference> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-dmarc-failure-reporting.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5598.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5598.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7624.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7624.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9562.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9562.xml"/> </references> </references> <section anchor="xsd"><name>DMARC XML Schema</name> <!--[rfced] In the XML schema in Appendix A, we updated "[@?RFC7489]" to "RFC 7489" and "[@I-D.ietf-dmarc-dmarcbis]" to "RFC 9989". We also made a few punctuation updates for consistency. Please let us know of any objections. --> <sourcecodetype="xsd"><?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:dmarc-2.0" xmlns="urn:ietf:params:xml:ns:dmarc-2.0" elementFormDefault="qualified"> <!--type="xml"><![CDATA[ <?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:dmarc-2.0" xmlns="urn:ietf:params:xml:ns:dmarc-2.0" elementFormDefault="qualified"> <!-- Elements with an optional"lang""lang" attribute.--> <xs:complexType name="langAttrString"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="lang" type="xs:language" use="optional" default="en"/> </xs:extension> </xs:simpleContent> </xs:complexType> <!----> <xs:complexType name="langAttrString"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="lang" type="xs:language" use="optional" default="en"/> </xs:extension> </xs:simpleContent> </xs:complexType> <!-- The time range in UTC defining the reporting period of this report, specified in seconds since epoch.--> <xs:complexType name="DateRangeType"> <xs:all> <xs:element name="begin" type="xs:integer" minOccurs="1" maxOccurs="1"/> <xs:element name="end" type="xs:integer" minOccurs="1" maxOccurs="1"/> </xs:all> </xs:complexType> <!----> <xs:complexType name="DateRangeType"> <xs:all> <xs:element name="begin" type="xs:integer" minOccurs="1" maxOccurs="1"/> <xs:element name="end" type="xs:integer" minOccurs="1" maxOccurs="1"/> </xs:all> </xs:complexType> <!-- Report generator metadata.--> <xs:complexType name="ReportMetadataType"> <xs:all> <!----> <xs:complexType name="ReportMetadataType"> <xs:all> <!-- Reporting Organization--> <xs:element name="org_name" type="xs:string" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="org_name" type="xs:string" minOccurs="1" maxOccurs="1"/> <!-- Contact to use when contacting the Reporting Organization--> <xs:element name="email" type="xs:string" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="email" type="xs:string" minOccurs="1" maxOccurs="1"/> <!-- Additional contact details--> <xs:element name="extra_contact_info" type="langAttrString" minOccurs="0" maxOccurs="1"/> <!----> <xs:element name="extra_contact_info" type="langAttrString" minOccurs="0" maxOccurs="1"/> <!-- Unique Report-ID--> <xs:element name="report_id" type="xs:string" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="report_id" type="xs:string" minOccurs="1" maxOccurs="1"/> <!-- Timestamps used when forming report data--> <xs:element name="date_range" type="DateRangeType" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="date_range" type="DateRangeType" minOccurs="1" maxOccurs="1"/> <!-- Optional error messages when processing DMARC policy--> <xs:element name="error" type="langAttrString" minOccurs="0" maxOccurs="1"/> <!----> <xs:element name="error" type="langAttrString" minOccurs="0" maxOccurs="1"/> <!-- Optional information about the generating software--> <xs:element name="generator" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType> <!----> <xs:element name="generator" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType> <!-- Alignment mode (relaxed or strict) for DKIM and SPF.--> <xs:simpleType name="AlignmentType"> <xs:restriction base="xs:string"> <xs:enumeration value="r"/> <xs:enumeration value="s"/> </xs:restriction> </xs:simpleType> <!----> <xs:simpleType name="AlignmentType"> <xs:restriction base="xs:string"> <xs:enumeration value="r"/> <xs:enumeration value="s"/> </xs:restriction> </xs:simpleType> <!-- The policy actions specified by p,spsp, and np in the DMARC Policy Record.--> <xs:simpleType name="DispositionType"> <xs:restriction base="xs:string"> <xs:enumeration value="none"/> <xs:enumeration value="quarantine"/> <xs:enumeration value="reject"/> </xs:restriction> </xs:simpleType> <!----> <xs:simpleType name="DispositionType"> <xs:restriction base="xs:string"> <xs:enumeration value="none"/> <xs:enumeration value="quarantine"/> <xs:enumeration value="reject"/> </xs:restriction> </xs:simpleType> <!-- The policy actions utilized on messages for this record.--> <!-- "none":--> <!-- "none": No action taken"pass":"pass": No action, passing DMARC w/enforcing policy"quarantine":"quarantine": Failed DMARC, message marked for quarantine"reject":"reject": Failed DMARC, marked as reject--> <xs:simpleType name="ActionDispositionType"> <xs:restriction base="xs:string"> <xs:enumeration value="none"/> <xs:enumeration value="pass"/> <xs:enumeration value="quarantine"/> <xs:enumeration value="reject"/> </xs:restriction> </xs:simpleType> <!----> <xs:simpleType name="ActionDispositionType"> <xs:restriction base="xs:string"> <xs:enumeration value="none"/> <xs:enumeration value="pass"/> <xs:enumeration value="quarantine"/> <xs:enumeration value="reject"/> </xs:restriction> </xs:simpleType> <!-- The method used to discover the DMARC Policy Record used during evaluation. The available values are"psl""psl" and"treewalk","treewalk", where"psl""psl" is the method from[@?RFC7489]RFC 7489 andthe "treewalk""treewalk" is described in[@I-D.ietf-dmarc-dmarcbis]. --> <xs:simpleType name="DiscoveryType"> <xs:restriction base="xs:string"> <xs:enumeration value="psl"/> <xs:enumeration value="treewalk"/> </xs:restriction> </xs:simpleType> <!--RFC 9989. --> <xs:simpleType name="DiscoveryType"> <xs:restriction base="xs:string"> <xs:enumeration value="psl"/> <xs:enumeration value="treewalk"/> </xs:restriction> </xs:simpleType> <!-- The published DMARC policy. Unspecified tags have their default values.--> <xs:complexType name="PolicyPublishedType"> <xs:all> <!----> <xs:complexType name="PolicyPublishedType"> <xs:all> <!-- The domain at which the DMARC record was found.--> <xs:element name="domain" type="xs:string" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="domain" type="xs:string" minOccurs="1" maxOccurs="1"/> <!-- The policy published for messages from:--> <!----> <!-- * the domain.--> <xs:element name="p" type="DispositionType" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="p" type="DispositionType" minOccurs="1" maxOccurs="1"/> <!-- * subdomains.--> <xs:element name="sp" type="DispositionType" minOccurs="0" maxOccurs="1"/> <!----> <xs:element name="sp" type="DispositionType" minOccurs="0" maxOccurs="1"/> <!-- * non-existent subdomains.--> <xs:element name="np" type="DispositionType" minOccurs="0" maxOccurs="1"/> <!----> <xs:element name="np" type="DispositionType" minOccurs="0" maxOccurs="1"/> <!-- The DKIM alignment mode.--> <xs:element name="adkim" type="AlignmentType" minOccurs="0" maxOccurs="1"/> <!----> <xs:element name="adkim" type="AlignmentType" minOccurs="0" maxOccurs="1"/> <!-- The SPF alignment mode.--> <xs:element name="aspf" type="AlignmentType" minOccurs="0" maxOccurs="1"/> <!----> <xs:element name="aspf" type="AlignmentType" minOccurs="0" maxOccurs="1"/> <!-- Method used to find/obtain DMARCpolicy --> <xs:element name="discovery_method" type="DiscoveryType" minOccurs="0" maxOccurs="1"/> <!--policy. --> <xs:element name="discovery_method" type="DiscoveryType" minOccurs="0" maxOccurs="1"/> <!-- Failure reporting options in effect.--> <xs:element name="fo" type="xs:string" minOccurs="0" maxOccurs="1"/> <!----> <xs:element name="fo" type="xs:string" minOccurs="0" maxOccurs="1"/> <!-- Whether testing mode was declared in the DMARCRecord --> <xs:element name="testing" type="TestingType" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType> <!--Record. --> <xs:element name="testing" type="TestingType" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType> <!-- Values for Testing mode attached topolicy --> <xs:simpleType name="TestingType"> <xs:restriction base="xs:string"> <xs:enumeration value="n"/> <xs:enumeration value="y"/> </xs:restriction> </xs:simpleType> <!--policy. --> <xs:simpleType name="TestingType"> <xs:restriction base="xs:string"> <xs:enumeration value="n"/> <xs:enumeration value="y"/> </xs:restriction> </xs:simpleType> <!-- The DMARC-aligned authentication result.--> <xs:simpleType name="DMARCResultType"> <xs:restriction base="xs:string"> <xs:enumeration value="pass"/> <xs:enumeration value="fail"/> </xs:restriction> </xs:simpleType> <!----> <xs:simpleType name="DMARCResultType"> <xs:restriction base="xs:string"> <xs:enumeration value="pass"/> <xs:enumeration value="fail"/> </xs:restriction> </xs:simpleType> <!-- Reasons that may affect DMARC disposition or execution.--> <xs:simpleType name="PolicyOverrideType"> <xs:restriction base="xs:string"> <xs:enumeration value="local_policy"/> <xs:enumeration value="mailing_list"/> <xs:enumeration value="other"/> <xs:enumeration value="policy_test_mode"/> <xs:enumeration value="trusted_forwarder"/> </xs:restriction> </xs:simpleType> <!----> <xs:simpleType name="PolicyOverrideType"> <xs:restriction base="xs:string"> <xs:enumeration value="local_policy"/> <xs:enumeration value="mailing_list"/> <xs:enumeration value="other"/> <xs:enumeration value="policy_test_mode"/> <xs:enumeration value="trusted_forwarder"/> </xs:restriction> </xs:simpleType> <!-- Override reason consists of pre-defined override type and free-text comment.--> <xs:complexType name="PolicyOverrideReason"> <xs:all> <xs:element name="type" type="PolicyOverrideType" minOccurs="1" maxOccurs="1"/> <xs:element name="comment" type="langAttrString" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType> <!----> <xs:complexType name="PolicyOverrideReason"> <xs:all> <xs:element name="type" type="PolicyOverrideType" minOccurs="1" maxOccurs="1"/> <xs:element name="comment" type="langAttrString" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType> <!-- Taking into account everything else in the record, the results of applying DMARC. If alignment fails and the policy applied does not match the domain's configured policy, the reason element MUST bespecified --> <xs:complexType name="PolicyEvaluatedType"> <xs:sequence> <xs:element name="disposition" type="ActionDispositionType" minOccurs="1" maxOccurs="1"/> <xs:element name="dkim" type="DMARCResultType" minOccurs="1" maxOccurs="1"/> <xs:element name="spf" type="DMARCResultType" minOccurs="1" maxOccurs="1"/> <xs:element name="reason" type="PolicyOverrideReason" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="RowType"> <xs:all> <!--specified. --> <xs:complexType name="PolicyEvaluatedType"> <xs:sequence> <xs:element name="disposition" type="ActionDispositionType" minOccurs="1" maxOccurs="1"/> <xs:element name="dkim" type="DMARCResultType" minOccurs="1" maxOccurs="1"/> <xs:element name="spf" type="DMARCResultType" minOccurs="1" maxOccurs="1"/> <xs:element name="reason" type="PolicyOverrideReason" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="RowType"> <xs:all> <!-- The connecting IP. IPv4address or IPv6address as defined in RFC3986 section 3.2.2 --> <xs:element name="source_ip" type="xs:string" minOccurs="1" maxOccurs="1"/> <!--3986, Section 3.2.2. --> <xs:element name="source_ip" type="xs:string" minOccurs="1" maxOccurs="1"/> <!-- The number of messages for which the PolicyEvaluatedType was applied.--> <xs:element name="count" type="xs:integer" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="count" type="xs:integer" minOccurs="1" maxOccurs="1"/> <!-- The DMARC disposition applied to matching messages.--> <xs:element name="policy_evaluated" type="PolicyEvaluatedType" minOccurs="1" maxOccurs="1"/> </xs:all> </xs:complexType> <xs:complexType name="IdentifierType"> <xs:all> <!----> <xs:element name="policy_evaluated" type="PolicyEvaluatedType" minOccurs="1" maxOccurs="1"/> </xs:all> </xs:complexType> <xs:complexType name="IdentifierType"> <xs:all> <!-- The RFC5322.From domain.--> <xs:element name="header_from" type="xs:string" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="header_from" type="xs:string" minOccurs="1" maxOccurs="1"/> <!-- The RFC5321.MailFromdomain --> <xs:element name="envelope_from" type="xs:string" minOccurs="0" maxOccurs="1"/> <!--domain. --> <xs:element name="envelope_from" type="xs:string" minOccurs="0" maxOccurs="1"/> <!-- The envelope recipient domain.--> <xs:element name="envelope_to" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType> <!----> <xs:element name="envelope_to" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType> <!-- DKIM verificationresult,result; see RFC86018601, Section 2.7.1.--> <xs:simpleType name="DKIMResultType"> <xs:restriction base="xs:string"> <xs:enumeration value="none"/> <xs:enumeration value="pass"/> <xs:enumeration value="fail"/> <xs:enumeration value="policy"/> <xs:enumeration value="neutral"/> <xs:enumeration value="temperror"/> <xs:enumeration value="permerror"/> </xs:restriction> </xs:simpleType> <xs:complexType name="DKIMAuthResultType"> <xs:all> <!----> <xs:simpleType name="DKIMResultType"> <xs:restriction base="xs:string"> <xs:enumeration value="none"/> <xs:enumeration value="pass"/> <xs:enumeration value="fail"/> <xs:enumeration value="policy"/> <xs:enumeration value="neutral"/> <xs:enumeration value="temperror"/> <xs:enumeration value="permerror"/> </xs:restriction> </xs:simpleType> <xs:complexType name="DKIMAuthResultType"> <xs:all> <!-- The"d=""d=" tag in the signature.--> <xs:element name="domain" type="xs:string" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="domain" type="xs:string" minOccurs="1" maxOccurs="1"/> <!-- The"s=""s=" tag in the signature.--> <xs:element name="selector" type="xs:string" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="selector" type="xs:string" minOccurs="1" maxOccurs="1"/> <!-- The DKIM verification result.--> <xs:element name="result" type="DKIMResultType" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="result" type="DKIMResultType" minOccurs="1" maxOccurs="1"/> <!-- Any extra information (e.g., from Authentication-Results).--> <xs:element name="human_result" type="langAttrString" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType> <!----> <xs:element name="human_result" type="langAttrString" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType> <!-- SPF domain scope.--> <xs:simpleType name="SPFDomainScope"> <xs:restriction base="xs:string"> <xs:enumeration value="mfrom"/> </xs:restriction> </xs:simpleType> <!----> <xs:simpleType name="SPFDomainScope"> <xs:restriction base="xs:string"> <xs:enumeration value="mfrom"/> </xs:restriction> </xs:simpleType> <!-- SPF verificationresult,result; see RFC86018601, Section 2.7.2.--> <xs:simpleType name="SPFResultType"> <xs:restriction base="xs:string"> <xs:enumeration value="none"/> <xs:enumeration value="pass"/> <xs:enumeration value="fail"/> <xs:enumeration value="softfail"/> <xs:enumeration value="policy"/> <xs:enumeration value="neutral"/> <xs:enumeration value="temperror"/> <xs:enumeration value="permerror"/> </xs:restriction> </xs:simpleType> <xs:complexType name="SPFAuthResultType"> <xs:all> <!----> <xs:simpleType name="SPFResultType"> <xs:restriction base="xs:string"> <xs:enumeration value="none"/> <xs:enumeration value="pass"/> <xs:enumeration value="fail"/> <xs:enumeration value="softfail"/> <xs:enumeration value="policy"/> <xs:enumeration value="neutral"/> <xs:enumeration value="temperror"/> <xs:enumeration value="permerror"/> </xs:restriction> </xs:simpleType> <xs:complexType name="SPFAuthResultType"> <xs:all> <!-- The checked domain.--> <xs:element name="domain" type="xs:string" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="domain" type="xs:string" minOccurs="1" maxOccurs="1"/> <!-- The scope of the checked domain.--> <xs:element name="scope" type="SPFDomainScope" minOccurs="0" maxOccurs="1"/> <!----> <xs:element name="scope" type="SPFDomainScope" minOccurs="0" maxOccurs="1"/> <!-- The SPF verification result.--> <xs:element name="result" type="SPFResultType" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="result" type="SPFResultType" minOccurs="1" maxOccurs="1"/> <!-- Any extra information (e.g., from Authentication-Results). The information in the field below should be for a person to be provided with additional information that may be useful when debugging SPF authentication issues. This could include broken records, invalid DNS responses, etc.--> <xs:element name="human_result" type="langAttrString" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType> <!----> <xs:element name="human_result" type="langAttrString" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType> <!-- This element contains DKIM and SPF results, uninterpreted with respect to DMARC.--> <xs:complexType name="AuthResultType"> <xs:sequence> <!----> <xs:complexType name="AuthResultType"> <xs:sequence> <!-- There may be zero or more DKIM signatures.--> <xs:element name="dkim" type="DKIMAuthResultType" minOccurs="0" maxOccurs="unbounded"/> <!----> <xs:element name="dkim" type="DKIMAuthResultType" minOccurs="0" maxOccurs="unbounded"/> <!-- There may be zero or one SPF result.--> <xs:element name="spf" type="SPFAuthResultType" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> <!----> <xs:element name="spf" type="SPFAuthResultType" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> <!-- This element contains all the authentication results that were evaluated by the receiving system for the given set of messages.--> <xs:complexType name="RecordType"> <xs:sequence> <xs:element name="row" type="RowType" minOccurs="1" maxOccurs="1"/> <xs:element name="identifiers" type="IdentifierType" minOccurs="1" maxOccurs="1"/> <xs:element name="auth_results" type="AuthResultType" minOccurs="1" maxOccurs="1"/> <!----> <xs:complexType name="RecordType"> <xs:sequence> <xs:element name="row" type="RowType" minOccurs="1" maxOccurs="1"/> <xs:element name="identifiers" type="IdentifierType" minOccurs="1" maxOccurs="1"/> <xs:element name="auth_results" type="AuthResultType" minOccurs="1" maxOccurs="1"/> <!-- Extension at record level--> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="ExtensionType"> <xs:sequence> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <!----> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="ExtensionType"> <xs:sequence> <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <!-- Parent--> <xs:element name="feedback"> <xs:complexType> <xs:sequence> <xs:element name="version" type="xs:decimal" minOccurs="0" maxOccurs="1"/> <xs:element name="report_metadata" type="ReportMetadataType" minOccurs="1" maxOccurs="1"/> <xs:element name="policy_published" type="PolicyPublishedType" minOccurs="1" maxOccurs="1"/> <!----> <xs:element name="feedback"> <xs:complexType> <xs:sequence> <xs:element name="version" type="xs:decimal" minOccurs="0" maxOccurs="1"/> <xs:element name="report_metadata" type="ReportMetadataType" minOccurs="1" maxOccurs="1"/> <xs:element name="policy_published" type="PolicyPublishedType" minOccurs="1" maxOccurs="1"/> <!-- Extension at top level--> <xs:element name="extension" type="ExtensionType" minOccurs="0" maxOccurs="1"/> <!----> <xs:element name="extension" type="ExtensionType" minOccurs="0" maxOccurs="1"/> <!-- One record per (IP, result, IDs Auths) tuples--> <xs:element name="record" type="RecordType" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> </sourcecode>--> <xs:element name="record" type="RecordType" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>]]></sourcecode> </section> <section anchor="sample-report"><name>Sample Report</name> <sourcecodetype="xml"><feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"> <version>1.0</version> <report_metadata> <org_name>Sample Reporter</org_name> <email>report_sender@example-reporter.com</email> <extra_contact_info>...</extra_contact_info> <report_id>3v98abbp8ya9n3va8yr8oa3ya</report_id> <date_range> <begin>302832000</begin> <end>302918399</end> </date_range> <generator>Exampletype="xml"><![CDATA[ <feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"> <version>1.0</version> <report_metadata> <org_name>Sample Reporter</org_name> <email>report_sender@example-reporter.com</email> <extra_contact_info>...</extra_contact_info> <report_id>3v98abbp8ya9n3va8yr8oa3ya</report_id> <date_range> <begin>302832000</begin> <end>302918399</end> </date_range> <generator>Example DMARC Aggregate Reporterv1.2</generator> </report_metadata> <policy_published> <domain>example.com</domain> <p>quarantine</p> <sp>none</sp> <np>none</np> <testing>n</testing> <discovery_method>treewalk</discovery_method> </policy_published> <record> <row> <source_ip>192.0.2.123</source_ip> <count>123</count> <policy_evaluated> <disposition>pass</disposition> <dkim>pass</dkim> <spf>fail</spf> </policy_evaluated> </row> <identifiers> <envelope_from>example.com</envelope_from> <header_from>example.com</header_from> </identifiers> <auth_results> <dkim> <domain>example.com</domain> <result>pass</result> <selector>abc123</selector> </dkim> <spf> <domain>example.com</domain> <result>fail</result> </spf> </auth_results> </record> </feedback> </sourcecode>v1.2</generator> </report_metadata> <policy_published> <domain>example.com</domain> <p>quarantine</p> <sp>none</sp> <np>none</np> <testing>n</testing> <discovery_method>treewalk</discovery_method> </policy_published> <record> <row> <source_ip>192.0.2.123</source_ip> <count>123</count> <policy_evaluated> <disposition>pass</disposition> <dkim>pass</dkim> <spf>fail</spf> </policy_evaluated> </row> <identifiers> <envelope_from>example.com</envelope_from> <header_from>example.com</header_from> </identifiers> <auth_results> <dkim> <domain>example.com</domain> <result>pass</result> <selector>abc123</selector> </dkim> <spf> <domain>example.com</domain> <result>fail</result> </spf> </auth_results> </record> </feedback>]]></sourcecode> </section> <section anchor="differences-from-rfc7489"><name>Differences fromRFC7489</name> <t>ARFC 7489</name> <t>Here is a bulleted list of some of the more noticeable/important differences between DMARC <xreftarget="RFC7489"></xref>target="RFC7489"/> and this document:</t> <ulspacing="compact">spacing="normal"> <li>Many elements of the defining XSD have been clarified, which means the structure of the report should be more consistent</li> <li>The report identifier has more structure</li> <li>Clarification provided about the number of domains to be addressed per report</li> <li>The addition of extensions as part of the report structure</li> <li>PSD is now included as part of the specification</li> <li>Selector is now required when reporting a DKIM signature</li> </ul> <t>Furthermore, the original DMARC specification was contained within a singledocument,document: <xreftarget="RFC7489"></xref>.target="RFC7489"/>. The original document has been split into threedocuments, DMARCbisdocuments: <xreftarget="I-D.ietf-dmarc-dmarcbis"></xref>,target="RFC9989"/>, this document, andDMARCbis Failure Reporting<xreftarget="I-D.ietf-dmarc-failure-reporting"></xref>.target="RFC9991"/>. This allows these pieces to potentially be altered in the future without re-opening the entire document, as well as allowing them to move through the IETF process independently.</t><t>Acknowledgements</t></section> <section numbered="false"> <name>Acknowledgements</name> <!--[rfced] FYI - We have alphabetized the names listed in the Acknowledgements section. We believe that was the intent as only two were out of order. Let us know if you prefer the original order. --> <t>Many thanks are deserved to those that helped create this document. Much of the content was created fromthe original<xreftarget="RFC7489"></xref>,target="RFC7489"/> and has now been updated to be more clear and correct some outstanding issues. The IETF DMARC Working Group has spent much time working to finalize this effort, and significant contributions were made bySeth Blank, Todd Herr, Steve Jones, Murray<contact fullname="Seth Blank"/>, <contact fullname="Todd Herr"/>, <contact fullname="Steve Jones"/>, <contact fullname="Scott Kitterman"/>, <contact fullname="Murray S.Kucherawy, Barry Leiba, John Levine, Scott Kitterman, Daniel Kvål, MartijnKucherawy"/>, <contact fullname="Daniel Kvål"/>, <contact fullname="Barry Leiba"/>, <contact fullname="John Levine"/>, <contact fullname="Martijn van derLee, Alessandro Veseley, and Matthäus Wander.</t>Lee"/>, <contact fullname="Alessandro Veseley"/>, and <contact fullname="Matthäus Wander"/>.</t> </section> </back> <!-- [rfced] FYI - We have added expansions for the following abbreviation per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. UUID = Universally Unique Identifier (UUID) --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>