Rfc9990

Providing Domain Owners with visibility into how Mail Receivers implement and enforce the DMARC mechanism in the form of feedback is critical to establishing and maintaining accurate authentication deployments. When Domain Owners can see what effect their policies and practices are having, they are better willing and able to use quarantine and reject policies. ¶

The DMARC aggregate feedback report is designed to provide Domain Owners with precise insight into: ¶

Aggregate DMARC feedback provides visibility into real-world mail streams that Domain Owners need in order to make informed decisions regarding the publication of a DMARC policy. When Domain Owners know what legitimate mail they are sending, what the authentication results are on that mail, and what forged Mail Receivers are getting, they can make better decisions the policies they need and the steps they need to take to enable those policies. When Domain Owners set policies appropriately and understand their effects, Mail Receivers can act on them confidently. ¶

Visibility comes in the form of daily (or more frequent) feedback reports that are originated from Mail Receivers and that contain aggregate data on message streams relevant to the Domain Owner. This information includes data messages that passed DMARC authentication as well as those that did not. ¶

A separate report MUST be generated for each DMARC Policy Domain encountered during the reporting period. See below for further explanation in Section 3.1.2 ("Handling Domains in Reports"). ¶

The report may include the following data: ¶

Each report MUST contain data for only one DMARC Policy Domain. A single report MUST contain data for one policy configuration. If multiple configurations were observed during a single reporting period, a reporting entity MAY choose to send multiple reports; otherwise, the reporting entity SHOULD note only the final configuration observed during the period. See below for further information. ¶

The format for these reports is defined in the XML Schema Definition (XSD) in Appendix A . The XSD includes the possible values for some of the elements below. Most of these values have a definition tied to [ RFC9989 ] . ¶

The format is also described in the following sections. Each section describes a collection of sibling elements in the XML hierarchy. There are pointers to where in the hierarchy each table fits. ¶

If a document does not match the specified format, the document evaluator SHOULD discard the report. The evaluator MAY choose to try to utilize some of the data; however, if the format is in question, the data may be as well. The report evaluator MAY choose to the report generator so that they may be alerted to an issue with the report format. ¶

The column "#" specifies how many times an element may appear -- this is sometimes referred to as multiplicity. The possible values are: ¶

Some elements contain text meant for humans and support an optional "lang" attribute whose value indicates the language of its contents. The default value is "en". Elements supporting this optional attribute are marked with "[@lang]" at the start of their content description in the following tables. ¶

DMARC aggregate feedback reports have the root element "feedback" with its XML namespace set to the DMARC namespace. ¶

The elements in this table MUST appear in the order listed. ¶

There MUST be at least one "record" element; these elements contain data stating that IP addresses were seen to have delivered messages for the Author Domain to the receiving system. For each IP address that is being reported, there will be at least one "record" element. ¶

Use of extensions may cause elements to be added here. These elements MUST be namespaced. ¶

The report MUST contain one or more records stating which IP addresses were seen to have delivered messages for the Author Domain to the receiving system. For each IP address that is being reported, there will be at least one "record" element. ¶

This element contains all the authentication results that were evaluated by the receiving system for the given set of messages. ¶

An unlimited number of "record" elements may be specified. ¶

Use of extensions may cause other elements to be added to the end of the record; such elements MUST be namespaced. ¶

One record (IP, result, authentication identifiers) per tuple. ¶

The elements in this table MUST appear in the order listed. ¶

A "row" element contains the details of the connecting system, and how many mail messages were received from it, for the particular combination of the policy evaluated. ¶

This element describes the results of applying the DMARC policy. If alignment fails and the policy applied does not match the DMARC Policy Domain's configured policy, the "reason" element MUST be included. ¶

The elements in this table MUST appear in the order listed. ¶

"spf" and "dkim" MUST be the evaluated values as they relate to DMARC, not the values the receiver may have used when overriding the policy. ¶

"reason" elements are meant to contain any notes the reporter might want to include as to why the "disposition" policy does not match the "policy_published", such as a local policy override. ¶

This element contains DKIM and SPF results, uninterpreted with respect to DMARC. ¶

If validation is attempted for any DKIM signature, the results MUST be included in the report (within reason; see Section 3.1.3 ("DKIM Signatures in Aggregate Reports") below for handling numerous signatures). ¶

The elements in this table MUST appear in the order listed. ¶

Only the "MAIL FROM" identity (see Section 2.4 of [ RFC7208 ] ) is used in DMARC. ¶

The only valid value for the "scope" element is "mfrom". ¶

"result" is a lowercase string where the value is one of the results defined in Section 2.7.2 of [ RFC8601 ] . ¶

The policy override reason consists of a pre-defined override type and free-text ; see Section 3.1.6 . ¶

In the same report, there MUST be a single DMARC Policy Domain, though there could be multiple RFC5322.From domains. Each RFC5322.From domain will create its own "record" within the report. Consider the case where there are three domains with traffic volume to report: example.com, foo.example.com, and bar.example.com. There will be explicit DMARC Policy Records for example.com and bar.example.com, with distinct policies. There is no explicit DMARC Policy Record for foo.example.com, so it will be reliant on the policy described for example.com. For a report period, there would now be two reports. ¶

The first report will be for bar.example.com and contain only one "record", for bar.example.com. The second report will be for example.com and will contain multiple "record" elements, one for example.com and one for foo.example.com (and by extension, other "record" elements for subdomains that likewise did not have an explicit DMARC Policy Record). ¶

Within a single message, the possibility exists that there could be multiple DKIM signatures. When validation of the message occurs, some signatures may pass, while some may not. As these pertain to DMARC, and especially to aggregate reporting, reporters may not find it clear which DKIM signatures they should include in a report. Signatures, regardless of outcome, could help the report ingester determine the source of a message. However, there is a preference as to which signatures are included. ¶

A report SHOULD contain no more than 100 signatures for a given "row", in decreasing priority. ¶

There are a few places where a unique identifier is specified as part of the body of the report, the subject, and so on. These unique identifiers should be consistent per each report. Specified below, the reader will see a "Report-ID" and "unique-id". These are the fields that MUST be identical when used. ¶

Here are a few examples of information contained within the "error" element(s): ¶

Be mindful that the "error" element is an unbounded string but should not contain an extremely large body. Provide enough information to assist the Domain Owner with understanding some issues with their authentication or DMARC Policy Record. ¶

The "reason" element, indicating an override of the DMARC policy, consists of a mandatory "type" element and an optional " " element. The "type" element MUST have one of the pre-defined values listed below. The " " element is an unbounded string for providing further details. ¶

Possible values for the policy override type: ¶

The document format supports optional elements for extensions. The absence or existence of this section SHOULD NOT create an error when processing reports. This will be covered in Section 5 ("Extensible Reporting"). ¶

Note that Domain Owners or their agents may change the published DMARC Policy Record for a domain or subdomain at any time. From a Mail Receiver's perspective, this will occur during a reporting period and may be noticed during that period, at the end of that period when reports are generated, or during a subsequent reporting period, all depending on the Mail Receiver's implementation. Under these conditions, it is possible that a Mail Receiver could do any of the following: ¶

Such policy changes are expected to be infrequent for any given domain, whereas more stringent policy monitoring requirements on the Mail Receiver would produce a very large burden at Internet scale. Therefore, it is the responsibility of Report Consumers (i.e., vendors) and Domain Owners to be aware of this situation and expect such mixed reports during the propagation of the new policy to Mail Receivers. ¶

A Mail Receiver discovers reporting requests when it looks up a DMARC Policy Record that corresponds to an RFC5322.From domain on received mail. The presence of the "rua" tag specifies where to send feedback. ¶

The Mail Receiver, after preparing a report, MUST evaluate the provided reporting URIs (see [ RFC9989 ] ) in the order given. If any of the URIs are malformed, they SHOULD be ignored. An attempt MUST be made to deliver an aggregate report to every remaining URI, up to the Receiver's limits on supported URIs. ¶

If delivery is not possible because the services advertised by the published URIs are not able to accept reports (e.g., the URI refers to a service that is unreachable), the Mail Receiver MAY cache that 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 Mail Receiver generating a feedback report SHOULD employ a secure transport mechanism, meaning the report should be delivered over a channel employing TLS (SMTP+STARTTLS). ¶

This identifier MUST be unique among reports to the same domain to aid receivers in identifying duplicate reports should they happen. The Report-ID value should be constructed using the following ABNF: ¶

The format specified here is not very strict, as the key goal is uniqueness. In order to create this uniqueness, the Mail Receiver may wish to use elements such as the receiving domain, the sending domain, and a timestamp in combination. An example string might be "[email protected]". An alternate could use a date string such as "[email protected]". ¶

The message generated by the Mail Receiver MUST be as described in [ RFC5322 ] and formatted per [ RFC2045 ] . The aggregate report itself MUST be included in one of the parts of the message, as an attachment with a corresponding media type from below. A human-readable annotation MAY be included as a body part (with a human-friendly content-type, such as "text/plain" or "text/html"). ¶

The aggregate data MUST be an XML file that SHOULD be subjected to GZIP [ RFC1952 ] compression. Declining to apply compression can cause the report to be too large for a receiver to process (the total message size could exceed the receiver SMTP size limit); doing the compression increases the chances of acceptance of the report at some compute cost. The aggregate data MUST be present using the media type "application/gzip" if compressed (see [ RFC6713 ] ) and "text/xml" otherwise. The attachment filename MUST be constructed using the following ABNF: ¶

The following primitive tokens that are used but otherwise unspecified are taken from "Core Rules" ( Appendix B.1 of [ RFC5234 ] ): DIGIT, ALPHA. ¶

The extension MUST be "xml" for a plain XML file or "xml.gz" for an XML file compressed using GZIP. ¶

"unique-id" allows an optional unique ID generated by the Mail Receiver to distinguish among multiple reports generated simultaneously by different sources within the same Domain Owner. A viable option may be to explore Universally Unique Identifiers (UUIDs) [ RFC9562 ] . ¶

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 receiver to overwrite the data from the original or discard the second instance of the 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 "mail.receiver.example": ¶

mail.receiver.example!example.com!1013662812!1013749130.xml.gz ¶

No specific MIME message structure is required for the message body. It is presumed that the aggregate reporting address will be equipped to extract body parts with the prescribed media type and filename and ignore the rest. ¶

Mail streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 4.4 of [ RFC9989 ] ). This practice minimizes the risk of Report Consumers processing fraudulent reports. ¶

The RFC5322.Subject field for individual report submissions MUST conform to the following ABNF: ¶

The first domain-name indicates the DNS domain name which the report was generated. The second domain-name indicates the DNS domain name representing the Mail Receiver generating the report. The purpose of the Report-ID: portion of the field is to enable the Domain Owner to identify and ignore duplicate reports that might be sent by a Mail Receiver. ¶

For instance, this is a possible Subject field for a report to the Domain Owner "example.com" from the Mail Receiver "mail.receiver.example". It is folded as allowed by [ RFC5322 ] : ¶

This transport mechanism potentially encounters a problem when feedback data size exceeds maximum allowable attachment sizes for either the generator or the consumer. ¶

Optionally, the report sender MAY choose to use the same "ridtxt" as a part or whole of the RFC5322.Message-Id header included with the report. Doing so may help receivers distinguish when a message is a re-transmission or duplicate report. ¶

The specification as written allows for the addition of other registered URI schemes to be supported in later versions. ¶

There may be a situation where the report generator attempts to deliver duplicate information to the receiver. This may manifest as an exact duplicate of the report or as duplicate information between two reports. In these situations, the decision of how to handle the duplicate data lies with the receiver. As noted above, the sender MUST use the same unique identifiers when sending the report. This allows the receiver to better understand when duplicates happen. Here are a few options on how to handle that duplicate information: ¶

When accepting the data, it's likely that the duplicate data has not yet been noticed and is a one-off experience. Long-term duplicate data is not ideal. In the situation of a partial time frame overlap, there is no clear way to distinguish the impact of the overlap. The receiver would need to accept or reject the duplicate data in whole. ¶