DMARC (Domain-based Message Authentication,
Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)
fTLD Registry Services600 13th Street, NW, Suite 400WashingtonDC20005United States of America+1 301 325-5475scott@kitterman.comDMARCemail authenticationTLDDMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-originating
organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving
organization can use to improve mail handling. The design of DMARC
presumes that domain names represent either nodes in the tree below
which registrations occur, or nodes where registrations have occurred;
it does not permit a domain name to have both of these properties
simultaneously. Since its deployment in 2015, use of DMARC has shown
a clear need for the ability to express policy for these domains as
well.Domains at which registrations can occur are referred to as Public
Suffix Domains (PSDs). This document describes an extension to DMARC
to enable DMARC functionality for PSDs.This document also seeks to address implementations that consider a
domain on a public Suffix list to be ineligible for DMARC
enforcement.DMARC provides a mechanism for
publishing organizational policy information to email receivers.
DMARC allows policy to be specified for both individual domains and
for organizational domains and their sub-domains within a single
organization. DMARC leverages public suffix lists to determine which
domains are organizational domains. It presumes that public suffix
list listed domains are not organizational domains and not subject to
DMARC processing; domains are either organizational domains,
sub-domains of organizational domains, or listed on a public suffix
list. For domains listed in a public suffix list, i.e. TLDs and
domains that exist between TLDs and organization level domains,
policy can only be published for the exact domain. No method is
available for these domains to express policy or receive feedback
reporting for sub-domains. This missing method allows for the abuse
of non-existent organizational-level domains and prevents
identification of domain abuse in email.
As an example, imagine a country code TLD (ccTLD) which has public
subdomains for government and commercial use (.gov.example and
.com.example). Suppose there exists a registered domain
"tax.gov.example" that is responsible for taxation in this imagined
country. However, by exploiting the typically unauthenticated nature of
email, there are regular malicious campaigns to impersonate this
organization that use similar-looking ("cousin") domains such as
"t4x.gov.example". These domains are not registered. Within the
".gov.example" public suffix, use of DMARC has been mandated, so
"gov.example" publishes the following DMARC record:
at
This DMARC record provides policy and a reporting destination for
mail sent from @gov.example. However, due to DMARC's current method
of discovering and applying policy at the organizational domain
level, the non-existent organizational domain of @tax.gov.example
does not and cannot fall under a DMARC policy.
Defensively registering all variants of "tax" is obviously not a scalable
strategy. The intent of this specification, therefore, is to enhance the
DMARC algorithm by enabling an agent receiving such a message to be able to
determine that a relevant policy is present at "gov.example", which is
precluded by the current DMARC algorithm.
This document provides a simple extension to DMARC
to allow operators of Public Suffix Domains (PSDs) to express
policy at the level of the PSD that covers all organizational domains
that do not explicitly publish DMARC records, extends the DMARC
policy query functionality to detect
and process such a policy, describes receiver feedback for such
policies, and provides controls to mitigate potential privacy
considerations associated with this extension.
This document also provides a new DMARC tag
to indicate requested handling policy for non-existent subdommains.
This is provided specifically to support phased deployment of PSD
DMARC, but is expected to be useful more generally. Undesired
rejection risks for mail purporting to be from domains that do not
exist are substantially lower than for those that do, so the
operational risk of requesting harsh policy treatment (e.g. reject) is
lower.
As an additional benefit, the PSD DMARC extension clarifies
existing requirements. Based on the requirements of DMARC, DMARC should function above the
organizational level for exact domain matches (i.e. if a DMARC record
were published for 'example', then mail from example@example should be
subject to DMARC processing). Testing had revealed that this is not
consistently applied in different implementations.
There are two types of Public Suffix Operators (PSOs) for which this
extension would be useful and appropriate:
Branded PSDs (e.g., ".google"): These domains are
effectively Organizational Domains as discussed in DMARC. They control all
subdomains of the tree. These are effectively private
domains, but listed in the Public Suffix List. They are
treated as Public for DMARC
purposes. They require the same protections as DMARC
Organizational Domains, but are currently unable to
benefit from DMARC.
Multi-organization PSDs that require DMARC usage (e.g.,
".bank"): Because existing Organizational Domains using
this PSD have their own DMARC policy, the applicability of
this extension is for non-existent domains. The extension
allows the brand protection benefits of DMARC to extend to
the entire PSD,
including cousin domains of registered organizations.
Due to the design of DMARC and the nature
of the Internet email architecture, there
are interoperability issues associated with
DMARC deployment. These are discussed in
Interoperability Issues between DMARC and Indirect Email Flows.
These issues are not typically applicable to PSDs, since they (e.g., the
".gov.example" used above) do not typically send mail.
This section defines terms used in the rest of the document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they appear in all
capitals, as shown here.
The global Internet Domain Name System (DNS) is documented in
numerous Requests for Comment (RFC). It defines a tree of names
starting with root, ".", immediately below which are Top Level
Domain names such as ".com" and ".us". They are not available
for private registration. In many cases the public portion of
the DNS tree is more than one level deep.
The domain name structure consists of a tree of names, each of
which is made of a sequence of words ("labels") separated by
period characters. The root of the tree is simply called ".".
The Internet community at large, through processes and policies
external to this work, selects points in this tree at which to
register domain names "owned" by independent organizations.
Real-world examples are ".com", ".org", ".us", and ".gov.uk".
Names at which such registrations occur are called Public
Suffix Domains (PSDs), and a registration consists of a label
selected by the registrant to which a desirable PSD is
appended. For example, "ietf.org" is a registered domain name,
and ".org" is its PSD.
The longest PSD is the Organizational Domain with one label
removed.A Public Suffix Operator manages operations within its PSD.
PSO Controlled Domain Names are names in the DNS that are
managed by a PSO and are not available for use as Organizational
Domains (the term Organizational Domains is defined in DMARC Section 3.2). Depending on PSD policy, these
will have one (e.g., ".com") or more (e.g., ".co.uk") name
components.
For DMARC purposes, a non-existent
domain is a domain for which there is an NXDOMAIN or NODATA
response for A, AAAA, and MX records. This is a broader definition
than that in NXDOMAIN.
This document updates DMARC as follows:References to "Domain Owners" also apply to PSOs.A new tag is added after "fo": Requested Mail Receiver policy for non-existent
subdomains (plain-text; OPTIONAL). Indicates the policy to be
enacted by the Receiver at the request of the Domain Owner. It
applies only to non-existent subdomains of the domain queried and
not to either existing subdomains or the domain itself. Its
syntax is identical to that of the "p" tag defined below. If
the 'np' tag is absent, the policy specified by the "sp" tag (if
the 'sp' tag is present) or the policy specified by the "p" tag,
if the 'sp' tag is not present, MUST be applied for non-existent
subdomains. Note that "np" will be ignored for DMARC records
published on subdomains of Organizational Domains and PSDs due to
the effect of the DMARC policy discovery mechanism described in
DMARC Section 6.6.3.
The following tag definitions from DMARC
are updated:
The sentence 'Policy applies to the domain queried
and to subdomains, unless subdomain policy is explicitly described
using the "sp" tag' is updated to read 'Policy applies to the domain
queried and to subdomains, unless subdomain policy is explicitly
described using the "sp" or "np" tags.'
The sentence 'If absent, the policy specified by
the "p" tag MUST be applied for subdomains' is updated to read
'If both the 'sp' tag is absent and the 'np' tag is either absent
or not applicable, the policy specified by the "p" tag MUST be
applied for subdomains.
In addition to the DMARC domain owner actions, PSOs that require
use of DMARC and participate in PSD DMARC ought to make that
information available to receivers. The mechanism for doing so is
one of the experimental elements of this document. See the experiment description.
Experience with DMARC has shown that some implementations
short-circuit messages, bypassing DMARC policy application, when
the domain name extracted by the receiver (from the RFC5322.From)
is on the public suffix list used by the receiver. This
negates the capability being created by this specification.
Therefore, the following paragraph is appended to Section 6.6.1
of DMARC:
Note that domain names that appear on a public suffix list are
not exempt from DMARC policy application and reporting.
A new step between step 3 and 4 is added:If the set is now empty and the longest PSD of the Organizational
Domain is one that the receiver has determined is acceptable
for PSD DMARC (discussed in the experiment description), the Mail
Receiver MUST query the DNS for a DMARC TXT record at the DNS
domain matching the longest PSD in
place of the RFC5322.From domain in the message (if
different). A possibly empty set of records is returned.
As an example, for a message with the Organizational Domain of
"example.compute.cloudcompany.com.example", the query for PSD DMARC
would use "compute.cloudcompany.com.example" as the longest PSD. The receiver would check to see
if that PSD is listed in the DMARC PSD Registry, and if so, perform
the policy lookup at "_dmarc.compute.cloudcompany.com.example".
Note: Because the PSD policy query comes after the Organizational
Domain policy query, PSD policy is not used for Organizational
domains that have published a DMARC policy. Specifically, this
is not a mechanism to provide feedback addresses (RUA/RUF) when
an Organizational Domain has declined to do so.
Operational note for PSD DMARC: For PSOs, feedback for non-existent
domains is desirable and useful, just as it is for org-level
DMARC operators. See of this document for
discussion of Privacy Considerations.
These privacy considerations are developed based on the requirements of
. The Privacy Considerations of apply to this document.
Providing feedback reporting to PSOs can, in some cases, create
leakage of information outside of an organization to the PSO.
This leakage could potentially be utilized as part of a program
of pervasive surveillance (See ). There
are roughly three cases to consider:
Single Organization PSDs (e.g., ".google"), RUA and RUF
reports based on PSD DMARC have the potential to contain
information about emails related to entities managed by
the organization. Since both the PSO and the
Organizational Domain owners are common, there is no
additional privacy risk for either normal or non-existent
Domain reporting due to PSD DMARC.
Multi-organization PSDs that require DMARC usage (e.g.,
".bank"): PSD DMARC based reports will only be generated
for domains that do not publish a DMARC policy at the
organizational or host level. For domains that do publish
the required DMARC policy records, the feedback reporting
addresses (RUA and RUF) of the organization (or hosts)
will be used. The only direct feedback leakage risk for
these PSDs are for Organizational Domains that are out of
compliance with PSD policy. Data on non-existent cousin
domains would be sent to the PSO.
Multi-organization PSDs (e.g., ".com") that do not mandate
DMARC usage: Privacy risks for Organizational Domains
that have not deployed DMARC within such PSDs are
significant. For non-DMARC Organizational Domains, all
DMARC feedback will be directed to the PSO. PSD DMARC is
opt-out (by publishing a DMARC record at the
Organizational Domain level) vice opt-in, which would be
the more desirable characteristic. This means that any
non-DMARC organizational domain would have its feedback
reports redirected to the PSO. The content of such
reports, particularly for existing domains, is privacy
sensitive.
PSOs will receive feedback on non-existent domains, which may be
similar to existing Organizational Domains. Feedback related to
such cousin domains have a small risk of carrying information
related to an actual Organizational Domain. To minimize this
potential concern, PSD DMARC feedback is best limited to
Aggregate Reports. Feedback Reports carry more detailed
information and present a greater risk.
Due to the inherent Privacy and Security risks associated with
PSD DMARC for Organizational Domains in multi-organization PSDs
that do not particpate in DMARC, any Feedback Reporting related to
multi-organizational PSDs ought to be limited to non-existent
domains except in cases where the reporter knows that PSO
requires use of DMARC.
This document does not change the Security Considerations of
and .
The risks of the issues identified in ,
Section 12.3, DNS Security, are amplified by PSD DMARC. In
particular, DNS cache poisoning (or Name Chaining), see for details, consequences are increased because a
sucessful attack would potentially have a much wider scope.
The risks of the issues identified in ,
Section 12.5, External Reporting Addresses, are amplified by PSD
DMARC. By design, PSD DMARC causes unrequested reporting of feedback
to entities external to the Organizational Domain. This is discussed
in more detail in .
This section describes actions requested to be completed by IANA.IANA is requested to add a new tag to DMARC Tag Registry in the Domain-based Message Authentication,
Reporting, and Conformance (DMARC) Parameters Registry.
The entry is as follows:
Public Suffix ListmultiplePSD DMARC Web Sitemultiple There are two experimental questions addressed in this document: one
regarding mitigation of PSD related privacy concerns and the other
on the utility of specifying separate DMARC policies for non-existent
sub-domains. Aditionally, as of the writing of this document operational and
policy constraints prevent this experiment from being deployed
globally. If the experiment shows that PSD DMARC solves a real
problem and can be used at a large scale, the results could prove
to be useful in removing constraints outside of the IETF that would
permit broader deployment.
To mitigate the privacy concerns associated with Multi-organization
PSDs that do not mandate DMARC usage, see ,
a mechanism to indicate which PSDs do not present this privacy risk is
appropriate. There are multiple approaches that are possible.
The experiment is to evaluate different possible approaches. The
experiment will be complete when there is rough consensus on a
technical approach that is demonstrated to be operationally usable and
effective at mitigating the privacy concern.
The mechanism needs the following attributes: Be reliably, publicly accessible Be under configuration control based on a public set of
criteria
List PSDs that either mandate DMARC for their registrants
or for which all lower level domains are controlled by the
PSO and that the relevant PSO has indicated a desire for
the PSD to participate in PSD DMARC
Have a small operational footprint (e.g. provide a
documented, lightweight mechanism for developers and
operators to retrieve the list of PSD DMARC participants)
Not allow PSO to add PSDs to the PSD DMARC participants
list without third party review
As of this writing, three approaches have been proposed. None of them
are ideal:
An extension to the Public Suffix List at A dedicated registry queried via DNS - an example of such
a service is described in below
An IANA registry PSOs that plan to implement PSD DMARC have indicated that the
ability to describe distinct policies for existing and non-
existing sub-domains would facilitate PSD DMARC deployment. There
are also suggestions that it would be more generally useful for
DMARC.
During the period of the experiment, uptake of the new 'np' tag
will be evaluated to support assessment of the utility of
including 'np' in a future, non-experimental update.
To facilitate experimentation around data leakage mitigation, samples
of the DNS based and IANA like registries are available at
.
A sample stand-alone DNS query service is available at . It was developed based on the contents
suggested for an IANA registry in an earlier revision of this draft.
Usage of the service is described on the web site.
provides an IANA like DMARC Public
Suffix Domain (PSD) Registry as a stand-alone DNS query service. It
follows the contents and structure described below. There is a Comma
Separated Value (CSV) version of the listed PSD domains which is
suitable for use in build updates for PSD DMARC capable software.
Names of PSDs participating in PSD DMARC must be registered this
new registry. New entries are assigned only for PSDs that
require use of DMARC. The requirement has to be documented in a
manner that satisfies the terms of Expert Review,per . The Designated Expert needs to confirm that
provided documentation adequately describes PSD policy to require
domain owners to use DMARC or that all domain owners are part of
a single organization with the PSO.
The initial set of entries in this registry is as follows:
provides a PSL like file to enable to
facilitate identification of PSD DMARC participants. Contents are
functionally identical to the IANA like registry, but presented in
a different format.
When using this approach, the input domain of the extension lookup
is supposed to be the output domain of the regular PSL lookup, i.e.
the organizational domain. This alternative data approach is
potentially useful since DMARC implementations already need to be
able to parse the data format, so it should be easier to implement.
There are two known implementations of PSD DMARC available for testing.
The authheaders Python module and command line tool is available
for download or installation from Pypi (Python Packaging Index).
It supports both use of the DNS based query service and download
of the CSV registry file from .
The zdkimfilter module is a separately available add-on to
Courier-MTA.
Mostly used for DKIM signing, it can be configured to also verify,
apply DMARC policies, and send aggregate reports. For PSD DMARC
it uses the PSL extension list approach, which is available from
from Thanks to the following individuals for their contributions (both
public and private) to improving this document. Special shout out to
Dave Crocker for naming the beast. Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen,
Zeke Hendrickson, Andrew Kennedy, John Levine, Dr Ian Levy, Craig
Schwartz, Alessandro Vesely, and Tim Wicinski