DMARC Aggregate Reporting

1.1. Terminology

In many IETF documents, several words, when they are in all capitals as shown below, are used to signify the requirements in the specification. These capitalized words can bring significant clarity and consistency to documents because their meanings are well defined. This document defines how those words are interpreted in IETF documents when the words are in all capitals.¶

• These words can be used as defined here, but using them is not required. Specifically, normative text does not require the use of these key words. They are used for clarity and consistency when that is what's wanted, but a lot of normative text does not use them and is still normative.¶

• The words have the meanings specified herein only when they are in all capitals.¶

• When these words are not capitalized, they have their normal English meanings and are not affected by this document.¶

Authors who follow these guidelines should incorporate this phrase near the beginning of their document:¶

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
   "MAY", and "OPTIONAL" in this document are to be interpreted as
   described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
   appear in all capitals, as shown here.

2.1. Aggregate Reports

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

• authentication results,¶
• corrective action that needs to be taken by Domain Owners, and¶
• the effect of Domain Owner DMARC policy on email streams processed by Mail Receivers.¶

Aggregate DMARC feedback provides visibility into real-world email streams that Domain Owners need to make informed decisions regarding the publication of 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 about the policies they need and the steps they need to take to enable those policies. When Domain Owners set policies appropriately and understand their effects, Mail Receivers can act on them confidently.¶

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

The report may include the following data:¶

• The DMARC policy discovered and applied, if any¶
• The selected message disposition¶
• The identifier evaluated by SPF and the SPF 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 in alignment¶
• A separate report should be generated for each Policy Domain encountered during the reporting period. If there are multiple 5322.From domains that are included, those should result in distinct records within the report. See below for further explanation in "Handling Domains in Reports".¶
• Sending and receiving domains¶
• The policy requested by the Domain Owner and the policy actually applied (if different)¶
• The number of successful authentications¶
• The counts of messages based on all messages received, even if their delivery is ultimately blocked by other filtering agents.¶

The format for these reports is defined in Appendix A.¶

DMARC Aggregate Reports MUST contain three primary sections; one consisting of descriptive information (with two subsections), and the other a set of IP-focused row-based data. Each report MUST contain data for only one Author 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 informative section MUST contain two sub-sections. One will be the metadata section which MUST contain the fields related to org_name, email, report_id, and date_range. Optional fields MAY include extra_contact_info, an error field, and an optional version field. The version field, if present, MUST contain a 1.0 [!@RFC7489] or 2.0 [RefNeeded], noting to which version of the aggregate reporting specification the report adheres. The date_range section which will note begin and end values as epoch timestamps. The other sub-section will be the policy_published, and record the policy configuration observed by the receiving system. Mandatory fields are domain, p, sp. Optional fields are fo, adkim, aspf, testing, and version_published. There MAY be an optional third section for extensions.¶

Within the data section, the report will contain row(s) of data stating which IPs were seen to have delivered messages for the Author Domain to the receiving system. For each IP that is being reported, there will be at least one record element, which will then have each of a row, identifiers, and auth_results sub-element. Within the row element, there MUST be source_ip and count. There MUST also exist a policy_evaluated, with sub-elements of disposition, dkim, and spf. There MAY be an element for reason, meant to include 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 (possible values listed in Appendix A). The dkim and spf elements MUST be the evaluated values as they relate to DMARC, not the values the receiver may have used when overriding the policy. Within the identifiers element, there MUST exist the data that was used to apply policy for the given IP. In most cases, this will be a header_from element, which will contain the 5322.From domain from the message.¶

There MUST be an auth_results element within the 'record' element. This will contain the data related to authenticating the messages associated with this sending IP. The dkim sub-element is optional as not all messages are signed, while there MUST be one spf sub-element. These elements MUST have a domain that was used during validation, as well as result. The dkim element MUST include a selector element that was observed during validation. For the spf element, the result element MUST contain a lower-case string where the value is one of none/neutral/pass/fail/softfail/temperror/permerror. The dkim result MUST contain a lower-case string where the value is one of none/pass/fail/policy/neutral/temperror/permerror. Both the spf and dkim results may optionally include a human_readable field meant for the report to convey more descriptive information back to the domain holder relating to evaluation failures. There MAY exist an optional section for extensions.¶

2.2. Extensions

There MAY be optional sections for extensions within the document. The absence or existence of this section SHOULD NOT create an error when processing reports. This will be covered in a separate section.¶

2.3. Changes in Policy During Reporting Period

Note that Domain Owners or their agents may change the published DMARC policy 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:¶

• generate for such a reporting period a single aggregate report that includes message dispositions based on the old policy, or a mix of the two policies, even though the report only contains a single "policy_published" element;¶
• generate multiple reports for the same period, one for each published policy occurring during the reporting period;¶
• generate a report whose end time occurs when the updated policy was detected, regardless of any requested report interval.¶

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 and Domain Owners to be aware of this situation and allow for such mixed reports during the propagation of the new policy to Mail Receivers.¶

2.4. Recommended Reporting Periods

Aggregate reports are most useful when they all cover a common time period. By contrast, correlation of these reports from multiple generators when they cover incongruent time periods is difficult or impossible. Report generators SHOULD, wherever possible, adhere to hour boundaries for the reporting period they are using. For example, starting a per-day report at 00:00; starting per-hour reports at 00:00, 01:00, 02:00; etc. Report generators using a 24-hour report period are strongly encouraged to begin that period at 00:00 UTC, regardless of local timezone or time of report production, in order to facilitate correlation.¶

2.5. Report Request Discovery

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.¶

2.6. Transport

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.¶

The Mail Receiver, after preparing a report, MUST evaluate the provided reporting URIs in the order given. Any reporting URI that includes a size limitation exceeded by the generated report (after compression and after any encoding required by the particular transport mechanism) MUST NOT be used. An attempt MUST be made to deliver an aggregate report to every remaining URI, up to the Receiver's limits on supported URIs.¶

If transport 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, or all provided URIs specify size limits exceeded by the generated record), the Mail Receiver MAY send a short report (see Section 7.2.2) indicating that a report is available but could not be sent. The Mail Receiver MAY cache that data and try again later, or MAY discard data that could not be sent.¶

 filename = receiver "!" policy-domain "!" begin-timestamp
            "!" end-timestamp [ "!" unique-id ] "." extension

 receiver = domain
            ; imported from [MAIL]

 policy-domain   = domain

 begin-timestamp = 1*DIGIT
                   ; seconds since 00:00:00 UTC January 1, 1970
                   ; indicating start of the time range contained
                   ; in the report

 end-timestamp = 1*DIGIT
                 ; seconds since 00:00:00 UTC January 1, 1970
                 ; indicating end of the time range contained
                 ; in the report

 unique-id = 1*(ALPHA / DIGIT)

 extension = "xml" / "xml.gz"

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

 dmarc-subject = %x52.65.70.6f.72.74 1*FWS       ; "Report"
                 %x44.6f.6d.61.69.6e.3a 1*FWS    ; "Domain:"
                 domain-name 1*FWS               ; from RFC 6376
                 %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
                 1*FWS domain-name 1*FWS
                 %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
                 msg-id                          ; from RFC 5322

 Subject: Report Domain: example.com
     Submitter: mail.receiver.example
     Report-ID: <2002.02.15.1>

6.1. Data Exposure Considerations

Aggregate reports are limited in scope to DMARC policy and disposition results, to information pertaining to the underlying authentication mechanisms, and to the identifiers involved in DMARC validation.¶

Aggregate report may expose sender and recipient identifiers, specifically the RFC5322.From addresses.¶

Domain Owners requesting reports will receive information about mail claiming to be from them, which includes mail that was not, in fact, from them. Information about the final destination of mail where it might otherwise be obscured by intermediate systems will therefore be exposed.¶

When message-forwarding arrangements exist, Domain Owners requesting reports will also receive information about mail forwarded to domains that were not originally part of their messages' recipient lists. This means that destination domains previously unknown to the Domain Owner may now become visible.¶

Disclosure of information about the messages is being requested by the entity generating the email in the first place, i.e., the Domain Owner and not the Mail Receiver, so this may not fit squarely within existing privacy policy provisions. For some providers, aggregate reporting is viewed as a function similar to complaint reporting about spamming or phishing and are treated similarly under the privacy policy. Report generators (i.e., Mail Receivers) are encouraged to review their reporting limitations under such policies before enabling DMARC reporting.¶

6.2. Report Recipients

A DMARC record can specify that reports should be sent to an intermediary operating on behalf of the Domain Owner. This is done when the Domain Owner contracts with an entity to monitor mail streams for abuse and performance issues. Receipt by third parties of such data may or may not be permitted by the Mail Receiver's privacy policy, terms of use, or other similar governing document. Domain Owners and Mail Receivers should both review and understand if their own internal policies constrain the use and transmission of DMARC reporting.¶

Some potential exists for report recipients to perform traffic analysis, making it possible to obtain metadata about the Receiver's traffic. In addition to verifying compliance with policies, Receivers need to consider that before sending reports to a third party.¶

6.3. Data Contained Within Reports (Tkt64)

Aggregate feedback reports contain aggregated data relating to messages purportedly originating from the Domain Owner. The data does not contain any identifying characteristics about individual users. No personal information such as individual email addresses, IP addresses of individuals, or the content of any messages, is included in reports.¶

Mail Receivers should have no concerns in sending reports as they do not contain personal information. In all cases, the data within the reports relates to the domain-level authentication information provided by mail servers sending messages on behalf of the Domain Owner. This information is necessary to assist Domain Owners in implementing and maintaining DMARC.¶

Domain Owners should have no concerns in receiving reports as they do not contain personal information. The reports only contain aggregated data related to the domain-level authentication details of messages claiming to originate from their domain. This information is essential for the proper implementation and operation of DMARC. Domain Owners who are unable to receive reports for organizational reasons, can choose to exclusively direct the reports to an external processor.¶