Using DMARC
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale
CA
94086
USA
+1.408.246.8253
dcrocker@bbiw.net
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.
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
[DMARC.ORG] built an additional authentication-based layer, called
Domain-based Message Authentication, Reporting & Conformance. allows a sender to indicate that their
emails are protected by SPF and/or DKIM, and tells a receiver what
to do if neither of those authentication methods passes; it also
provides a reporting mechanism, from receivers back to domain
owners. Such capabilities over the public Internet are unusual and
their use is not yet well-understood. This document formulates a set
of best practices for the use of DMARC.
Discussion is divided along basic lines of activity:
Development
DNS Configuration
Receiver Processing
Report Generation
This initial version of the document is primarily meant to
seed discussion, rather than offer complete consideration of the
topic... Besides obviously soliciting more content and discussion, a
review of the document's organization is strongly requested.
An IETF mailing list for discussing DMARC issues has been requested:
dmarc@ietf.org.
{This section is meant for any software development practices,
relevant to the use of DMARC. -ed}
Malformed DMARC policy TXT records in DNS.
Can these be used for anything?
Should a policy that does not conform to the spec be
ignored?
Is there any benefit in attempting to infer meaning
(monitor = none, non = ??, rejec = ??)
How lenient can one safely be as regards spacing,
quotes, separators and slashes?
Is there anyway I can report the malformation to the
domain owner?
Rapid adoption of DMARC by apparent spammers
Thousands upon thousands of DMARC records published by
abusive domains -- probably wildcarding, but it works
out the same
Using data that is several weeks old, we have a handful
of domains that are accepting aggregate reports for over
20 thousand subdomains each
Are the reports (either aggregate or forensic) providing
the spammers insight that they did not already have?
***POTENTIALLY PROBLEMATIC QUESTION TO FOLLOW*** Should
I only send reports to domains that I trust?
Minimum requirements for aggregate report XML documents
What is the bare minimum (in terms of data gleaned from
a given email) I need to produce a valid report?
What sections of the XML need to be repeated when there
is a new aggregation point (email from a different IP,
for example)
Essentially this could be considered "XML for people who
thought they could figure out how to read an XSD but
reality crashed that party."
Minimum requirements for forensic reports (soft-fail reports)
What is the bare minimum required to produce a forensic
report.
This section is meant as a catch-all, for items that haven't yet
been assigned to their appropriate section.
Performing remote destination checking
What happens if I don't?
Identifier alignment
{This has been cited, but not yet explained, as a
potential BCP issue. -ed}
Owner vs. Operator
{It is possible that there are distinctive practices for
domain name owners, versus agents that operate DNS or
email services on behalf of the name owner. -ed}
DNS Abuse
Most probably don't see this, but adding potentially
multiple new DNS lookups per email multiplies
rapidly
DNS Cache can only help for so long
Agg reports are (probably) created from some other
host
If Org Domain policy lookups are required, you may get
two lookups every time there is a single lookup
Domain-based Message Authentication, Reporting
and Conformance (DMARC)
Cloudmark
Sender Policy Framework (SPF) for Authorizing Use of
Domains in E-Mail, Version 1
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.
DomainKeys Identified Mail (DKIM) Signatures
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]
DMARC and this draft are the result of lengthy efforts by an
informal industry consortium: dmarc.org.