RFC 7489
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Independent Submission M. Kucherawy, Ed. Request for Comments: 7489 Category: Informational E. Zwicky, Ed. ISSN: 2070-1721 Yahoo! March 2015 Domain-based Message Authentication, Reporting, and Conformance (DMARC)Abstract
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7489.
Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.Table of Contents
1. Introduction ....................................................3 2. Requirements ....................................................5 2.1. High-Level Goals ...........................................5 2.2. Out of Scope ...............................................6 2.3. Scalability ................................................6 2.4. Anti-Phishing ..............................................7 3. Terminology and Definitions .....................................7 3.1. Identifier Alignment .......................................8 3.2. Organizational Domain .....................................11 4. Overview .......................................................12 4.1. Authentication Mechanisms .................................12 4.2. Key Concepts ..............................................12 4.3. Flow Diagram ..............................................13 5. Use of RFC5322.From ............................................15 6. Policy .........................................................15 6.1. DMARC Policy Record .......................................16 6.2. DMARC URIs ................................................16 6.3. General Record Format .....................................17 6.4. Formal Definition .........................................21 6.5. Domain Owner Actions ......................................22 6.6. Mail Receiver Actions .....................................23 6.7. Policy Enforcement Considerations .........................27 7. DMARC Feedback .................................................28 7.1. Verifying External Destinations ...........................28 7.2. Aggregate Reports .........................................30 7.3. Failure Reports ...........................................36 8. Minimum Implementations ........................................37 9. Privacy Considerations .........................................38 9.1. Data Exposure Considerations ..............................38 9.2. Report Recipients .........................................39
10. Other Topics ..................................................39 10.1. Issues Specific to SPF ...................................39 10.2. DNS Load and Caching .....................................40 10.3. Rejecting Messages .......................................40 10.4. Identifier Alignment Considerations ......................41 10.5. Interoperability Issues ..................................41 11. IANA Considerations ...........................................42 11.1. Authentication-Results Method Registry Update ............42 11.2. Authentication-Results Result Registry Update ............42 11.3. Feedback Report Header Fields Registry Update ............44 11.4. DMARC Tag Registry .......................................44 11.5. DMARC Report Format Registry .............................45 12. Security Considerations .......................................46 12.1. Authentication Methods ...................................46 12.2. Attacks on Reporting URIs ................................46 12.3. DNS Security .............................................47 12.4. Display Name Attacks .....................................47 12.5. External Reporting Addresses .............................48 12.6. Secure Protocols .........................................48 13. References ....................................................49 13.1. Normative References .....................................49 13.2. Informative References ...................................50 Appendix A. Technology Considerations .............................52 A.1. S/MIME .....................................................52 A.2. Method Exclusion ...........................................53 A.3. Sender Header Field ........................................53 A.4. Domain Existence Test ......................................54 A.5. Issues with ADSP in Operation ..............................54 A.6. Organizational Domain Discovery Issues .....................55 Appendix B. Examples ..............................................56 B.1. Identifier Alignment Examples ..............................56 B.2. Domain Owner Example .......................................58 B.3. Mail Receiver Example .....................................63 B.4. Utilization of Aggregate Feedback: Example .................64 B.5. mailto Transport Example ...................................65 Appendix C. DMARC XML Schema ......................................66 Acknowledgements ..................................................73 Authors' Addresses ................................................731. Introduction
The Sender Policy Framework ([SPF]) and DomainKeys Identified Mail ([DKIM]) provide domain-level authentication. They enable cooperating email receivers to detect mail authorized to use the domain name, which can permit differential handling. (A detailed discussion of the threats these systems attempt to address can be found in [DKIM-THREATS].) However, there has been no single widely accepted or publicly available mechanism to communication of
domain-specific message-handling policies for receivers, or to
request reporting of authentication and disposition of received mail.
Absent the ability to obtain feedback reports, originators who have
implemented email authentication have difficulty determining how
effective their authentication is. As a consequence, use of
authentication failures to filter mail typically does not succeed.
Over time, one-on-one relationships were established between select
senders and receivers with privately communicated means to assert
policy and receive message traffic and authentication disposition
reporting. Although these ad hoc practices have been generally
successful, they require significant manual coordination between
parties, and this model does not scale for general use on the
Internet.
This document defines Domain-based Message Authentication, Reporting,
and Conformance (DMARC), a mechanism by which email operators
leverage existing authentication and policy advertisement
technologies to enable both message-stream feedback and enforcement
of policies against unauthenticated email.
DMARC allows Domain Owners and receivers to collaborate by:
1. Providing receivers with assertions about Domain Owners' policies
2. Providing feedback to senders so they can monitor authentication
and judge threats
The basic outline of DMARC is as follows:
1. Domain Owners publish policy assertions about domains via the
DNS.
2. Receivers compare the RFC5322.From address in the mail to the SPF
and DKIM results, if present, and the DMARC policy in DNS.
3. These receivers can use these results to determine how the mail
should be handled.
4. The receiver sends reports to the Domain Owner or its designee
about mail claiming to be from their domain.
Security terms used in this document are defined in [SEC-TERMS].
DMARC differs from previous approaches to policy advertisement (e.g., [SPF] and [ADSP]) in that: o Authentication technologies are: 1. decoupled from any technology-specific policy mechanisms, and 2. used solely to establish reliable per-message domain-level identifiers. o Multiple authentication technologies are used to: 1. reduce the impact of transient authentication errors 2. reduce the impact of site-specific configuration errors and deployment gaps 3. enable more use cases than any individual technology supports alone o Receiver-generated feedback is supported, allowing senders to establish confidence in authentication practices. o The domain name extracted from a message's RFC5322.From field is the primary identifier in the DMARC mechanism. This identifier is used in conjunction with the results of the underlying authentication technologies to evaluate results under DMARC. Experience with DMARC has revealed some issues of interoperability with email in general that require due consideration before deployment, particularly with configurations that can cause mail to be rejected. These are discussed in Section 10.2. Requirements
Specification of DMARC is guided by the following high-level goals, security dependencies, detailed requirements, and items that are documented as out of scope.2.1. High-Level Goals
DMARC has the following high-level goals: o Allow Domain Owners to assert the preferred handling of authentication failures, for messages purporting to have authorship within the domain. o Allow Domain Owners to verify their authentication deployment.
o Minimize implementation complexity for both senders and receivers,
as well as the impact on handling and delivery of legitimate
messages.
o Reduce the amount of successfully delivered spoofed email.
o Work at Internet scale.
2.2. Out of Scope
Several topics and issues are specifically out of scope for the
initial version of this work. These include the following:
o different treatment of messages that are not authenticated versus
those that fail authentication;
o evaluation of anything other than RFC5322.From;
o multiple reporting formats;
o publishing policy other than via the DNS;
o reporting or otherwise evaluating other than the last-hop IP
address;
o attacks in the RFC5322.From field, also known as "display name"
attacks;
o authentication of entities other than domains, since DMARC is
built upon SPF and DKIM, which authenticate domains; and
o content analysis.
2.3. Scalability
Scalability is a major issue for systems that need to operate in a
system as widely deployed as current SMTP email. For this reason,
DMARC seeks to avoid the need for third parties or pre-sending
agreements between senders and receivers. This preserves the
positive aspects of the current email infrastructure.
Although DMARC does not introduce third-party senders (namely
external agents authorized to send on behalf of an operator) to the
email-handling flow, it also does not preclude them. Such third
parties are free to provide services in conjunction with DMARC.
2.4. Anti-Phishing
DMARC is designed to prevent bad actors from sending mail that claims to come from legitimate senders, particularly senders of transactional email (official mail that is about business transactions). One of the primary uses of this kind of spoofed mail is phishing (enticing users to provide information by pretending to be the legitimate service requesting the information). Thus, DMARC is significantly informed by ongoing efforts to enact large-scale, Internet-wide anti-phishing measures. Although DMARC can only be used to combat specific forms of exact- domain spoofing directly, the DMARC mechanism has been found to be useful in the creation of reliable and defensible message streams. DMARC does not attempt to solve all problems with spoofed or otherwise fraudulent email. In particular, it does not address the use of visually similar domain names ("cousin domains") or abuse of the RFC5322.From human-readable <display-name>.3. Terminology and Definitions
This section defines terms used in the rest of the document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. Readers are encouraged to be familiar with the contents of [EMAIL-ARCH]. In particular, that document defines various roles in the messaging infrastructure that can appear the same or separate in various contexts. For example, a Domain Owner could, via the messaging security mechanisms on which DMARC is based, delegate the ability to send mail as the Domain Owner to a third party with another role. This document does not address the distinctions among such roles; the reader is encouraged to become familiar with that material before continuing. The following terms are also used: Authenticated Identifiers: Domain-level identifiers that are validated using authentication technologies are referred to as "Authenticated Identifiers". See Section 4.1 for details about the supported mechanisms. Author Domain: The domain name of the apparent author, as extracted from the RFC5322.From field.
Domain Owner: An entity or organization that owns a DNS domain. The
term "owns" here indicates that the entity or organization being
referenced holds the registration of that DNS domain. Domain
Owners range from complex, globally distributed organizations, to
service providers working on behalf of non-technical clients, to
individuals responsible for maintaining personal domains. This
specification uses this term as analogous to an Administrative
Management Domain as defined in [EMAIL-ARCH]. It can also refer
to delegates, such as Report Receivers, when those are outside of
their immediate management domain.
Identifier Alignment: When the domain in the RFC5322.From address
matches a domain validated by SPF or DKIM (or both), it has
Identifier Alignment.
Mail Receiver: The entity or organization that receives and
processes email. Mail Receivers operate one or more Internet-
facing Mail Transport Agents (MTAs).
Organizational Domain: The domain that was registered with a domain
name registrar. In the absence of more accurate methods,
heuristics are used to determine this, since it is not always the
case that the registered domain name is simply a top-level DNS
domain plus one component (e.g., "example.com", where "com" is a
top-level domain). The Organizational Domain is determined by
applying the algorithm found in Section 3.2.
Report Receiver: An operator that receives reports from another
operator implementing the reporting mechanism described in this
document. Such an operator might be receiving reports about its
own messages, or reports about messages related to another
operator. This term applies collectively to the system components
that receive and process these reports and the organizations that
operate them.
3.1. Identifier Alignment
Email authentication technologies authenticate various (and
disparate) aspects of an individual message. For example, [DKIM]
authenticates the domain that affixed a signature to the message,
while [SPF] can authenticate either the domain that appears in the
RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
HELO domain, or both. These may be different domains, and they are
typically not visible to the end user.
DMARC authenticates use of the RFC5322.From domain by requiring that
it match (be aligned with) an Authenticated Identifier. The
RFC5322.From domain was selected as the central identity of the DMARC
mechanism because it is a required message header field and therefore guaranteed to be present in compliant messages, and most Mail User Agents (MUAs) represent the RFC5322.From field as the originator of the message and render some or all of this header field's content to end users. Thus, this field is the one used by end users to identify the source of the message and therefore is a prime target for abuse. Many high-profile email sources, such as email service providers, require that the sending agent have authenticated before email can be generated. Thus, for these mailboxes, the mechanism described in this document provides recipient end users with strong evidence that the message was indeed originated by the agent they associate with that mailbox, if the end user knows that these various protections have been provided. Domain names in this context are to be compared in a case-insensitive manner, per [DNS-CASE]. It is important to note that Identifier Alignment cannot occur with a message that is not valid per [MAIL], particularly one with a malformed, absent, or repeated RFC5322.From field, since in that case there is no reliable way to determine a DMARC policy that applies to the message. Accordingly, DMARC operation is predicated on the input being a valid RFC5322 message object, and handling of such non-compliant cases is outside of the scope of this specification. Further discussion of this can be found in Section 6.6.1. Each of the underlying authentication technologies that DMARC takes as input yields authenticated domains as their outputs when they succeed. From the perspective of DMARC, each can be operated in a "strict" mode or a "relaxed" mode. A Domain Owner would normally select strict mode if it wanted Mail Receivers to apply DMARC processing only to messages bearing an RFC5322.From domain exactly matching the domains those mechanisms will verify. Relaxed mode can be used when the operator also wishes to affect message flows bearing subdomains of the verified domains.3.1.1. DKIM-Authenticated Identifiers
DMARC permits Identifier Alignment, based on the result of a DKIM authentication, to be strict or relaxed. (Note that these are not related to DKIM's "simple" and "relaxed" canonicalization modes.)
In relaxed mode, the Organizational Domains of both the [DKIM]- authenticated signing domain (taken from the value of the "d=" tag in the signature) and that of the RFC5322.From domain must be equal if the identifiers are to be considered aligned. In strict mode, only an exact match between both of the Fully Qualified Domain Names (FQDNs) is considered to produce Identifier Alignment. To illustrate, in relaxed mode, if a validated DKIM signature successfully verifies with a "d=" domain of "example.com", and the RFC5322.From address is "alerts@news.example.com", the DKIM "d=" domain and the RFC5322.From domain are considered to be "in alignment". In strict mode, this test would fail, since the "d=" domain does not exactly match the FQDN of the address. However, a DKIM signature bearing a value of "d=com" would never allow an "in alignment" result, as "com" should appear on all public suffix lists (see Appendix A.6.1) and therefore cannot be an Organizational Domain. Identifier Alignment is required because a message can bear a valid signature from any domain, including domains used by a mailing list or even a bad actor. Therefore, merely bearing a valid signature is not enough to infer authenticity of the Author Domain. Note that a single email can contain multiple DKIM signatures, and it is considered to be a DMARC "pass" if any DKIM signature is aligned and verifies.3.1.2. SPF-Authenticated Identifiers
DMARC permits Identifier Alignment, based on the result of an SPF authentication, to be strict or relaxed. In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment. Note that the RFC5321.HELO identity is not typically used in the context of DMARC (except when required to "fake" an otherwise null reverse-path), even though a "pure SPF" implementation according to [SPF] would check that identifier.
For example, if a message passes an SPF check with an RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address portion of the RFC5322.From field contains "payments@example.com", the Authenticated RFC5321.MailFrom domain identifier and the RFC5322.From domain are considered to be "in alignment" in relaxed mode, but not in strict mode.3.1.3. Alignment and Extension Technologies
If in the future DMARC is extended to include the use of other authentication mechanisms, the extensions will need to allow for domain identifier extraction so that alignment with the RFC5322.From domain can be verified.3.2. Organizational Domain
The Organizational Domain is determined using the following algorithm: 1. Acquire a "public suffix" list, i.e., a list of DNS domain names reserved for registrations. Some country Top-Level Domains (TLDs) make specific registration requirements, e.g., the United Kingdom places company registrations under ".co.uk"; other TLDs such as ".com" appear in the IANA registry of top-level DNS domains. A public suffix list is the union of all of these. Appendix A.6.1 contains some discussion about obtaining a public suffix list. 2. Break the subject DNS domain name into a set of "n" ordered labels. Number these labels from right to left; e.g., for "example.com", "com" would be label 1 and "example" would be label 2. 3. Search the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be "x". 4. Construct a new DNS domain name using the name that matched from the public suffix list and prefixing to it the "x+1"th label from the subject domain. This new name is the Organizational Domain. Thus, since "com" is an IANA-registered TLD, a subject domain of "a.b.c.d.example.com" would have an Organizational Domain of "example.com". The process of determining a suffix is currently a heuristic one. No list is guaranteed to be accurate or current.
(next page on part 2)
