Domain-based Message Authentication, Reporting & Conformance

The information below is for an old version of the document
Document Proposed charter Domain-based Message Authentication, Reporting & Conformance WG (dmarc) Snapshot
Title Domain-based Message Authentication, Reporting & Conformance
Last updated 2014-07-30
State IESG review Rechartering
WG State Active
IESG Responsible AD Alexey Melnikov
Charter Edit AD Pete Resnick
Send notices to


Domain-based Message Authentication, Reporting & Conformance (DMARC)
   uses existing mail authentication technologies (SPF and DKIM) to
   extend validation to the RFC5322.From field. DMARC uses DNS records
   to add policy-related requests for receivers and defines a feedback
   mechanism from receivers back to domain owners. This allows a domain
   owner to advertise that mail can safely receive differential
   handling, such as rejection, when the use of the domain name in the
   From field is not authenticated. Existing deployment of DMARC has
   demonstrated utility at internet scale, in dealing with significant
   email abuse, and has permitted simplifying some mail handling
   processes. However, DMARC is problematic for mail that does not flow
   from operators having a relationship with the domain owner, directly
   to receivers operating the destination mailbox (for example, mailing
   lists, publish-to-friend functionality, mailbox forwarding via
   ".forward", and third-party services that send on behalf of
clients).    The working group will explore possible updates and
extensions to the    specifications in order to address limitations and/or
add    capabilities. It will also provide technical implementation
guidance    and review possible enhancements elsewhere in the mail
handling    sequence that could improve could DMARC compatibility.

   The existing DMARC base specification has been submitted as an
   Independent Submission to become an Informational RFC.

   Specifications produced by the working group will ensure preservation
   of DMARC utility for detecting unauthorized use of domain names,
   while improving the identification of legitimate sources that do not
   currently conform to DMARC requirements. Issues based on operational
   experience and/or data aggregated from multiple sources will be given

   The working group will seek to preserve interoperability with the
   installed base of DMARC systems, and provide detailed justification
   for any non-interoperability. As the working group develops solutions
   to deal with indirect mail flows, it will seek to maintain the
   end-to-end nature of existing identifier fields in mail, in
   particular avoiding solutions that require rewriting of originator

   Working group activities will pursue three tracks:

      1. Addressing the issues with indirect mail flows

   The working group will specify mechanisms for reducing or eliminating
   the DMARC's effects on indirect mail flows, including deployed
   behaviors of many different intermediaries, such as mailing list
   managers, automated mailbox forwarding services, and MTAs that
   perform enhanced message handling that results in message
   modification. Among the choices for addressing these issues are:

      - A form of DKIM signature that is better able to survive
transit         through intermediaries.

      - Collaborative or passive transitive mechanisms that
enable an         intermediary to participate in the trust
sequence, propagating         authentication directly or
reporting its results.

      - Message modification by an intermediary, to avoid
authentication         failures, such as by using specified
conventions for changing         the aligned identity.

   Consideration also will be given to survivable authentication through
   sequences of multiple intermediaries.

      2. Reviewing and improving the base DMARC specification

   The working group will not develop additional mail authentication
   technologies, but may document authentication requirements that are

   The base specification relies on the ability of an email receiver to
   determine the organizational domain responsible for sending mail. 
An    organizational domain is the 'base' name that is allocated
from a    public registry; examples of registries include ".com"
or "".    While the common practice is to use a
"public suffix" list to    determine organizational domain, it
is widely recognized that this    solution will not scale, and that the
current list often is    inaccurate. The task of defining a standard
mechanism for identifying    organizational domain is out of scope for
this working group. However    the working group can consider extending
the base DMARC specification    to accommodate such a standard, should it
be developed during the    life of this working group.

   Improvements in DMARC features (identifier alignment, reporting,
   policy preferences) will be considered, such as:

      - Enumeration of data elements required in
"Failure" reports         (specifically to
address privacy issues)       - Handling potential reporting
abuse       - Aggregate reporting to support additional
reporting scenarios       - Alternate reporting channels  
    - Utility of arbitrary identifier alignment      
- Utility of a formalized policy exception mechanism

      3.  DMARC Usage

   The working group will document operational practices in terms of
   configuration, installation, monitoring, diagnosis and reporting. It
   will catalog currently prevailing guidelines as well as developing
   advice on practices that are not yet well-established but which are
   believed to be appropriate.

   The group will consider separating configuration and other deployment
   information that needs to be in the base spec, from information that
   should be in a separate guide.

   Among the topics anticipated to be included in the document are:

      - Identifier alignment configuration options
      - Implementation decisions regarding "pct"
      - Determining effective RUA sending frequency
      - Leveraging policy caching
      - Various options for integrating within an existing flow
      - Defining a useful, common set of options for the
addresses to         which feedback reports are to be sent
      - When and how to use local policy override options

   Work Items

   Phase I:

      Draft description of interoperability issues for indirect
mail       flows and plausible methods for reducing them.

   Phase II:

      Specification of DMARC improvements to support indirect
mail flows

      Draft Guide on DMARC Usage

   Phase III:

      Review and refinement of the DMARC specification

      Completion of Guide on DMARC Usage


   DMARC -
   SPF - RFC7208
   Authentication-Results Header Field - RFC7001
   DKIM - RFC6376
   Internet Message Format - RFC5322
   OAR / Original Authentication Results -
   Using DMARC -  draft-crocker-dmarc-bcp-03
   Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00
   DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03