RFC 9091

Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains

📅 published July 2021, from ietf

RFC 9091: Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains 🎀

Okay bestie, let's start with the vibe check ✨ This is RFC 9091, published in July 2021 by the IETF. It's an Experimental doc (category: Experimental, ISSN 2070-1721). The authors are S. Kitterman from fTLD Registry Services and T. Wicinski as editor. The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Abstract

Okay so, DMARC (defined in RFC 7489) lets a domain-controlling organization publish domain-level policies and preferences for message validation, disposition, and reporting. Mail-receiving organizations can use those to improve how they handle mail 📬

DMARC splits a name into the part that's a Public Suffix Domain (PSD), with Organizational Domain names created beneath it. The basic DMARC setup lets Organizational Domains set policies for their subdomains, but it doesn't give PSDs that power 🥲 This document adds an extension to DMARC so PSDs can fully use DMARC too. It's giving full DMARC glow-up 🦋

Some DMARC implementations think a PSD is ineligible for DMARC enforcement. This spec is here to fix that exact problem 💖

Status of This Memo

This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧪

It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 for the details 🤓

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9091 🌸

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, since they explain your rights and restrictions for this document 📜 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
  1.1.  Example
  1.2.  Discussion
2.  Terminology and Definitions
  2.1.  Conventions Used in This Document
  2.2.  Public Suffix Domain (PSD)
  2.3.  Organizational Domain
  2.4.  Longest PSD
  2.5.  Public Suffix Operator (PSO)
  2.6.  PSO-Controlled Domain Names
  2.7.  Non-existent Domains
3.  PSD DMARC Updates to DMARC Requirements
  3.1.  General Updates
  3.2.  Changes in Section 6.3 ("General Record Format")
  3.3.  Changes in Section 6.4 ("Formal Definition")
  3.4.  Changes in Section 6.5 ("Domain Owner Actions")
  3.5.  Changes in Section 6.6.1 ("Extract Author Domain")
  3.6.  Changes in Section 6.6.3 ("Policy Discovery")
  3.7.  Changes in Section 7 ("DMARC Feedback")
4.  Privacy Considerations
5.  Security Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Appendix A.  PSD DMARC Privacy Concern Mitigation Experiment
Appendix B.  DMARC PSD Registry Examples
  B.1.  DMARC PSD DNS Query Service
  B.2.  DMARC PSD Registry
  B.3.  DMARC PSD PSL Extension
Appendix C.  Implementations
  C.1.  Authheaders Module
  C.2.  Zdkimfilter Module
Acknowledgements
Authors' Addresses

1. Introduction ✨

Okay, so DMARC [RFC7489] gives email receivers a way to find organizational policy info. It lets you set policy for individual domains and for Organizational Domains and their subdomains, all within one organization 🏢

To figure out the Organizational Domain for a message being checked (and therefore where to look for the policy), DMARC uses a public suffix list. You can read about how that works in Section 3.2 of the DMARC specification [RFC7489]. Right now, the most common public suffix list is the one maintained by the Mozilla Foundation, published at https://publicsuffix.org 🌈

In the basic DMARC model, PSDs aren't Organizational Domains, so they don't go through DMARC processing at all. DMARC has three categories of domains: Organizational Domains, subdomains of Organizational Domains, and PSDs. A PSD can only publish a DMARC policy for itself, not for any subdomains under it. This limit can open the door to abuse with non-existent organizational-level domains, and it makes it harder to spot domain abuse in email 👀

This document is an experimental update to the DMARC specification [RFC7489] to help stop that abuse 🛡️

1.1. Example

Picture this 🎬 There's a Top-Level Domain (TLD), ".example", with public subdomains for government and commercial use (".gov.example" and ".com.example"). Whoever maintains a list of that PSD structure would add entries for both subdomains, which marks them as PSDs where Organizational Domains can be registered. Now say there's a legit domain called "tax.gov.example", registered under ".gov.example".

Because email is typically unauthenticated, bad actors regularly run campaigns pretending to be this organization using lookalike ("cousin") domains such as "t4x.gov.example". Those domains aren't registered 😬

Inside the ".gov.example" public suffix, DMARC use is mandatory, so "gov.example" publishes this DMARC DNS record:

_dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject;"
                             "rua=mailto:dmc@dmarc.svc.gov.example" )

That record gives policy and a reporting destination for mail sent from @gov.example. "tax.gov.example" can do the same and publish its own record for mail from @tax.gov.example. But because DMARC currently finds and applies policy at the Organizational Domain level, the non-existent Organizational Domain @t4x.gov.example doesn't and can't fall under a DMARC policy. Main character problem 💀

Registering every variant of "tax" defensively is not a scalable plan. So this spec's goal is to improve DMARC's discovery method. That way, a receiving agent can tell there's a relevant policy at "gov.example", which the current DMARC spec doesn't allow for 🙌

1.2. Discussion

This document is a simple extension to [RFC7489] that lets Public Suffix Domain (PSD) operators do three things, plus one bonus:

  • Express policy at the PSD level, covering all Organizational Domains that don't explicitly publish DMARC records
  • Extend the DMARC policy query functionality to detect and process that policy
  • Describe receiver feedback for those policies
  • Provide controls to reduce potential privacy considerations tied to this extension

It also adds a new DMARC tag for requesting a handling policy for non-existent subdomains. It's specifically there to support a phased rollout of PSD DMARC, but it's expected to be useful more broadly too. Undesired rejection risks for mail claiming to be from domains that don't exist are a lot lower than for domains that do exist, so the operational risk of asking for harsh treatment (e.g., reject) is lower too 🫶

The PSD DMARC extension also clears up some existing requirements. Based on [RFC7489], DMARC should work above the organizational level for exact domain matches. For example, if a DMARC record were published for "example", then mail from example@example should go through DMARC processing. Testing showed this isn't applied consistently across implementations 🧐

There are two types of Public Suffix Operators (PSOs) this extension would be useful and appropriate for:

Branded PSDs (e.g., ".google"): : These domains are effectively Organizational Domains, as discussed in [RFC7489]. They control every subdomain in their tree. They're effectively private domains that are listed in the current public suffix list, and they're treated as public for DMARC purposes. They need the same protections as DMARC Organizational Domains, but right now they can't benefit from DMARC 🌟

Multi-organization PSDs that require DMARC usage (e.g., ".bank"): : Since existing Organizational Domains under this PSD already have their own DMARC policy, this extension applies to non-existent domains. It lets the brand protection benefits of DMARC reach the whole PSD, including cousin domains of registered organizations 💜

Because of how DMARC is designed and the nature of the Internet email architecture [RFC5598], there are interoperability issues with DMARC deployment. These are covered in "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows" [RFC7960]. Those issues don't usually apply to PSDs, since they (e.g., the ".gov.example" used above) typically don't send mail 📭

2. Terminology and Definitions 📚

This section defines the terms used through the rest of the document. Let's get our vocab straight, bestie 🫶

2.1. Conventions Used in This Document

Here are the key words that carry special meaning. They're interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, like this: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" ✨ If they show up in lowercase, they're just regular words, no cap 💅

2.2. Public Suffix Domain (PSD)

The global Internet Domain Name System (DNS) is documented in tons of RFCs 🤯 It defines a tree of names starting at the root, ".", and directly below that are Top-Level Domain names like ".com" and ".us". Every name in the tree is a sequence of words ("labels") separated by period characters, and the root of the tree is simply called ".". The wider Internet community, through processes and policies that sit outside this work, picks the points in this tree where independent organizations can register domain names they "own". Real-world examples are ".com", ".org", ".us", and ".gov.uk". Those registration points are called "Public Suffix Domains (PSDs)". A registration is a label chosen by the registrant, with a desired PSD added to the end. For example, "ietf.org" is a registered domain name, and ".org" is its PSD 🌸

2.3. Organizational Domain

The term "Organizational Domain" is defined in Section 3.2 of [RFC7489] 📖

2.4. Longest PSD

The longest PSD is the Organizational Domain with one label removed. It names the immediate parent node of the Organizational Domain in the DNS namespace tree 🌳

2.5. Public Suffix Operator (PSO) 🦋

okay so a Public Suffix Operator (PSO) is the org that runs a PSD 🧚. Like, they're the ones keeping things tidy and managing what's out there, especially the DNS records published for names at and under that domain. 💅

2.6. PSO-Controlled Domain Names 🌸

these are the DNS names a PSO manages that can't be used as Organizational Domains, bestie 🙅‍♀️. They can be one label long (like .com) or more (like .co.uk), depending on the PSD's policy. ✨

2.7. Non-existent Domains 🙈

for DMARC, a non-existent domain is one that comes back with an NXDOMAIN or NODATA response for A, AAAA, and MX records. ngl this is a broader definition than the one in [RFC8020], so be careful not to mix them up 💀.

3. PSD DMARC Updates to DMARC Requirements 🎀

to join this experiment, implementations should interpret [RFC7489] the way the following subsections describe 🧁.

3.1. General Updates 💜

anywhere DMARC talks about "Domain Owners," that also includes PSOs now. main character energy 👑.

3.2. Changes in Section 6.3 ("General Record Format") 🍓

we're adding a paragraph to this section, plus a brand-new tag that goes right after "fo" ✨:

np: the Requested Mail Receiver policy for non-existent subdomains (plain-text; OPTIONAL). It tells the Receiver which policy to enforce because the Domain Owner asked for it. It only covers non-existent subdomains of the domain being queried, not existing subdomains and not the domain itself. Its syntax matches the "p" tag defined below. If the "np" tag isn't there, then non-existent subdomains MUST get the policy from the "sp" tag (if "sp" is present) or from the "p" tag (if "sp" is absent). Heads up 👀: "np" gets ignored for DMARC records published on subdomains of Organizational Domains and PSDs, because of the DMARC policy discovery mechanism in Section 6.6.3 of [RFC7489].

these existing DMARC tags get updated too 🔥:

  • p: the phrase 'Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag' now reads 'Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" or "np" tags.'
  • sp: the phrase 'If absent, the policy specified by the "p" tag MUST be applied for subdomains' now reads '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.'

3.3. Changes in Section 6.4 ("Formal Definition") 🧠

the ABNF [RFC5234] for DMARC gets a new definition, "dmarc-nprequest" 🦋:

            dmarc-nprequest =  "np" *WSP "=" *WSP
                ( "none" / "quarantine" / "reject" )

and "dmarc-record" gets updated too, so it now looks like this 💅:

dmarc-record    = dmarc-version dmarc-sep
              [dmarc-request]
              [dmarc-sep dmarc-srequest]
              [dmarc-sep dmarc-auri]
              [dmarc-sep dmarc-furi]
              [dmarc-sep dmarc-adkim]
              [dmarc-sep dmarc-aspf]
              [dmarc-sep dmarc-ainterval]
              [dmarc-sep dmarc-fo]
              [dmarc-sep dmarc-rfmt]
              [dmarc-sep dmarc-percent]
              [dmarc-sep]
              [dmarc-sep dmarc-nprequest]
              ; components other than dmarc-version and
              ; dmarc-request may appear in any order

3.4. Changes in Section 6.5 ("Domain Owner Actions") 🌈

okay so on top of the usual DMARC Domain Owner actions, PSOs that need DMARC and take part in PSD DMARC ought to make that info available to receivers 🫶. This doc's experimental way of doing that is in Appendix B, so go check it out ✨.

3.5. Changes in Section 6.6.1 ("Extract Author Domain") 💀

so here's the tea 🍵: some implementations short-circuit messages and skip DMARC policy application when the domain pulled from the RFC5322.From domain is on the receiver's public suffix list. Which totally undercuts what this spec is trying to do 😭. So we're adding this paragraph to the end of Section 6.6.1 of [RFC7489]:

Note that domain names that appear on a public suffix list are not exempt from DMARC policy application and reporting.

3.6. Changes in Section 6.6.3 ("Policy Discovery") 🔍

we're adding a brand-new step between steps 3 and 4 🧚:

3A. If the set is now empty and the longest PSD ([RFC9091], Section 2.4) of the Organizational Domain is one that the receiver has decided is acceptable for PSD DMARC (based on the data in one of the DMARC PSD Registry Examples described in Appendix B of [RFC9091]), 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.

for example 🦋: if a message has the Organizational Domain example.compute.cloudcompany.com.example, the PSD DMARC query would use compute.cloudcompany.com.example as the longest PSD. The receiver checks whether that PSD is in the DMARC PSD Registry, and if it is, it does the policy lookup at _dmarc.compute.cloudcompany.com.example 💖.

Note: Since the PSD policy query happens after the Organizational Domain policy query, PSD policy doesn't get used for Organizational Domains that already published a DMARC policy. To be clear, this is NOT a way to provide feedback addresses (RUA/RUF) when an Organizational Domain has said no thanks 🙅‍♀️.

3.7. Changes in Section 7 ("DMARC Feedback") 🎀

we're adding a paragraph to this section too. It basically says that PSOs want feedback for non-existent domains, just like org-level DMARC operators do, and that Section 4 of [RFC9091] has the privacy discussion for PSD DMARC 🫶.

4. Privacy Considerations 🔒

these privacy considerations are based on the requirements in [RFC6973]. The privacy considerations in [RFC7489] also apply to the mechanisms in this document 💜. To join this experiment, implementations should be aware of the privacy considerations in this section. If the experiment works out, this section should be folded into the "Privacy Considerations" section as "Feedback Leakage" ✨.

okay real talk 🥺: sending feedback reports to PSOs can sometimes leak info from an organization to the PSO. That leak could be used as part of pervasive surveillance (see [RFC7624]). There are roughly three cases to think about:

Single Organization PSDs (e.g., ".google")

RUA and RUF reports based on PSD DMARC might include info about emails tied to entities the organization manages. Since both the PSO and the Organizational Domain Owners are the same group, there's no extra privacy risk for normal or non-existent domain reporting from PSD DMARC 🙌.

Multi-organization PSDs that require DMARC usage (e.g., ".bank")

reports based on PSD DMARC only get generated for domains that don't publish a DMARC policy at the organizational or host level. For domains that do publish the required DMARC policy records, the feedback addresses (RUA and RUF) of the organization (or hosts) get used. The only direct feedback-leakage risk for these PSDs is 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

the privacy risks for Organizational Domains that haven't deployed DMARC in these PSDs are significant 😭. For non-DMARC Organizational Domains, all DMARC feedback goes to the PSO. PSD DMARC is opt-out (you publish a DMARC record at the Organizational Domain level to get out of it) instead of opt-in, which would be way more desirable 💅. So any non-DMARC Organizational Domain would have its Feedback Reports redirected to the PSO. The content of those reports, especially for existing domains, is privacy sensitive 🙈.

PSOs will get feedback on non-existent domains, which may look a lot like existing Organizational Domains. Feedback about these cousin domains has a small risk of carrying info about an actual Organizational Domain. To keep that concern small, PSD DMARC feedback MUST be limited to Aggregate Reports 🛡️. Feedback Reports carry more detailed info and are riskier.

because of the privacy and security risks PSD DMARC creates for Organizational Domains in multi-organization PSDs that don't take part in DMARC, any feedback reporting for multi-organizational PSDs MUST be limited to non-existent domains, unless the reporter knows the PSO requires DMARC usage (by checking the DMARC PSD Registry) 🔥.

5. Security Considerations 🚨

this document doesn't change the security considerations of [RFC7489] and [RFC7960] 🫶.

okay but the risks from Section 12.3 of [RFC7489] ("DNS Security") get amplified by PSD DMARC, and that's a big deal 😱. Consequences of DNS cache poisoning (or name chaining) go up, because a successful attack could have a much wider scope (see [RFC3833] for details).

the risks from Section 12.5 of [RFC7489] ("External Reporting Addresses") also get amplified by PSD DMARC 💀. By design, PSD DMARC causes unrequested feedback reporting to entities outside the Organizational Domain. More on that in Section 4 🔍.

6. IANA Considerations 🌷

IANA added a new tag to the "DMARC Tag Registry" in the "Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters" registry ✨. The "Status" column is defined in Section 11.4 of [RFC7489].

here's the new entry 💖:

  +==========+===========+=========+=============================+
  | Tag Name | Reference | Status  | Description                 |
  +==========+===========+=========+=============================+
  | np       | RFC 9091  | current | Requested handling policy   |
  |          |           |         | for non-existent subdomains |
  +----------+-----------+---------+-----------------------------+

                              Table 1

7. References 📚

7.1. Normative References 📚✨

okay so these are the docs this one needs to read first, no skipping bestie 🫶

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234,
           DOI 10.17487/RFC5234, January 2008,
           <https://www.rfc-editor.org/info/rfc5234>.

[RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
           Message Authentication, Reporting, and Conformance
           (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
           <https://www.rfc-editor.org/info/rfc7489>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References 🦋

these ones are more like "ooh, go read this if you're curious" energy, not required reading 🌸

[PSD-DMARC]
           "Public Suffix Domain DMARC", <https://psddmarc.org/>.

[RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
           Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August
           2004, <https://www.rfc-editor.org/info/rfc3833>.

[RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
           DOI 10.17487/RFC5598, July 2009,
           <https://www.rfc-editor.org/info/rfc5598>.

[RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
           Morris, J., Hansen, M., and R. Smith, "Privacy
           Considerations for Internet Protocols", RFC 6973,
           DOI 10.17487/RFC6973, July 2013,
           <https://www.rfc-editor.org/info/rfc6973>.

[RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
           Trammell, B., Huitema, C., and D. Borkmann,
           "Confidentiality in the Face of Pervasive Surveillance: A
           Threat Model and Problem Statement", RFC 7624,
           DOI 10.17487/RFC7624, August 2015,
           <https://www.rfc-editor.org/info/rfc7624>.

[RFC7960]  Martin, F., Ed., Lear, E., Ed., Draegen, T., Ed., Zwicky,
           E., Ed., and K. Andersen, Ed., "Interoperability Issues
           between Domain-based Message Authentication, Reporting,
           and Conformance (DMARC) and Indirect Email Flows",
           RFC 7960, DOI 10.17487/RFC7960, September 2016,
           <https://www.rfc-editor.org/info/rfc7960>.

[RFC8020]  Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
           Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
           November 2016, <https://www.rfc-editor.org/info/rfc8020>.

[RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

Appendix A. PSD DMARC Privacy Concern Mitigation Experiment 🧪

okay this is the experiment part, and it's giving science fair with a privacy twist 🔬 there are three questions being looked at in this doc:

  • ✨ Section 3.2 changes policy discovery so it adds an extra DNS lookup. To see if that lookup is actually useful, PSDs are going to publish extra DMARC records and then analyze the DMARC reports. It's a success if a consensus of PSDs that publish DMARC records can collect useful data.
  • 💜 Section 3.2 adds the "np" tag for non-existent subdomains (DNS NXDOMAIN). PSOs who want to test this will add the flag to their DMARC record and analyze the DMARC reports for deployment. It's a win if organizations find explicitly blocking non-existent subdomains desirable and if doing so provides added value.
  • 🌈 Section 4 talks about three cases where giving feedback could let information leak out of an organization. This experiment will analyze the Feedback Reports generated for each case to see if there's any information leakage. no cap, this one's kinda important 😭

Appendix B. DMARC PSD Registry Examples 💅

so to help with experimenting on stopping data leaks, there are samples of the DNS-based and IANA-like registries over at [PSD-DMARC]. we're giving the vibe check on the good stuff 🍓

B.1. DMARC PSD DNS Query Service 🧚

there's a sample stand-alone DNS query service at [PSD-DMARC]. it was built off the contents that were suggested for an IANA registry in an earlier draft version of this doc. you can read about how to use it at [PSD-DMARC] too 🫶

B.2. DMARC PSD Registry 📋

[PSD-DMARC] gives you 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's also a Comma-Separated Value (CSV) version of the listed PSDs, which is perfect for build updates for PSD DMARC-capable software 🔥

PSDs that are deploying DMARC and participating in PSD DMARC must register their public suffix domain in this new registry. the requirement has to be documented in a way that satisfies the terms of Expert Review, per [RFC8126]. the Designated Expert needs to confirm that the provided documentation adequately describes PSD policy requiring Domain Owners to use DMARC, or that all Domain Owners are part of a single organization with the PSO 💖

The authoritative registry can be found here: <https://psddmarc.org>

B.3. DMARC PSD PSL Extension 🌸

[PSD-DMARC] provides a file formatted like the Public Suffix List (PSL) to make it easier to spot PSD DMARC participants. the contents are functionally identical to the IANA-like registry, just presented in a different format.

when you use this approach, the input domain of the extension lookup is supposed to be the output domain of the regular PSL lookup, aka the Organizational Domain. this alternative data approach could be really useful since DMARC implementations already need to parse this data format, so it should be easier to implement 🎀

Appendix C. Implementations 👑

there are two known implementations of PSD DMARC you can test out 🧁

C.1. Authheaders Module 🐍

the authheaders Python module and command line tool can be downloaded or installed from Pypi (Python Packaging Index). it supports both the DNS-based query service and downloading the CSV registry file from [PSD-DMARC] ✨

C.2. Zdkimfilter Module 🦋

the zdkimfilter module is a separate add-on to Courier-MTA. it's mostly used for DomainKeys Identified Mail (DKIM) signing, but it can also be configured to verify, apply DMARC policies, and send Aggregate Reports. for PSD DMARC, it uses the PSL extension list approach, which is available from [PSD-DMARC] 💅

Acknowledgements 🫶

thank you to the following people for their contributions (both public and private) to making this doc better: 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 💜

a special shoutout to Dave Crocker for coming up with the name 👑✨

Authors' Addresses 🌸

Scott Kitterman
fTLD Registry Services
Suite 400
600 13th Street, NW
Washington, DC 20005
United States of America

Phone: +1 301 325-5475
Email: scott@kitterman.com


Tim Wicinski (editor)
Elkins, WV 26241
United States of America

Email: tjw.ietf@gmail.com
📦 where this page comes from