Network Working Group D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking
Intended status: Best Current Practice April 01, 2013
Expires: October 03, 2013
Using DMARC
draft-crocker-dmarc-bcp-01
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 03, 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
Crocker Expires October 03, 2013 [Page 1]
Internet-Draft dmarcops April 2013
(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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Development . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Barriers to Adoption (or, How I Learned to Stop
Worrying and Love DMARC) . . . . . . . . . . . . . . . . . . 4
4. Planning for DMARC adoption . . . . . . . . . . . . . . . . . 6
4.1. Decide what you need to do . . . . . . . . . . . . . . . 6
4.2. Picking Alignment and SP Parameter Values . . . . . . . . 7
4.3. Incremental Roll-Out, Sending . . . . . . . . . . . . . . 8
4.4. Incremental Roll-Out, Receiving . . . . . . . . . . . . . 8
4.5. [Original bullets] . . . . . . . . . . . . . . . . . . . 8
5. DNS Configuration . . . . . . . . . . . . . . . . . . . . . . 9
6. Receiver Processing . . . . . . . . . . . . . . . . . . . . . 10
7. Report Generation . . . . . . . . . . . . . . . . . . . . . . 10
7.1. DMARC aggregate XML report naming and report metadata . . 10
7.2. Minimum requirements for DMARC XML aggregate
report records . . . . . . . . . . . . . . . . . . . . . 12
7.3. Use and Reporting of Local Policy Overrides . . . . . . . 16
7.4. Minimum requirements for DMARC forensic reports . . . . . 19
7.5. Additional concerns . . . . . . . . . . . . . . . . . . . 20
8. Report Receipt and Analysis . . . . . . . . . . . . . . . . . 20
8.1. Report Receipt . . . . . . . . . . . . . . . . . . . . . 20
8.2. Report Analysis . . . . . . . . . . . . . . . . . . . . . 22
8.3. Report Processing and Analysis Services . . . 24
8.4. Additional concerns . . . . . . . . . . . . . . . . . . . 24
9. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Interaction Issues . . . . . . . . . . . . . . . . . . . . . 25
11. DMARC Commentary . . . . . . . . . . . . . . . . . . . . . . 25
12. Privacy Concerns. . . . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. References - Normative . . . . . . . . . . . . . . . . . 26
14.2. References - Informative . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
Crocker Expires October 03, 2013 [Page 2]
Internet-Draft dmarcops April 2013
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:
* Development
* DNS Configuration
* Report Generation
* Receiver Processing
An IETF mailing list for discussing DMARC issues has been
established: dmarc@ietf.org.
Editor's Note: The current version incorporates new sections of
relatively raw text from the original DMARC team and edited
merely to convert to xml2rfc format. It has not yet
received editing for content. The version is being issued
as an Internet Draft in order to create an archived
snapshot, and possibly to whet more appetites for adding
content... /Dave
2. Development
{This section is meant for any any software development practices,
relevant to the use of DMARC. -ed}
Core Functionality
Tools Support
Crocker Expires October 03, 2013 [Page 3]
Internet-Draft dmarcops April 2013
3. Barriers to Adoption (or, How I Learned to Stop Worrying and Love
DMARC)
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
o I don't know where all my email is sent from!
One of the first questions that is often raised pertains to
having an accurate inventory of all sources that may send email
for a given domain as well as having processes to keep such an
inventory up-to-date. This is critical as any policy expressed
may have implications to mail delivery on that base domain.
In addition, it is all too easy to have any source send email
on your domain (which is the underlying problem leading to
phishing and other similar email threats).
Such an inventory must consider sources that include organic or
on-site mail capabilities as well as outsourced mail delivery.
Also on this list are special purpose emails that are often
sent as part broader capability, usually in an outsourcing or
'cloud' capacity
In actuality, the deployment of DMARC as a sender can actually
help allay such concerns. Through both aggregate and message
level feedback, DMARC provides a more regular and reliable
reporting capability which can augment an established inventory
effort or serve as a core capability in setting such an
inventory management regime. Starting with a 'none' policy
(p=none) expressed in a published policy, one can achieve that
visibility without having any other implications to mail
handling behavior.
o If I publish a DMARC policy, I lose flexibility in email delivery.
While DMARC is an important new technology to help address
phishing, it is not a strategy of itself. Part of the
deployment of DMARC is the consideration of segmentation of
various email sources, usually through the use of subdomains.
Whereas it is common to send email using a second-level domain
(e.g. blah.com), segmenting different email sources and
providers (e.g. source1.blah.com, source2.blah.com) can
enhance email visibility and diagnostic capability while
Crocker Expires October 03, 2013 [Page 4]
Internet-Draft dmarcops April 2013
providing a way out of the 'one-size-fits-all' concern.
Furthermore, this allows for a more manageable and incremental
approach to deploying DMARC allowing more aggressive policies
to be deployed in areas where there is higher confidence in
email authentication practices.
o I use third-party senders for my emails.
While the use of third party vendors for email delivery
requires some additional consideration, it is not a major
hurdle for adoption. Having good Service Level Agreements
(SLAs) with your providers that touch upon any changes that
might impact email authentication should be explicit if at all
possible to include such items as changes to email hosts and
addresses (usually impacting SPF) or DKIM key rotations.
Providing visibility to vendors of their results via regular
aggregate or message level reporting can help tremendously if
mail rejection due to 'false-negatives'.[*] Applying subdomain
segregation as noted previously can also be helpful for
reporting purposes when more than one email provider is used.
[*]In this context, a false positive is the identification
of a valid email failing authentication and having a DMARC
policy applied when it should not have.
o Some of my email is auto-forwarded.
The email auto-forwarding scenario has been considered in the
deployment of DMARC. It is for that reason that a DMARC policy
is only applied if both SPF and DMARC authentication fails. In
the auto-forwarding scenario, one can expect SPF to fail at the
final destination, while DKIM is more resilient in that regard.
But there are those circumstances that in the process of auto-
forwarding emails are modified (including changes to message
contents through automatic footer insertion such as Anti-Virus
stamps).
Any time an email is handled, the chance for non-delivery
increases. From a sender's point of view though, the email did
reach the mailbox as expressed by the individual who supplied
the address in the first place.
Additional concerns:
Reasons for not publishing a DMARC record (yet).
Concern for incremental deployment.
Crocker Expires October 03, 2013 [Page 5]
Internet-Draft dmarcops April 2013
Going through mailing lists.
Variability in receiver processing; creates unpredictability
overall.
4. Planning for DMARC adoption
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 is intended to protect transactional mail.[*] If you don't send
transactional mail, you are not in the primary use case for DMARC,
and you probably do not want to set up domains with p=reject. 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.
ISSUE: this is a major assertion and usage constraint. It might
be worth a separate discussion in the document, to give guidance
on different styles of 'users' and how DMARC is, or is not,
appropriate to them. (/ed)
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.
Crocker Expires October 03, 2013 [Page 6]
Internet-Draft dmarcops April 2013
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
Crocker Expires October 03, 2013 [Page 7]
Internet-Draft dmarcops April 2013
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 rollout 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]
How to implement DMARC on a corporate email domain.
Crocker Expires October 03, 2013 [Page 8]
Internet-Draft dmarcops April 2013
Choosing the domain name for alignment.
Choosing Strict vs. Relaxed.
Incremental Roll-Out.
5. DNS Configuration
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]
o Malformed DMARC policy TXT records in DNS.
Can these be used for anything?
Should a policy that does not conform to the spec be ignored?
Is there any benefit in attempting to infer meaning (monitor =
none, non = ??, rejec = ??)
How lenient can one safely be as regards spacing, quotes,
separators and slashes?
Is there anyway I can report the malformation to the domain
owner?
Crocker Expires October 03, 2013 [Page 9]
Internet-Draft dmarcops April 2013
o DMARC records for many domain names.
6. Receiver Processing
o Rapid adoption of DMARC by apparent spammers.
Thousands upon thousands of DMARC records published by abusive
domains -- probably wildcarding, but it works out the same
Using data that is several weeks old, we have a handful of
domains that are accepting aggregate reports for over 20
thousand subdomains each
Are the reports (either aggregate or forensic) providing the
spammers insight that they did not already have?
***POTENTIALLY PROBLEMATIC QUESTION TO FOLLOW*** Should I only
send reports to domains that I trust?
7. Report Generation
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.
<report_metadata>
<org_name> This is generally the domain responsible for
producing the data in the report (i.e. the report
Crocker Expires October 03, 2013 [Page 10]
Internet-Draft dmarcops April 2013
generator). In the example below it is
'google.com'. The report itself contains data
about messages addressed to users at gmail.com and
many other domains hosted by Google.
<email> The email address where a report recipient can
alert the report generator to problems related to
the DMARC aggregate report. This can be a mailing
list address or contain multiple email addresses.
<extra_contact_info> A place to point out additional
information or resources provided by the report
generator. This could be the URL of a website with
additional help, a phone number, etc.
<report_id> A unique report identifier. This should be
unique across all reports by the report generator
over time, including reports generated in parallel
across multiple MTA's.
<date_range> Date range of messages included in the report.
The specification says "specified in seconds since
epoch". Note that the begin timestamp for your
first report should not be the value 0, but should
instead be the begin date/time for the interval.
<begin> UNIX timestamp in UTC.
<end> UNIX timestamp in UTC.
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.
<?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>
Crocker Expires October 03, 2013 [Page 11]
Internet-Draft dmarcops April 2013
<policy_published>
<domain>facebook.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>reject</p>
<sp>reject</sp>
<pct>100</pct>
</policy_published>
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.
<source_ip> IP address (IPv4 or IPv6) of the connecting SMTP
host.
<count> The aggregated count of messages represented by this
record. The values of all fields contained within the
<record> must be identical to be part of the aggregate count
in this record.
<policy_evaluated>
<disposition> The <disposition> field in DMARC aggregate
data is intended to convey the final DMARC
Crocker Expires October 03, 2013 [Page 12]
Internet-Draft dmarcops April 2013
disposition of the message. This is the result of
the domain's policy combined with the DKIM and SPF
aligned policy results. The <disposition> field is
NOT intended to convey the ultimate placement of
the message by the receiving MTA, if for example
the report generator decides not to take the DMARC
action based on a local policy (Section 7.3). The
allowable results are "none", "quarantine", or
"reject".
<spf> The DMARC aligned result for SPF. This must be
either "pass" or "fail".
<dkim> The DMARC aligned result for DKIM. This must be
either "pass" or "fail".
<identifiers>
<header_from> This is the RFC 5322.From domain in the
message(s) for this record. Note that this is the
domain following the @ in the original address,
stripped of all surrounding non-domain commentary.
<auth_results>
<dkim>
<domain> This is the DKIM signing domain (d=) in
the DKIM signature that the receiver
chose to validate and report.
<result> This is the result of the DKIM
authentication check. This is NOT the
DMARC aligned result. The allowable
results are specified in the DMARC XML
Schema and refer to RFC 5451. Note
that the correct value to report when
no signature is present is "none" as
opposed to "neutral" or NULL.
<spf>
<domain> This is the domain used for the SPF
check. Usually it will be the RFC
5321.MAILFROM domain. In cases of a
NULL MAILFROM it may be the EHLO
domain, depending on receiver
implementation of SPF.
Crocker Expires October 03, 2013 [Page 13]
Internet-Draft dmarcops April 2013
<result> This is the result of the SPF
authentication check. This is NOT the
DMARC aligned result. The allowable
results are specified in the DMARC XML
Schema. Note that the correct way to
report that no record exists is "none"
as opposed to a NULL value.
Below are three examples of real DMARC XML records for a domain with
a DMARC reject policy in place.
Example 1. 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 2. This record indicates that 3 messages were represented by
this set of data points. The disposition for these messages was
Crocker Expires October 03, 2013 [Page 14]
Internet-Draft dmarcops April 2013
"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. 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>
Crocker Expires October 03, 2013 [Page 15]
Internet-Draft dmarcops April 2013
<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>
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.
<policy_evaluated>
<disposition> See Section 7.2.
Crocker Expires October 03, 2013 [Page 16]
Internet-Draft dmarcops April 2013
<spf> See Section 7.2.
<dkim> See Section 7.2.
<reason> Present ONLY if the report generator means to tell
the report recipient that they did not follow the
DMARC disposition.
<type> If a <reason> is included in the record
the <type> must be present. The
purpose of this field is to explain why
the DMARC policy was overridden.
Allowable values are "forwarded",
"sampled_out", "trusted_forwarder",
"mailing_list", "local_policy", and
"other". DMARC does NOT attempt to
standardize the meaning of each of
these types nor the methodology by
which a report generator determines the
<type> to report.
<comment> Optional. A report generator may
include extra explanatory text here.
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>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>
Crocker Expires October 03, 2013 [Page 17]
Internet-Draft dmarcops April 2013
</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 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.
<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>
Crocker Expires October 03, 2013 [Page 18]
Internet-Draft dmarcops April 2013
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>support.facebook.com</domain>
</spf>
</auth_results>
</record>
7.4. Minimum requirements for DMARC forensic reports
DMARC forensic 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. Forensic 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 forensic 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.
Crocker Expires October 03, 2013 [Page 19]
Internet-Draft dmarcops April 2013
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
o Minimum requirements for aggregate report XML documents.
What is the bare minimum (in terms of data gleaned from a given
email) I need to produce a valid report?
What sections of the XML need to be repeated when there is a
new aggregation point (email from a different IP, for example)
Essentially this could be considered "XML for people who
thought they could figure out how to read an XSD but reality
crashed that party."
o Minimum requirements for forensic reports (soft-fail reports).
What is the bare minimum required to produce a forensic report.
Whether to request Failure Reports (ruf=)
o Utility of Local Policy Overrides.
8. Report Receipt and Analysis
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
Crocker Expires October 03, 2013 [Page 20]
Internet-Draft dmarcops April 2013
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.
Are they correct without typographical errors?
Did you include the "mailto:" prefix?
Crocker Expires October 03, 2013 [Page 21]
Internet-Draft dmarcops April 2013
2. Is the domain in your rua and ruf address the same as the domain
of your DMARC record?
If not, did you follow the process to verify external
destinations for data? See section 6.2 [DMARC]. for details.
3. Check your email receiving infrastructure and mail logs for
indications of problems receiving email.
Are you accepting email with potentially large attachments?
Do you need to whitelist any IP addresses? Or are you
checking DMARC on the incoming messages which may be failing?
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.
o Identify the number of sources (i.e. IP addresses) sending email
using your From domain. How many are there and how does that
compare to your knowledge of your organization's email sending
infrastructure?
o What is the daily volume of email messages (i.e. sum of all
counts) sent using your From domain? What is the volume from your
known sources vs. those you did not know about?
o What is the daily volume that passed DMARC aligned SPF and DKIM?
Passed only one but not the other?
o What is the daily volume of unauthenticated messages, those that
failed both DMARC aligned SPF and DKIM?
Crocker Expires October 03, 2013 [Page 22]
Internet-Draft dmarcops April 2013
o Are any previously unknown sources of email passing either or both
of DMARC aligned SPF or DKIM? If so why?
o What are all of these previously unknown sources of email using
your From domain?
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.
o Some number of records will indicate that the authentication check
(either SPF or DKIM) passed, yet the DMARC aligned value is a
failure. If you want to verify that these are all in fact due to
misaligned identifiers you can query your data store to show a
count of all such cases where the <spf><domain> or <dkim><domain>
does not match or have a sub-domain match to the <header_from>.
o If your domain has a reject policy, you may want to check how many
records have a <dkim> and <spf> value of "fail" in the
<policy_evaluated> section, but do not have a <disposition> of
"reject". If that occurs it indicates a problem with the
evaluation of your DMARC record.
o If a message that failed both DKIM and SPF is still delivered and
your domain has a reject policy (you may know this if it is
reported to you via customer complaint or from your own testing),
before assuming receiver error you should check for local policy
overrides (Section 7.3). Try to identify records in DMARC data
Crocker Expires October 03, 2013 [Page 23]
Internet-Draft dmarcops April 2013
where the <disposition> is correctly designated as "reject", but a
<reason><type> is indicated for the policy override. This is not
an error on the part of the receiver, but is allowable per the
DMARC specification.
8.3. Report Processing and Analysis Services
Do DMARC.org members think it is appropriate to point out here that
there are vendor and 3rd party resources that can help with report
receipt, processing, and analysis? Of course we would not mention
specifics here, but could point to the dmarc.org/resources. I feel
it is appropriate to point out that a build vs buy decision is
possible.
8.4. Additional concerns
When can I expect to receive my first aggregate report?
DMARC failure/forensic reports are not being received.
Distinguishing mis-processing of DMARC versus local policy
variations.
9. Miscellaneous
This section is meant as a catch-all, for items that haven't yet been
assigned to their appropriate section.
o Performing remote destination checking
What happens if I don't?
o Identifier alignment
{This has been cited, but not yet explained, as a potential BCP
issue. -ed}
o Owner vs. Operator
{It is possible that there are distinctive practices for domain
name owners, versus agents that operate DNS or email services
on behalf of the name owner. -ed}
Crocker Expires October 03, 2013 [Page 24]
Internet-Draft dmarcops April 2013
10. Interaction Issues
Some issues come into play when DMARC is used in conjunction with one
or more other services.
o Sender using both DMARC and ADSP.
11. DMARC Commentary
This section explains a number of choices made for DMARC.
o Rationale for choosing ZIP for the aggregate reports.
12. Privacy Concerns.
IP Addresses in reports
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.
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.
[Original listing of issues]
o DNS Abuse.
Crocker Expires October 03, 2013 [Page 25]
Internet-Draft dmarcops April 2013
Most probably don't see this, but adding potentially multiple
new DNS lookups per email multiplies rapidly
DNS Cache can only help for so long
Agg reports are (probably) created from some other host
If Org Domain policy lookups are required, you may get two
lookups every time there is a single lookup
14. References
14.1. References - Normative
[DMARC] Kucherawy, M., Ed., "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 [1]. 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
Crocker Expires October 03, 2013 [Page 26]
Internet-Draft dmarcops April 2013
Dave Crocker (editor)
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086
USA
Phone: +1.408.246.8253
Email: dcrocker@bbiw.net
Crocker Expires October 03, 2013 [Page 27]