About
PSD DMARC
The design of DMARC precludes grouping policies for a set of domains above the organizational level, such as TLDs (Top Level Domains). These types of domains (which are not all at the top level of the DNS tree) can be collectively referred to as Public Suffix Domains (PSDs). For the subset of PSDs that require DMARC usage, PSD DAMRC provides an extension to DMARC to enable DMARC functionality for such domains.
Not all PSDs are suitable for PSD DMARC. Details are described in the RFC linked below. In order for receivers to know if the query for a PSD DMARC record should be made as an extension to the RFC 7489 policy discover mechanis, some kind of list or service (TBD) is needed in order to prevent inappropriate usage of PSD DMARC.
DMARC
This web site is about DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains) AKA PSD DMARC, a DMARC extension. DMARC (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. DMARC policies can be applied at the individual domain level or for a set of domains at the organizational level.
Initial registry, query, and PSL extention services
RFC 9091, Appendix B.2 specifies psddmarc.org as the authoritativ location for the DMARC PSD Registry.
There is both an online registry provided largely in the style of an IANA parameter registry (completely unaffiliated with IANA and an online DNS based query service.
Additionally, there is a Public Suffix List (PSL) format extension provided by Alessandro Vesely.
THIS SERVICE IS PROVIDED BY THE CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Service Details
The online registry provides a csv file that is suitable (for testing only) to be downloaded and parsed ocassionally. The registry is not expected to change with any frequency.
The DNS query service is meant to provide ~real time responses on the PSD DMARC status of a particular public suffix.
The PSL extension uses the same format as the PSL. It is meant to be periodically updated using the same mechanisms as are used for PSL updates.
The date of the last change to the data in any of these services can be found here. It is a text file containing only the last modification date in the format YYYY-MM-DD.
DMARC Updates
The IETF DMARC Working Group produced RFC 9091, which defines the initial design for PSD DMARC and is working on an overal revision of DMARC which both incorporates PSD DMARC and updates DMARC to address opertional and design issues identified since DMARC was first fielded. The draft-ietf-dmarc-dmarcbis design currently includes a new policy discovery mechanism that supports the goals of PSD DMARC without requiring a registry, query, or extension service. It is, however, still being developed and potentially subject to change.
The only change needed for PSDs to be compatible with this update is to add "psd=y" to their DMARC record. By specification, DMARC ignores unknown tags, so there is no backward compatibility risk associated with adding this tag. psddmarc.org recommends adding it now. See the .gov (_dmarc.org) record for an example.