One document matched: draft-crocker-dmarc-bcp-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no"?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc inline="yes"?>
<?rfc topblock="yes" ?>
<?rfc autobreaks="yes" ?>
<rfc
category="bcp"
docName="draft-crocker-dmarc-bcp-01"
ipr="trust200902">
<front>
<title
abbrev="dmarcops">Using DMARC</title>
<author
fullname="Dave Crocker"
initials="D."
role="editor"
surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<date
day=""
month=""
year="2013"></date>
<area></area>
<workgroup></workgroup>
<keyword></keyword>
<abstract>
<t>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. </t>
</abstract>
</front>
<middle>
<section
title="Introduction">
<t>Email abuse often relies on unauthorized use of a domain name, such
as one belonging to a well-known company (brand). <xref
target="RFC4408">SPF</xref> and <xref
target="RFC6376">DKIM</xref> 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. <xref
target="DMARC"></xref> 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. </t>
<t>Discussion is divided along basic lines of activity: <list>
<t><list
style="symbols">
<t>Development</t>
<t>DNS Configuration</t>
<t>Report Generation</t>
<t>Receiver Processing</t>
</list></t>
</list>
</t>
<t>An IETF mailing list for discussing DMARC issues has been
established: dmarc@ietf.org.<list>
<t><list
style="hanging">
<t
hangText="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 </t>
</list></t>
</list></t>
</section>
<section
title="Development">
<t>{This section is meant for any any software development practices,
relevant to the use of DMARC. -ed} <list>
<t>Core Functionality</t>
<t>Tools Support</t>
</list></t>
</section>
<section
title="Barriers to Adoption (or, How I Learned
to Stop Worrying and Love DMARC)">
<t>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</t>
<t><list
style="symbols">
<t>I don't know where all my email is sent from! <list>
<t>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. </t>
<t>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).</t>
<t>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</t>
<t>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.</t>
</list><vspace></vspace></t>
<t>If I publish a DMARC policy, I lose flexibility in email
delivery. <list>
<t>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 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.</t>
</list><vspace></vspace></t>
<t>I use third-party senders for my emails. <list>
<t>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.<list>
<t>[*]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.</t>
</list>
</t>
</list><vspace></vspace></t>
<t>Some of my email is auto-forwarded. <list>
<t>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). </t>
<t>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.</t>
</list><vspace></vspace></t>
</list></t>
<t>Additional concerns:<list>
<t>Reasons for not publishing a DMARC record (yet).</t>
<t> Concern for incremental deployment.</t>
<t>Going through mailing lists.</t>
<t>Variability in receiver processing; creates unpredictability
overall.</t>
</list></t>
</section>
<section
title="Planning for DMARC adoption">
<t>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.</t>
<section
title="Decide what you need to do">
<t>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.<list>
<t>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)</t>
</list></t>
<t>So, first you need to determine what domains you own, and sort
them into piles.</t>
<t>Sending domains:<list
style="numbers">
<t>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.</t>
<t>Domains that send only transactional mail. These should
also be protected at p=reject, but you will need to follow
normal roll-out procedures.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<t>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: <list
style="numbers">
<t>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. </t>
<t>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).</t>
<t>Move the transactional mail to another domain, usually a
subdomain of the original domain (official.example.com, for
instance).</t>
<t>Decide not to protect the mail with DMARC directly and
use a p=none record to get reporting.</t>
</list>
</t>
<t>Receiving domains: <list
style="numbers">
<t>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.</t>
<t>Domains that receive mail for individuals. These domains
should implement inbound DMARC to mitigate phishing
problems.</t>
</list></t>
</section>
<section
title="Picking Alignment and SP Parameter Values">
<t>Once you know what domains you are trying to protect, you can
pick values for alignment and for sp.</t>
<t>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.</t>
<t>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 rollout you will need separate records.</t>
</section>
<section
title="Incremental Roll-Out, Sending">
<t>The procedure for incrementally rolling out DMARC on an
individual Sending domain is discussed elsewhere.</t>
<t>Most senders have multiple domains, however, and will have to
pick which ones to work on first. Start with some combination of <list
style="numbers">
<t>Your most attacked domains.</t>
<t>The easiest domains to secure.</t>
</list></t>
<t>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)</t>
</section>
<section
title="Incremental Roll-Out, Receiving">
<t>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.</t>
</section>
<section
title="[Original bullets]">
<t><list>
<t>How to implement DMARC on a corporate email domain.</t>
<t>Choosing the domain name for alignment.</t>
<t>Choosing Strict vs. Relaxed.</t>
<t>Incremental Roll-Out.</t>
</list></t>
</section>
</section>
<section
title="DNS Configuration">
<t>
<list
style="hanging">
<t
hangText="Malformed Policies">DMARC policies published in DNS
which are malformed should be ignored by validators with
regard to policy assertions.</t>
<t
hangText="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.</t>
<t
hangText="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.</t>
<t
hangText="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.</t>
</list>[Original listing of issues]<list
style="symbols">
<t>Malformed DMARC policy TXT records in DNS. <list>
<t>Can these be used for anything?</t>
<t>Should a policy that does not conform to the spec be
ignored?</t>
<t>Is there any benefit in attempting to infer meaning
(monitor = none, non = ??, rejec = ??)</t>
<t>How lenient can one safely be as regards spacing,
quotes, separators and slashes?</t>
<t>Is there anyway I can report the malformation to the
domain owner?</t>
</list></t>
<t>DMARC records for many domain names.</t>
</list>
</t>
</section>
<section
title="Receiver Processing">
<t>
<list
style="symbols">
<t>Rapid adoption of DMARC by apparent spammers. <list>
<t>Thousands upon thousands of DMARC records published by
abusive domains -- probably wildcarding, but it works
out the same</t>
<t>Using data that is several weeks old, we have a handful
of domains that are accepting aggregate reports for over
20 thousand subdomains each</t>
<t>Are the reports (either aggregate or forensic) providing
the spammers insight that they did not already have?</t>
<t>***POTENTIALLY PROBLEMATIC QUESTION TO FOLLOW*** Should
I only send reports to domains that I trust?</t>
</list></t>
</list>
</t>
</section>
<section
anchor="repgen"
title="Report Generation">
<section
title="DMARC aggregate XML report naming and report metadata">
<t>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. </t>
<t>The correct compression mechanism and filename convention is
described in <xref
target="DMARC">section 12.2.1</xref> 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. </t>
<t>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. </t>
<t><list>
<t><list
style="hanging">
<t
hangText="<report_metadata>">
<list
style="hanging">
<t
hangText="<org_name>"> This is generally
the domain responsible for producing the data
in the report (i.e. the report 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. </t>
<t
hangText="<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. </t>
<t
hangText="<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. </t>
<t
hangText="<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. </t>
<t
hangText="<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. <list
style="hanging">
<t
hangText="<begin>"> UNIX timestamp
in UTC. </t>
<t
hangText="<end>"> UNIX timestamp in
UTC. </t>
</list></t>
</list></t>
</list></t>
</list></t>
<t>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. <list>
<t><figure>
<artwork type="xml"><![CDATA[<?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>]]></artwork>
</figure></t>
</list></t>
</section>
<section
anchor="repminreq"
title="Minimum requirements for DMARC XML aggregate
report records">
<t>The data contained in a DMARC aggregate report, at minimum,
allows a report recipient to: <list
style="numbers">
<t> Identify sources sending email purporting to be
“From” its domain and sub-domains. </t>
<t> Determine the aligned DMARC results of SPF and DKIM
checks. </t>
<t> Determine the DMARC disposition of the message. </t>
<t> Determine the identities used to check the underlying
authentication mechanisms. </t>
<t> Determine the results of the underlying authentication
mechanism checks. </t>
</list></t>
<t>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. <list>
<t><list
style="hanging">
<t
hangText="<source_ip>"> IP address (IPv4 or
IPv6) of the connecting SMTP host. </t>
<t
hangText="<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. </t>
<t
hangText="<policy_evaluated>">
<list
style="hanging">
<t
hangText="<disposition>"> The
<disposition> field in DMARC aggregate
data is intended to convey the final DMARC
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 (<xref
target="localpolicy"></xref>). The allowable
results are “none”,
“quarantine”, or
“reject”. </t>
<t
hangText="<spf>"> The DMARC aligned
result for SPF. This must be either
“pass” or “fail”. </t>
<t
hangText="<dkim>"> The DMARC aligned
result for DKIM. This must be either
“pass” or “fail”. </t>
</list></t>
<t
hangText="<identifiers>">
<list
style="hanging">
<t
hangText="<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. </t>
</list></t>
<t
hangText="<auth_results>">
<list
style="hanging">
<t
hangText="<dkim>">
<list
style="hanging">
<t
hangText="<domain>"> This is the
DKIM signing domain (d=) in the DKIM
signature that the receiver chose to
validate and report. </t>
<t
hangText="<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. </t>
</list></t>
<t
hangText="<spf>">
<list
style="hanging">
<t
hangText="<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. </t>
<t
hangText="<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. </t>
</list></t>
</list></t>
</list></t>
</list></t>
<t>Below are three examples of real DMARC XML records for a domain
with a DMARC reject policy in place. </t>
<t>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”. <list>
<t><figure>
<artwork type="xml"><![CDATA[<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>]]></artwork>
</figure></t>
</list></t>
<t>Example 2. 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. <list>
<t><figure>
<artwork type="xml"><![CDATA[<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>]]></artwork>
</figure></t>
</list></t>
<t>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”. <list>
<t><figure>
<artwork type="xml"><![CDATA[<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> ]]></artwork>
</figure></t>
</list></t>
</section>
<section
anchor="localpolicy"
title="Use and Reporting of Local Policy Overrides">
<t>The DMARC specification allows for a DMARC compliant receiver to
take an action that is different than the DMARC disposition for
the message (see <xref
target="DMARC">Section B.3.1, SMTP-time Processing</xref>).
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. </t>
<t>The reporting of a “PolicyOverrideReason” is
specified in <xref
target="DMARC">Appendix C</xref>. 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. <list>
<t><list
style="hanging">
<t
hangText="<policy_evaluated>">
<list
style="hanging">
<t
hangText="<disposition>"> See <xref
target="repminreq"></xref>. </t>
<t
hangText="<spf>"> See <xref
target="repminreq"></xref>. </t>
<t
hangText="<dkim>"> See <xref
target="repminreq"></xref>.</t>
<t
hangText="<reason>"> Present ONLY if the
report generator means to tell the report
recipient that they did not follow the DMARC
disposition. <list
style="hanging">
<t
hangText="<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. </t>
<t
hangText="<comment>"> Optional. A
report generator may include extra
explanatory text here. </t>
</list></t>
</list></t>
</list></t>
</list></t>
<t>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. <list>
<t><figure>
<artwork type="xml">
<![CDATA[<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>]]></artwork>
</figure></t>
</list></t>
<t>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. <list>
<t><figure>
<artwork type="xml"><![CDATA[<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> ]]></artwork>
</figure></t>
</list></t>
</section>
<section
anchor="minreqfor"
title="Minimum requirements for DMARC forensic reports">
<t>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. </t>
<t>The data contained in a DMARC forensic report, at minimum, allows
a report recipient to: <list
style="numbers">
<t> Identify the source sending each failed message purporting
to be “From” its domain or sub-domain. </t>
<t> Determine the aligned DMARC result of the SPF and DKIM
checks. </t>
<t> 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. </t>
<t> Identify the full DKIM signature checked (if the message
was DKIM signed). </t>
<t> Identify the results of the SPF and DKIM authentication
checks. </t>
<t> Identify the URLs in the body of the message. </t>
<t> Identify the full RFC5322.From email address in the
message. This should include the display name portion of
the From. </t>
<t> Identify the Subject of the message. </t>
</list></t>
<t>Details on the format of failure reports are found in <xref
target="DMARC">sections 8.4. and 8.4.1</xref>. </t>
</section>
<section
title="Additional concerns">
<t><list
style="symbols">
<t>Minimum requirements for aggregate report XML documents. <list>
<t>What is the bare minimum (in terms of data gleaned
from a given email) I need to produce a valid
report?</t>
<t> What sections of the XML need to be repeated when
there is a new aggregation point (email from a
different IP, for example)</t>
<t>Essentially this could be considered "XML for people
who thought they could figure out how to read an XSD
but reality crashed that party."</t>
</list></t>
<t>Minimum requirements for forensic reports (soft-fail
reports). <list>
<t>What is the bare minimum required to produce a
forensic report.</t>
<t> Whether to request Failure Reports (ruf=)</t>
</list>
</t>
<t>Utility of Local Policy Overrides.</t>
</list></t>
</section>
</section>
<section
title="Report Receipt and Analysis">
<section
title="Report Receipt">
<section
title="Your first DMARC aggregate reports">
<t>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. </t>
<t>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.
</t>
</section>
<section
title="Your first DMARC failure reports">
<t>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. </t>
<t>The failure reports you will receive are specified in <xref
target="DMARC">section 8.4. and 8.4.1</xref>.. 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. </t>
</section>
<section
title="What if I do not receive any DMARC
reports?">
<t>If you have published DMARC records and waited 24 to 48 hours
yet still received no data you should check the following: <list
style="numbers">
<t> Check the rua and ruf addresses in your DMARC record.<list>
<t> Are they correct without typographical errors? </t>
<t> Did you include the "mailto:" prefix? </t>
</list></t>
<t> Is the domain in your rua and ruf address the same as
the domain of your DMARC record? <list>
<t>If not, did you follow the process to verify
external destinations for data? See <xref
target="DMARC">section 6.2</xref>. for details.
</t>
</list></t>
<t> Check your email receiving infrastructure and mail logs
for indications of problems receiving email. <list>
<t> Are you accepting email with potentially large
attachments? </t>
<t> Do you need to whitelist any IP addresses? Or are
you checking DMARC on the incoming messages which
may be failing? </t>
</list></t>
</list></t>
</section>
</section>
<section
title="Report Analysis">
<section
title="Data contained in DMARC reports">
<t>For detailed descriptions on the meaning of different data
fields in DMARC aggregate XML files please see the
descriptions in subsections .1-.3 of <xref
target="repgen"></xref>. For a description of the data
contained in a failure report (see <xref
target="minreqfor"></xref>). 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. </t>
</section>
<section
title="What should I look for first?">
<t>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. <list
style="symbols">
<t>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? </t>
<t>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? </t>
<t>What is the daily volume that passed DMARC aligned SPF
and DKIM? Passed only one but not the other? </t>
<t>What is the daily volume of unauthenticated messages,
those that failed both DMARC aligned SPF and DKIM? </t>
<t>Are any previously unknown sources of email passing
either or both of DMARC aligned SPF or DKIM? If so why? </t>
<t>What are all of these previously unknown sources of
email using your From domain? </t>
</list></t>
<t>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. </t>
<t>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. </t>
</section>
<section
title="Investigating Anomalies in DMARC
data">
<t>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. <list
style="symbols">
<t>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>. </t>
<t>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. </t>
<t>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 (<xref
target="localpolicy"></xref>). Try to identify
records in DMARC data 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.
</t>
</list></t>
</section>
</section>
<section
title="Report Processing and Analysis
Services">
<t>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. </t>
</section>
<section
title="Additional concerns">
<t><list>
<t>When can I expect to receive my first aggregate report?</t>
<t>DMARC failure/forensic reports are not being received.</t>
<t>Distinguishing mis-processing of DMARC versus local policy
variations.</t>
</list></t>
</section>
</section>
<section
title="Miscellaneous">
<t>This section is meant as a catch-all, for items that haven't yet
been assigned to their appropriate section. <list
style="symbols">
<t>Performing remote destination checking <list>
<t>What happens if I don't?</t>
</list>
</t>
<t>Identifier alignment<list>
<t>{This has been cited, but not yet explained, as a
potential BCP issue. -ed}</t>
</list></t>
<t>Owner vs. Operator<list>
<t>{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}</t>
</list></t>
</list></t>
</section>
<section
title="Interaction Issues">
<t>Some issues come into play when DMARC is used in conjunction with
one or more other services.</t>
<t><list
style="symbols">
<t> Sender using both DMARC and ADSP.</t>
</list></t>
</section>
<section
title="DMARC Commentary">
<t>This section explains a number of choices made for DMARC.</t>
<t><list
style="symbols">
<t>Rationale for choosing ZIP for the aggregate reports.</t>
</list></t>
</section>
<section
title="Privacy Concerns.">
<t>
<list>
<t>IP Addresses in reports</t>
</list></t>
</section>
<section
title="Security Considerations">
<t> In this section we describe several security considerations related
to the implementation of the DMARC protocol. <list
style="numbers">
<t>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.</t>
<t>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.</t>
</list> [Original listing of issues] <list
style="symbols">
<t>DNS Abuse. <list>
<t>Most probably don't see this, but adding potentially
multiple new DNS lookups per email multiplies
rapidly</t>
<t>DNS Cache can only help for so long</t>
<t>Agg reports are (probably) created from some other
host</t>
<t>If Org Domain policy lookups are required, you may get
two lookups every time there is a single lookup </t>
</list></t>
</list></t>
</section>
</middle>
<back>
<references
title="References - Normative">
<reference
anchor="DMARC">
<front>
<title
abbrev="DMARC">Domain-based Message Authentication, Reporting
and Conformance (DMARC)</title>
<author
fullname="M. Kucherawy"
initials="M."
role="editor"
surname="Kucherawy">
<organization>Cloudmark</organization>
</author>
<date
day="30"
month="March"
year="2013"></date>
</front>
<seriesInfo
name="URL"
value="https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/"></seriesInfo>
</reference>
</references>
<references
title="References - Informative">
<reference
anchor="RFC4408">
<front>
<title>Sender Policy Framework (SPF) for Authorizing Use of
Domains in E-Mail, Version 1</title>
<author
fullname="M. Wong"
initials="M."
surname="Wong">
<organization></organization>
</author>
<author
fullname="W. Schlitt"
initials="W."
surname="Schlitt">
<organization></organization>
</author>
<date
month="April"
year="2006"></date>
<abstract>
<t>E-mail on the Internet can be forged in a number of ways.
In particular, existing protocols place no restriction on
what a sending host can use as the reverse-path of a
message or the domain given on the SMTP HELO/EHLO commands.
This document describes version 1 of the ender Policy
Framework (SPF) protocol, whereby a domain may explicitly
authorize the hosts that are allowed to use its domain
name, and a receiving host may check such authorization.
This memo defines an Experimental Protocol for the Internet
community.</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="4408"></seriesInfo>
<format
octets="105009"
target="http://www.rfc-editor.org/rfc/rfc4408.txt"
type="TXT"></format>
</reference>
<reference
anchor="RFC6376">
<front>
<title>DomainKeys Identified Mail (DKIM) Signatures</title>
<author
fullname="D. Crocker"
initials="D."
surname="Crocker">
<organization></organization>
</author>
<author
fullname="T. Hansen"
initials="T."
surname="Hansen">
<organization></organization>
</author>
<author
fullname="M. Kucherawy"
initials="M."
surname="Kucherawy">
<organization></organization>
</author>
<date
month="September"
year="2011"></date>
<abstract>
<t>DomainKeys Identified Mail (DKIM) permits a person, role,
or organization that owns the signing domain to claim some
responsibility for a message by associating the domain with
the message. This can be an author's organization, an
operational relay, or one of their agents. DKIM separates
the question of the identity of the Signer of the message
from the purported author of the message. Assertion of
responsibility is validated through a cryptographic
signature and by querying the Signer's domain directly to
retrieve the appropriate public key. Message transit from
author to recipient is through relays that typically make
no substantive change to the message content and thus
preserve the DKIM signature.</t><t> This memo
obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] </t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="6376"></seriesInfo>
<format
octets="176999"
target="http://www.rfc-editor.org/rfc/rfc6376.txt"
type="TXT"></format>
</reference>
</references>
<section
title="Acknowledgements">
<t> DMARC and the version of this document submitted to the IETF were
the result of lengthy efforts by an informal industry consortium: <eref
target="http://dmarc.org">DMARC.org</eref>. 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.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:29:19 |