One document matched: draft-crocker-dmarc-bcp-02.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-02" 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" />
<area />
<workgroup />
<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>
<list>
<t><list style="hanging">
<t hangText="*** EDITOR'S NOTE *** ">The current version incorporates new sections of
relatively raw text from the original DMARC.org team and has been edited
merely to convert to xml2rfc format. This version has not yet received
editing for content, or any of the wider, public review, discussion and
revision that is intended. This version is being issued as an Internet Draft
in order to create an archived snapshot, including noting the authors of
specific sub-sections. It is also hoped this version whets more appetites
for adding content... /Dave </t>
</list></t>
</list></t>
<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" /> 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.</t>
</section>
<section title="Development {T. Draegen}">
<t>This section addresses issues that can occur when developing systems related to DMARC.
Additional resources for developing DMARC can be found at DMARC.ORG.</t>
<section title="Developing DMARC Components">
<t>DMARC builds on a number of existing technologies, and introduces new components only
when necessary. This section helps to identify which components are readily available
and where new development may be necessary. Combined, the components discussed here
form an end-to-end DMARC solution.</t>
<section title="Runtime DMARC processing - Sender side">
<t>DMARC requires very little new functionality for senders of email. SPF and DKIM
are well developed technologies that can be implemented and deployed in isolation,
and are supported by existing communities. DMARC uses TXT-based DNS records that
are common. Support for underscores in DNS labels is important to consider while
developing DNS tools that support DMARC, as DMARC records are located by
prepending "_dmarc." to a domain and performing a TXT query.</t>
<t>The ability to configure the domain used for 5321.MailFrom addresses and for DKIM
d= tags is important from a development perspective. Users of DMARC often require
flexibility in specifying the domains used in both, as DMARC introduces the
concept of Identifier Alignment to tie existing authentication technologies to
email's 5322.From header domain.</t>
</section>
<section title="Runtime DMARC processing - Receiver side">
<t>Because DMARC leverages existing authentication technology, developers can often
integrate this functionality into existing systems without needing to develop
entirely new modules. Developers need to take note that DMARC introduces a linkage
between email's 5322.From header domain and the domains authenticated by SPF and
DKIM, and so Authenticated Domains must be made available from SPF and DKIM
processing.</t>
<t>Receiver side processing of DMARC results can also be performed during the SMTP
conversation, which may cause developers to re-factor SPF and DKIM processing code
that otherwise might occur after a message has been accepted. Performing the DMARC
check during the SMTP conversation allows receivers to enforce "reject" policies
immediately.</t>
<t>Receiver side DMARC development also introduces the concept of Organization
Domain, which should be developed in a modular way so that future
enhancements/development in the area of Organization Domain discovery can be
easily integrated.</t>
<t>The use of Authentication-Results headers is highly recommended to ease
down-stream processing by receivers.</t>
<t>The collection of feedback statistics for use in generating DMARC aggregate likely
presents the most opportunity for new development. Collection, harvesting, and
storage of such statistics should be properly assessed and scoped. The size of
collected datasets can become quite large or high-volume email sites.</t>
</section>
<section title="Feedback processing - Generator">
<t>Receivers that generate DMARC feedback should be aware of several facets of
DMARC-related development.</t>
<t>For feedback that is generated once a day, feedback should span an entire 24 hour
UTC-based cycle.</t>
<t>Monitoring and controls around the generation of DMARC feedback should be
constructed to allow operators the ability to discover abuse of report generating
code. Abusers will construct DMARC records for large numbers of domains that send
unwanted email. Consider developing hooks so that intelligence decisions can be
made as to when DMARC data collection occurs to limit wasted data collection and
storage resources. </t>
<t>See Section 7. "Report Generation" for additional details.</t>
</section>
<section title="Feedback processing - Consumer">
<t>Report consumers should be able to control the flow of incoming data to disallow
abuse of reporting addresses.</t>
<t>See Section 8. "Report Receipt and Analysis" for additional details.</t>
</section>
</section>
<section title="Developing DMARC-compliant Systems">
<t>Developers of DMARC-compliant systems should consider DMARC functionality from the
perspective of the day to day operator, and ensure their ease of use and deployment
scenarios are addressed. The configuration of domains, the maintenance of SPF records
and DKIM signing keys, and the ability to quickly diagnose and correct problems are
essential when creating robust DMARC-compliant systems.</t>
<t>Integration of existing functionality to build a DMARC-compliant system can be helped
by leveraging interoperability tests for various integrated components.</t>
</section>
<section title="Sending DMARC-compliant Email">
<t>Large portions of this document are relevant to sending DMARC-compliant email.</t>
</section>
<section title="Original bullets:">
<t>
<list style="symbols">
<t>Core Functionality</t>
<t>Tools Support</t>
</list></t>
</section>
</section>
<section
title="Barriers to Adoption (or, How I Learned
to Stop Worrying and Love DMARC) {A. Popowycz}">
<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 /></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 /></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 /></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 /></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 {E. Zwicky}">
<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 provides protection against some forms of email domain name abuse. Its
restricted policy form (p=quarantine or p=reject) is not intended for all use cases,
and is beneficial only in the presence of an actual spoofing problem. You may,
however, want to protect mailboxes by checking inbound mail, and you may want
information about how your domains are showing up at recipients by publishing a
p=none record.</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 roll-out 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 {M. Hammer}">
<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>Should a receiver try to infer meaning in the case where the syntax of a
DMARC TXT record isn't correct? For example, if "p=monitor" (or p="non",
etc.) should the receiver assume the domain owner wants to only "monitor"
the domain (requesting no action other than reports) and apply processing as
if it was "p=none"? What if there are what appear to be obvious spelling
mistakes (e.g. "p=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 {S.Solanki}">
<section title="Preparing for DMARC processing">
<t>DMARC is a policy enforcement and reporting standard that builds on SPF and DKIM to
provide more deterministic outcomes of authentication-failed messages. DMARC
implementation helps receivers to more easily identify email from senders as
legitimate, and helps keep spam and phishing messages from reaching the inbox. </t>
<t>The receiver could use the following data points to better understand their incoming
email traffic: <list style="symbols">
<t>Total # of phishing messages and campaigns</t>
<t># of highly phished domains</t>
<t>Total # of senders publishing DMARC records</t>
<t>Total # of messages likely to be processed for DMARC evaluation</t>
</list></t>
<t>The next step is to scope the engineering work to implement DMARC processing. This
includes but not limited to <list style="symbols">
<t>Support for DKIM and SPF evaluation</t>
<t>Processing DMARC record policy</t>
<t>Aggregate and message level reporting</t>
<t>Evaluating for Privacy and performance implications</t>
<t>Integration with existing authentication mechanisms from processing to user
interface</t>
</list></t>
<t>It is recommended to participate in open DMARC forums, for pursuing general questions
or learning from experience of receivers who have already previously implemented
DMARC</t>
</section>
<section title="Implementing DMARC at receiver">
<t>During implementation the goal is to be compliant with the specification. In
particular the "must have" attributes have to be implemented to be considered
compliant. The optional attributes are left to receiver to determine implementation. </t>
<t>While implementing the specification consider leveraging or building the following
technologies <list style="symbols">
<t>DNS service to do real-time lookup</t>
<t>Cache to store recently obtained DMARC records </t>
<t>Dedicated reporting infrastructure to send regular aggregate and message level
reporting</t>
<t>Instrumentation to track the flow of messages through DMARC processing
pipeline</t>
<t>Configuration knobs to tune sampling rate and DMARC authentication priority</t>
<t>Trusted sender visual identification in the emails that pass DMARC
authentication</t>
</list></t>
</section>
<section title="Rolling out DMARC">
<t> A phased approach is best recommended for DMARC roll-out at receiver side. Start
with a small percentage of your email traffic being subject to DMARC processing.</t>
<t>Reach out to a select group of trusted senders who you know have already published
DMARC records. Work closely with them over a period of weeks to determine if the
implementation is working as expected. </t>
<t>Things to observe include but not limited to <list>
<t>Messages not getting DMARC verdict as expected (either false positives or false
negatives)</t>
<t>Reports not being sent in expected format or with missing information</t>
</list></t>
<t>Once any potential issues are fixed, consider ramping up the traffic to a larger
portion of the incoming traffic. This will identify issues normally caught at scale
such as excessing reporting queues or caching performance. This is also a good time
to monitor feedback on dmarc-dev forums where senders usually post observations or
complaints about DMARC issues. </t>
<t>Once satisfied with the feedback you are ready to roll it out full scale to the site
and announce to the world. </t>
</section>
<section title="Post roll-out">
<t>Post roll-out give sufficient time to evaluate if the processing pipeline is working
as expected.</t>
<t>These include monitoring the generated reports in your instrumentation
infrastructure. Specifically the "reject" and "quarantine" verdicts will give a
direct idea of how many phishing messages were filtered </t>
<t>This is a good time to share a summary of your experience implementing DMARC and its
benefits to you as the receiver over time. Feedback regarding quality of
documentation and any items missing or incorrect should be informed to the community
via dmarc-dev for future versions of the document. </t>
</section>
<section title="Original Bullets">
<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 failure) 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>
<section anchor="repgen" title="Report Generation {M. Jones}">
<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" />). 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><list>
<t><figure title="Example - 1 Msg / Disp Reject / No DKIM">
<preamble>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”.</preamble>
<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><list>
<t><figure title="Example - 3 Msgs / Disp None / DKIM-SPF Mix">
<preamble>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.</preamble>
<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><list>
<t><figure title="Example - 1 msg / Disp Reject / No DKIM">
<preamble>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”.</preamble>
<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" />. </t>
<t hangText="<spf>"> See <xref target="repminreq" />. </t>
<t hangText="<dkim>"> See <xref target="repminreq" />.</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 failure reports">
<t>DMARC failure reports serve two primary purposes. First is to allow a domain owner to
investigate in more detail, legitimate sources of their email that are failing one or
both modes of authentication. For example, from aggregate data one might know that a
domain’s 3rd party email is failing DKIM some percentage of the time yet not
know which messages are affected. Failure reports could show a consistent From
address and Subject from the source that are unsigned, indicating a specific campaign
not being signed by DKIM. Second is to allow a domain owner to understand and
mitigate specific threat campaigns abusing their domain. Examples include early
identification of phishing URLs in current campaigns for quick takedown or
identification of Subjects used in current campaigns which can be used by customer
service call center personnel to handle customer calls. </t>
<t>The data contained in a DMARC failure 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 failure reports (soft-fail reports). <list>
<t>What is the bare minimum required to produce a failure 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 {M. Jones}">
<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" />. For a description of the data contained in a failure report
(see <xref target="minreqfor" />). 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" />).
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>Is it appropriate to point out here that there are vendor and 3rd party resources
that can help with report receipt, processing, and analysis? Of course specifics
would not be mentioned here, but the document could point to the dmarc.org/resources
page. This could aid in making build vs. buy decisions. </t>
</section>
<section title="Additional concerns">
<t><list>
<t>When can I expect to receive my first aggregate report?</t>
<t>DMARC failure 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 -- What were they thinking of...?">
<t>This section explains a number of choices made for DMARC.</t>
<t><list style="hanging">
<t hangText="Rationale for choosing ZIP for the aggregate reports: {P. Midgen}">
primary consideration was increasing the amount of data that could be presented in
a single message and avoiding report truncation (e.g. many folks limit inbound
message size to 25MB). text compresses well in general, so we thought compression
would make sense. // rather than compress at the transport layer (e.g. send a
chunked/compressed stream over http) we thought email attachments were kinda
braindead given the existing message-based feedback infrastructure (e.g. ndr, arf,
etc.). // zip is everywhere, we needed to make no special consideration using it,
and (i believe, but this needs checking) it is also a registered content-type
(golden arrow of rationale leads back to "zip is everywhere").</t>
<t
hangText="Why doesn't DMARC solve its problem with mailing lists/gatewats? {P. Midgen}"
> This question typically refers to a set of well-known issues where messages
transiting mailing list managers (MLMs), relays, or forwarders fail DKIM or SPF
checks. <list>
<t>As a first principle, solving common operational issues in underlying
authentication mechanisms is out of scope for DMARC.</t>
</list></t>
<t>The recommendation is for senders to use both SPF and DKIM, since we know from
research conducted during draft development that the likelihood of simultaneous
SPF & DKIM failure, while possible, is far less common than individual
failures.</t>
<t>Senders are encouraged to use both SPF & DKIM to ensure robust operation of
DMARC and to pave the way for future technologies that will benefit from broad
adoption of email authentication, such as domain reputation.</t>
<t>This question also refers to the issue of expanding the set of alignable
authenticated identities under DMARC. At the moment DMARC looks at the
RFC5321.MailFrom (a/k/a envelope sender or return-path) for SPF, and the d= field
in the message's DKIM-Signature block(s), and attempts to align them with the
RFC5322.From domain since this in the majority of cases is displayed to the
message recipient by the MUA.</t>
<t> The import of that consideration can be argued, but we universally felt it was
important because it is such a common practice and because we are able in majority
of cases representing a high volume of mail to authenticate and align identities
with RFC5322.From. <list>
<t>There is no standardized practice for authenticating against the Sender or
other identity sources, it is out of scope for DMARC to do so and until
there exists a reliable and reasonably well-adopted mechanism that does so,
DMARC will rely on the envelope and body From identities.</t>
</list></t>
<t>As a final statement on this issue, it is worth reiterating the role of local
policy in the determination of message disposition. In a sense SPF and DKIM serve
to inform local policy mechanisms on the disposition of authenticated mail. DMARC
carries that tradition forward, but at the end of the day it is a matter of local
policy whether to act on the suggestions of authentication and policy mechanisms
or simply mark the message and move it further down the delivery pipeline.</t>
<t hangText="Who is the target audience for the DMARC specification? {P. Midgen}">
DMARC is intended for submission to become an IETF standard; in a sense this means
the intended audience is the entire internet and email community. That said, it
isn't for everyone. We believe DMARC does four important things:<list
style="numbers">
<t>Provides a method for uniform evaluation of the authentication results
generated by standard and well-deployed email authentication mechanisms
against a common set of identities.</t>
<t>Provides a reporting mechanism allowing senders to understand the
performance of their email authentication practices, and get an idea of the
IPs sending email on behalf of their domains.</t>
<t>Provides a deterministic policy mechanism allowing the sender to tell the
receiver how to dispose of their email in the event the policy conditions
aren't met.</t>
<t>It achieves this sender/receiver communication via DNS, at Internet
scale.</t>
</list> We figured most folks would find 1, 2 and 4 appealing; everyone likes
information and even more so if it is obtained easily and at low risk. Number 3 is
more tricky: under what circumstances should a sender publish anything other than
p=none? This depends on a huge number of variables and there is no if-then-else
type of guideline. Here are some of the things to consider: <list style="numbers">
<t>Are your domains used fraudulently? DMARC will help curb fraudulent use of
your organizational domain and subdomains. It will not stop homograph/cousin
domain abuse (e.g. fac3book.com), and it will not stop domain-padding (e.g.
facebook.superbaddudes.junkyjunkjunkorama1234.com) abuse.</t>
<t>Are you an ISP, MBP, or EDU? Your users tend to move around, have multiple
accounts, forward messages and do other things that increase the possibility
for a DMARC false positive. You, even more so than everyone else, will want
to start with a monitor-only policy so you can model the what-ifs. </t>
<t>Do you send mostly transactional, point-to-point mail (e.g. account
statements, password resets, etc.)? These are good candidates for DMARC
since our observation has been that these tend to be low risk of
failure.</t>
</list></t>
</list></t>
</section>
<section title="Privacy Considerations. {T. Adams}">
<t><list style="hanging">
<t hangText="NOTE: ">Capitalized terms related to privacy used in this section are
consistent with the "Guidelines on the Protection of Privacy and Transborder Flows
of Personal Data" published in 1980 (and subsequently reviewed in 2011) by the
Organisation for Economic Co-operation and Development (OECD).</t>
</list></t>
<t>Each of the two DMARC feedback reports have different characteristics related to privacy
based on their design. Aggregate Reports (RUA) are sent by a receiver at periodic
intervals (e.g. daily) and contain summary data regarding the number and type of email
messages that are processed in relation to the domain owner's DMARC policy. As such,
they do not contain Personal Data and are considered to have no impact on privacy.</t>
<t>The one identified exception to this is when an individual (a.k.a. "a Natural Person
with legal rights") is operating his or her own email server. In this case, the IP
address of the sending server reported in the RUA may identify the individual and thus
be classified as Personal Data in some jurisdictions.</t>
<t>Failure Reports (RUF), on the other hand, are sent by an email receiver each time an
email message being processed fails the DMARC authentication checks. The RUF may include
Personal Data as well as Sensitive Data, depending on the applicable regulatory
jurisdiction. When supporting RUF reports, an email receiver should consider whether or
not to include the full content of the unauthenticated email, as well as what email
header fields to redact.</t>
<t>As part of this consideration, the email receiver will need to understand its roll in
the flow of Personal Data. For example, the domain owner can be viewed as the Data
Controller for email sent under its aegis as is the case for email sent from the servers
of a company by its employees or transactional systems. In this case, the email receiver
is the Data Processor acting on behalf of the Data Controller, and as such the legal
responsibility for protection of the data rests with the domain owner. Thus, legitimate
mail that inadvertently fails the DMARC authorization checks (e.g. if the email was
handled by mailing list management software acting as an Intermediary Processor) is
clearly handled by this case.</t>
<t>The primary area of debate about privacy and RUF reporting revolves around the
protections offered to the individual (i.e. the "bad actor") who sends fraudulent email
purporting to be from another domain. Specifically, should the bad actor be protected by
privacy regulations within the applicable jurisdiction? Within the context of current
regulatory guidance, it is possible to view the email receiver as the Data Processor on
behalf of the bad actor, who is filling the role of Data Controller. It is an open
question only insofar as what to do about this bad actor who is clearly not
participating in the data flow in good faith.</t>
<t>Given that there is significant value in quickly identifying bad actors, and taking
appropriate enforcement action, it is worth exploring how to clarify that existing data
sharing regulations allow RUF reports. In any case, both the email receiver (as the
report generator) and the domain owner (as the report recipient) should ensure that the
appropriate operational policies are in place to protect the Personal Data being handled
as dictated by their part of the data flow.</t>
<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. {O. Gavrylyako}</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. {O.
Gavrylyako}</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" />
</front>
<seriesInfo name="URL"
value="https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/" />
</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 />
</author>
<author fullname="W. Schlitt" initials="W." surname="Schlitt">
<organization />
</author>
<date month="April" year="2006" />
<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" />
<format octets="105009" target="http://www.rfc-editor.org/rfc/rfc4408.txt" type="TXT" />
</reference>
<reference anchor="RFC6376">
<front>
<title>DomainKeys Identified Mail (DKIM) Signatures</title>
<author fullname="D. Crocker" initials="D." surname="Crocker">
<organization />
</author>
<author fullname="T. Hansen" initials="T." surname="Hansen">
<organization />
</author>
<author fullname="M. Kucherawy" initials="M." surname="Kucherawy">
<organization />
</author>
<date month="September" year="2011" />
<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" />
<format octets="176999" target="http://www.rfc-editor.org/rfc/rfc6376.txt" type="TXT" />
</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 09:27:02 |