| Internet-Draft | DKIM DNS | November 2026 |
| Chuang & Clayton | Expires 6 May 2027 | [Page] |
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.¶
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.¶
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.¶
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.¶
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].¶
There are two forms of whitespace used in this specification:¶
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.¶
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.¶
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.¶
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.¶
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 )¶
The overall syntax is a Tag=Value list as described in Section 2.4.¶
Key records are defined for three key types:¶
| Key type | Algorithm | DKIM1 usage | DKIM2 usage |
|---|---|---|---|
| "rsa" | RSA [RFC8017] | [RFC6376], [RFC8301] | [DKIM2SPEC] |
| "ed25519" | Ed25519 [RFC8032] | [RFC8463] | [DKIM2SPEC] |
| "mldsa44" | ML-DSA-44 [FIPS-204] | not defined | [DKIM2SPEC] |
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.¶
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"¶
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].¶
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
¶
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 ]¶
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
¶
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¶
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
¶
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
¶
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.¶
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"¶
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
¶
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".¶
IANA is requested to update the following entries and add the "f" entry. Other entries are unchanged.¶
| 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 |
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."¶
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 |
IANA is requested to update both entries as follows:¶
| TYPE | REFERENCE | STATUS |
|---|---|---|
| [RFC6376], RFC XXXX | historic | |
| * | [RFC6376], RFC XXXX | historic |
IANA is requested to update both entries as follows:¶
| TYPE | REFERENCE | STATUS |
|---|---|---|
| y | [RFC6376], RFC XXXX | historic |
| s | [RFC6376], RFC XXXX | historic |
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 |
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.¶
| RR Type | _NODE NAME | Reference |
|---|---|---|
| TXT | _domainkey | [RFC6376], RFC XXXX |
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].¶
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.¶
RFC Editor: please remove this section before publication.¶
Substantial rework.¶