Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting
Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows for Domain Owners to request aggregate reports from receivers. This report is an XML document and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted by the receiver to the Domain Owner's specified destination as declared in the associated DNS record. This document obsoletes RFC 7489.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 39 must, 7 should, 10 may.
3.1 Aggregate Reports
- MUSTA separate report MUST be generated for each DMARC Policy Domain encountered during the reporting period.
- MUSTEach report MUST contain data for only one DMARC Policy Domain.
- MUSTA single report MUST contain data for one policy configuration.
- MAYIf 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.
3.1.1 Description of the Content of the XML File
- SHOULDIf a document does not match the specified format, the document evaluator SHOULD discard the report.
- MAYThe evaluator MAY choose to try to utilize some of the data; however, if the format is in question, the data may be as well.
- MAYThe report evaluator MAY choose to contact the report generator so that they may be alerted to an issue with the report format.
- OPTIONALO: OPTIONAL, zero or one element
- REQUIREDR: REQUIRED, exactly one element
- OPTIONAL*: OPTIONAL, zero or more elements
- REQUIRED+: REQUIRED, one or more elements
3.1.1.2 First Level Elements
- MUSTThe elements in this table MUST appear in the order listed.
- MUST+==================+===+============================================+ | Element name | # | Content | +==================+===+============================================+ | version | O | MUST have the value 1.0.
- MUSTThere 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.
3.1.1.4 Contents of the "date_range" Element
- SHOULD NOTWhen generating reports, these reporting periods SHOULD NOT overlap.
3.1.1.6 Contents of the "extension" Element
- MUSTThese elements MUST be namespaced.
3.1.1.7 Contents of the "record" Element
- MUSTThe 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.
- MUSTUse of extensions may cause other elements to be added to the end of the record; such elements MUST be namespaced.
3.1.1.9 Contents of the "policy_evaluated" Element
- MUSTIf alignment fails and the policy applied does not match the DMARC Policy Domain's configured policy, the "reason" element MUST be included.
- MUST* "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.
3.1.1.10 Contents of the "identifiers" Element
- MAY* "envelope_from" MAY exist but be empty if the message had a null reverse-path (see Section 4.5.5 of [RFC5321]).
3.1.1.11 Contents of the "auth_results" Element
- MUSTIf 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).
3.1.2 Handling Domains in Reports
- MUSTIn the same report, there MUST be a single DMARC Policy Domain, though there could be multiple RFC5322.From domains.
3.1.3 DKIM Signatures in Aggregate Reports
- SHOULDA report SHOULD contain no more than 100 signatures for a given "row", in decreasing priority.
3.1.4 Unique Identifiers in Aggregate Reporting
- MUSTThese are the fields that MUST be identical when used.
3.1.6 Policy Override Reason
- MUSTThe "type" element MUST have one of the pre-defined values listed below.
3.2 Extensions
- SHOULD NOTThe absence or existence of this section SHOULD NOT create an error when processing reports.
3.5 Report Delivery
- MUSTThe Mail Receiver, after preparing a report, MUST evaluate the provided reporting URIs (see [RFC9989]) in the order given.
- SHOULDIf any of the URIs are malformed, they SHOULD be ignored.
- MUSTAn attempt MUST be made to deliver an aggregate report to every remaining URI, up to the Receiver's limits on supported URIs.
- MAYIf 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.
- SHOULDWhere 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).
3.5.1 Definition of Report-ID
- MUSTThis identifier MUST be unique among reports to the same domain to aid receivers in identifying duplicate reports should they happen.
3.5.2 Email
- MUSTThe message generated by the Mail Receiver MUST be as described in [RFC5322] and formatted per [RFC2045].
- MUSTThe aggregate report itself MUST be included in one of the parts of the message, as an attachment with a corresponding media type from below.
- MAYA human-readable annotation MAY be included as a body part (with a human-friendly content-type, such as "text/plain" or "text/html").
- MUSTThe aggregate data MUST be an XML file that SHOULD be subjected to GZIP [RFC1952] compression.
- MUSTThe aggregate data MUST be present using the media type "application/gzip" if compressed (see [RFC6713]) and "text/xml" otherwise.
- MUSTThe attachment filename MUST be constructed using the following ABNF:
- MUSTThe extension MUST be "xml" for a plain XML file or "xml.gz" for an XML file compressed using GZIP.
- MUSTIf a report generator needs to re-send a report, the system MUST use the same filename as the original report.
- MUSTMail streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 4.4 of [RFC9989]).
- MUSTThe RFC5322.Subject field for individual report submissions MUST conform to the following ABNF:
- MAYOptionally, 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.
3.5.4 Handling of Duplicates
- MUSTAs noted above, the sender MUST use the same unique identifiers when sending the report.
4 Verifying External Destinations
- MUSTWhen a Mail Receiver discovers a DMARC Policy Record in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [RFC3986] specified in the "rua" tag, the following verification steps MUST be taken:
- MAYIf the result of this request is a temporary DNS error of some kind (e.g., a timeout), the Mail Receiver MAY elect to temporarily fail the delivery so the verification test can be repeated later.
- MUSTIn particular, the "v=DMARC1" tag is mandatory and MUST appear first in the list.
- MUSTHowever, to prevent loops or indirect abuse, the overriding URI MUST use the same destination host from the first step.
- MUSTWhere the above algorithm fails to confirm that the external reporting was authorized by the Report Consumer, the URI MUST be ignored by the Mail Receiver generating the report.
- MUST NOTFurther, if the confirming record includes a URI whose host is again different than the domain publishing that override, the Mail Receiver generating the report MUST NOT generate a report to either the original or the override URI.
5 Extensible Reporting
- MUSTThese extensions MUST be properly formatted XML and meant to exist within the structure of a DMARC report.
- MUSTIn either case, the extensions MUST contain a URI to the definition of the extension so that the receiver understands how to interpret the data.
- SHOULDIf a processor is unable to handle an extension in a report, it SHOULD ignore the data and continue to the next extension.
7.3 Feedback Leakage
- MUSTTo minimize this potential concern, PSD DMARC feedback MUST be limited to aggregate reports.
10.2 Informative References
- MUSTIf alignment fails and the policy applied does not match the domain's configured policy, the reason element MUST be specified.