dkim W. Chuang Internet-Draft Google Updates: 6376 (if approved) R. Clayton Intended status: Standards Track Yahoo Expires: 6 May 2027 2 November 2026 Domain Name Specification for DKIM1 and DKIM2 draft-ietf-dkim-dkim2-dns-03 Abstract DomainKeys Identified Mail (DKIM) permits the owner of a signing domain to document that they have handled an email message by associating their domain with the message. One part of this involves publishing a public key to a Domain Name System (DNS) record associated with the domain. Signing with the associated private key establishes their connection to the message. This document describes how to find the relevant DNS record and how information is recorded within it. This document updates RFC 6376, which describes DKIM, by clarifying the RSA public key format and by deprecating key record features that have not turned out to be useful. It also describes which parts of the key record are relevant to DomainKeys Identified Mail v2 (DKIM2) and describes a new Domain Policy Record for DKIM2 that can hold domain-wide settings. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2027. Chuang & Clayton Expires 6 May 2027 [Page 1] Internet-Draft DKIM DNS November 2026 Copyright Notice Copyright (c) 2026 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 of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 2.1. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Imported ABNF tokens . . . . . . . . . . . . . . . . . . 4 2.3. Common ABNF tokens . . . . . . . . . . . . . . . . . . . 4 2.4. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 5 3. Public key management . . . . . . . . . . . . . . . . . . . . 5 4. Key records . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. v= Version of the DKIM key record . . . . . . . . . . . . 6 4.2. k= Key type . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. p= Public-key data . . . . . . . . . . . . . . . . . . . 7 4.4. h= Acceptable hash algorithms . . . . . . . . . . . . . . 7 4.5. n= Notes that might be of interest to a human . . . . . . 7 4.6. s= Service type . . . . . . . . . . . . . . . . . . . . . 8 4.7. t= Flags . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Domain Policy Record . . . . . . . . . . . . . . . . . . . . 8 5.1. v= Version of the Domain Policy Record . . . . . . . . . 9 5.2. f= Flags for the Domain Policy Record . . . . . . . . . . 9 6. Updates to RFC 6376 . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7.1. _domainkey DNS TXT Record Tag Specifications . . . . . . 9 7.2. DKIM Key Type . . . . . . . . . . . . . . . . . . . . . . 10 7.3. DKIM Service Types . . . . . . . . . . . . . . . . . . . 10 7.4. DKIM Selector Flags . . . . . . . . . . . . . . . . . . . 11 7.5. DKIM2 Domain Policy Flags . . . . . . . . . . . . . . . . 11 7.6. Underscored and Globally Scoped DNS Node Names . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments {#acks :numbered="false"} . . . . . 14 Changes from Earlier Versions . . . . . . . . . . . . . . . . . . 15 Chuang & Clayton Expires 6 May 2027 [Page 2] Internet-Draft DKIM DNS November 2026 draft-ietf-dkim-dkim2-dns-03 . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction DomainKeys Identified Mail permits the owner of a signing domain to document that they have handled an email message by associating their domain with the message by means of a cryptographic signature. [RFC6376] describes how this is achieved in a protocol we will call, for the purposes of this document, DKIM1. [DKIM2SPEC] describes DomainKeys Identified Mail v2, which we will call DKIM2. Usage of the term DKIM should be understood as referring to both DKIM1 and DKIM2. DKIM1 and DKIM2 use the same method of storing public key values in the Domain Name System (DNS). This document serves two purposes. It describes all the features of the key storage system used by DKIM1 as updated by [RFC8301] and [RFC8463] (along with errata) but then deprecates various features which have turned out to be of little practical use. It also states which of these features DKIM2 uses. Further, a new DKIM2-only Domain Policy Record is defined. DKIM1 does not use this. 2. Terminology and Definitions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Terms such as Signer, Verifier, Signing Domain and Selector are used as defined in [DKIM2SPEC]. Basic email terminology is taken from [RFC5598]. Syntax descriptions use Augmented BNF (ABNF) [RFC5234], together with the %s"..." notation for case-sensitive strings defined in [RFC7405]. 2.1. Whitespace There are two forms of whitespace used in this specification: Chuang & Clayton Expires 6 May 2027 [Page 3] Internet-Draft DKIM DNS November 2026 * WSP represents simple whitespace, i.e. a space or a tab character (formal definition in [RFC5234]). * FWS is folding whitespace. It allows multiple lines separated by CRLF followed by at least one whitespace, to be joined. The formal ABNF for these are (WSP given for information only): WSP = SP / HTAB FWS = [*WSP CRLF] 1*WSP The definition of FWS is identical to that in [RFC5322] except for the exclusion of obs-FWS. 2.2. Imported ABNF tokens Tokens are imported from other RFCs as noted. Those RFCs should be considered definitive. * "qp-section" (a single line of quoted-printable-encoded text) is imported from [RFC2045]. * "sub-domain" (a single domain label) is imported from [RFC5321]. Tokens not defined herein are imported from [RFC5234]. These are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, etc. 2.3. Common ABNF tokens The following ABNF tokens are used elsewhere in this document: hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) [ [FWS] "=" [ [FWS] "=" ] ] Note that base64strings are defined in [RFC4648], but that document does not contain any ABNF. A base64string MUST be padded with zero bits and trailing = characters provided if needed. This allows implementations to compare base64string values without decoding them. FWS may appear anywhere within a base64string and is ignored when the value is used. Chuang & Clayton Expires 6 May 2027 [Page 4] Internet-Draft DKIM DNS November 2026 2.4. Tag=Value Lists Key records use the "tag=value" syntax defined in the "Tag=Value Lists" section of [DKIM2SPEC], including its rules on whitespace, case sensitivity, duplicate tags, unrecognized tags, empty values and default values. 3. Public key management DKIM links a public key to the Signing Domain by fetching a public key value from the DNS. Selectors permit a Signing Domain to use multiple public keys, possibly using different cryptographic algorithms. Selectors allow keys to be rotated or distributed to third parties. DKIM keys are stored in a subdomain named "_domainkey". Given a Signing Domain "example.com" and a Selector of "foo.bar", the DNS query will be for "foo.bar._domainkey.example.com". Keys are held in a TXT RR at the selector name. Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace. TXT records that begin with a "v=" tag with a value other than "DKIM1" are ignored. If more than one record then remains, this is an error. ABNF: selector = sub-domain *( "." sub-domain ) 4. Key records The overall syntax is a Tag=Value list as described in Section 2.4. Key records are defined for three key types: Chuang & Clayton Expires 6 May 2027 [Page 5] Internet-Draft DKIM DNS November 2026 +===========+===============+======================+=============+ | Key type | Algorithm | DKIM1 usage | DKIM2 usage | +===========+===============+======================+=============+ | "rsa" | RSA [RFC8017] | [RFC6376], [RFC8301] | [DKIM2SPEC] | +-----------+---------------+----------------------+-------------+ | "ed25519" | Ed25519 | [RFC8463] | [DKIM2SPEC] | | | [RFC8032] | | | +-----------+---------------+----------------------+-------------+ | "mldsa44" | ML-DSA-44 | not defined | [DKIM2SPEC] | | | [FIPS-204] | | | +-----------+---------------+----------------------+-------------+ Table 1: Key types The algorithms used with these keys, and the RSA key sizes, are specified in [DKIM2SPEC]; for DKIM1 see [RFC8301]. The current valid tags for key records are described below. The p= tag MUST be present; all other tags are optional. It is RECOMMENDED to provide a v= tag. The h=, n=, s= and t= tags are deprecated: they SHOULD NOT be used in DKIM1 key records, and DKIM2 ignores them if they are present. 4.1. v= Version of the DKIM key record If specified, this tag MUST be set to "DKIM1" (without the quotes) and an exact match with those characters is required. If absent, the record is processed as if v=DKIM1 were present. This tag MUST be the first tag in the record. Records beginning with a "v=" tag with any other value MUST be discarded. ABNF: key-v-tag = %s"v" [FWS] "=" [FWS] %s"DKIM1" 4.2. k= Key type This tag indicates what type of key is present. If omitted then the value "rsa" is used. The p= tag is interpreted for the different key types as follows: rsa: p= is an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey ([RFC8017], Sections 3.1 and A.1.1) or a SubjectPublicKeyInfo containing one ([RFC5280], [RFC4055]). ed25519: p= is the 32-octet Ed25519 public key [RFC8463]. Chuang & Clayton Expires 6 May 2027 [Page 6] Internet-Draft DKIM DNS November 2026 mldsa44: p= is the 1312-octet ML-DSA-44 public key output by ML- DSA.KeyGen (Algorithm 1 of [FIPS-204], encoded by pkEncode, Algorithm 22), with no SubjectPublicKeyInfo or other wrapper. DKIM1 Signers and Verifiers MUST support "rsa". DKIM2 Verifiers MUST support all three key types. ABNF: key-k-tag = %s"k" [FWS] "=" [FWS] key-k-tag-type key-k-tag-type = %s"rsa" / %s"ed25519" / %s"mldsa44" / x-key-k-tag-type x-key-k-tag-type = hyphenated-word ; for future extension 4.3. p= Public-key data The public key data is a base64string whose format depends on the k= tag. An empty value means that this public key has been revoked. An "ed25519" key that is not 32 octets, or an "mldsa44" key that is not 1312 octets, is malformed. ABNF: key-p-tag = %s"p" [FWS] "=" [ [FWS] base64string ] 4.4. h= Acceptable hash algorithms A colon-separated list of the hash algorithms that may be used with this key. When absent all are allowed. Note that [RFC8301] forbids the use of "rsa-sha1" for DKIM1. ABNF: key-h-tag = %s"h" [FWS] "=" [FWS] key-h-tag-alg *( [FWS] ":" [FWS] key-h-tag-alg ) key-h-tag-alg = %s"sha1" / %s"sha256" / x-key-h-tag-alg x-key-h-tag-alg = hyphenated-word ; for future extension 4.5. n= Notes that might be of interest to a human The notes text MUST be in quoted-printable format. DKIM does not use this text for any purpose. ABNF: key-n-tag = %s"n" [FWS] "=" [FWS] qp-section Chuang & Clayton Expires 6 May 2027 [Page 7] Internet-Draft DKIM DNS November 2026 4.6. s= Service type A colon-separated list of service types to which the record applies (default "_"). DKIM1 Verifiers ignore the key record if the list does not contain either "_" or "email". ABNF: key-s-tag = %s"s" [FWS] "=" [FWS] key-s-tag-type *( [FWS] ":" [FWS] key-s-tag-type ) key-s-tag-type = %s"email" / "*" / x-key-s-tag-type x-key-s-tag-type = hyphenated-word ; for future extension 4.7. t= Flags A colon-separated list of flags (default none). The flags are "y" (the domain is testing DKIM1) and "s" (DKIM1 requires an i= domain to be the same as d=). Unrecognized flags are ignored. ABNF: key-t-tag = %s"t" [FWS] "=" [FWS] key-t-tag-flag *( [FWS] ":" [FWS] key-t-tag-flag ) key-t-tag-flag = %s"y" / %s"s" / x-key-t-tag-flag x-key-t-tag-flag = hyphenated-word ; for future extension 5. Domain Policy Record The Domain Policy Record for a domain is a TXT RR at "_domainkey" under that domain (for "example.com", "_domainkey.example.com"). This record is used by DKIM2 and not by DKIM1. It is a Tag=Value list (see Section 2.4). The two current valid tags are described below. The v= tag MUST be present; the f= tag is optional. TXT records at that name that do not begin with v=DKIM1 are ignored. If more than one remains, this is an error. If the "strict" flag is absent, or there is no f= tag, or there is no Domain Policy Record, subdomains are authorized. The record applies only to the domain that holds it; it is not inherited by subdomains or parents. Chuang & Clayton Expires 6 May 2027 [Page 8] Internet-Draft DKIM DNS November 2026 5.1. v= Version of the Domain Policy Record This tag MUST be set to "DKIM1" (without the quotes) and an exact match with those characters is required. This tag MUST be the first tag in the record. ABNF: dpr-v-tag = %s"v" [FWS] "=" [FWS] %s"DKIM1" 5.2. f= Flags for the Domain Policy Record A colon-separated list of flags (default none). One flag is defined, "strict": subdomains of the domain are not authorized to make From header fields that use the domain Authentic (see [DKIM2SPEC]). Unrecognized flags are ignored. ABNF: dpr-f-tag = %s"f" [FWS] "=" [ [FWS] dpr-f-tag-flag *( [FWS] ":" [FWS] dpr-f-tag-flag ) ] dpr-f-tag-flag = %s"strict" / x-dpr-f-tag-flag x-dpr-f-tag-flag = hyphenated-word ; for future extension 6. Updates to RFC 6376 This document updates [RFC6376] as follows: * The h=, n=, s= and t= tags are deprecated (see Section 4). * An "rsa" key may be either an RSAPublicKey or a SubjectPublicKeyInfo containing one. This resolves errata 3017, 6674 and 7001. * TXT records at a selector name that begin with v= other than "DKIM1" are ignored; more than one remaining record is an error. 7. IANA Considerations IANA is requested to make the following changes to registries in the "DomainKeys Identified Mail (DKIM) Parameters" group. As set out in [RFC6376], the status of an entry is either "active" or "historic". 7.1. _domainkey DNS TXT Record Tag Specifications IANA is requested to update the following entries and add the "f" entry. Other entries are unchanged. Chuang & Clayton Expires 6 May 2027 [Page 9] Internet-Draft DKIM DNS November 2026 +======+=====================+==========+ | TYPE | REFERENCE | STATUS | +======+=====================+==========+ | v | [RFC6376], RFC XXXX | active | +------+---------------------+----------+ | h | [RFC6376], RFC XXXX | historic | +------+---------------------+----------+ | k | [RFC6376], RFC XXXX | active | +------+---------------------+----------+ | n | [RFC6376], RFC XXXX | historic | +------+---------------------+----------+ | p | [RFC6376], RFC XXXX | active | +------+---------------------+----------+ | s | [RFC6376], RFC XXXX | historic | +------+---------------------+----------+ | t | [RFC6376], RFC XXXX | historic | +------+---------------------+----------+ | f | RFC XXXX | active | +------+---------------------+----------+ Table 2 IANA is also requested to add a note to the registry: "Tags in this registry are used in DKIM key records and in the DKIM2 Domain Policy Record. A tag name is registered once and has one meaning." 7.2. DKIM Key Type IANA is requested to update the "rsa" entry and to add the "mldsa44" entry as follows: +=========+======================+========+ | TYPE | REFERENCE | STATUS | +=========+======================+========+ | rsa | [RFC8017], RFC XXXX | active | +---------+----------------------+--------+ | mldsa44 | [FIPS-204], RFC XXXX | active | +---------+----------------------+--------+ Table 3 7.3. DKIM Service Types IANA is requested to update both entries as follows: Chuang & Clayton Expires 6 May 2027 [Page 10] Internet-Draft DKIM DNS November 2026 +=======+=====================+==========+ | TYPE | REFERENCE | STATUS | +=======+=====================+==========+ | email | [RFC6376], RFC XXXX | historic | +-------+---------------------+----------+ | * | [RFC6376], RFC XXXX | historic | +-------+---------------------+----------+ Table 4 7.4. DKIM Selector Flags IANA is requested to update both entries as follows: +======+=====================+==========+ | TYPE | REFERENCE | STATUS | +======+=====================+==========+ | y | [RFC6376], RFC XXXX | historic | +------+---------------------+----------+ | s | [RFC6376], RFC XXXX | historic | +------+---------------------+----------+ Table 5 7.5. DKIM2 Domain Policy Flags IANA is requested to create a new registry, "DKIM2 Domain Policy Flags", in the same group, for the flags used in the f= tag of the Domain Policy Record (see Section 5). New entries are assigned by IETF Review [RFC8126]. Each entry has a TYPE, a REFERENCE and a STATUS ("active" or "historic"). The initial entry is: +========+===========+========+ | TYPE | REFERENCE | STATUS | +========+===========+========+ | strict | RFC XXXX | active | +--------+-----------+--------+ Table 6 7.6. Underscored and Globally Scoped DNS Node Names IANA is requested to update the "_domainkey" entry for the TXT RR type in the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552] as follows. This document places the Domain Policy Record at the "_domainkey" name itself, in addition to the key records beneath it. Chuang & Clayton Expires 6 May 2027 [Page 11] Internet-Draft DKIM DNS November 2026 +=========+============+=====================+ | RR Type | _NODE NAME | Reference | +=========+============+=====================+ | TXT | _domainkey | [RFC6376], RFC XXXX | +---------+------------+---------------------+ Table 7 8. Security Considerations An "mldsa44" key of the wrong length is malformed (see p=); accepting one would lose the strong unforgeability ML-DSA provides (Section 3.6.2 of [FIPS-204]). See also the Security Considerations of [RFC6376] and [DKIM2SPEC]. 9. References 9.1. Normative References [DKIM2SPEC] Clayton, R., Chuang, W., and B. Gondwana, "DomainKeys Identified Mail Signatures v2 (DKIM2)", Work in Progress, Internet-Draft, draft-ietf-dkim-dkim2-spec-09, 1 November 2026, . [FIPS-204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, August 2024, . [ITU-X660-1997] ITU-T, "Information technology - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: General procedures", ITU-T Recommendation X.660, August 1997. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Chuang & Clayton Expires 6 May 2027 [Page 12] Internet-Draft DKIM DNS November 2026 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, DOI 10.17487/RFC4055, June 2005, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", STD 68, RFC 7405, DOI 10.17487/RFC7405, December 2014, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . Chuang & Clayton Expires 6 May 2027 [Page 13] Internet-Draft DKIM DNS November 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)", RFC 8301, DOI 10.17487/RFC8301, January 2018, . [RFC8463] Levine, J., "A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)", RFC 8463, DOI 10.17487/RFC8463, September 2018, . 9.2. Informative References [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . [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, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . Appendix A. Acknowledgments {#acks :numbered="false"} The parent document to this is DKIM [RFC6376] from which the vast majority of content is copied with only slight editing to update for DKIM2. The DKIM RFC was edited by Dave Crocker, Tony Hansen, and Murray Kucherawy. In addition, another source for this document is the Ed25519 extension to DKIM [RFC8463] with content transferred verbatim directly. The Ed25519 extension RFC was written by John Levine. Credit for the content and specification for DKIM and the Ed25519 extension, from which DKIM2 is derived, goes to them. Thanks goes to Christian Rößner for writing a detailed errata on RSA encoding in [RFC6376], and to Bron Gondwana for working through the errata history including those on the DKIM WG errata database. Thanks goes to Hannah Stern and Mauro De Gennaro for their valuable review comments. Chuang & Clayton Expires 6 May 2027 [Page 14] Internet-Draft DKIM DNS November 2026 Changes from Earlier Versions RFC Editor: please remove this section before publication. draft-ietf-dkim-dkim2-dns-03 * Substantial rework. Authors' Addresses Wei Chuang Google Email: weihaw@google.com Richard Clayton Yahoo Email: rclayton@yahooinc.com Chuang & Clayton Expires 6 May 2027 [Page 15]