rfc9990.original   rfc9990.txt 
DMARC A. Brotman (ed) Internet Engineering Task Force (IETF) A. Brotman, Ed.
Internet-Draft Comcast, Inc. Request for Comments: 9990 Comcast, Inc.
Obsoletes: 7489 (if approved) 17 March 2025 Obsoletes: 7489 May 2026
Intended status: Standards Track Category: Standards Track
Expires: 18 September 2025 ISSN: 2070-1721
Domain-based Message Authentication, Reporting, and Conformance (DMARC) Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
Aggregate Reporting Aggregate Reporting
draft-ietf-dmarc-aggregate-reporting-32
Abstract Abstract
Domain-based Message Authentication, Reporting, and Conformance Domain-based Message Authentication, Reporting, and Conformance
(DMARC) allows for Domain Owners to request aggregate reports from (DMARC) allows for Domain Owners to request aggregate reports from
receivers. This report is an XML document, and contains extensible receivers. This report is an XML document and contains extensible
elements that allow for other types of data to be specified later. elements that allow for other types of data to be specified later.
The aggregate reports can be submitted by the receiver to the Domain The aggregate reports can be submitted by the receiver to the Domain
Owner's specified destination as declared in the associated DNS Owner's specified destination as declared in the associated DNS
record. record.
Status of This Memo This document obsoletes RFC 7489.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 18 September 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9990.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
1.1.1. Notation . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Notation
1.1.2. DMARC Terminology . . . . . . . . . . . . . . . . . . 3 1.1.2. DMARC Terminology
2. Document Status . . . . . . . . . . . . . . . . . . . . . . . 4 2. Document Status
3. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 4 3. DMARC Feedback
3.1. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 4 3.1. Aggregate Reports
3.1.1. Description of the content XML file . . . . . . . . . 5 3.1.1. Description of the Content of the XML File
3.1.2. Handling Domains in Reports . . . . . . . . . . . . . 14 3.1.2. Handling Domains in Reports
3.1.3. DKIM Signatures in Aggregate Reports . . . . . . . . 14 3.1.3. DKIM Signatures in Aggregate Reports
3.1.4. Unique Identifiers in Aggregate Reporting . . . . . . 14 3.1.4. Unique Identifiers in Aggregate Reporting
3.1.5. Error element . . . . . . . . . . . . . . . . . . . . 15 3.1.5. Error Element
3.1.6. Policy Override Reason . . . . . . . . . . . . . . . 15 3.1.6. Policy Override Reason
3.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Extensions
3.3. Changes in Policy During Reporting Period . . . . . . . . 16 3.3. Changes in Policy During a Reporting Period
3.4. Report Request Discovery . . . . . . . . . . . . . . . . 16 3.4. Report Request Discovery
3.5. Report Delivery . . . . . . . . . . . . . . . . . . . . . 16 3.5. Report Delivery
3.5.1. Definition of Report-ID . . . . . . . . . . . . . . . 17 3.5.1. Definition of Report-ID
3.5.2. Email . . . . . . . . . . . . . . . . . . . . . . . . 17 3.5.2. Email
3.5.3. Other Methods . . . . . . . . . . . . . . . . . . . . 19 3.5.3. Other Methods
3.5.4. Handling of Duplicates . . . . . . . . . . . . . . . 20 3.5.4. Handling of Duplicates
4. Verifying External Destinations . . . . . . . . . . . . . . . 20 4. Verifying External Destinations
5. Extensible Reporting . . . . . . . . . . . . . . . . . . . . 22 5. Extensible Reporting
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations
6.1. Registration request for the DMARC namespace: . . . . . . 24 6.1. Registration for the DMARC Namespace
6.2. Registration request for the DMARC XML schema: . . . . . 24 6.2. Registration for the DMARC XML Schema
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 7. Privacy Considerations
7.1. Report Recipients . . . . . . . . . . . . . . . . . . . . 24 7.1. Report Recipients
7.2. Data Contained Within Reports . . . . . . . . . . . . . . 24 7.2. Data Contained Within Reports
7.3. Feedback Leakage . . . . . . . . . . . . . . . . . . . . 25 7.3. Feedback Leakage
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations
8.1. Report Contents as an Attack . . . . . . . . . . . . . . 26 8.1. Report Content as an Attack
8.2. False Information . . . . . . . . . . . . . . . . . . . . 26 8.2. False Information
8.3. Disclosure of Filtering Information . . . . . . . . . . . 26 8.3. Disclosure of Filtering Information
9. Operational Considerations . . . . . . . . . . . . . . . . . 27 9. Operational Considerations
9.1. Report Generation . . . . . . . . . . . . . . . . . . . . 27 9.1. Report Generation
9.2. Report Evaluation . . . . . . . . . . . . . . . . . . . . 27 9.2. Report Evaluation
9.3. Report Storage . . . . . . . . . . . . . . . . . . . . . 27 9.3. Report Storage
10. Normative References . . . . . . . . . . . . . . . . . . . . 27 10. References
11. Informative References . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References
Appendix A. DMARC XML Schema . . . . . . . . . . . . . . . . . . 30 10.2. Informative References
Appendix B. Sample Report . . . . . . . . . . . . . . . . . . . 37 Appendix A. DMARC XML Schema
Appendix C. Differences from RFC7489 . . . . . . . . . . . . . . 38 Appendix B. Sample Report
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix C. Differences from RFC 7489
Acknowledgements
Author's Address
1. Introduction 1. Introduction
A key component of DMARC [I-D.ietf-dmarc-dmarcbis] (Domain-based A key component of Domain-based Message Authentication, Reporting,
Message Authentication, Reporting, and Conformance) is the ability and Conformance (DMARC) [RFC9989] is the ability for Domain Owners to
for Domain Owners to request that Mail Receivers provide various request that Mail Receivers provide various types of reports. These
types of reports. These reports allow Domain Owners to have insight reports allow Domain Owners to have insight into which IP addresses
into which IP addresses are sending on their behalf, and some insight are sending on their behalf and some insight into whether or not the
into whether or not the volume may be legitimate. volume may be legitimate.
These reports expose information relating to the DMARC policy, as These reports expose information relating to the DMARC policy, as
well as the outcome of SPF (Sender Policy Framework) [RFC7208] & DKIM well as the outcome of Sender Policy Framework (SPF) [RFC7208] and
(DomainKeys Identified Mail) [RFC6376] validation. DomainKeys Identified Mail (DKIM) [RFC6376] validation.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.1.1. Notation 1.1.1. Notation
Certain properties of mail messages described in this document are Certain properties of mail messages described in this document are
referenced using notation found in [RFC5598] (e.g., "RFC5322.From"). referenced using notation found in [RFC5598] (e.g., "RFC5322.From").
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] and [RFC7405]. notation of [RFC5234] and [RFC7405].
1.1.2. DMARC Terminology 1.1.2. DMARC Terminology
There are a number of terms defined in [I-D.ietf-dmarc-dmarcbis] that There are a number of terms defined in [RFC9989] that are used within
are used within this document. Understanding those definitions will this document. Understanding those definitions will aid in reading
aid in reading this document. The terms below are of noted interest: this document. The terms below are of noted interest:
* Author Domain * Author Domain
* DMARC Policy Record * DMARC Policy Record
* Domain Owner * Domain Owner
* Mail Receiver * Mail Receiver
* Organizational Domain * Organizational Domain
* Report Consumer * Report Consumer
2. Document Status 2. Document Status
This document, in part, along with DMARCbis [I-D.ietf-dmarc-dmarcbis] This document, in part, along with [RFC9989] and [RFC9991], obsoletes
DMARCbis Failure Reporting [I-D.ietf-dmarc-failure-reporting], and replaces DMARC [RFC7489].
obsoletes and replaces DMARC [RFC7489].
3. DMARC Feedback 3. DMARC Feedback
Providing Domain Owners with visibility into how Mail Receivers Providing Domain Owners with visibility into how Mail Receivers
implement and enforce the DMARC mechanism in the form of feedback is implement and enforce the DMARC mechanism in the form of feedback is
critical to establishing and maintaining accurate authentication critical to establishing and maintaining accurate authentication
deployments. When Domain Owners can see what effect their policies deployments. When Domain Owners can see what effect their policies
and practices are having, they are better willing and able to use and practices are having, they are better willing and able to use
quarantine and reject policies. quarantine and reject policies.
skipping to change at page 4, line 26 skipping to change at line 168
deployments. When Domain Owners can see what effect their policies deployments. When Domain Owners can see what effect their policies
and practices are having, they are better willing and able to use and practices are having, they are better willing and able to use
quarantine and reject policies. quarantine and reject policies.
3.1. Aggregate Reports 3.1. Aggregate Reports
The DMARC aggregate feedback report is designed to provide Domain The DMARC aggregate feedback report is designed to provide Domain
Owners with precise insight into: Owners with precise insight into:
* authentication results, * authentication results,
* corrective action that needs to be taken by Domain Owners, and * corrective action that needs to be taken by Domain Owners, and
* the effect of Domain Owner DMARC policy on mail streams processed * the effect of Domain Owner DMARC policy on mail streams processed
by Mail Receivers. by Mail Receivers.
Aggregate DMARC feedback provides visibility into real-world mail Aggregate DMARC feedback provides visibility into real-world mail
streams that Domain Owners need in order to make informed decisions streams that Domain Owners need in order to make informed decisions
regarding the publication of a DMARC policy. When Domain Owners know regarding the publication of a DMARC policy. When Domain Owners know
what legitimate mail they are sending, what the authentication what legitimate mail they are sending, what the authentication
results are on that mail, and what forged mail receivers are getting, results are on that mail, and what forged Mail Receivers are getting,
they can make better decisions about the policies they need and the they can make better decisions about the policies they need and the
steps they need to take to enable those policies. When Domain Owners steps they need to take to enable those policies. When Domain Owners
set policies appropriately and understand their effects, Mail set policies appropriately and understand their effects, Mail
Receivers can act on them confidently. Receivers can act on them confidently.
Visibility comes in the form of daily (or more frequent) Mail Visibility comes in the form of daily (or more frequent) feedback
Receiver-originated feedback reports that contain aggregate data on reports that are originated from Mail Receivers and that contain
message streams relevant to the Domain Owner. This information aggregate data on message streams relevant to the Domain Owner. This
includes data about messages that passed DMARC authentication as well information includes data about messages that passed DMARC
as those that did not. authentication as well as those that did not.
A separate report MUST be generated for each DMARC Policy Domain A separate report MUST be generated for each DMARC Policy Domain
encountered during the reporting period. See below for further encountered during the reporting period. See below for further
explanation in Section 3.1.2, "Handling Domains in Reports". explanation in Section 3.1.2 ("Handling Domains in Reports").
The report may include the following data: The report may include the following data:
* The DMARC policy discovered and applied, if any * The DMARC policy discovered and applied, if any
* The selected message disposition * The selected message disposition
* The identifier evaluated by SPF and the SPF result, if any * The identifier evaluated by SPF and the SPF result, if any
* The identifier evaluated by DKIM and the DKIM result, if any * The identifier evaluated by DKIM and the DKIM result, if any
* For both DKIM and SPF, an indication of whether the identifier was * For both DKIM and SPF, an indication of whether the identifier was
in DMARC alignment (see Section 3.2.10 of in DMARC alignment (see Section 3.2.10 of [RFC9989])
[I-D.ietf-dmarc-dmarcbis])
* Sending and receiving domains * Sending and receiving domains
* The number of successful authentications * The number of successful authentications
* The counts of messages based on all messages received, even if * The counts of messages based on all messages received, even if
their delivery is ultimately blocked by other filtering agents. their delivery is ultimately blocked by other filtering agents.
Each report MUST contain data for only one DMARC Policy Domain. A Each report MUST contain data for only one DMARC Policy Domain. A
single report MUST contain data for one policy configuration. If single report MUST contain data for one policy configuration. If
multiple configurations were observed during a single reporting multiple configurations were observed during a single reporting
period, a reporting entity MAY choose to send multiple reports, period, a reporting entity MAY choose to send multiple reports;
otherwise the reporting entity SHOULD note only the final otherwise, the reporting entity SHOULD note only the final
configuration observed during the period. See below for further configuration observed during the period. See below for further
information. information.
3.1.1. Description of the content XML file 3.1.1. Description of the Content of the XML File
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.
The format for these reports is defined in the XML Schema Definition The format for these reports is defined in the XML Schema Definition
(XSD) in Appendix A. The XSD includes the possible values for some (XSD) in Appendix A. The XSD includes the possible values for some
of the elements below. Most of these values have a definition tied of the elements below. Most of these values have a definition tied
to [I-D.ietf-dmarc-dmarcbis]. to [RFC9989].
The format is also described in the following sections. Each section The format is also described in the following sections. Each section
describes a collection of sibling elements in the XML hierarchy. describes a collection of sibling elements in the XML hierarchy.
There are pointers to where in the hierarchy each table fits. There are pointers to where in the hierarchy each table fits.
If a document does not match the the specified format, the document If a document does not match the specified format, the document
evaluator SHOULD discard the report. The evaluator MAY choose to try evaluator SHOULD discard the report. The evaluator MAY choose to try
to utilize some of the data, though if the format is in question, so to utilize some of the data; however, if the format is in question,
may be the data. The report evaluator MAY choose to contact the the data may be as well. The report evaluator MAY choose to contact
report generator so that they may be alerted to an issue with the the report generator so that they may be alerted to an issue with the
report format. report format.
The column "#" specifies how many times an element may appear, this The column "#" specifies how many times an element may appear -- this
is sometimes referred to as multiplicity. The possible values are: is sometimes referred to as multiplicity. The possible values are:
O: OPTIONAL, zero or one element O: OPTIONAL, zero or one element
R: REQUIRED, exactly one element R: REQUIRED, exactly one element
*: OPTIONAL, zero or more elements *: OPTIONAL, zero or more elements
+: REQUIRED, one or more elements +: REQUIRED, one or more elements
Some elements contain text meant for humans and support an optional Some elements contain text meant for humans and support an optional
"lang" attribute whose value indicate the language of its contents. "lang" attribute whose value indicates the language of its contents.
The default value is "en". Elements supporting this optional The default value is "en". Elements supporting this optional
attribute is marked with "[@lang]" at the start of their content attribute are marked with "[@lang]" at the start of their content
description in the following tables. description in the following tables.
3.1.1.1. XML root element 3.1.1.1. XML Root Element
DMARC aggregate feedback reports have the root element "feedback" DMARC aggregate feedback reports have the root element "feedback"
with its XML namespace set to the DMARC namespace. with its XML namespace set to the DMARC namespace.
+==============+===+===========================================+ +==============+===+===========================================+
| Element name | # | Content | | Element name | # | Content |
+==============+===+===========================================+ +==============+===+===========================================+
| feedback | R | First level elements, see Section 3.1.1.2 | | feedback | R | First level elements; see Section 3.1.1.2 |
+--------------+---+-------------------------------------------+ +--------------+---+-------------------------------------------+
Table 1: The XML root element. Table 1: The XML Root Element
3.1.1.2. First Level Elements 3.1.1.2. First Level Elements
The elements in this table MUST appear in the order listed. The elements in this table MUST appear in the order listed.
+==================+===+============================================+ +==================+===+============================================+
| Element name | # | Content | | Element name | # | Content |
+==================+===+============================================+ +==================+===+============================================+
| version | O | MUST have the value 1.0. | | version | O | MUST have the value 1.0. |
+------------------+---+--------------------------------------------+ +------------------+---+--------------------------------------------+
| report_metadata | R | Report generator metadata, see | | report_metadata | R | Report generator metadata; see |
| | | Section 3.1.1.3. | | | | Section 3.1.1.3. |
+------------------+---+--------------------------------------------+ +------------------+---+--------------------------------------------+
| policy_published | R | The DMARC policy configuration | | policy_published | R | The DMARC policy configuration |
| | | observed by the receiving | | | | observed by the receiving |
| | | system, see Section 3.1.1.5. | | | | system; see Section 3.1.1.5. |
+------------------+---+--------------------------------------------+ +------------------+---+--------------------------------------------+
| extension | O | Allows for future | | extension | O | Allows for future |
| | | extensibility, see | | | | extensibility; see |
| | | Section 3.1.1.6 | | | | Section 3.1.1.6. |
+------------------+---+--------------------------------------------+ +------------------+---+--------------------------------------------+
| record | + | Record(s) of the feedback from | | record | + | Record(s) of the feedback from |
| | | the report generator, see | | | | the report generator; see |
| | | Section 3.1.1.7. | | | | Section 3.1.1.7. |
+------------------+---+--------------------------------------------+ +------------------+---+--------------------------------------------+
Table 2: First level elements of the Aggregate Feedback Report. Table 2: First Level Elements of the Aggregate Feedback Report
There MUST be at least one "record" element, they contain data There MUST be at least one "record" element; these elements contain
stating which IP addresses were seen to have delivered messages for data stating that IP addresses were seen to have delivered messages
the Author Domain to the receiving system. For each IP address that for the Author Domain to the receiving system. For each IP address
is being reported, there will be at least one "record" element. that is being reported, there will be at least one "record" element.
3.1.1.3. Report generator metadata 3.1.1.3. Report Generator Metadata
+====================+===+=========================================+ +====================+===+=========================================+
| Element name | # | Content | | Element name | # | Content |
+====================+===+=========================================+ +====================+===+=========================================+
| org_name | R | Name of the Reporting Organization. | | org_name | R | Name of the Reporting Organization. |
+--------------------+---+-----------------------------------------+ +--------------------+---+-----------------------------------------+
| email | R | Contact to use when contacting the | | email | R | Contact to use when contacting the |
| | | Reporting Organization. | | | | Reporting Organization. |
+--------------------+---+-----------------------------------------+ +--------------------+---+-----------------------------------------+
| extra_contact_info | O | [@lang] Additional contact details. | | extra_contact_info | O | [@lang] Additional contact details. |
+--------------------+---+-----------------------------------------+ +--------------------+---+-----------------------------------------+
| report_id | R | Unique Report-ID, see Section 3.5.1. | | report_id | R | Unique Report-ID; see Section 3.5.1. |
+--------------------+---+-----------------------------------------+ +--------------------+---+-----------------------------------------+
| date_range | R | The reporting period, see | | date_range | R | The reporting period; see |
| | | Section 3.1.1.4. | | | | Section 3.1.1.4. |
+--------------------+---+-----------------------------------------+ +--------------------+---+-----------------------------------------+
| error | O | [@lang] Error messages encountered when | | error | O | [@lang] Error messages encountered when |
| | | processing the DMARC Policy Record, see | | | | processing the DMARC Policy Record; see |
| | | Section 3.1.5. | | | | Section 3.1.5. |
+--------------------+---+-----------------------------------------+ +--------------------+---+-----------------------------------------+
| generator | O | The name and version of the report | | generator | O | The name and version of the report |
| | | generator; this can help the Report | | | | generator; this can help the Report |
| | | Consumer find out where to report bugs. | | | | Consumer find out where to report bugs. |
+--------------------+---+-----------------------------------------+ +--------------------+---+-----------------------------------------+
Table 3: Report generator metadata Table 3: Report Generator Metadata
3.1.1.4. Contents of the "date_range" element 3.1.1.4. Contents of the "date_range" Element
The time range in UTC defining the reporting period of this report. This element describes the time range in UTC defining the reporting
period of this report.
+==============+===+================================+ +==============+===+================================+
| Element name | # | Content | | Element name | # | Content |
+==============+===+================================+ +==============+===+================================+
| begin | R | Start of the reporting period. | | begin | R | Start of the reporting period. |
+--------------+---+--------------------------------+ +--------------+---+--------------------------------+
| end | R | End of the reporting period. | | end | R | End of the reporting period. |
+--------------+---+--------------------------------+ +--------------+---+--------------------------------+
Table 4: Contents of the "date_range" element Table 4: Contents of the "date_range" Element
* "begin" and "end" contain the number of seconds since epoch. * "begin" and "end" contain the number of seconds since the epoch.
The "begin" and "end" are meant to denote the reporting period, and The "begin" and "end" elements are meant to denote the reporting
not the first/last observed message from the reporting period. When period and not the first/last observed message from the reporting
generating reports, these reporting periods SHOULD NOT overlap. period. When generating reports, these reporting periods SHOULD NOT
Typically, the reporting period will encompass a single UTC day, overlap. Typically, the reporting period will encompass a single UTC
beginning at 0000UTC. day, beginning at 0000UTC.
3.1.1.5. Contents of the "policy_published" element 3.1.1.5. Contents of the "policy_published" Element
Information on the DMARC Policy Record published for the Author This element provides information on the DMARC Policy Record
Domain. The elements from "p" and onwards contain the discovered or published for the Author Domain. The elements from "p" and onwards
default value for the DMARC policy applied. contain the discovered or default value for the DMARC policy applied.
Unspecified tags have their default values. Unspecified tags have their default values.
+==================+===+=======================================+ +==================+===+=======================================+
| Element name | # | Content | | Element name | # | Content |
+==================+===+=======================================+ +==================+===+=======================================+
| domain | R | The DMARC Policy Domain. | | domain | R | The DMARC Policy Domain. |
+------------------+---+---------------------------------------+ +------------------+---+---------------------------------------+
| discovery_method | O | The method used to discover the DMARC | | discovery_method | O | The method used to discover the DMARC |
| | | Policy Record used during evaluation. | | | | Policy Record used during evaluation. |
+------------------+---+---------------------------------------+ +------------------+---+---------------------------------------+
| p | R | A Domain Owner Assessment Policy. | | p | R | A Domain Owner Assessment Policy. |
+------------------+---+---------------------------------------+ +------------------+---+---------------------------------------+
| sp | O | A Domain Owner Assessment Policy. | | sp | O | A Domain Owner Assessment Policy. |
+------------------+---+---------------------------------------+ +------------------+---+---------------------------------------+
| np | O | A Domain Owner Assessment Policy. | | np | O | A Domain Owner Assessment Policy. |
+------------------+---+---------------------------------------+ +------------------+---+---------------------------------------+
| fo | O | The value for the failure reporting | | fo | O | The value for the failure reporting |
| | | options. | | | | options. |
+------------------+---+---------------------------------------+ +------------------+---+---------------------------------------+
| adkim | O | The DKIM Identifier Alignment mode. | | adkim | O | The DKIM Identifier Alignment mode. |
+------------------+---+---------------------------------------+ +------------------+---+---------------------------------------+
| aspf | O | The SPF Identifier Alignment mode. | | aspf | O | The SPF Identifier Alignment mode. |
+------------------+---+---------------------------------------+ +------------------+---+---------------------------------------+
| testing | O | The value of the "t" tag. | | testing | O | The value of the "t" tag. |
+------------------+---+---------------------------------------+ +------------------+---+---------------------------------------+
Table 5: Contents of the "policy_published" element Table 5: Contents of the "policy_published" Element
* "discovery_method" can have the value "psl" or "treewalk", where * "discovery_method" can have the value "psl" or "treewalk", where
"psl" is the method from [RFC7489] and "treewalk" is described in "psl" is the method from [RFC7489] and "treewalk" is described in
[I-D.ietf-dmarc-dmarcbis]. [RFC9989].
* Many of the items above (p, sp, etc.) are defined in the * Many of the items above (p, sp, etc.) are defined in [RFC9989].
[I-D.ietf-dmarc-dmarcbis] document.
3.1.1.6. Contents of the "extension" element 3.1.1.6. Contents of the "extension" Element
Use of extensions may cause elements to be added here. These Use of extensions may cause elements to be added here. These
elements MUST be namespaced. elements MUST be namespaced.
+==========================+===+==========================+ +==========================+===+==========================+
| Element name | # | Content | | Element name | # | Content |
+==========================+===+==========================+ +==========================+===+==========================+
| <any namespaced element> | * | File level elements | | <any namespaced element> | * | File level elements |
| | | defined by an extension. | | | | defined by an extension. |
+--------------------------+---+--------------------------+ +--------------------------+---+--------------------------+
Table 6: Contents of the "extension" element
* "<any namespaced element>" Table 6: Contents of the "extension" Element
Zero or more elements in the namespace of the related extension * "<any namespaced element>": Zero or more elements in the namespace
declared in the XML root element. of the related extension declared in the XML root element.
3.1.1.7. Contents of the "record" element 3.1.1.7. Contents of the "record" Element
The report MUST contain record(s) stating which IP addresses were The report MUST contain one or more records stating which IP
seen to have delivered messages for the Author Domain to the addresses were seen to have delivered messages for the Author Domain
receiving system. For each IP address that is being reported, there to the receiving system. For each IP address that is being reported,
will be at least one "record" element. there will be at least one "record" element.
This element contains all the authentication results that were This element contains all the authentication results that were
evaluated by the receiving system for the given set of messages. evaluated by the receiving system for the given set of messages.
An unlimited number of "record" elements may be specified. An unlimited number of "record" elements may be specified.
Use of extensions may cause other elements to be added to the end of Use of extensions may cause other elements to be added to the end of
the record, such elements MUST be namespaced. the record; such elements MUST be namespaced.
One record per (IP, result, authenitication identifiers) tuples. One record per (IP, result, authentication identifiers) tuples.
The elements in this table MUST appear in the order listed. The elements in this table MUST appear in the order listed.
+==============+===+============================================+ +==============+===+============================================+
| Element name | # | Content | | Element name | # | Content |
+==============+===+============================================+ +==============+===+============================================+
| row | R | See Section 3.1.1.8. | | row | R | See Section 3.1.1.8. |
+--------------+---+--------------------------------------------+ +--------------+---+--------------------------------------------+
| identifiers | R | The data that was used to apply policy for | | identifiers | R | The data that was used to apply policy for |
| | | the given "row", see Section 3.1.1.10. | | | | the given "row"; see Section 3.1.1.10. |
+--------------+---+--------------------------------------------+ +--------------+---+--------------------------------------------+
| auth_results | R | The data related to authenticating the | | auth_results | R | The data related to authenticating the |
| | | messages associated with this sending IP | | | | messages associated with this sending IP |
| | | address, see Section 3.1.1.11. | | | | address; see Section 3.1.1.11. |
+--------------+---+--------------------------------------------+ +--------------+---+--------------------------------------------+
| <any | * | Record level elements defined by an | | <any | * | Record level elements defined by an |
| namespaced | | extension. | | namespaced | | extension. |
| element> | | | | element> | | |
+--------------+---+--------------------------------------------+ +--------------+---+--------------------------------------------+
Table 7: Contents of the "record" element
* "<any namespaced element>" Table 7: Contents of the "record" Element
Zero or more elements in the namespace of the related extension * "<any namespaced element>": Zero or more elements in the namespace
declared in the XML root element. of the related extension declared in the XML root element.
3.1.1.8. Contents of the "row" element 3.1.1.8. Contents of the "row" Element
A "row" element contains the details of the connecting system, and A "row" element contains the details of the connecting system, and
how many mails were received from it, for the particular combination how many mail messages were received from it, for the particular
of the policy evaluated. combination of the policy evaluated.
+==================+===+=======================================+ +==================+===+=======================================+
| Element name | # | Content | | Element name | # | Content |
+==================+===+=======================================+ +==================+===+=======================================+
| source_ip | R | The connecting IP address. | | source_ip | R | The connecting IP address. |
| | | IPv4address or IPv6address as defined | | | | IPv4address or IPv6address as defined |
| | | in Section 3.2.2 of [RFC3986] | | | | in Section 3.2.2 of [RFC3986]. |
+------------------+---+---------------------------------------+ +------------------+---+---------------------------------------+
| count | R | Number of messages for which the | | count | R | Number of messages for which the |
| | | "policy_evaluated" was applied. | | | | "policy_evaluated" was applied. |
+------------------+---+---------------------------------------+ +------------------+---+---------------------------------------+
| policy_evaluated | R | The DMARC disposition applied to | | policy_evaluated | R | The DMARC disposition applied to |
| | | matching messages, see | | | | matching messages; see |
| | | Section 3.1.1.9. | | | | Section 3.1.1.9. |
+------------------+---+---------------------------------------+ +------------------+---+---------------------------------------+
Table 8: Contents of the "row" element Table 8: Contents of the "row" Element
3.1.1.9. Contents of the "policy_evaluated" element 3.1.1.9. Contents of the "policy_evaluated" Element
The results of applying the DMARC policy. If alignment fails and the This element describes the results of applying the DMARC policy. If
policy applied does not match the DMARC Policy Domain's configured alignment fails and the policy applied does not match the DMARC
policy, the "reason" element MUST be included. Policy Domain's configured policy, the "reason" element MUST be
included.
The elements in this table MUST appear in the order listed. The elements in this table MUST appear in the order listed.
+==============+===+==========================================+ +==============+===+==========================================+
| Element name | # | Content | | Element name | # | Content |
+==============+===+==========================================+ +==============+===+==========================================+
| disposition | R | The result of applying the DMARC policy. | | disposition | R | The result of applying the DMARC policy. |
+--------------+---+------------------------------------------+ +--------------+---+------------------------------------------+
| dkim | R | The result of the DKIM DMARC Identifier | | dkim | R | The result of the DKIM DMARC Identifier |
| | | alignment test. | | | | Alignment test. |
+--------------+---+------------------------------------------+ +--------------+---+------------------------------------------+
| spf | R | The result of the SPF DMARC Identifier | | spf | R | The result of the SPF DMARC Identifier |
| | | alignment test. | | | | Alignment test. |
+--------------+---+------------------------------------------+ +--------------+---+------------------------------------------+
| reason | * | Policy override reason, see | | reason | * | Policy override reason; see |
| | | Section 3.1.1.14. | | | | Section 3.1.1.14. |
+--------------+---+------------------------------------------+ +--------------+---+------------------------------------------+
Table 9: Contents of the "policy_evaluated" element Table 9: Contents of the "policy_evaluated" Element
* "spf" and "dkim" MUST be the evaluated values as they relate to * "spf" and "dkim" MUST be the evaluated values as they relate to
DMARC, not the values the receiver may have used when overriding DMARC, not the values the receiver may have used when overriding
the policy. the policy.
* "reason" elements are meant to include any notes the reporter * "reason" elements are meant to contain any notes the reporter
might want to include as to why the "disposition" policy does not might want to include as to why the "disposition" policy does not
match the "policy_published", such as a local policy override. match the "policy_published", such as a local policy override.
3.1.1.10. Contents of the "identifiers" element 3.1.1.10. Contents of the "identifiers" Element
+===============+===+===========================================+ +===============+===+===========================================+
| Element name | # | Content | | Element name | # | Content |
+===============+===+===========================================+ +===============+===+===========================================+
| header_from | R | The RFC5322.From domain from the message. | | header_from | R | The RFC5322.From domain from the message. |
+---------------+---+-------------------------------------------+ +---------------+---+-------------------------------------------+
| envelope_from | O | The RFC5321.MailFrom domain that the SPF | | envelope_from | O | The RFC5321.MailFrom domain that the SPF |
| | | check has been applied to. | | | | check has been applied to. |
+---------------+---+-------------------------------------------+ +---------------+---+-------------------------------------------+
| envelope_to | O | The RFC5321.RcptTo domain from the | | envelope_to | O | The RFC5321.RcptTo domain from the |
| | | message. | | | | message. |
+---------------+---+-------------------------------------------+ +---------------+---+-------------------------------------------+
Table 10: Contents of the "identifiers" element Table 10: Contents of the "identifiers" Element
* "envelope_from" MAY be existing but empty if the message had a * "envelope_from" MAY exist but be empty if the message had a null
null reverse-path (see Section 4.5.5 of [RFC5321]). reverse-path (see Section 4.5.5 of [RFC5321]).
3.1.1.11. Contents of the "auth_results" element 3.1.1.11. Contents of the "auth_results" Element
Contains DKIM and SPF results, uninterpreted with respect to DMARC. This element contains DKIM and SPF results, uninterpreted with
respect to DMARC.
If validation is attempted for any DKIM signature, the results MUST If validation is attempted for any DKIM signature, the results MUST
be included in the report (within reason, see Section 3.1.3, "DKIM be included in the report (within reason; see Section 3.1.3 ("DKIM
Signatures in Aggregate Reports", below for handling numerous Signatures in Aggregate Reports") below for handling numerous
signatures). signatures).
The elements in this table MUST appear in the order listed. The elements in this table MUST appear in the order listed.
+==============+===+=============================+ +==============+===+=============================+
| Element name | # | Content | | Element name | # | Content |
+==============+===+=============================+ +==============+===+=============================+
| dkim | * | DKIM authentication result, | | dkim | * | DKIM authentication result; |
| | | see Section 3.1.1.12. | | | | see Section 3.1.1.12. |
+--------------+---+-----------------------------+ +--------------+---+-----------------------------+
| spf | O | SPF authentication result, | | spf | O | SPF authentication result; |
| | | see Section 3.1.1.13. | | | | see Section 3.1.1.13. |
+--------------+---+-----------------------------+ +--------------+---+-----------------------------+
Table 11: Contents of the "auth_results" element Table 11: Contents of the "auth_results" Element
3.1.1.12. Contents of the "dkim" element 3.1.1.12. Contents of the "dkim" Element
+==============+===+===============================================+ +==============+===+===============================================+
| Element name | # | Content | | Element name | # | Content |
+==============+===+===============================================+ +==============+===+===============================================+
| domain | R | The domain that was used during validation | | domain | R | The domain that was used during validation |
| | | (the "d=" tag in the signature). | | | | (the "d=" tag in the signature). |
+--------------+---+-----------------------------------------------+ +--------------+---+-----------------------------------------------+
| selector | R | The selector that was used during validation | | selector | R | The selector that was used during validation |
| | | (the "s=" tag in the signature). | | | | (the "s=" tag in the signature). |
+--------------+---+-----------------------------------------------+ +--------------+---+-----------------------------------------------+
| result | R | DKIM verification result, see below. | | result | R | DKIM verification result; see below. |
+--------------+---+-----------------------------------------------+ +--------------+---+-----------------------------------------------+
| human_result | O | [@lang] More descriptive information to the | | human_result | O | [@lang] More descriptive information to the |
| | | Domain Owner relating to evaluation failures. | | | | Domain Owner relating to evaluation failures. |
+--------------+---+-----------------------------------------------+ +--------------+---+-----------------------------------------------+
Table 12: Contents of the "dkim" element Table 12: Contents of the "dkim" Element
* "result" is a lower-case string where the value is one of the * "result" is a lowercase string where the value is one of the
results defined in Section 2.7.1 of [RFC8601]. results defined in Section 2.7.1 of [RFC8601].
3.1.1.13. Contents of the "spf" element 3.1.1.13. Contents of the "spf" Element
Only the "MAIL FROM" identity (see Section 2.4 of [RFC7208]) is used Only the "MAIL FROM" identity (see Section 2.4 of [RFC7208]) is used
in DMARC. in DMARC.
+==============+===+===============================================+ +==============+===+===============================================+
| Element name | # | Content | | Element name | # | Content |
+==============+===+===============================================+ +==============+===+===============================================+
| domain | R | The domain that was used during validation. | | domain | R | The domain that was used during validation. |
+--------------+---+-----------------------------------------------+ +--------------+---+-----------------------------------------------+
| scope | O | The source of the domain used during | | scope | O | The source of the domain used during |
| | | validation. | | | | validation. |
+--------------+---+-----------------------------------------------+ +--------------+---+-----------------------------------------------+
| result | R | SPF verification result, see below. | | result | R | SPF verification result; see below. |
+--------------+---+-----------------------------------------------+ +--------------+---+-----------------------------------------------+
| human_result | O | [@lang] More descriptive information to the | | human_result | O | [@lang] More descriptive information to the |
| | | Domain Owner relating to evaluation failures. | | | | Domain Owner relating to evaluation failures. |
+--------------+---+-----------------------------------------------+ +--------------+---+-----------------------------------------------+
Table 13: Contents of the "spf" element Table 13: Contents of the "spf" Element
* The only valid value for the "scope" element is "mfrom". * The only valid value for the "scope" element is "mfrom".
* "result" is a lower-case string where the value is one of the * "result" is a lowercase string where the value is one of the
results defined in Section 2.7.2 of [RFC8601]. results defined in Section 2.7.2 of [RFC8601].
3.1.1.14. Contents of the "reason" element 3.1.1.14. Contents of the "reason" Element
The policy override reason consists of a pre-defined override type The policy override reason consists of a pre-defined override type
and free-text comment, see Section 3.1.6 and free-text comment; see Section 3.1.6.
+==============+===+============================================+ +==============+===+============================================+
| Element name | # | Content | | Element name | # | Content |
+==============+===+============================================+ +==============+===+============================================+
| type | R | The reason the DMARC policy was overridden | | type | R | The reason the DMARC policy was overridden |
+--------------+---+--------------------------------------------+ +--------------+---+--------------------------------------------+
| comment | O | [@lang] Further details, if available. | | comment | O | [@lang] Further details, if available. |
+--------------+---+--------------------------------------------+ +--------------+---+--------------------------------------------+
Table 14: Contents of the "reason" element Table 14: Contents of the "reason" Element
3.1.2. Handling Domains in Reports 3.1.2. Handling Domains in Reports
In the same report, there MUST be a single DMARC Policy Domain, In the same report, there MUST be a single DMARC Policy Domain,
though there could be multiple RFC5322.From Domains. Each though there could be multiple RFC5322.From domains. Each
RFC5322.From domain will create its own "record" within the report. RFC5322.From domain will create its own "record" within the report.
Consider the case where there are three domains with traffic volume Consider the case where there are three domains with traffic volume
to report: example.com, foo.example.com, and bar.example.com. There to report: example.com, foo.example.com, and bar.example.com. There
will be explicit DMARC Policy Records for example.com and will be explicit DMARC Policy Records for example.com and
bar.example.com, with distinct policies. There is no explicit DMARC 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 Record for foo.example.com, so it will be reliant on the
policy described for example.com. For a report period, there would policy described for example.com. For a report period, there would
now be two reports. now be two reports.
The first will be for bar.example.com, and contain only one "record",
for bar.example.com. The second report would be for example.com and The first report will be for bar.example.com and contain only one
contain multiple "record" elements, one for example.com and one for "record", for bar.example.com. The second report will be for
foo.example.com (and extensibly, other "record" elements for example.com and will contain multiple "record" elements, one for
subdomains which likewise did not have an explicit DMARC Policy example.com and one for foo.example.com (and extensibly, other
Record). "record" elements for subdomains that likewise did not have an
explicit DMARC Policy Record).
3.1.3. DKIM Signatures in Aggregate Reports 3.1.3. DKIM Signatures in Aggregate Reports
Within a single message, the possibility exists that there could be Within a single message, the possibility exists that there could be
multiple DKIM signatures. When validation of the message occurs, multiple DKIM signatures. When validation of the message occurs,
some signatures may pass, while some may not. As these pertain to some signatures may pass, while some may not. As these pertain to
DMARC, and especially to aggregate reporting, reporters may not find DMARC, and especially to aggregate reporting, reporters may not find
it clear which DKIM signatures they should include in a report. it clear which DKIM signatures they should include in a report.
Signatures, regardless of outcome, could help the report ingester Signatures, regardless of outcome, could help the report ingester
determine the source of a message. However, there is a preference as determine the source of a message. However, there is a preference as
skipping to change at page 14, line 37 skipping to change at line 647
multiple DKIM signatures. When validation of the message occurs, multiple DKIM signatures. When validation of the message occurs,
some signatures may pass, while some may not. As these pertain to some signatures may pass, while some may not. As these pertain to
DMARC, and especially to aggregate reporting, reporters may not find DMARC, and especially to aggregate reporting, reporters may not find
it clear which DKIM signatures they should include in a report. it clear which DKIM signatures they should include in a report.
Signatures, regardless of outcome, could help the report ingester Signatures, regardless of outcome, could help the report ingester
determine the source of a message. However, there is a preference as determine the source of a message. However, there is a preference as
to which signatures are included. to which signatures are included.
1. A signature that passes DKIM, in strict alignment with the 1. A signature that passes DKIM, in strict alignment with the
RFC5322.From domain RFC5322.From domain
2. A signature that passes DKIM, in relaxed alignment with the 2. A signature that passes DKIM, in relaxed alignment with the
RFC5322.From domain RFC5322.From domain
3. Any other DKIM signatures that pass 3. Any other DKIM signatures that pass
4. DKIM signatures that do not pass 4. DKIM signatures that do not pass
A report SHOULD contain no more than 100 signatures for a given A report SHOULD contain no more than 100 signatures for a given
"row", in decreasing priority. "row", in decreasing priority.
3.1.4. Unique Identifiers in Aggregate Reporting 3.1.4. Unique Identifiers in Aggregate Reporting
There are a few places where a unique identifier is specified as part 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 of the body of the report, the subject, and so on. These unique
identifiers should be consistent per each report. Specified below, identifiers should be consistent per each report. Specified below,
the reader will see a "Report-ID" and "unique-id". These are the the reader will see a "Report-ID" and "unique-id". These are the
fields that MUST be identical when used. fields that MUST be identical when used.
3.1.5. Error element 3.1.5. Error Element
A few examples of information contained within the "error" Here are a few examples of information contained within the "error"
element(s): element(s):
* DMARC Policy Record evaluation errors (invalid "rua" or "sp", * DMARC Policy Record evaluation errors (invalid "rua", "sp", etc.)
etc.)
* Multiple DMARC Policy Records at a given location * Multiple DMARC Policy Records at a given location
Be mindful that the "error" element is an unbounded string, but Be mindful that the "error" element is an unbounded string but should
should not contain an extremely large body. Provide enough not contain an extremely large body. Provide enough information to
information to assist the Domain Owner with understanding some issues assist the Domain Owner with understanding some issues with their
with their authentication or DMARC Policy Record. authentication or DMARC Policy Record.
3.1.6. Policy Override Reason 3.1.6. Policy Override Reason
The "reason" element, indicating an override of the DMARC policy, The "reason" element, indicating an override of the DMARC policy,
consists of a mandatory "type" element and an optional "comment" consists of a mandatory "type" element and an optional "comment"
element. The "type" element MUST have one of the pre-defined values element. The "type" element MUST have one of the pre-defined values
listed below. The "comment" element is an unbounded string for listed below. The "comment" element is an unbounded string for
providing further details. providing further details.
Possible values for the policy override type: Possible values for the policy override type:
"local_policy": The Mail Receiver's local policy exempted the message "local_policy": The Mail Receiver's local policy exempted the
from being subjected to the Domain Owner's requested policy action. message from being subjected to the Domain Owner's requested
policy action.
"mailing_list": Local heuristics determined that the message arrived "mailing_list": Local heuristics determined that the message arrived
via a mailing list, and thus authentication of the original message via a mailing list, and thus authentication of the original
was not expected to succeed. message was not expected to succeed.
"other": Some policy exception not covered by the other entries in "other": Some policy exception not covered by the other entries in
this list occurred. Additional detail can be found in the "comment" this list occurred. Additional details can be found in the
element. "comment" element.
"policy_test_mode": The message was exempted from application of "policy_test_mode": The message was exempted from application of
policy by the testing mode ("t" tag) in the DMARC Policy Record. policy by the testing mode ("t" tag) in the DMARC Policy Record.
"trusted_forwarder": Message authentication failure was anticipated "trusted_forwarder": Message authentication failure was anticipated
by other evidence linking the message to a locally maintained list of by other evidence linking the message to a locally maintained list
known and trusted forwarders. of known and trusted forwarders.
3.2. Extensions 3.2. Extensions
The document format supports optional elements for extensions. The The document format supports optional elements for extensions. The
absence or existence of this section SHOULD NOT create an error when absence or existence of this section SHOULD NOT create an error when
processing reports. This will be covered in a separate section, processing reports. This will be covered in Section 5 ("Extensible
Extensible Reporting, Section 5. Reporting").
3.3. Changes in Policy During Reporting Period 3.3. Changes in Policy During a Reporting Period
Note that Domain Owners or their agents may change the published Note that Domain Owners or their agents may change the published
DMARC Policy Record for a domain or subdomain at any time. From a DMARC Policy Record for a domain or subdomain at any time. From a
Mail Receiver's perspective, this will occur during a reporting Mail Receiver's perspective, this will occur during a reporting
period and may be noticed during that period, at the end of that period and may be noticed during that period, at the end of that
period when reports are generated, or during a subsequent reporting period when reports are generated, or during a subsequent reporting
period, all depending on the Mail Receiver's implementation. Under period, all depending on the Mail Receiver's implementation. Under
these conditions, it is possible that a Mail Receiver could do any of these conditions, it is possible that a Mail Receiver could do any of
the following: the following:
* generate for such a reporting period a single aggregate report * generate for such a reporting period a single aggregate report
that includes message dispositions based on the old policy, or a that includes message dispositions based on the old policy, or a
mix of the two policies, even though the report only contains a mix of the two policies, even though the report only contains a
single "policy_published" element; single "policy_published" element
* generate multiple reports for the same period, one for each * generate multiple reports for the same period, one for each
published policy occurring during the reporting period; published policy occurring during the reporting period
Such policy changes are expected to be infrequent for any given Such policy changes are expected to be infrequent for any given
domain, whereas more stringent policy monitoring requirements on the domain, whereas more stringent policy monitoring requirements on the
Mail Receiver would produce a very large burden at Internet scale. Mail Receiver would produce a very large burden at Internet scale.
Therefore, it is the responsibility of Report Consumers (i.e., Therefore, it is the responsibility of Report Consumers (i.e.,
vendors) and Domain Owners to be aware of this situation and expect vendors) and Domain Owners to be aware of this situation and expect
such mixed reports during the propagation of the new policy to Mail such mixed reports during the propagation of the new policy to Mail
Receivers. Receivers.
3.4. Report Request Discovery 3.4. Report Request Discovery
A Mail Receiver discovers reporting requests when it looks up a DMARC A Mail Receiver discovers reporting requests when it looks up a DMARC
Policy Record that corresponds to an RFC5322.From domain on received Policy Record that corresponds to an RFC5322.From domain on received
mail. The presence of the "rua" tag specifies where to send mail. The presence of the "rua" tag specifies where to send
feedback. feedback.
3.5. Report Delivery 3.5. Report Delivery
The Mail Receiver, after preparing a report, MUST evaluate the The Mail Receiver, after preparing a report, MUST evaluate the
provided reporting URIs (See [I-D.ietf-dmarc-dmarcbis]) in the order provided reporting URIs (see [RFC9989]) in the order given. If any
given. If any of the URIs are malformed, they SHOULD be ignored. An of the URIs are malformed, they SHOULD be ignored. An attempt MUST
attempt MUST be made to deliver an aggregate report to every be made to deliver an aggregate report to every remaining URI, up to
remaining URI, up to the Receiver's limits on supported URIs. the Receiver's limits on supported URIs.
If delivery is not possible because the services advertised by the If delivery is not possible because the services advertised by the
published URIs are not able to accept reports (e.g., the URI refers published URIs are not able to accept reports (e.g., the URI refers
to a service that is unreachable), the Mail Receiver MAY cache that to a service that is unreachable), the Mail Receiver MAY cache that
data and try again later, or MAY discard data that could not be sent. data and try again later or MAY discard data that could not be sent.
Where the URI specified in a "rua" tag does not specify otherwise, a Where the URI specified in a "rua" tag does not specify otherwise, a
Mail Receiver generating a feedback report SHOULD employ a secure Mail Receiver generating a feedback report SHOULD employ a secure
transport mechanism, meaning the report should be delivered over a transport mechanism, meaning the report should be delivered over a
channel employing TLS (SMTP+STARTTLS). channel employing TLS (SMTP+STARTTLS).
3.5.1. Definition of Report-ID 3.5.1. Definition of Report-ID
This identifier MUST be unique among reports to the same domain to This identifier MUST be unique among reports to the same domain to
aid receivers in identifying duplicate reports should they happen. aid receivers in identifying duplicate reports should they happen.
The Report-ID value should be constructed using the following ABNF: The Report-ID value should be constructed using the following ABNF:
ridfmt = (dot-atom-text ["@" dot-atom-text]) ; from RFC 5322 ridfmt = (dot-atom-text ["@" dot-atom-text]) ; from RFC 5322
ridtxt = ("<" ridfmt ">") / ridfmt ridtxt = ("<" ridfmt ">") / ridfmt
The format specified here is not very strict as the key goal is The format specified here is not very strict, as the key goal is
uniqueness. In order to create this uniqueness, the Mail Receiver uniqueness. In order to create this uniqueness, the Mail Receiver
may wish to use elements such as the receiving domain, sending may wish to use elements such as the receiving domain, the sending
domain, and a timestamp in combination. An example string might be domain, and a timestamp in combination. An example string might be
"1721054318-example.com@example.org". An alternate could use a date "1721054318-example.com@example.org". An alternate could use a date
string such as "2024-03-27_example.com@example.org". string such as "2024-03-27_example.com@example.org".
3.5.2. Email 3.5.2. Email
The message generated by the Mail Receiver MUST be a [RFC5322] The message generated by the Mail Receiver MUST be a [RFC5322]
message formatted per [RFC2045]. The aggregate report itself MUST be message formatted per [RFC2045]. The aggregate report itself MUST be
included in one of the parts of the message, as an attachment with a included in one of the parts of the message, as an attachment with a
corresponding media type from below. A human-readable annotation MAY corresponding media type from below. A human-readable annotation MAY
be included as a body part (with a human-friendly content-type, such be included as a body part (with a human-friendly content-type, such
as "text/plain" or "text/html"). as "text/plain" or "text/html").
The aggregate data MUST be an XML file that SHOULD be subjected to The aggregate data MUST be an XML file that SHOULD be subjected to
GZIP [RFC1952] compression. Declining to apply compression can cause GZIP [RFC1952] compression. Declining to apply compression can cause
the report to be too large for a receiver to process (the total the report to be too large for a receiver to process (the total
message size could exceed the receiver SMTP size limit); doing the message size could exceed the receiver SMTP size limit); doing the
compression increases the chances of acceptance of the report at some compression increases the chances of acceptance of the report at some
compute cost. The aggregate data MUST be present using the media compute cost. The aggregate data MUST be present using the media
type "application/gzip" if compressed (see [RFC6713]), and "text/xml" type "application/gzip" if compressed (see [RFC6713]) and "text/xml"
otherwise. The attachment filename MUST be constructed using the otherwise. The attachment filename MUST be constructed using the
following ABNF: following ABNF:
filename = receiver "!" policy-domain "!" begin-timestamp filename = receiver "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension "!" end-timestamp [ "!" unique-id ] "." extension
receiver = domain-name
; imported from RFC 6376
policy-domain = domain-name receiver = domain-name
; imported from RFC 6376
begin-timestamp = 1*DIGIT policy-domain = domain-name
; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained
; in the report
end-timestamp = 1*DIGIT begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970 ; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained ; indicating start of the time range contained
; in the report ; in the report
unique-id = 1*(ALPHA / DIGIT) end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained
; in the report
extension = "xml" / "xml.gz" unique-id = 1*(ALPHA / DIGIT)
extension = "xml" / "xml.gz"
The following primitive tokens that are used but otherwise The following primitive tokens that are used but otherwise
unspecified are taken from the "Core Rules" of [RFC5234]: DIGIT, unspecified are taken from "Core Rules" (Appendix B.1 of [RFC5234]):
ALPHA. DIGIT, ALPHA.
The extension MUST be "xml" for a plain XML file, or "xml.gz" for an The extension MUST be "xml" for a plain XML file or "xml.gz" for an
XML file compressed using GZIP. XML file compressed using GZIP.
"unique-id" allows an optional unique ID generated by the Mail "unique-id" allows an optional unique ID generated by the Mail
Receiver to distinguish among multiple reports generated Receiver to distinguish among multiple reports generated
simultaneously by different sources within the same Domain Owner. A simultaneously by different sources within the same Domain Owner. A
viable option may be to explore UUIDs [RFC9562]. viable option may be to explore Universally Unique Identifiers
(UUIDs) [RFC9562].
If a report generator needs to re-send a report, the system MUST use If a report generator needs to re-send a report, the system MUST use
the same filename as the original report. This would allow the the same filename as the original report. This would allow the
receiver to overwrite the data from the original, or discard second receiver to overwrite the data from the original or discard the
instance of the report. second instance of the report.
For example, this is a sample filename for the gzip file of a report For example, this is a sample filename for the gzip file of a report
to the Domain Owner "example.com" from the Mail Receiver to the Domain Owner "example.com" from the Mail Receiver
"mail.receiver.example": "mail.receiver.example":
mail.receiver.example!example.com!1013662812!1013749130.xml.gz mail.receiver.example!example.com!1013662812!1013749130.xml.gz
No specific MIME message structure is required for the message body. No specific MIME message structure is required for the message body.
It is presumed that the aggregate reporting address will be equipped It is presumed that the aggregate reporting address will be equipped
to extract body parts with the prescribed media type and filename and to extract body parts with the prescribed media type and filename and
ignore the rest. ignore the rest.
Mail streams carrying DMARC feedback data MUST conform to the DMARC Mail streams carrying DMARC feedback data MUST conform to the DMARC
mechanism, thereby resulting in an aligned "pass" (see Section 4.4 of mechanism, thereby resulting in an aligned "pass" (see Section 4.4 of
[I-D.ietf-dmarc-dmarcbis]). This practice minimizes the risk of [RFC9989]). This practice minimizes the risk of Report Consumers
Report Consumers processing fraudulent reports. processing fraudulent reports.
The RFC5322.Subject field for individual report submissions MUST The RFC5322.Subject field for individual report submissions MUST
conform to the following ABNF: conform to the following ABNF:
; FWS is imported from RFC 5322 ; FWS is imported from RFC 5322
dmarc-subject = %s"Report" 1*FWS %s"Domain:" dmarc-subject = %s"Report" 1*FWS %s"Domain:"
1*FWS domain-name 1*FWS ; policy domain 1*FWS domain-name 1*FWS ; policy domain
%s"Submitter:" 1*FWS %s"Submitter:" 1*FWS
domain-name 1*FWS ; report generator domain-name 1*FWS ; report generator
[ %s"Report-ID:" 1*FWS ridtxt ] ; defined above [ %s"Report-ID:" 1*FWS ridtxt ] ; defined above
The first domain-name indicates the DNS domain name about which the The first domain-name indicates the DNS domain name about which the
report was generated. The second domain-name indicates the DNS report was generated. The second domain-name indicates the DNS
domain name representing the Mail Receiver generating the report. domain name representing the Mail Receiver generating the report.
The purpose of the Report-ID: portion of the field is to enable the The purpose of the Report-ID: portion of the field is to enable the
Domain Owner to identify and ignore duplicate reports that might be Domain Owner to identify and ignore duplicate reports that might be
sent by a Mail Receiver. sent by a Mail Receiver.
For instance, this is a possible Subject field for a report to the For instance, this is a possible Subject field for a report to the
Domain Owner "example.com" from the Mail Receiver Domain Owner "example.com" from the Mail Receiver
skipping to change at page 20, line 9 skipping to change at line 903
3.5.3. Other Methods 3.5.3. Other Methods
The specification as written allows for the addition of other The specification as written allows for the addition of other
registered URI schemes to be supported in later versions. registered URI schemes to be supported in later versions.
3.5.4. Handling of Duplicates 3.5.4. Handling of Duplicates
There may be a situation where the report generator attempts to There may be a situation where the report generator attempts to
deliver duplicate information to the receiver. This may manifest as deliver duplicate information to the receiver. This may manifest as
an exact duplicate of the report, or as duplicate information between an exact duplicate of the report or as duplicate information between
two reports. In these situations, the decision of how to handle the two reports. In these situations, the decision of how to handle the
duplicate data lies with the receiver. As noted above, the sender duplicate data lies with the receiver. As noted above, the sender
MUST use the same unique identifiers when sending the report. This MUST use the same unique identifiers when sending the report. This
allows the receiver to better understand when duplicates happen. A allows the receiver to better understand when duplicates happen.
few options on how to handle that duplicate information: Here are a few options on how to handle that duplicate information:
* Reject back to sender, ideally with a permfail error noting the * Reject back to sender, ideally with a permfail error noting the
duplicate receipt duplicate receipt
* Discard upon receipt * Discard upon receipt
* Inspect the contents to evaluate the timestamps and reported data, * Inspect the contents to evaluate the timestamps and reported data,
act as appropriate act as appropriate
* Accept the duplicate data * Accept the duplicate data
When accepting the data, that's likely in a situation where it's not 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 yet noticed or a one-off experience. Long-term duplicate data is not
not ideal. In the situation of a partial time frame overlap, there ideal. In the situation of a partial time frame overlap, there is no
is no clear way to distinguish the impact of the overlap. The clear way to distinguish the impact of the overlap. The receiver
receiver would need to accept or reject the duplicate data in whole. would need to accept or reject the duplicate data in whole.
4. Verifying External Destinations 4. Verifying External Destinations
It is possible to specify destinations for the different reports that It is possible to specify destinations for the different reports that
are outside the authority of the Domain Owner making the request. are outside the authority of the Domain Owner making the request.
This allows domains that do not operate mail servers to request This allows domains that do not operate mail servers to request
reports and have them go someplace that is able to receive and reports and have them go someplace that is able to receive and
process them. process them.
Without checks, this would allow a bad actor to publish a DMARC Without checks, this would allow a bad actor to publish a DMARC
Policy Record that requests that reports be sent to a victim address, Policy Record that requests that reports be sent to a victim address
and then send a large volume of mail that will fail both DKIM and SPF and then send a large volume of mail that will fail both DKIM and SPF
checks to a wide variety of destinations; the victim will in turn be checks to a wide variety of destinations; the victim will in turn be
flooded with unwanted reports. Therefore, a verification mechanism flooded with unwanted reports. Therefore, a verification mechanism
is included. is included.
When a Mail Receiver discovers a DMARC Policy Record in the DNS, and When a Mail Receiver discovers a DMARC Policy Record in the DNS, and
the Organizational Domain at which that record was discovered is not the Organizational Domain at which that record was discovered is not
identical to the Organizational Domain of the host part of the identical to the Organizational Domain of the host part of the
authority component of a [RFC3986] specified in the "rua" tag, the authority component of a [RFC3986] specified in the "rua" tag, the
following verification steps MUST be taken: following verification steps MUST be taken:
skipping to change at page 21, line 21 skipping to change at line 967
positive determination of the external reporting relationship positive determination of the external reporting relationship
cannot be made; stop. cannot be made; stop.
5. Query the DNS for a TXT record at the constructed name. If the 5. Query the DNS for a TXT record at the constructed name. If the
result of this request is a temporary DNS error of some kind result of this request is a temporary DNS error of some kind
(e.g., a timeout), the Mail Receiver MAY elect to temporarily (e.g., a timeout), the Mail Receiver MAY elect to temporarily
fail the delivery so the verification test can be repeated later. fail the delivery so the verification test can be repeated later.
6. For each record returned, parse the result as a series of 6. For each record returned, parse the result as a series of
"tag=value" pairs, i.e., the same overall format as the DMARC "tag=value" pairs, i.e., the same overall format as the DMARC
Policy Record (see Section 4.7 of [I-D.ietf-dmarc-dmarcbis]). In Policy Record (see Section 4.7 of [RFC9989]). In particular, the
particular, the "v=DMARC1" tag is mandatory and MUST appear first "v=DMARC1" tag is mandatory and MUST appear first in the list.
in the list. Discard any that do not pass this test. A trailing Discard any that do not pass this test. A trailing ";" is
";" is optional. optional.
7. If the result includes no TXT resource records that pass basic 7. If the result includes no TXT resource records that pass basic
parsing, a positive determination of the external reporting parsing, a positive determination of the external reporting
relationship cannot be made; stop. relationship cannot be made; stop.
8. If at least one TXT resource record remains in the set after 8. If at least one TXT resource record remains in the set after
parsing, then the external reporting arrangement was authorized parsing, then the external reporting arrangement was authorized
by the Report Consumer. by the Report Consumer.
9. If a "rua" tag is thus discovered, replace the corresponding 9. If a "rua" tag is thus discovered, replace the corresponding
skipping to change at page 22, line 22 skipping to change at line 1014
if it wishes to receive reports for other domains. if it wishes to receive reports for other domains.
A Report Consumer that is willing to receive reports for any domain A Report Consumer that is willing to receive reports for any domain
can use a wildcard DNS record. For example, a TXT resource record at can use a wildcard DNS record. For example, a TXT resource record at
"*._report._dmarc.example.com" containing at least "v=DMARC1" "*._report._dmarc.example.com" containing at least "v=DMARC1"
confirms that example.com is willing to receive DMARC reports for any confirms that example.com is willing to receive DMARC reports for any
domain. domain.
If the Report Consumer is overcome by volume, it can simply remove If the Report Consumer is overcome by volume, it can simply remove
the confirming DNS record. However, due to positive caching, the the confirming DNS record. However, due to positive caching, the
change could take as long as the time-to-live (TTL) on the record to change could take as long as the Time to Live (TTL) on the record to
go into effect. go into effect.
If the length of the DNS query is excessively long (Step 4 above), 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 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 shorter or reach out to another party that may allow for a shorter
DNS label. DNS label.
5. Extensible Reporting 5. Extensible Reporting
DMARC reports allow for some extensibility, as defined by future DMARC reports allow for some extensibility, as defined by future
documents that utilize DMARC as a foundation. These extensions MUST documents that utilize DMARC as a foundation. These extensions MUST
be properly formatted XML and meant to exist within the structure of be properly formatted XML and meant to exist within the structure of
a DMARC report. Two positions of type "<any>" are provided in the a DMARC report. Two positions of type "<any>" are provided in the
existing DMARC structure, one at file level, in an "<extension>" existing DMARC structure: one at file level in an "<extension>"
element after "<policy_published>" and one at record level, after element after "<policy_published>" and one at record level after
"<auth_results>". In either case, the extensions MUST contain a URI "<auth_results>". In either case, the extensions MUST contain a URI
to the definition of the extension so that the receiver understands to the definition of the extension so that the receiver understands
how to interpret the data. how to interpret the data.
At file level: At file level:
<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0" <feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
xmlns:ext="URI for an extension-supplied name space"> xmlns:ext="URI for an extension-supplied name space">
... ...
<policy_published> <policy_published>
skipping to change at page 23, line 20 skipping to change at line 1051
<p>quarantine</p> <p>quarantine</p>
<sp>none</sp> <sp>none</sp>
<testing>n</testing> <testing>n</testing>
</policy_published> </policy_published>
<extension> <extension>
<ext:arc-override>never</ext:arc-override> <ext:arc-override>never</ext:arc-override>
</extension> </extension>
Within the "record" element: Within the "record" element:
<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
xmlns:ext="URI for an extension-supplied name space">
...
<record> <record>
<row> <row>
... ...
</row> </row>
<identifiers> <identifiers>
... ...
</identifiers> </identifiers>
<auth_results> <auth_results>
... ...
</auth_results> </auth_results>
<ext:arc-results> <ext:arc-results>
... ...
</ext:arc-results> </ext:arc-results>
</record> </record>
<record> <record>
... ...
Here "arc-override" and "arc-results" are hypothetical element names Here "arc-override" and "arc-results" are hypothetical element names
defined in the extension's name space. defined in the extension's namespace.
Extension elements are optional. Any number of extensions is Extension elements are optional. Any number of extensions is
allowed. If a processor is unable to handle an extension in a allowed. If a processor is unable to handle an extension in a
report, it SHOULD ignore the data and continue to the next extension. report, it SHOULD ignore the data and continue to the next extension.
6. IANA Considerations 6. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. Two URI conforming to a registry mechanism described in [RFC3688]. Two URI
assignments will be registered by the IANA. assignments have been registered by the IANA.
6.1. Registration request for the DMARC namespace:
URI: urn:ietf:params:xml:ns:dmarc-2.0
Registrant Contact: Internet Engineering Task Force (iesg@ietf.org) 6.1. Registration for the DMARC Namespace
XML: None. Namespace URIs do not represent an XML specification. IANA has registered the following URI in the "ns" registry within the
"IETF XML Registry" group:
6.2. Registration request for the DMARC XML schema: URI: urn:ietf:params:xml:ns:dmarc-2.0
Registrant Contact: The IESG (iesg@ietf.org)
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:schema:dmarc-2.0 6.2. Registration for the DMARC XML Schema
Registrant Contact: Internet Engineering Task Force (iesg@ietf.org) IANA has registered the following URI in the "schema" registry within
the "IETF XML Registry" group:
XML: See Appendix A. DMARC XML Schema ([W3C.REC-xmlschema-1] and URI: urn:ietf:params:xml:schema:dmarc-2.0
[W3C.REC-xmlschema-2]) in this document. Registrant Contact: The IESG (iesg@ietf.org)
XML: See the DMARC XML schema [W3C.REC-xmlschema-1]
[W3C.REC-xmlschema-2] in Appendix A of this document.
7. Privacy Considerations 7. Privacy Considerations
This section will discuss exposure related to DMARC aggregate This section discusses exposure related to DMARC aggregate reporting.
reporting.
7.1. Report Recipients 7.1. Report Recipients
A DMARC Policy Record can specify that reports should be sent to an A DMARC Policy Record can specify that reports should be sent to an
intermediary operating on behalf of the Domain Owner. This is done intermediary operating on behalf of the Domain Owner. This is done
when the Domain Owner contracts with an entity to monitor mail when the Domain Owner contracts with an entity to monitor mail
streams for abuse and performance issues. Receipt by third parties streams for abuse and performance issues. Receipt by third parties
of such data may or may not be permitted by the Mail Receiver's of such data may or may not be permitted by the Mail Receiver's
privacy policy, terms of use, or other similar governing document. privacy policy, terms of use, or other similar governing document.
Domain Owners and Mail Receivers should both review and understand if Domain Owners and Mail Receivers should both review and understand if
skipping to change at page 24, line 51 skipping to change at line 1131
traffic. In addition to verifying compliance with policies, traffic. In addition to verifying compliance with policies,
Receivers need to consider that before sending reports to a third Receivers need to consider that before sending reports to a third
party. party.
7.2. Data Contained Within Reports 7.2. Data Contained Within Reports
Aggregate feedback reports contain aggregated data relating to Aggregate feedback reports contain aggregated data relating to
messages purportedly originating from the Domain Owner. The data messages purportedly originating from the Domain Owner. The data
does not contain any identifying characteristics about individual does not contain any identifying characteristics about individual
users. No personal information such as individual mail addresses, IP users. No personal information such as individual mail addresses, IP
addresses of individuals, or the content of any messages, is included addresses of individuals, or the content of any messages is included
in reports. in reports.
Mail Receivers should have no concerns in sending reports as they do Mail Receivers should have no concerns in sending reports, as they do
not contain personal information. In all cases, the data within the not contain personal information. In all cases, the data within the
reports relates to the domain-level authentication information reports relates to the domain-level authentication information
provided by mail servers sending messages on behalf of the Domain provided by mail servers sending messages on behalf of the Domain
Owner. This information is necessary to assist Domain Owners in Owner. This information is necessary to assist Domain Owners in
implementing and maintaining DMARC. implementing and maintaining DMARC.
Domain Owners should have no concerns in receiving reports as they do Domain Owners should have no concerns in receiving reports, as they
not contain personal information. The reports only contain do not contain personal information. The reports only contain
aggregated data related to the domain-level authentication details of aggregated data related to the domain-level authentication details of
messages claiming to originate from their domain. This information messages claiming to originate from their domain. This information
is essential for the proper implementation and operation of DMARC. is essential for the proper implementation and operation of DMARC.
Domain Owners who are unable to receive reports for organizational Domain Owners who are unable to receive reports for organizational
reasons, can choose to exclusively direct the reports to an external reasons can choose to exclusively direct the reports to an external
processor. processor.
7.3. Feedback Leakage 7.3. Feedback Leakage
Providing feedback reporting to PSOs (Public Suffix Operator) for a Providing feedback reporting to Public Suffix Operators (PSOs) for a
PSD (Public Suffix Domain) [I-D.ietf-dmarc-dmarcbis] can, in some Public Suffix Domain (PSD) [RFC9989] can, in some cases, cause
cases, cause information to leak out of an organization to the PSO. information to leak out of an organization to the PSO. This leakage
This leakage could potentially be utilized as part of a program of could potentially be utilized as part of a program of pervasive
pervasive surveillance (see [RFC7624]). There are roughly three surveillance (see [RFC7624]). There are roughly three cases to
cases to consider: consider:
* Single Organization PSDs (e.g., ".mil")
Single Organization PSDs (e.g., ".mil"):
Aggregate reports based on PSD DMARC have the potential to contain Aggregate reports based on PSD DMARC have the potential to contain
information about mails related to entities managed by the information about mail related to entities managed by the
organization. Since both the PSO and the Organizational Domain organization. Since both the PSO and the Organizational Domain
Owners are common, there is no additional privacy risk for either Owners are common, there is no additional privacy risk for either
normal or non-existent domain reporting due to PSD DMARC. normal or non-existent domain reporting due to PSD DMARC.
* Multi-organization PSDs requiring DMARC usage (e.g., ".bank") Multi-organization PSDs requiring DMARC usage (e.g., ".bank"):
Aggregate reports based on PSD DMARC will only be generated for Aggregate reports based on PSD DMARC will only be generated for
domains that do not publish a DMARC Policy Record at the domains that do not publish a DMARC Policy Record at the
Organizational Domain or host level. For domains that do publish Organizational Domain or host level. For domains that do publish
the required DMARC Policy Records, the feedback reporting the required DMARC Policy Records, the feedback reporting
addresses of the Organizational Domain (or hosts) will be used. addresses of the Organizational Domain (or hosts) will be used.
The only direct risk of feedback leakage for these PSDs are for The only direct risk of feedback leakage for these PSDs are for
Organizational Domains that are out of compliance with PSD policy. Organizational Domains that are out of compliance with PSD policy.
Data on non-existent domains would be sent to the PSO. Data on non-existent domains would be sent to the PSO.
* Multi-organization PSDs not requiring DMARC usage (e.g., ".com") Multi-organization PSDs not requiring DMARC usage (e.g., ".com"):
Privacy risks for Organizational Domains that have not deployed Privacy risks for Organizational Domains that have not deployed
DMARC within such PSDs can be significant. For non-DMARC DMARC within such PSDs can be significant. For non-DMARC
Organizational Domains, all DMARC feedback will be directed to the Organizational Domains, all DMARC feedback will be directed to the
PSO if that PSO itself has a DMARC Policy Record that specifies a PSO if that PSO itself has a DMARC Policy Record that specifies a
"rua" tag. Any non-DMARC Organizational Domain would have its "rua" tag. Any non-DMARC Organizational Domain would have its
Feedback Reports redirected to the PSO. The content of such feedback reports redirected to the PSO. The content of such
reports, particularly for existing domains, is privacy sensitive. reports, particularly for existing domains, is privacy sensitive.
PSOs will receive feedback on non-existent domains, which may be PSOs will receive feedback on non-existent domains, which may be
similar to existing Organizational Domains. Feedback related to such similar to existing Organizational Domains. Feedback related to such
domains have a small risk of carrying information related to an domains have a small risk of carrying information related to an
actual Organizational Domain. To minimize this potential concern, actual Organizational Domain. To minimize this potential concern,
PSD DMARC feedback MUST be limited to aggregate reports. Failure PSD DMARC feedback MUST be limited to aggregate reports. Failure
reports carry more detailed information and present a greater risk. reports carry more detailed information and present a greater risk.
8. Security Considerations 8. Security Considerations
While reviewing this document and its Security Considerations, it is While reviewing this document and its security considerations, it is
ideal that the reader would also review Privacy Considerations above, ideal that the reader also review the Privacy Considerations section
as well as the Privacy Considerations and Security Considerations in above, as well as the privacy considerations and security
section 9 and 10 of [I-D.ietf-dmarc-dmarcbis]. considerations in Sections 10 and 11 of [RFC9989].
8.1. Report Contents as an Attack 8.1. Report Content as an Attack
Aggregate reports are supposed to be processed automatically. An Aggregate reports are supposed to be processed automatically. An
attacker might attempt to compromise the integrity or availability of attacker might attempt to compromise the integrity or availability of
the report processor by sending malformed reports. In particular, the report processor by sending malformed reports. In particular,
the archive decompressor and XML parser are at risk to resource the archive decompressor and XML parser are at risk to resource
exhaustion attacks (zip bomb or XML bomb). exhaustion attacks (zip bomb or XML bomb).
8.2. False Information 8.2. False Information
The data contained within aggregate reports may be forged. An The data contained within aggregate reports may be forged. An
attacker might attempt to interfere with or influence policy attacker might attempt to interfere with or influence policy
decisions by submitting false reports in large volume. The attacker decisions by submitting false reports in large volume. The attacker
could also be attempting to influence platform architecture could also be attempting to influence platform architecture
decisions. A volume-based attack may also impact the ability for a decisions. A volume-based attack may also impact the ability for a
report receiver to accept reports from other entities. Report Receiver to accept reports from other entities.
8.3. Disclosure of Filtering Information 8.3. Disclosure of Filtering Information
While not specified in this document itself, the availability of While not specified in this document itself, the availability of
extensions could enable the report generator to disclose information extensions could enable the report generator to disclose information
about message placement (Inbox/Spam/etc). This is very much about message placement (Inbox/Spam/etc.). This is very much
discouraged as it could relay this information to a malicious party, discouraged as it could relay this information to a malicious party,
allowing them to understand more about filtering methodologies at a allowing them to understand more about filtering methodologies at a
receiving entity. receiving entity.
9. Operational Considerations 9. Operational Considerations
9.1. Report Generation 9.1. Report Generation
* The error fields should be reasonably terse and usable. * The error fields should be reasonably terse and usable.
* If reports cannot be generator, the system should ideally log a
* If reports cannot be generated, the system should ideally log a
useful error that helps troubleshoot the issue. useful error that helps troubleshoot the issue.
9.2. Report Evaluation 9.2. Report Evaluation
As noted above, if a report does not match the specified format, the As noted above, if a report does not match the specified format, the
evaluator will likely find the contents to be in question. evaluator will likely find the contents to be in question.
Alternately, the evaluator may decide to sideline those reports so Alternately, the evaluator may decide to sideline those reports so
they can more easily collaborate with the report generator to they can more easily collaborate with the report generator to
identify where the issues are happening. identify where the issues are happening.
It's quite likely that the data contained within the reports will be It's quite likely that the data contained within the reports will be
extracted and stored in a system that allows for easy reporting, extracted and stored in a system that allows for easy reporting,
dashboarding, and/or monitoring. The XML reports themselves are not dashboarding, and/or monitoring. The XML reports themselves are not
human readable in bulk, and a system such as the above may aid the human readable in bulk, and a system such as the above may aid the
Domain Owner with identifying issues. Domain Owner with identifying issues.
9.3. Report Storage 9.3. Report Storage
Once a report is accepted and properly parsed by the report Once a report is accepted and properly parsed by the report
evaluator, it is entirely up to that evaluator what they wish to do evaluator, it is entirely up to that evaluator as to what they wish
with the XML documents. For some domains, the quantity of reports to do with the XML documents. For some domains, the quantity of
could be fairly high, or the size of the reports themselves could be reports could be fairly high, or the size of the reports themselves
large. Once the data from the reports has been extracted and could be large. Once the data from the reports has been extracted
indexed, the reports seemingly have little value in most situations. and indexed, the reports seemingly have little value in most
situations.
10. Normative References 10. References
[I-D.ietf-dmarc-dmarcbis] 10.1. Normative References
Herr, T. M. and J. Levine, "Domain-based Message
Authentication, Reporting, and Conformance (DMARC)", Work
in Progress, Internet-Draft, draft-ietf-dmarc-dmarcbis-40,
17 March 2025,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
ietf-dmarc-dmarcbis/>.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, DOI 10.17487/RFC1952, May 1996, RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>. <https://www.rfc-editor.org/info/rfc1952>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
skipping to change at page 29, line 28 skipping to change at line 1335
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8601] Kucherawy, M., "Message Header Field for Indicating [RFC8601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 8601, Message Authentication Status", RFC 8601,
DOI 10.17487/RFC8601, May 2019, DOI 10.17487/RFC8601, May 2019,
<https://www.rfc-editor.org/info/rfc8601>. <https://www.rfc-editor.org/info/rfc8601>.
[RFC9989] Herr, T., Ed. and J. R. Levine, Ed., "Domain-Based Message
Authentication, Reporting, and Conformance (DMARC)",
RFC 9989, DOI 10.17487/RFC9989, May 2026,
<https://www.rfc-editor.org/info/rfc9989>.
[W3C.REC-xmlschema-1] [W3C.REC-xmlschema-1]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, Thompson, H. S., Ed., Beech, D., Ed., Maloney, M., Ed.,
"XML Schema Part 1: Structures", W3C REC-xmlschema-1, 2 and N. Mendelsohn, Ed., "XML Schema Part 1: Structures
May 2001, <http://www.w3.org/TR/xmlschema-1/>. Second Edition", W3C Recommendation, 28 October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.
Latest version available at
https://www.w3.org/TR/xmlschema-1/.
[W3C.REC-xmlschema-2] [W3C.REC-xmlschema-2]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", Biron, P. V., Ed. and A. Malhotra, Ed., "XML Schema Part
W3C REC-xmlschema-2, 2 May 2001, 2: Datatypes Second Edition", W3C Recommendation, 28
<http://www.w3.org/TR/xmlschema-2/>. October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
11. Informative References Latest version available at
https://www.w3.org/TR/xmlschema-2/.
[I-D.ietf-dmarc-failure-reporting] 10.2. Informative References
Jones, S. M. and A. Vesely, "Domain-based Message
Authentication, Reporting, and Conformance (DMARC) Failure
Reporting", Work in Progress, Internet-Draft, draft-ietf-
dmarc-failure-reporting-12, 9 January 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-
failure-reporting-12>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009, DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>. <https://www.rfc-editor.org/info/rfc5598>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann, Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A "Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624, Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015, DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>. <https://www.rfc-editor.org/info/rfc7624>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/info/rfc9562>. 2024, <https://www.rfc-editor.org/info/rfc9562>.
[RFC9991] Jones, S. M., Ed. and A. Vesely, Ed., "Domain-Based
Message Authentication, Reporting, and Conformance (DMARC)
Failure Reporting", RFC 9991, DOI 10.17487/RFC9991, May
2026, <https://www.rfc-editor.org/info/rfc9991>.
Appendix A. DMARC XML Schema Appendix A. DMARC XML Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:dmarc-2.0" targetNamespace="urn:ietf:params:xml:ns:dmarc-2.0"
xmlns="urn:ietf:params:xml:ns:dmarc-2.0" xmlns="urn:ietf:params:xml:ns:dmarc-2.0"
elementFormDefault="qualified"> elementFormDefault="qualified">
<!-- Elements with an optional "lang" attribute. --> <!-- Elements with an optional "lang" attribute. -->
<xs:complexType name="langAttrString"> <xs:complexType name="langAttrString">
skipping to change at page 31, line 31 skipping to change at line 1442
</xs:complexType> </xs:complexType>
<!-- Alignment mode (relaxed or strict) for DKIM and SPF. --> <!-- Alignment mode (relaxed or strict) for DKIM and SPF. -->
<xs:simpleType name="AlignmentType"> <xs:simpleType name="AlignmentType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="r"/> <xs:enumeration value="r"/>
<xs:enumeration value="s"/> <xs:enumeration value="s"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- The policy actions specified by p, sp and np in the <!-- The policy actions specified by p, sp, and np in the
DMARC Policy Record. --> DMARC Policy Record. -->
<xs:simpleType name="DispositionType"> <xs:simpleType name="DispositionType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="none"/> <xs:enumeration value="none"/>
<xs:enumeration value="quarantine"/> <xs:enumeration value="quarantine"/>
<xs:enumeration value="reject"/> <xs:enumeration value="reject"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- The policy actions utilized on messages for this record. --> <!-- The policy actions utilized on messages for this record. -->
skipping to change at page 32, line 11 skipping to change at line 1470
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="none"/> <xs:enumeration value="none"/>
<xs:enumeration value="pass"/> <xs:enumeration value="pass"/>
<xs:enumeration value="quarantine"/> <xs:enumeration value="quarantine"/>
<xs:enumeration value="reject"/> <xs:enumeration value="reject"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- The method used to discover the DMARC Policy Record used during <!-- The method used to discover the DMARC Policy Record used during
evaluation. The available values are "psl" and "treewalk", evaluation. The available values are "psl" and "treewalk",
where "psl" is the method from [@?RFC7489] and the "treewalk" where "psl" is the method from RFC 7489 and "treewalk" is
is described in [@I-D.ietf-dmarc-dmarcbis]. --> described in RFC 9989. -->
<xs:simpleType name="DiscoveryType"> <xs:simpleType name="DiscoveryType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="psl"/> <xs:enumeration value="psl"/>
<xs:enumeration value="treewalk"/> <xs:enumeration value="treewalk"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- The published DMARC policy. Unspecified tags have their <!-- The published DMARC policy. Unspecified tags have their
default values. --> default values. -->
<xs:complexType name="PolicyPublishedType"> <xs:complexType name="PolicyPublishedType">
skipping to change at page 32, line 43 skipping to change at line 1502
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<!-- * non-existent subdomains. --> <!-- * non-existent subdomains. -->
<xs:element name="np" type="DispositionType" <xs:element name="np" type="DispositionType"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<!-- The DKIM alignment mode. --> <!-- The DKIM alignment mode. -->
<xs:element name="adkim" type="AlignmentType" <xs:element name="adkim" type="AlignmentType"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<!-- The SPF alignment mode. --> <!-- The SPF alignment mode. -->
<xs:element name="aspf" type="AlignmentType" <xs:element name="aspf" type="AlignmentType"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<!-- Method used to find/obtain DMARC policy --> <!-- Method used to find/obtain DMARC policy. -->
<xs:element name="discovery_method" type="DiscoveryType" <xs:element name="discovery_method" type="DiscoveryType"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<!-- Failure reporting options in effect. --> <!-- Failure reporting options in effect. -->
<xs:element name="fo" type="xs:string" <xs:element name="fo" type="xs:string"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<!-- Whether testing mode was declared in the DMARC Record --> <!-- Whether testing mode was declared in the DMARC Record. -->
<xs:element name="testing" type="TestingType" <xs:element name="testing" type="TestingType"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
</xs:all> </xs:all>
</xs:complexType> </xs:complexType>
<!-- Values for Testing mode attached to policy --> <!-- Values for Testing mode attached to policy. -->
<xs:simpleType name="TestingType"> <xs:simpleType name="TestingType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="n"/> <xs:enumeration value="n"/>
<xs:enumeration value="y"/> <xs:enumeration value="y"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- The DMARC-aligned authentication result. --> <!-- The DMARC-aligned authentication result. -->
<xs:simpleType name="DMARCResultType"> <xs:simpleType name="DMARCResultType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
skipping to change at page 33, line 49 skipping to change at line 1555
<xs:element name="type" type="PolicyOverrideType" <xs:element name="type" type="PolicyOverrideType"
minOccurs="1" maxOccurs="1"/> minOccurs="1" maxOccurs="1"/>
<xs:element name="comment" type="langAttrString" <xs:element name="comment" type="langAttrString"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
</xs:all> </xs:all>
</xs:complexType> </xs:complexType>
<!-- Taking into account everything else in the record, <!-- Taking into account everything else in the record,
the results of applying DMARC. If alignment fails the results of applying DMARC. If alignment fails
and the policy applied does not match the domain's and the policy applied does not match the domain's
configured policy, the reason element MUST be specified --> configured policy, the reason element MUST be specified. -->
<xs:complexType name="PolicyEvaluatedType"> <xs:complexType name="PolicyEvaluatedType">
<xs:sequence> <xs:sequence>
<xs:element name="disposition" type="ActionDispositionType" <xs:element name="disposition" type="ActionDispositionType"
minOccurs="1" maxOccurs="1"/> minOccurs="1" maxOccurs="1"/>
<xs:element name="dkim" type="DMARCResultType" <xs:element name="dkim" type="DMARCResultType"
minOccurs="1" maxOccurs="1"/> minOccurs="1" maxOccurs="1"/>
<xs:element name="spf" type="DMARCResultType" <xs:element name="spf" type="DMARCResultType"
minOccurs="1" maxOccurs="1"/> minOccurs="1" maxOccurs="1"/>
<xs:element name="reason" type="PolicyOverrideReason" <xs:element name="reason" type="PolicyOverrideReason"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="RowType"> <xs:complexType name="RowType">
<xs:all> <xs:all>
<!-- The connecting IP. IPv4address or IPv6address <!-- The connecting IP. IPv4address or IPv6address
as defined in RFC 3986 section 3.2.2 --> as defined in RFC 3986, Section 3.2.2. -->
<xs:element name="source_ip" type="xs:string" <xs:element name="source_ip" type="xs:string"
minOccurs="1" maxOccurs="1"/> minOccurs="1" maxOccurs="1"/>
<!-- The number of messages for which the <!-- The number of messages for which the
PolicyEvaluatedType was applied. --> PolicyEvaluatedType was applied. -->
<xs:element name="count" type="xs:integer" <xs:element name="count" type="xs:integer"
minOccurs="1" maxOccurs="1"/> minOccurs="1" maxOccurs="1"/>
<!-- The DMARC disposition applied to matching messages. --> <!-- The DMARC disposition applied to matching messages. -->
<xs:element name="policy_evaluated" type="PolicyEvaluatedType" <xs:element name="policy_evaluated" type="PolicyEvaluatedType"
minOccurs="1" maxOccurs="1"/> minOccurs="1" maxOccurs="1"/>
</xs:all> </xs:all>
</xs:complexType> </xs:complexType>
<xs:complexType name="IdentifierType"> <xs:complexType name="IdentifierType">
<xs:all> <xs:all>
<!-- The RFC5322.From domain. --> <!-- The RFC5322.From domain. -->
<xs:element name="header_from" type="xs:string" <xs:element name="header_from" type="xs:string"
minOccurs="1" maxOccurs="1"/> minOccurs="1" maxOccurs="1"/>
<!-- The RFC5321.MailFrom domain --> <!-- The RFC5321.MailFrom domain. -->
<xs:element name="envelope_from" type="xs:string" <xs:element name="envelope_from" type="xs:string"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<!-- The envelope recipient domain. --> <!-- The envelope recipient domain. -->
<xs:element name="envelope_to" type="xs:string" <xs:element name="envelope_to" type="xs:string"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
</xs:all> </xs:all>
</xs:complexType> </xs:complexType>
<!-- DKIM verification result, see RFC 8601 Section 2.7.1. --> <!-- DKIM verification result; see RFC 8601, Section 2.7.1. -->
<xs:simpleType name="DKIMResultType"> <xs:simpleType name="DKIMResultType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="none"/> <xs:enumeration value="none"/>
<xs:enumeration value="pass"/> <xs:enumeration value="pass"/>
<xs:enumeration value="fail"/> <xs:enumeration value="fail"/>
<xs:enumeration value="policy"/> <xs:enumeration value="policy"/>
<xs:enumeration value="neutral"/> <xs:enumeration value="neutral"/>
<xs:enumeration value="temperror"/> <xs:enumeration value="temperror"/>
<xs:enumeration value="permerror"/> <xs:enumeration value="permerror"/>
</xs:restriction> </xs:restriction>
skipping to change at page 35, line 33 skipping to change at line 1636
</xs:all> </xs:all>
</xs:complexType> </xs:complexType>
<!-- SPF domain scope. --> <!-- SPF domain scope. -->
<xs:simpleType name="SPFDomainScope"> <xs:simpleType name="SPFDomainScope">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="mfrom"/> <xs:enumeration value="mfrom"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- SPF verification result, see RFC 8601 Section 2.7.2. --> <!-- SPF verification result; see RFC 8601, Section 2.7.2. -->
<xs:simpleType name="SPFResultType"> <xs:simpleType name="SPFResultType">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="none"/> <xs:enumeration value="none"/>
<xs:enumeration value="pass"/> <xs:enumeration value="pass"/>
<xs:enumeration value="fail"/> <xs:enumeration value="fail"/>
<xs:enumeration value="softfail"/> <xs:enumeration value="softfail"/>
<xs:enumeration value="policy"/> <xs:enumeration value="policy"/>
<xs:enumeration value="neutral"/> <xs:enumeration value="neutral"/>
<xs:enumeration value="temperror"/> <xs:enumeration value="temperror"/>
<xs:enumeration value="permerror"/> <xs:enumeration value="permerror"/>
skipping to change at page 38, line 34 skipping to change at line 1781
<selector>abc123</selector> <selector>abc123</selector>
</dkim> </dkim>
<spf> <spf>
<domain>example.com</domain> <domain>example.com</domain>
<result>fail</result> <result>fail</result>
</spf> </spf>
</auth_results> </auth_results>
</record> </record>
</feedback> </feedback>
Appendix C. Differences from RFC7489 Appendix C. Differences from RFC 7489
A bulleted list of some of the more noticeable/important differences Here is a bulleted list of some of the more noticeable/important
between DMARC [RFC7489] and this document: differences between DMARC [RFC7489] and this document:
* Many elements of the defining XSD have been clarified, which means * Many elements of the defining XSD have been clarified, which means
the structure of the report should be more consistent the structure of the report should be more consistent
* The report identifier has more structure * The report identifier has more structure
* Clarification about the number of domains to be addressed per
report * Clarification provided about the number of domains to be addressed
per report
* The addition of extensions as part of the report structure * The addition of extensions as part of the report structure
* PSD is now included as part of the specification * PSD is now included as part of the specification
* Selector is now required when reporting a DKIM signature * Selector is now required when reporting a DKIM signature
Furthermore, the original DMARC specification was contained within a Furthermore, the original DMARC specification was contained within a
single document, [RFC7489]. The original document has been split single document: [RFC7489]. The original document has been split
into three documents, DMARCbis [I-D.ietf-dmarc-dmarcbis], this into three documents: [RFC9989], this document, and [RFC9991]. This
document, and DMARCbis Failure Reporting allows these pieces to potentially be altered in the future without
re-opening the entire document, as well as allowing them to move
[I-D.ietf-dmarc-failure-reporting]. This allows these pieces to through the IETF process independently.
potentially be altered in the future without re-opening the entire
document, as well as allowing them to move through the IETF process
independently.
Acknowledgements Acknowledgements
Many thanks are deserved to those that helped create this document. Many thanks are deserved to those that helped create this document.
Much of the content was created from the original [RFC7489], and has Much of the content was created from [RFC7489] and has now been
now been updated to be more clear and correct some outstanding updated to be more clear and correct some outstanding issues. The
issues. The IETF DMARC Working Group has spent much time working to IETF DMARC Working Group has spent much time working to finalize this
finalize this effort, and significant contributions were made by Seth effort, and significant contributions were made by Seth Blank, Todd
Blank, Todd Herr, Steve Jones, Murray S. Kucherawy, Barry Leiba, Herr, Steve Jones, Scott Kitterman, Murray S. Kucherawy, Daniel Kvål,
John Levine, Scott Kitterman, Daniel Kvål, Martijn van der Lee, Barry Leiba, John Levine, Martijn van der Lee, Alessandro Veseley,
Alessandro Veseley, and Matthäus Wander. and Matthäus Wander.
Author's Address Author's Address
Alex Brotman Alex Brotman (editor)
Comcast, Inc. Comcast, Inc.
Email: alex_brotman@comcast.com Email: alex_brotman@comcast.com
 End of changes. 216 change blocks. 
498 lines changed or deleted 526 lines changed or added

This html diff was produced by rfcdiff 1.48.