Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7489

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Pages: 73
Informational
Errata
Updated by:  85538616
Part 1 of 4 – Pages 1 to 11
None   None   Next

Top   ToC   RFC7489 - Page 1
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.
Top   ToC   RFC7489 - Page 2
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
Top   ToC   RFC7489 - Page 3
   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 ................................................73

1. 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
Top   ToC   RFC7489 - Page 4
   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].
Top   ToC   RFC7489 - Page 5
   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.
Top   ToC   RFC7489 - Page 6
   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.
Top   ToC   RFC7489 - Page 7

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.
Top   ToC   RFC7489 - Page 8
   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
Top   ToC   RFC7489 - Page 9
   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.)
Top   ToC   RFC7489 - Page 10
   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.
Top   ToC   RFC7489 - Page 11
   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)

Next Section