RFC 7489
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
7. DMARC Feedback
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.7.1. Verifying External Destinations
It is possible to specify destinations for the different reports that are outside the authority of the Domain Owner making the request. This allows domains that do not operate mail servers to request reports and have them go someplace that is able to receive and process them. Without checks, this would allow a bad actor to publish a DMARC 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 checks to a wide variety of destinations; the victim will in turn be flooded with unwanted reports. Therefore, a verification mechanism is included. When a Mail Receiver discovers a DMARC policy 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 [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:reports@red.example.net", 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.7.2. Aggregate Reports
The DMARC aggregate feedback report is designed to provide Domain Owners with precise insight into: o authentication results, o corrective action that needs to be taken by Domain Owners, and o 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 format for these reports is defined in 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.7.2.1. 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 SHOULD 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.
7.2.1.1. Email
The message generated by the Mail Receiver MUST be a [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 = %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
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.
7.2.1.2. Other Methods
The specification as written allows for the addition of other registered URI schemes to be supported in later versions.7.2.2. Error Reports
When a Mail Receiver is unable to complete delivery of a report via any of the URIs listed by the Domain Owner, the Mail Receiver SHOULD generate an error message. An attempt MUST be made to send this report to all listed "mailto" URIs, and it MAY also be sent to any or all other listed URIs. The error report MUST be formatted per [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.
7.3. Failure Reports
Failure reports are normally generated and sent almost immediately after the Mail Receiver detects a DMARC failure. Rather than waiting for an aggregate report, these reports are useful for quickly notifying the Domain Owners when there is an authentication failure. Whether the failure is due to an infrastructure problem or the message is inauthentic, failure reports also provide more information about the failed message than is available in an aggregate report. These reports SHOULD include any URI(s) from the message that failed authentication. These reports SHOULD include as much of the message and message header as is reasonable to support the Domain Owner's investigation into what caused the message to fail authentication and track down the sender. When a Domain Owner requests failure reports for the purpose of forensic analysis, and the Mail Receiver is willing to provide such reports, the Mail Receiver generates and sends a message using the format described in [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).
7.3.1. Reporting Format Update
Operators implementing this specification also implement an augmented version of [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.8. Minimum Implementations
A minimum implementation of DMARC has the following characteristics: o Is able to send and/or receive reports at least daily; o Is able to send and/or receive reports using "mailto" URIs;
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.
9. Privacy Considerations
This section discusses security issues specific to private data that
may be included in the interactions that are part of DMARC.
9.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.
Failed-message reporting provides message-specific details pertaining
to authentication failures. Individual reports can contain message
content as well as trace header fields. Domain Owners are able to
analyze individual reports and attempt to determine root causes of
authentication mechanism failures, gain insight into
misconfigurations or other problems with email and network
infrastructure, or inspect messages for insight into abusive
practices.
Both report types may expose sender and recipient identifiers (e.g.,
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
existing privacy policy provisions. For some providers, aggregate reporting and failed-message reporting are 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.9.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.10. Other Topics
This section discusses some topics regarding choices made in the development of DMARC, largely to commit the history to record.10.1. Issues Specific to SPF
Though DMARC does not inherently change the semantics of an SPF policy record, historically lax enforcement of such policies has led many to publish extremely broad records containing many large network ranges. Domain Owners are strongly encouraged to carefully review their SPF records to understand which networks are authorized to send on behalf of the Domain Owner before publishing a DMARC record. Some receiver architectures might implement SPF in advance of any DMARC operations. This means that a "-" prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Operators choosing to use "-all" should be aware of this.
10.2. DNS Load and Caching
DMARC policies are communicated using the DNS and therefore inherit a number of considerations related to DNS caching. The inherent conflict between freshness and the impact of caching on the reduction of DNS-lookup overhead should be considered from the Mail Receiver's point of view. Should Domain Owners publish a DNS record with a very short TTL, Mail Receivers can be provoked through the injection of large volumes of messages to overwhelm the Domain Owner's DNS. Although this is not a concern specific to DMARC, the implications of a very short TTL should be considered when publishing DMARC policies. Conversely, long TTLs will cause records to be cached for long periods of time. This can cause a critical change to DMARC parameters advertised by a Domain Owner to go unnoticed for the length of the TTL (while waiting for DNS caches to expire). Avoiding this problem can mean shorter TTLs, with the potential problems described above. A balance should be sought to maintain responsiveness of DMARC preference changes while preserving the benefits of DNS caching.10.3. Rejecting Messages
This proposal calls for rejection of a message during the SMTP session under certain circumstances. This is preferable to generation of a Delivery Status Notification ([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.
10.4. Identifier Alignment Considerations
The DMARC mechanism allows both DKIM and SPF-authenticated
identifiers to authenticate email on behalf of a Domain Owner and,
possibly, on behalf of different subdomains. If malicious or unaware
users can gain control of the SPF record or DKIM selector records for
a subdomain, the subdomain can be used to generate DMARC-passing
email on behalf of the Organizational Domain.
For example, an attacker who controls the SPF record for
"evil.example.com" can send mail with an RFC5322.From field
containing "foo@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.
10.5. Interoperability Issues
DMARC limits which end-to-end scenarios can achieve a "pass" result.
Because DMARC relies on [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.11. IANA Considerations
This section describes actions completed by IANA.11.1. Authentication-Results Method Registry Update
IANA has added the following to the "Email Authentication Methods" registry: Method: dmarc Defined: RFC 7489 ptype: header Property: from Value: the domain portion of the RFC5322.From field Status: active Version: 111.2. Authentication-Results Result Registry Update
IANA has added the following in the "Email Authentication Result Names" registry: Code: none Existing/New Code: existing Defined: [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: active11.3. Feedback Report Header Fields Registry Update
The following has been added to the "Feedback Report Header Fields" registry: Field Name: Identity-Alignment Description: indicates whether the message about which a report is being generated had any identifiers in alignment as defined in RFC 7489 Multiple Appearances: No Related "Feedback-Type": auth-failure Reference: RFC 7489 Status: current11.4. DMARC Tag Registry
A new registry tree called "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters" has been created. Within it, a new sub-registry called the "DMARC Tag Registry" has been created. Names of DMARC tags must be registered with IANA in this new sub-registry. New entries are assigned only for values that have been documented in a manner that satisfies the terms of Specification Required, per [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 |
+----------+-------------+---------+------------------------------+
11.5. DMARC Report Format Registry
Also within "Domain-based Message Authentication, Reporting, and
Conformance (DMARC) Parameters", a new sub-registry called "DMARC
Report Format Registry" has been created.
Names of DMARC failure reporting formats must be registered with IANA
in this registry. New entries are assigned only for values that
satisfy the definition of Specification Required, per
[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]) | +--------+-------------+---------+-----------------------------+12. Security Considerations
This section discusses security issues and possible remediations (where available) for DMARC.12.1. Authentication Methods
Security considerations from the authentication methods used by DMARC are incorporated here by reference.12.2. Attacks on Reporting URIs
URIs published in DNS TXT records are well-understood possible targets for attack. Specifications such as [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.
12.3. DNS Security
The DMARC mechanism and its underlying technologies (SPF, DKIM)
depend on the security of the DNS. To reduce the risk of subversion
of the DMARC mechanism due to DNS-based exploits, serious
consideration should be given to the deployment of DNSSEC in parallel
with the deployment of DMARC by both Domain Owners and Mail
Receivers.
Publication of data using DNSSEC is relevant to Domain Owners and
third-party Report Receivers. DNSSEC-aware resolution is relevant to
Mail Receivers and Report Receivers.
12.4. Display Name Attacks
A common attack in messaging abuse is the presentation of false
information in the display-name portion of the 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: "user@example.org via Bug Tracker" <support@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.
12.5. External Reporting Addresses
To avoid abuse by bad actors, reporting addresses generally have to
be inside the domains about which reports are requested. In order to
accommodate special cases such as a need to get reports about domains
that cannot actually receive mail, 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.
12.6. Secure Protocols
This document encourages use of secure transport mechanisms to
prevent loss of private data to third parties that may be able to
monitor such transmissions. Unencrypted mechanisms should be
avoided.
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.
(page 49 continued on part 4)
