tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7489

Informational
Pages: 73
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~mail

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

Part 1 of 4, p. 1 to 11
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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 RFC Part