URI] specified in the "rua" or "ruf" tag, the following verification steps are to be taken: 1. Extract the host portion of the authority component of the URI. Call this the "destination host", as it refers to a Report Receiver. 2. Prepend the string "_report._dmarc".
3. Prepend the domain name from which the policy was retrieved, after conversion to an A-label if needed. 4. Query the DNS for a TXT record at the constructed name. If the result of this request is a temporary DNS error of some kind (e.g., a timeout), the Mail Receiver MAY elect to temporarily fail the delivery so the verification test can be repeated later. 5. For each record returned, parse the result as a series of "tag=value" pairs, i.e., the same overall format as the policy record (see Section 6.4). In particular, the "v=DMARC1" tag is mandatory and MUST appear first in the list. Discard any that do not pass this test. 6. If the result includes no TXT resource records that pass basic parsing, a positive determination of the external reporting relationship cannot be made; stop. 7. If at least one TXT resource record remains in the set after parsing, then the external reporting arrangement was authorized by the Report Receiver. 8. If a "rua" or "ruf" tag is thus discovered, replace the corresponding value extracted from the domain's DMARC policy record with the one found in this record. This permits the Report Receiver to override the report destination. However, to prevent loops or indirect abuse, the overriding URI MUST use the same destination host from the first step. For example, if a DMARC policy query for "blue.example.com" contained "rua=mailto:firstname.lastname@example.org", the host extracted from the latter ("red.example.net") does not match "blue.example.com", so this procedure is enacted. A TXT query for "blue.example.com._report._dmarc.red.example.net" is issued. If a single reply comes back containing a tag of "v=DMARC1", then the relationship between the two is confirmed. Moreover, "red.example.net" has the opportunity to override the report destination requested by "blue.example.com" if needed. Where the above algorithm fails to confirm that the external reporting was authorized by the Report Receiver, the URI MUST be ignored by the Mail Receiver generating the report. Further, if the confirming record includes a URI whose host is again different than the domain publishing that override, the Mail Receiver generating the report MUST NOT generate a report to either the original or the override URI.
A Report Receiver publishes such a record in its DNS if it wishes to receive reports for other domains. A Report Receiver that is willing to receive reports for any domain can use a wildcard DNS record. For example, a TXT resource record at "*._report._dmarc.example.com" containing at least "v=DMARC1" confirms that example.com is willing to receive DMARC reports for any domain. If the Report Receiver is overcome by volume, it can simply remove 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 go into effect. A Mail Receiver might decide not to enact this procedure if, for example, it relies on a local list of domains for which external reporting addresses are permitted. Appendix C.
The report SHOULD include the following data: o The DMARC policy discovered and applied, if any o The selected message disposition o The identifier evaluated by SPF and the SPF result, if any o The identifier evaluated by DKIM and the DKIM result, if any o For both DKIM and SPF, an indication of whether the identifier was in alignment o Data for each Domain Owner's subdomain separately from mail from the sender's Organizational Domain, even if there is no explicit subdomain policy o Sending and receiving domains o The policy requested by the Domain Owner and the policy actually applied (if different) o The number of successful authentications o The counts of messages based on all messages received, even if their delivery is ultimately blocked by other filtering agents 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: o 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; o generate multiple reports for the same period, one for each published policy occurring during the reporting period; o 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. 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. 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. 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.
MAIL] message formatted per [MIME]. The aggregate report itself MUST be included in one of the parts of the message. A human-readable portion MAY be included as a MIME part (such as a text/plain part). The aggregate data MUST be an XML file that SHOULD be subjected to GZIP compression. Declining to apply compression can cause the report to be too large for a receiver to process (a commonly observed receiver limit is ten megabytes); doing the compression increases the chances of acceptance of the report at some compute cost. The aggregate data SHOULD be present using the media type "application/ gzip" if compressed (see [GZIP]), and "text/xml" otherwise. The filename is typically constructed using the following ABNF: filename = receiver "!" policy-domain "!" begin-timestamp "!" end-timestamp [ "!" unique-id ] "." extension unique-id = 1*(ALPHA / DIGIT) 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 extension = "xml" / "xml.gz" 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.
For example, this is a possible 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.gz No specific MIME message structure is required. It is presumed that the aggregate reporting address will be equipped to extract MIME parts with the prescribed media type and filename and ignore the rest. Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). This practice minimizes the risk of report consumers processing fraudulent reports. The RFC5322.Subject field for individual report submissions SHOULD conform to the following ABNF: dmarc-subject = %x184.108.40.206f.72.74 1*FWS ; "Report" %x44.6f.6d.61.69.6e.3a 1*FWS ; "Domain:" domain-name 1*FWS ; from RFC 6376 %x220.127.116.11d.18.104.22.168.72.3a ; "Submitter:" 1*FWS domain-name 1*FWS %x22.214.171.124f.72.74.2d.49.44.3a ; "Report-ID:" msg-id ; from RFC 5322 The first domain-name indicates the DNS domain name about which the report was generated. The second domain-name indicates the DNS domain name representing the Mail Receiver generating the report. The purpose of the Report-ID: portion of the field is to enable the Domain Owner to identify and ignore duplicate reports that might be sent by a Mail Receiver. 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 line-wrapped as allowed by [MAIL]: Subject: Report Domain: example.com Submitter: mail.receiver.example Report-ID: <2002.02.15.1> This transport mechanism potentially encounters a problem when feedback data size exceeds maximum allowable attachment sizes for either the generator or the consumer. See Section 7.2.2 for further discussion.
MIME]. A text/plain part MUST be included that contains field-value pairs such as those found in Section 2 of [DSN]. The fields required, which may appear in any order, are as follows: Report-Date: A [MAIL]-formatted date expression indicating when the transport failure occurred. Report-Domain: The domain-name about which the failed report was generated. Report-ID: The Report-ID: that the report tried to use. Report-Size: The size, in bytes, of the report that was unable to be sent. This MUST represent the number of bytes that the Mail Receiver attempted to send. Where more than one transport system was attempted, the sizes may be different; in such cases, separate error reports MUST be generated so that this value matches the actual attempt that was made. Submitter: The domain-name representing the Mail Receiver that generated, but was unable to submit, the report. Submitting-URI: The URI(s) to which the Mail Receiver tried, but failed, to submit the report. An additional text/plain part MAY be included that gives a human- readable explanation of the above and MAY also include a URI that can be used to seek assistance.
AFRF]; this document updates that reporting format, as described in Section 7.3.1. The destination(s) and nature of the reports are defined by the "ruf" and "fo" tags as defined in Section 6.3. Where multiple URIs are selected to receive failure reports, the report generator MUST make an attempt to deliver to each of them. An obvious consideration is the denial-of-service attack that can be perpetrated by an attacker who sends numerous messages purporting to be from the intended victim Domain Owner but that fail both SPF and DKIM; this would cause participating Mail Receivers to send failure reports to the Domain Owner or its delegate in potentially huge volumes. Accordingly, participating Mail Receivers are encouraged to aggregate these reports as much as is practical, using the Incidents field of the Abuse Reporting Format ([ARF]). Various aggregation techniques are possible, including the following: o only send a report to the first recipient of multi-recipient messages; o store reports for a period of time before sending them, allowing detection, collection, and reporting of like incidents; o apply rate limiting, such as a maximum number of reports per minute that will be generated (and the remainder discarded).
AFRF] as follows: 1. A DMARC failure report includes the following ARF header fields, with the indicated normative requirement levels: * Identity-Alignment (REQUIRED; defined below) * Delivery-Result (OPTIONAL) * DKIM-Domain, DKIM-Identity, DKIM-Selector (REQUIRED if the message was signed by DKIM) * DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (OPTIONAL if the message was signed by DKIM) * SPF-DNS (REQUIRED) 2. The "Identity-Alignment" field is defined to contain a comma- separated list of authentication mechanism names that produced an aligned identity, or the keyword "none" if none did. ABNF: id-align = "Identity-Alignment:" [CFWS] ( "none" / dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) ) [CFWS] dmarc-method = ( "dkim" / "spf" ) ; each may appear at most once in an id-align 3. Authentication Failure Type "dmarc" is defined, which is to be used when a failure report is generated because some or all of the authentication mechanisms failed to produce aligned identifiers. Note that a failure report generator MAY also independently produce an AFRF message for any or all of the underlying authentication methods.
o Other than in exceptional circumstances such as resource exhaustion, can generate or accept a report up to ten megabytes in size; o If acting as a Mail Receiver, fully implements the provisions of Section 6.6. RFC5322.From addresses), and although the [AFRF] format used for failed-message reporting supports redaction, failed-message reporting is capable of exposing the entire message to the report recipient. 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
DSN]), since fraudulent messages caught and rejected using DMARC would then result in annoying generation of such failure reports that go back to the RFC5321.MailFrom address. This synchronous rejection is typically done in one of two ways: o Full rejection, wherein the SMTP server issues a 5xy reply code as an indication to the SMTP client that the transaction failed; the SMTP client is then responsible for generating notification that delivery failed (see Section 4.2.5 of [SMTP]). o A "silent discard", wherein the SMTP server returns a 2xy reply code implying to the client that delivery (or, at least, relay) was successfully completed, but then simply discarding the message with no further action. Each of these has a cost. For instance, a silent discard can help to prevent backscatter, but it also effectively means that the SMTP server has to be programmed to give a false result, which can confound external debugging efforts.
Similarly, the text portion of the SMTP reply may be important to consider. For example, when rejecting a message, revealing the reason for the rejection might give an attacker enough information to bypass those efforts on a later attempt, though it might also assist a legitimate client to determine the source of some local issue that caused the rejection. In the latter case, when doing an SMTP rejection, providing a clear hint can be useful in resolving issues. A receiver might indicate in plain text the reason for the rejection by using the word "DMARC" somewhere in the reply text. Many systems are able to scan the SMTP reply text to determine the nature of the rejection. Thus, providing a machine-detectable reason for rejection allows the problems causing rejections to be properly addressed by automated systems. For example: 550 5.7.1 Email rejected per DMARC policy for example.com If a Mail Receiver elects to defer delivery due to inability to retrieve or apply DMARC policy, this is best done with a 4xy SMTP reply code. RFC5322.From field containing "email@example.com" that can pass both authentication and the DMARC check against "example.com". The Organizational Domain administrator should be careful not to delegate control of subdomains if this is an issue, and to consider using the "strict" Identifier Alignment option if appropriate. SPF] and/or [DKIM] to achieve a "pass", their limitations also apply.
Additional DMARC constraints occur when a message is processed by some Mediators, such as mailing lists. Transiting a Mediator often causes either the authentication to fail or Identifier Alignment to be lost. These transformations may conform to standards but will still prevent a DMARC "pass". In addition to Mediators, mail that is sent by authorized, independent third parties might not be sent with Identifier Alignment, also preventing a "pass" result. Issues specific to the use of policy mechanisms alongside DKIM are further discussed in [DKIM-LISTS], particularly Section 5.2. RFC5322.From field Status: active Version: 1 AUTH-RESULTS] Auth Method: dmarc (added)
Meaning: No DMARC policy record was published for the aligned identifier, or no aligned identifier could be extracted. Status: active Code: pass Existing/New Code: existing Defined: [AUTH-RESULTS] Auth Method: dmarc (added) Meaning: A DMARC policy record was published for the aligned identifier, and at least one of the authentication mechanisms passed. Status: active Code: fail Existing/New Code: existing Defined: [AUTH-RESULTS] Auth Method: dmarc (added) Meaning: A DMARC policy record was published for the aligned identifier, and none of the authentication mechanisms passed. Status: active Code: temperror Existing/New Code: existing Defined: [AUTH-RESULTS] Auth Method: dmarc (added) Meaning: A temporary error occurred during DMARC evaluation. A later attempt might produce a final result. Status: active
Code: permerror Existing/New Code: existing Defined: [AUTH-RESULTS] Auth Method: dmarc (added) Meaning: A permanent error occurred during DMARC evaluation, such as encountering a syntactically incorrect DMARC record. A later attempt is unlikely to produce a final result. Status: active IANA-CONSIDERATIONS]. Each registration must include the tag name; the specification that defines it; a brief description; and its status, which must be one of "current", "experimental", or "historic". The Designated Expert needs to confirm that the provided
specification adequately describes the new tag and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers. To avoid version compatibility issues, tags added to the DMARC specification are to avoid changing the semantics of existing records when processed by implementations conforming to prior specifications. The initial set of entries in this registry is as follows: +----------+-------------+---------+------------------------------+ | Tag Name | Reference | Status | Description | +----------+-------------+---------+------------------------------+ | adkim | RFC 7489 | current | DKIM alignment mode | +----------+-------------+---------+------------------------------+ | aspf | RFC 7489 | current | SPF alignment mode | +----------+-------------+---------+------------------------------+ | fo | RFC 7489 | current | Failure reporting options | +----------+-------------+---------+------------------------------+ | p | RFC 7489 | current | Requested handling policy | +----------+-------------+---------+------------------------------+ | pct | RFC 7489 | current | Sampling rate | +----------+-------------+---------+------------------------------+ | rf | RFC 7489 | current | Failure reporting format(s) | +----------+-------------+---------+------------------------------+ | ri | RFC 7489 | current | Aggregate Reporting interval | +----------+-------------+---------+------------------------------+ | rua | RFC 7489 | current | Reporting URI(s) for | | | | | aggregate data | +----------+-------------+---------+------------------------------+ | ruf | RFC 7489 | current | Reporting URI(s) for | | | | | failure data | +----------+-------------+---------+------------------------------+ | sp | RFC 7489 | current | Requested handling policy | | | | | for subdomains | +----------+-------------+---------+------------------------------+ | v | RFC 7489 | current | Specification version | +----------+-------------+---------+------------------------------+
[IANA-CONSIDERATIONS]. In addition to a reference to a permanent specification, each registration must include the format name; a brief description; and its status, which must be one of "current", "experimental", or "historic". The Designated Expert needs to confirm that the provided specification adequately describes the report format and clearly presents how it would be used within the DMARC context by Domain Owners and Mail Receivers. The initial entry in this registry is as follows: +--------+-------------+---------+-----------------------------+ | Format | Reference | Status | Description | | Name | | | | +--------+-------------+---------+-----------------------------+ | afrf | RFC 7489 | current | Authentication Failure | | | | | Reporting Format (see | | | | | [AFRF]) | +--------+-------------+---------+-----------------------------+ DNS] and [ROLES] either expose or cause the exposure of email addresses that could be flooded by an attacker, for example; MX, NS, and other records found in the DNS advertise potential attack destinations; common DNS names such as "www" plainly identify the locations at which particular services can be found, providing destinations for targeted denial-of-service or penetration attacks. Thus, Domain Owners will need to harden these addresses against various attacks, including but not limited to: o high-volume denial-of-service attacks; o deliberate construction of malformed reports intended to identify or exploit parsing or processing vulnerabilities;
o deliberate construction of reports containing false claims for the Submitter or Reported-Domain fields, including the possibility of false data from compromised but known Mail Receivers. RFC5322.From field. For example, it is possible for the email address in that field to be an arbitrary address or domain name, while containing a well-known name (a person, brand, role, etc.) in the display name, intending to fool the end user into believing that the name is used legitimately. The attack is predicated on the notion that most common MUAs will show the display name and not the email address when both are available. Generally, display name attacks are out of scope for DMARC, as further exploration of possible defenses against these attacks needs to be undertaken. There are a few possible mechanisms that attempt mitigation of these attacks, such as the following: o If the display name is found to include an email address (as specified in [MAIL]), execute the DMARC mechanism on the domain name found there rather than the domain name discovered originally. However, this addresses only a very specific attack space, and spoofers can easily circumvent it by simply not using an email address in the display name. There are also known cases of legitimate uses of an email address in the display name with a domain different from the one in the address portion, e.g., From: "firstname.lastname@example.org via Bug Tracker" <email@example.com>
o In the MUA, only show the display name if the DMARC mechanism succeeds. This too is easily defeated, as an attacker could arrange to pass the DMARC tests while fraudulently using another domain name in the display name. o In the MUA, only show the display name if the DMARC mechanism passes and the email address thus validated matches one found in the receiving user's list of known addresses. Section 7.1 describes a DNS-based mechanism for verifying approved external reporting. The obvious consideration here is an increased DNS load against domains that are claimed as external recipients. Negative caching will mitigate this problem, but only to a limited extent, mostly dependent on the default TTL in the domain's SOA record. Where possible, external reporting is best achieved by having the report be directed to domains that can receive mail and simply having it automatically forwarded to the desired external destination. Note that the addresses shown in the "ruf" tag receive more information that might be considered private data, since it is possible for actual email content to appear in the failure reports. The URIs identified there are thus more attractive targets for intrusion attempts than those found in the "rua" tag. Moreover, attacking the DNS of the subject domain to cause failure data to be routed fraudulently to an attacker's systems may be an attractive prospect. Deployment of [DNSSEC] is advisable if this is a concern. The verification mechanism presented in Section 7.1 is currently not mandatory ("MUST") but strongly recommended ("SHOULD"). It is possible that it would be elevated to a "MUST" by later security review.
In particular, a message that was originally encrypted or otherwise secured might appear in a report that is not sent securely, which could reveal private information.