DMARC [RFC 7489
] 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 subdomains within a single organization.
To determine the Organizational Domain for a message under evaluation, and thus where to look for a policy statement, DMARC makes use of a public suffix list. The process for doing this can be found in Section 3.2
of RFC 7489
. Currently, the most common public suffix list being used is the one maintained by the Mozilla Foundation and made public at <https://publicsuffix.org
In the basic DMARC model, Public Suffix Domains (PSDs) are not Organizational Domains and are thus not subject to DMARC processing. In DMARC, domains fall into one of three categories: Organizational Domains, subdomains of Organizational Domains, or PSDs. A PSD can only publish DMARC policy for itself and not for any subdomains under it. In some cases, this limitation allows for the abuse of non-existent organizational-level domains and hampers identification of domain abuse in email.
This document specifies experimental updates to the DMARC specification [RFC 7489
] in an attempt to mitigate this abuse.
As an example, imagine a Top-Level Domain (TLD), ".example", that has public subdomains for government and commercial use (".gov.example" and ".com.example"). The maintainer of a list of such a PSD structure would include entries for both of these subdomains, thereby indicating that they are PSDs, below which Organizational Domains can be registered. Suppose further that there exists a legitimate domain called "tax.gov.example", registered within ".gov.example".
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". Such domains are not registered.
Within the ".gov.example" public suffix, use of DMARC has been mandated, so "gov.example" publishes the following DMARC DNS record:
_dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject;"
This DMARC record provides policy and a reporting destination for mail sent from @gov.example. Similarly, "tax.gov.example" will have a DMARC record that specifies policy for mail sent from addresses @tax.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 @t4x.gov.example does not and cannot fall under a DMARC policy.
Defensively registering all variants of "tax" is not a scalable strategy. The intent of this specification, therefore, is to enhance the DMARC discovery method 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 specification.
This document provides a simple extension to [RFC 7489
] 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
Extend the DMARC policy query functionality to detect and process such a policy
Describe receiver feedback for such policies
Provide 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 subdomains. 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 [RFC 7489
], 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 has 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 [RFC 7489]. They control all subdomains of thetree. These are effectively private domains but listed in the current publicsuffix list. They are treated as public for DMARC purposes. They require thesame protections as DMARC Organizational Domains but are currently unable tobenefit from DMARC.
Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
Because existing Organizational Domains using this PSD have their ownDMARC policy, the applicability of this extension is for non-existentdomains. The extension allows the brand protection benefits of DMARC to extendto the entire PSD, including cousin domains of registered organizations.
Due to the design of DMARC and the nature of the Internet [RFC 5598
], there are interoperability issues associated with DMARC deployment. These are discussed in "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows" [RFC 7960
]. These issues are not typically applicable to PSDs since they (e.g., the ".gov.example" used above) do not typically send mail.