Network Working Group D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking
Intended status: Best Current Practice April 29, 2013
Expires: October 31, 2013

Using DMARC
draft-crocker-dmarc-bcp-02

Abstract

Email abuse often relies on unauthorized use of a domain name, such as one belonging to a well-known company (brand). SPF and DKIM provide basic domain name authentication methods for email. A recent industry effort built an additional authentication-based layer, called Domain-based Message Authentication, Reporting & Conformance (DMARC). It allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes; it also provides a reporting mechanism, from receivers back to domain owners. Such capabilities over the public Internet are unusual and their use is not yet well-understood. This document formulates a set of best practices for the use of DMARC.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 31, 2013.

Copyright Notice

Copyright (c) 2013 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

Email abuse often relies on unauthorized use of a domain name, such as one belonging to a well-known company (brand). SPF [RFC4408] and DKIM [RFC6376] provide basic domain name authentication methods for email. A recent industry effort (DMARC.org) built an additional authentication-based layer, called Domain-based Message Authentication, Reporting & Conformance. [DMARC] allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes; it also provides a reporting mechanism, from receivers back to domain owners. Such capabilities over the public Internet are unusual and their use is not yet well-understood. This document formulates a set of best practices for the use of DMARC.

Discussion is divided along basic lines of activity:

An IETF mailing list for discussing DMARC issues has been established: dmarc@ietf.org.

2. Development {T. Draegen}

This section addresses issues that can occur when developing systems related to DMARC. Additional resources for developing DMARC can be found at DMARC.ORG.

2.1. Developing DMARC Components

DMARC builds on a number of existing technologies, and introduces new components only when necessary. This section helps to identify which components are readily available and where new development may be necessary. Combined, the components discussed here form an end-to-end DMARC solution.

2.1.1. Runtime DMARC processing - Sender side

DMARC requires very little new functionality for senders of email. SPF and DKIM are well developed technologies that can be implemented and deployed in isolation, and are supported by existing communities. DMARC uses TXT-based DNS records that are common. Support for underscores in DNS labels is important to consider while developing DNS tools that support DMARC, as DMARC records are located by prepending "_dmarc." to a domain and performing a TXT query.

The ability to configure the domain used for 5321.MailFrom addresses and for DKIM d= tags is important from a development perspective. Users of DMARC often require flexibility in specifying the domains used in both, as DMARC introduces the concept of Identifier Alignment to tie existing authentication technologies to email's 5322.From header domain.

2.1.2. Runtime DMARC processing - Receiver side

Because DMARC leverages existing authentication technology, developers can often integrate this functionality into existing systems without needing to develop entirely new modules. Developers need to take note that DMARC introduces a linkage between email's 5322.From header domain and the domains authenticated by SPF and DKIM, and so Authenticated Domains must be made available from SPF and DKIM processing.

Receiver side processing of DMARC results can also be performed during the SMTP conversation, which may cause developers to re-factor SPF and DKIM processing code that otherwise might occur after a message has been accepted. Performing the DMARC check during the SMTP conversation allows receivers to enforce "reject" policies immediately.

Receiver side DMARC development also introduces the concept of Organization Domain, which should be developed in a modular way so that future enhancements/development in the area of Organization Domain discovery can be easily integrated.

The use of Authentication-Results headers is highly recommended to ease down-stream processing by receivers.

The collection of feedback statistics for use in generating DMARC aggregate likely presents the most opportunity for new development. Collection, harvesting, and storage of such statistics should be properly assessed and scoped. The size of collected datasets can become quite large or high-volume email sites.

2.1.3. Feedback processing - Generator

Receivers that generate DMARC feedback should be aware of several facets of DMARC-related development.

For feedback that is generated once a day, feedback should span an entire 24 hour UTC-based cycle.

Monitoring and controls around the generation of DMARC feedback should be constructed to allow operators the ability to discover abuse of report generating code. Abusers will construct DMARC records for large numbers of domains that send unwanted email. Consider developing hooks so that intelligence decisions can be made as to when DMARC data collection occurs to limit wasted data collection and storage resources.

See Section 7. "Report Generation" for additional details.

2.1.4. Feedback processing - Consumer

Report consumers should be able to control the flow of incoming data to disallow abuse of reporting addresses.

See Section 8. "Report Receipt and Analysis" for additional details.

2.2. Developing DMARC-compliant Systems

Developers of DMARC-compliant systems should consider DMARC functionality from the perspective of the day to day operator, and ensure their ease of use and deployment scenarios are addressed. The configuration of domains, the maintenance of SPF records and DKIM signing keys, and the ability to quickly diagnose and correct problems are essential when creating robust DMARC-compliant systems.

Integration of existing functionality to build a DMARC-compliant system can be helped by leveraging interoperability tests for various integrated components.

2.3. Sending DMARC-compliant Email

Large portions of this document are relevant to sending DMARC-compliant email.

2.4. Original bullets:

3. Barriers to Adoption (or, How I Learned to Stop Worrying and Love DMARC) {A. Popowycz}

Within this section are discussed various hurdles, either real or feared, that might need to be overcome to incorporate DMARC into successful operational service. This includes issues that are applicable from either a sending perspective, as a receiver, or both. When considering DMARC, one must consider the operational and technical maturity that would support a successful implementation

Additional concerns:

4. Planning for DMARC adoption {E. Zwicky}

Distinct from lower-level issues in the specific steps for deploying and using DMARC is the approach taken in overall planning for its integration and use within the operational email service.

4.1. Decide what you need to do

DMARC provides protection against some forms of email domain name abuse. Its restricted policy form (p=quarantine or p=reject) is not intended for all use cases, and is beneficial only in the presence of an actual spoofing problem. You may, however, want to protect mailboxes by checking inbound mail, and you may want information about how your domains are showing up at recipients by publishing a p=none record.

So, first you need to determine what domains you own, and sort them into piles.

Sending domains:

  1. Domains that do not send mail. These should be protected with p=reject, and you can do this quite rapidly -- you might want to set them to p=none briefly to verify that you really don't send mail from them, but otherwise you can move directly to p=reject.
  2. Domains that send only transactional mail. These should also be protected at p=reject, but you will need to follow normal roll-out procedures.
  3. Domains that send mail, but never send transactional mail. (For instance, if you are a mailbox provider, the customer domains do not send transactional mail.) These can be set to p=none if you want reporting, or left without records.
  4. Domains that send both transactional mail and mail for individuals -- for many companies, their main corporate domains are in this situation. They both send transactional mail and contain users who do things like send mail to mailing lists.

If you have mixed domains that contain both transactional mail and mail from individuals that join mailing lists, you have four main choices, in order from best protection of your brand to least:

  1. Make a declaration that these domains officially represent your brand and you do not, as a matter of policy, support forwarding mail from them or joining mailing lists from them. When you have enforced this to the extent appropriate to your environment, roll out p=reject.
  2. Move the individuals to another domain, ideally an entirely separate one (so if your original domain is example.com, you might move the individuals to example-employees.com, letting you protect all of example.com at p=reject).
  3. Move the transactional mail to another domain, usually a subdomain of the original domain (official.example.com, for instance).
  4. Decide not to protect the mail with DMARC directly and use a p=none record to get reporting.

Receiving domains:

  1. Domains that receive transactional mail (for instance, domains where you handle customer inquiries). If you think forged mail from official transactional domains will be a problem here, then you should implement inbound DMARC; in most cases, however, you derive no large benefit from having it on, and may lose mail from misconfigured domains, and might as well leave it off.
  2. Domains that receive mail for individuals. These domains should implement inbound DMARC to mitigate phishing problems.

4.2. Picking Alignment and SP Parameter Values

Once you know what domains you are trying to protect, you can pick values for alignment and for sp.

If you have a large pile of sending domains like shipping.example.com, ordering.example.com, todays-promotions.example.com, you probably want to make a single, relaxed alignment record for example.com. The same is true for any domain in which you know people frequently create new sending domains with little coordination.

If you have a small number of sending domains, you probably want to make an entry for each with strict alignment and sp=reject. You will also want a sp=reject entry on the parent domain. So, for instance, if example.com sends transactional mail only from important.example.com and marketing mail from marketing.example.com, while the employees hang out on example.com, all three domains should be set to strict alignment and sp=reject. In theory you could in omit the records for important.example.com and marketing.example.com in this situation. In practice, you will almost certainly work your way up to p=reject on different schedules for them, so at least during roll-out you will need separate records.

4.3. Incremental Roll-Out, Sending

The procedure for incrementally rolling out DMARC on an individual Sending domain is discussed elsewhere.

Most senders have multiple domains, however, and will have to pick which ones to work on first. Start with some combination of

  1. Your most attacked domains.
  2. The easiest domains to secure.

If you can't easily identify domains in either of these categories, turn on DMARC with p=none for a wide assortment of domains, and see if that clarifies matters. (Often it reveals domains that are in both categories at once; domains used for sending some particular piece of signed, transactional mail, where much more forged mail than good mail is sent.) You can use the p=none reporting on a lower domain to substitute for turning on p=none on a subdomain (so, for instance, if you have example.com at p=none and notice that alerts.example.com sends out only DKIM-signed mail, you can move alerts.example.com directly to p=quarantine, and senders who are familiar with DMARC and their sending environment may choose to move it directly to p=reject)

4.4. Incremental Roll-Out, Receiving

In order to have fully implemented DMARC on the receiving side, you must both act on mail and report on mail. In general, you will have to pick one of these to do first; do you turn on reporting, and report all mail as exempted for local reasons, or do you turn on actions first? Both of these are acceptable compromises, as long as you are rejecting rather than silently discarding mail when p=reject. However, you should not spend very long in either state.

4.5. [Original bullets]

5. DNS Configuration {M. Hammer}

Malformed Policies:
DMARC policies published in DNS which are malformed should be ignored by validators with regard to policy assertions.
Reporting malformed policies:
If a malformed record is identified by a validating/reporting entity and that entity wishes to attempt reporting a problem with the record, a report may be sent to the address(s) indicated in the RUA field. As an alternative, a report may be sent to the technical contact indicated in the WHOIS record for the domain.
Managing DMARC records:
Implementers publishing quarantine or reject policies should take care to ensure the integrity of their mail streams when rotating DKIM keys. For owners/administrators that manage large numbers of domains, it is recommended to automate management and configuration of DMARC records as well as underlying DKIM and SPF records to ensure consistency and correct deployment of records.
Publishing DMARC reject policies for non mailing domains:
For domains which never send mail, it is appropriate to publish a DMARC reject policy as a way to prevent abuse.

[Original listing of issues]

6. Receiver Processing {S.Solanki}

6.1. Preparing for DMARC processing

DMARC is a policy enforcement and reporting standard that builds on SPF and DKIM to provide more deterministic outcomes of authentication-failed messages. DMARC implementation helps receivers to more easily identify email from senders as legitimate, and helps keep spam and phishing messages from reaching the inbox.

The receiver could use the following data points to better understand their incoming email traffic:

The next step is to scope the engineering work to implement DMARC processing. This includes but not limited to

It is recommended to participate in open DMARC forums, for pursuing general questions or learning from experience of receivers who have already previously implemented DMARC

6.2. Implementing DMARC at receiver

During implementation the goal is to be compliant with the specification. In particular the "must have" attributes have to be implemented to be considered compliant. The optional attributes are left to receiver to determine implementation.

While implementing the specification consider leveraging or building the following technologies

6.3. Rolling out DMARC

A phased approach is best recommended for DMARC roll-out at receiver side. Start with a small percentage of your email traffic being subject to DMARC processing.

Reach out to a select group of trusted senders who you know have already published DMARC records. Work closely with them over a period of weeks to determine if the implementation is working as expected.

Things to observe include but not limited to

Once any potential issues are fixed, consider ramping up the traffic to a larger portion of the incoming traffic. This will identify issues normally caught at scale such as excessing reporting queues or caching performance. This is also a good time to monitor feedback on dmarc-dev forums where senders usually post observations or complaints about DMARC issues.

Once satisfied with the feedback you are ready to roll it out full scale to the site and announce to the world.

6.4. Post roll-out

Post roll-out give sufficient time to evaluate if the processing pipeline is working as expected.

These include monitoring the generated reports in your instrumentation infrastructure. Specifically the "reject" and "quarantine" verdicts will give a direct idea of how many phishing messages were filtered

This is a good time to share a summary of your experience implementing DMARC and its benefits to you as the receiver over time. Feedback regarding quality of documentation and any items missing or incorrect should be informed to the community via dmarc-dev for future versions of the document.

6.5. Original Bullets

7. Report Generation {M. Jones}

7.1. DMARC aggregate XML report naming and report metadata

The first step most recipients of DMARC aggregate XML reports will take, after accepting the compressed files via email, will be to uncompress the file and run a script or program to parse and store the data contained within the reports. In order for this to work properly, the filenames and report metadata must work in a standard way from all DMARC compliant report generators.

The correct compression mechanism and filename convention is described in section 12.2.1 [DMARC] for emailed reports. It is important to ensure that the uncompressed filename still adheres to the specified naming convention. Cases have been noted were upon uncompressing a file, the new filename is something entirely different than what is specified in section 12.2.1.

In the report metadata there are several fields that contain important information for a report recipient. Here is a brief description of each field and some notes on usage and/or problems encountered with each. 

<?xml version="1.0" encoding="UTF-8" ?> 
<feedback> 
   <report_metadata> 
      <org_name>google.com</org_name> 
      <email>noreply-dmarc-support@google.com</email> 
      <extra_contact_info>http://support.google.com/a/bin/answer.py?answer=2466580</extra_contact_info> 
      <report_id>303460054821571539</report_id> 
      <date_range> 
         <begin>1364169600</begin> 
         <end>1364255999</end> 
         </date_range> 
      </report_metadata> 
   <policy_published> 
      <domain>facebook.com</domain> 
      <adkim>r</adkim> 
      <aspf>r</aspf> 
      <p>reject</p> 
      <sp>reject</sp> 
      <pct>100</pct> 
      </policy_published>

Below is a sample of report metadata and policy discovery sections of DMARC XML report with a the file name: google.com!facebook.com!1364169600!1364255999.xml.

7.2. Minimum requirements for DMARC XML aggregate report records

The data contained in a DMARC aggregate report, at minimum, allows a report recipient to:

  1. Identify sources sending email purporting to be “From” its domain and sub-domains.
  2. Determine the aligned DMARC results of SPF and DKIM checks.
  3. Determine the DMARC disposition of the message.
  4. Determine the identities used to check the underlying authentication mechanisms.
  5. Determine the results of the underlying authentication mechanism checks.

To make this possible, each record in a DMARC report must contain a minimum set of data. The fields below are defined in Appendix C. DMARC XML Schema and are critical to producing a complete aggregate report. Some notes on usage of these fields are included to help guide you in your deployment.

Below are three examples of real DMARC XML records for a domain with a DMARC reject policy in place.

This record indicates a single message matching this set of data points. The DMARC disposition for this message was “reject” based on DMARC aligned results for SPF and DKIM of “fail” and the domain’s reject policy. The empty DKIM domain field and DKIM authentication result of “none” indicates that there was no DKIM signature. The result of the SPF authentication check was “neutral”.

<record> 
   <row> 
      <source_ip>91.98.85.94</source_ip> 
      <count>1</count> 
      <policy_evaluated> 
         <disposition>reject</disposition> 
         <dkim>fail</dkim> 
         <spf>fail</spf> 
         </policy_evaluated> 
      </row> 
   <identifiers> 
      <header_from>blog.facebook.com</header_from> 
      </identifiers> 
   <auth_results> 
      <dkim> 
         <domain></domain> 
         <result>none</result> 
         </dkim> 
      <spf> 
         <domain>blog.facebook.com</domain> 
         <result>neutral</result> 
         </spf> 
      </auth_results> 
   </record>

Example - 1 Msg / Disp Reject / No DKIM

This record indicates that 3 messages were represented by this set of data points. The disposition for these messages was “none” because the DMARC aligned result for DKIM was “pass”. The DMARC aligned result for SPF was “fail”. The messages passed the DKIM authentication check and failed the SPF authentication check.

<record> 
   <row> 
      <source_ip>141.161.2.153</source_ip> 
      <count>3</count> 
      <policy_evaluated> 
         <disposition>none</disposition> 
         <dkim>pass</dkim> 
         <spf>fail</spf> 
         </policy_evaluated> 
      </row> 
   <identifiers> 
      <header_from>facebook.com</header_from> 
      </identifiers> 
   <auth_results> 
      <dkim> 
         <domain>facebook.com</domain> 
         <result>pass</result> 
         </dkim> 
      <spf> 
         <domain>facebook.com</domain> 
         <result>fail</result> 
         </spf> 
      </auth_results> 
   </record>

Example - 3 Msgs / Disp None / DKIM-SPF Mix

This record indicates a single message matching this set of data points. The DMARC disposition for this message was “reject” based on DMARC aligned results for SPF and DKIM of “fail” and the domain’s reject policy. There was no DKIM signature on this message, as in Example 1. The SPF authentication result was “pass” with a MAILFROM domain of “classifiedads.com”. The SPF domain is not aligned with the header From domain, causing the DMARC aligned SPF result to be “fail”.

<record> 
   <row> 
      <source_ip>65.61.105.5</source_ip> 
      <count>1</count> 
      <policy_evaluated> 
         <disposition>reject</disposition> 
         <dkim>fail</dkim> 
         <spf>fail</spf> 
         </policy_evaluated> 
      </row> 
   <identifiers> 
      <header_from>facebook.com</header_from> 
      </identifiers> 
   <auth_results> 
      <dkim> 
         <domain></domain> 
         <result>none</result> 
         </dkim> 
      <spf> 
         <domain>classifiedads.com</domain> 
         <result>pass</result> 
         </spf> 
      </auth_results> 
   </record>

Example - 1 msg / Disp Reject / No DKIM

7.3. Use and Reporting of Local Policy Overrides

The DMARC specification allows for a DMARC compliant receiver to take an action that is different than the DMARC disposition for the message (see Section B.3.1, SMTP-time Processing [DMARC]). Reasons that a receiver may choose to do so include overriding a reject policy if the message source is a known forwarder or mailing list that breaks DKIM and SPF. If a message source has a high reputation the receiver may choose to accept and/or analyze a message with local rules despite a DMARC disposition of “reject”. While ultimately an email receiver’s local policy and the final placement of a message cannot be standardized by DMARC, the DMARC related reporting of such can.

The reporting of a “PolicyOverrideReason” is specified in Appendix C [DMARC]. A <reason> tag is included in the <policy_evaluated> section of the <record> with two sub-fields, <type> and <comment>. Below are the DMARC XML tags and fields involved with a brief explanation of each and two real examples of DMARC records with a PolicyOverrideReason. 

<record> 
   <row> 
      <source_ip>132.205.122.20</source_ip> 
      <count>19</count> 
      <policy_evaluated> 
         <disposition>reject</disposition> 
         <dkim>fail</dkim> 
         <spf>fail</spf> 
         <reason> 
            <type>mailing_list</type> 
            <comment></comment> 
            </reason> 
         </policy_evaluated> 
      </row> 
   <identifiers> 
      <header_from>star.c10r.facebook.com</header_from> 
      </identifiers> 
   <auth_results> 
      <dkim> 
         <domain>facebookmail.com</domain> 
         <result>neutral</result> 
         <human_result></human_result> 
         </dkim> 
      <spf> 
         <domain>star.c10r.facebook.com</domain> 
                 <result>neutral</result> 
         </spf> 
      </auth_results> 
   </record>

Example 1. In this example the DMARC disposition is reject, based on the domain’s DMARC reject policy and DMARC aligned SPF and DKIM results of “fail”. But a <reason><type> of “mailing_list” is reported by the report generator. The report recipient can interpret this to mean that the domain’s reject policy was correctly applied, but the receiver chose to override the reject action because the message source is a known mailing list which cause SPF and DKIM to break. 

<record> 
   <row> 
      <source_ip>195.23.141.86</source_ip> 
      <count>2</count> 
      <policy_evaluated> 
         <disposition>none</disposition> 
         <dkim>pass</dkim> 
         <spf>fail</spf> 
         <reason> 
            <type>forwarded</type> 
            <comment></comment> 
            </reason> 
         </policy_evaluated> 
      </row> 
   <identifiers> 
      <header_from>support.facebook.com</header_from> 
      </identifiers> 
   <auth_results> 
      <dkim> 
         <domain>support.facebook.com</domain> 
         <result>pass</result> 
         <human_result></human_result> 
         </dkim> 
      <spf> 
         <domain>support.facebook.com</domain> 
         </spf>
      </auth_results> 
   </record>

Example 2. In this example the DMARC disposition is “none” because the DMARC aligned DKIM result is “pass”, thus the domain’s DMARC reject policy is not applicable. Yet the report generator still chose to report a policy override <reason><type> of “forwarded” in the record. This is perfectly acceptable, even though the policy override reason did not impact the treatment of the message as far as DMARC is concerned.

7.4. Minimum requirements for DMARC failure reports

DMARC failure reports serve two primary purposes. First is to allow a domain owner to investigate in more detail, legitimate sources of their email that are failing one or both modes of authentication. For example, from aggregate data one might know that a domain’s 3rd party email is failing DKIM some percentage of the time yet not know which messages are affected. Failure reports could show a consistent From address and Subject from the source that are unsigned, indicating a specific campaign not being signed by DKIM. Second is to allow a domain owner to understand and mitigate specific threat campaigns abusing their domain. Examples include early identification of phishing URLs in current campaigns for quick takedown or identification of Subjects used in current campaigns which can be used by customer service call center personnel to handle customer calls.

The data contained in a DMARC failure report, at minimum, allows a report recipient to:

  1. Identify the source sending each failed message purporting to be “From” its domain or sub-domain.
  2. Determine the aligned DMARC result of the SPF and DKIM checks.
  3. Identify the domain used to check SPF. If this is different than the MailFrom domain or the MailFrom domain is NULL and the receiver checks EHLO, that identifier must be indicated in the failure report.
  4. Identify the full DKIM signature checked (if the message was DKIM signed).
  5. Identify the results of the SPF and DKIM authentication checks.
  6. Identify the URLs in the body of the message.
  7. Identify the full RFC5322.From email address in the message. This should include the display name portion of the From.
  8. Identify the Subject of the message.

Details on the format of failure reports are found in sections 8.4. and 8.4.1 [DMARC].

7.5. Additional concerns

8. Report Receipt and Analysis {M. Jones}

8.1. Report Receipt

8.1.1. Your first DMARC aggregate reports

Upon successful publication of a DMARC record for your domain you will soon begin to receive DMARC data. Current report generator practice is to aggregate DMARC data daily. Therefore you should expect to receive your first aggregate data in the range of 12 – 48 hours after you first publish the record. This can vary depending on the time of day your record was published. DMARC aggregate reports should use UTC day boundaries for the reporting intervals. There is also some time lag while your record propagates through DNS is discoverable by DMARC compliant receivers.

The aggregate data files will arrive as gzipped email attachments. While the DMARC specification allows for multiple types of URIs to indicate your preference for aggregate data delivery, current report generator practice is to deliver reports via email using the mailto: URI specified in the rua tag. Note that if you list multiple email addresses in your rua tag, you should list them in the order of the highest priority address first, as there have been report generators who do not send to all addresses. In these cases the report generator does send reports to at least the first address listed. Upon receipt of these files you will need to uncompress them for further processing or manual inspection.

8.1.2. Your first DMARC failure reports

Upon successful publication of a DMARC record for your domain you will also begin to receive DMARC failure data for individual message failures at the email address specified in your DMARC record’s ruf tag. You will likely receive your first reports within the first 24 hours of your record being published. There are several factors that will affect the timing and source of your first failure reports. First, the current practice is that only a small number of DMARC receivers are providing failure reports, as it is optional for a DMARC receiver to provide this data. Therefore you should not expect failure reports from all of the same report generators that send you aggregate reports. Next, failure reports are not aggregated and the current practice among report generators is to generate a report near real time when they receive the failed message.

The failure reports you will receive are specified in section 8.4. and 8.4.1 [DMARC].. These reports are intended to be machine readable and it is recommended that you automate the process of parsing and storing the data contained in the reports. The volume of these reports you will receive can be highly variable and it is not limited by the amount of email that you send. Attacks using your domain can happen at any time and their nature is largely outside of your control. Therefore it is also recommended that your report processing infrastructure be able to rate limit or sample the inbound reports in a way that does not negatively impact the sending infrastructure of report generators.

8.1.3. What if I do not receive any DMARC reports?

If you have published DMARC records and waited 24 to 48 hours yet still received no data you should check the following:

  1. Check the rua and ruf addresses in your DMARC record.
  2. Is the domain in your rua and ruf address the same as the domain of your DMARC record?
  3. Check your email receiving infrastructure and mail logs for indications of problems receiving email.

8.2. Report Analysis

8.2.1. Data contained in DMARC reports

For detailed descriptions on the meaning of different data fields in DMARC aggregate XML files please see the descriptions in subsections .1-.3 of Section 7. For a description of the data contained in a failure report (see Section 7.4). In order to move on to the analysis of DMARC data, it is important to understand what the report generator is telling you in each field.

8.2.2. What should I look for first?

There are many ways you can approach the analysis of DMARC data for your domain. The approach you take will likely depend on what you already know about your domain’s email sending and abuse of your domain. It is recommended that in general you start with aggregate data. Here are some suggestions on initial things to look for.

As you analyze data and answer some of these questions, it will lead to deeper investigation. At some point you will reach a limit to what you can learn from the aggregate data and likely need to look further using failure reports if they are available. You may want to search for examples of failures coming from a particular IP address to understand what kind of messages are being sent. With the From, Subject, and URLs in failure reports you may be able to identify specific phishing or spam campaigns using your domain.

Once you have a good understanding of the current state of your domain’s email you can use DMARC data to begin remediating problems and tracking the ongoing progress of your changes. Depending on your domain’s email characteristics your ultimate goal may be to publish DMARC reject policies or to simply continue collecting intelligence about your email.

8.2.3. Investigating Anomalies in DMARC data

When analyzing DMARC data you will likely come across results that you want to verify or understand better. In some cases this is possible via further analysis of additional DMARC aggregate data fields. In other cases it is helpful if you have failure reports to analyze. A few examples of common things to explore are noted below.

8.3. Report Processing and Analysis Services

Is it appropriate to point out here that there are vendor and 3rd party resources that can help with report receipt, processing, and analysis? Of course specifics would not be mentioned here, but the document could point to the dmarc.org/resources page. This could aid in making build vs. buy decisions.

8.4. Additional concerns

9. Miscellaneous

This section is meant as a catch-all, for items that haven't yet been assigned to their appropriate section.

10. Interaction Issues

Some issues come into play when DMARC is used in conjunction with one or more other services.

11. DMARC Commentary -- What were they thinking of...?

This section explains a number of choices made for DMARC.

Rationale for choosing ZIP for the aggregate reports: {P. Midgen}
primary consideration was increasing the amount of data that could be presented in a single message and avoiding report truncation (e.g. many folks limit inbound message size to 25MB). text compresses well in general, so we thought compression would make sense. // rather than compress at the transport layer (e.g. send a chunked/compressed stream over http) we thought email attachments were kinda braindead given the existing message-based feedback infrastructure (e.g. ndr, arf, etc.). // zip is everywhere, we needed to make no special consideration using it, and (i believe, but this needs checking) it is also a registered content-type (golden arrow of rationale leads back to "zip is everywhere").
Why doesn't DMARC solve its problem with mailing lists/gatewats? {P. Midgen}
This question typically refers to a set of well-known issues where messages transiting mailing list managers (MLMs), relays, or forwarders fail DKIM or SPF checks.
The recommendation is for senders to use both SPF and DKIM, since we know from research conducted during draft development that the likelihood of simultaneous SPF & DKIM failure, while possible, is far less common than individual failures.
Senders are encouraged to use both SPF & DKIM to ensure robust operation of DMARC and to pave the way for future technologies that will benefit from broad adoption of email authentication, such as domain reputation.
This question also refers to the issue of expanding the set of alignable authenticated identities under DMARC. At the moment DMARC looks at the RFC5321.MailFrom (a/k/a envelope sender or return-path) for SPF, and the d= field in the message's DKIM-Signature block(s), and attempts to align them with the RFC5322.From domain since this in the majority of cases is displayed to the message recipient by the MUA.
The import of that consideration can be argued, but we universally felt it was important because it is such a common practice and because we are able in majority of cases representing a high volume of mail to authenticate and align identities with RFC5322.From.
As a final statement on this issue, it is worth reiterating the role of local policy in the determination of message disposition. In a sense SPF and DKIM serve to inform local policy mechanisms on the disposition of authenticated mail. DMARC carries that tradition forward, but at the end of the day it is a matter of local policy whether to act on the suggestions of authentication and policy mechanisms or simply mark the message and move it further down the delivery pipeline.
Who is the target audience for the DMARC specification? {P. Midgen}
DMARC is intended for submission to become an IETF standard; in a sense this means the intended audience is the entire internet and email community. That said, it isn't for everyone. We believe DMARC does four important things:
  1. Provides a method for uniform evaluation of the authentication results generated by standard and well-deployed email authentication mechanisms against a common set of identities.
  2. Provides a reporting mechanism allowing senders to understand the performance of their email authentication practices, and get an idea of the IPs sending email on behalf of their domains.
  3. Provides a deterministic policy mechanism allowing the sender to tell the receiver how to dispose of their email in the event the policy conditions aren't met.
  4. It achieves this sender/receiver communication via DNS, at Internet scale.

We figured most folks would find 1, 2 and 4 appealing; everyone likes information and even more so if it is obtained easily and at low risk. Number 3 is more tricky: under what circumstances should a sender publish anything other than p=none? This depends on a huge number of variables and there is no if-then-else type of guideline. Here are some of the things to consider:

  1. Are your domains used fraudulently? DMARC will help curb fraudulent use of your organizational domain and subdomains. It will not stop homograph/cousin domain abuse (e.g. fac3book.com), and it will not stop domain-padding (e.g. facebook.superbaddudes.junkyjunkjunkorama1234.com) abuse.
  2. Are you an ISP, MBP, or EDU? Your users tend to move around, have multiple accounts, forward messages and do other things that increase the possibility for a DMARC false positive. You, even more so than everyone else, will want to start with a monitor-only policy so you can model the what-ifs.
  3. Do you send mostly transactional, point-to-point mail (e.g. account statements, password resets, etc.)? These are good candidates for DMARC since our observation has been that these tend to be low risk of failure.

12. Privacy Considerations. {T. Adams}

NOTE:
Capitalized terms related to privacy used in this section are consistent with the "Guidelines on the Protection of Privacy and Transborder Flows of Personal Data" published in 1980 (and subsequently reviewed in 2011) by the Organisation for Economic Co-operation and Development (OECD).

Each of the two DMARC feedback reports have different characteristics related to privacy based on their design. Aggregate Reports (RUA) are sent by a receiver at periodic intervals (e.g. daily) and contain summary data regarding the number and type of email messages that are processed in relation to the domain owner's DMARC policy. As such, they do not contain Personal Data and are considered to have no impact on privacy.

The one identified exception to this is when an individual (a.k.a. "a Natural Person with legal rights") is operating his or her own email server. In this case, the IP address of the sending server reported in the RUA may identify the individual and thus be classified as Personal Data in some jurisdictions.

Failure Reports (RUF), on the other hand, are sent by an email receiver each time an email message being processed fails the DMARC authentication checks. The RUF may include Personal Data as well as Sensitive Data, depending on the applicable regulatory jurisdiction. When supporting RUF reports, an email receiver should consider whether or not to include the full content of the unauthenticated email, as well as what email header fields to redact.

As part of this consideration, the email receiver will need to understand its roll in the flow of Personal Data. For example, the domain owner can be viewed as the Data Controller for email sent under its aegis as is the case for email sent from the servers of a company by its employees or transactional systems. In this case, the email receiver is the Data Processor acting on behalf of the Data Controller, and as such the legal responsibility for protection of the data rests with the domain owner. Thus, legitimate mail that inadvertently fails the DMARC authorization checks (e.g. if the email was handled by mailing list management software acting as an Intermediary Processor) is clearly handled by this case.

The primary area of debate about privacy and RUF reporting revolves around the protections offered to the individual (i.e. the "bad actor") who sends fraudulent email purporting to be from another domain. Specifically, should the bad actor be protected by privacy regulations within the applicable jurisdiction? Within the context of current regulatory guidance, it is possible to view the email receiver as the Data Processor on behalf of the bad actor, who is filling the role of Data Controller. It is an open question only insofar as what to do about this bad actor who is clearly not participating in the data flow in good faith.

Given that there is significant value in quickly identifying bad actors, and taking appropriate enforcement action, it is worth exploring how to clarify that existing data sharing regulations allow RUF reports. In any case, both the email receiver (as the report generator) and the domain owner (as the report recipient) should ensure that the appropriate operational policies are in place to protect the Personal Data being handled as dictated by their part of the data flow.

13. Security Considerations

In this section we describe several security considerations related to the implementation of the DMARC protocol.

  1. The authors see DNS as a potential abuse target. According to the DMARC specification, mail receivers read the DMARC policy from the corresponding DNS txt record. Theoretically a wrong or malicious implementation might result in multiple DNS queries per message, resulting in a DoS attack on DNS. Such an attack is unlikely to happen; not only is it expensive, the same result can be achieved by simpler means. To avoid causing accidental DNS DoS attacks, implementers consider using a DNS cache. {O. Gavrylyako}
  2. The authors see the volume of aggregated reports generated by other hosts as potential for abuse. Sending a large volume of reports could constitute a DoS attack on the sender domain. Such an attack is also expensive and more theoretical than practical. Nevertheless, to protect against this type of abuse, one should publish a _reports._dmarc DNS txt record to restrict malicious domains from redirecting their aggregate reports to an abuse target. Another related potential risk is excessively large aggregate reports that could be damaging to the recipient, though the same abuse affect can be achieved without the DMARC protocol. The majority of mail recipients enforce message size limits. {O. Gavrylyako}

[Original listing of issues]

14. References

14.1. References - Normative

[DMARC] Kucherawy, M., "Domain-based Message Authentication, Reporting and Conformance (DMARC)", URL https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/, March 2013.

14.2. References - Informative

[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[RFC6376] Crocker, D., Hansen, T. and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.

Appendix A. Acknowledgements

DMARC and the version of this document submitted to the IETF were the result of lengthy efforts by an informal industry consortium: DMARC.org. Participating companies included: Agari, American Greetings, AOL, Bank of America, Cloudmark, Comcast, Facebook, Fidelity Investments, Google, JPMorgan Chase & Company, LinkedIn, Microsoft, Netease, Paypal, ReturnPath, Trusted Domain Project, and Yahoo!. Although the number of contributors and supporters are too numerous to mention, notable individual contributions were made by J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim Draegen, Murray Kucherawy, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen. The contributors would also like to recognize the invaluable input and guidance that was provided by J.D. Falk.

Author's Address

Dave Crocker (editor) Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA Phone: +1.408.246.8253 EMail: dcrocker@bbiw.net