| Internet-Draft | PQC in DKIM | November 2026 |
| Buck | Expires 6 May 2027 | [Page] |
This document discusses suitable post-quantum (PQ) signature algorithms for DomainKeys Identified Mail (DKIM). Because DKIM signatures are carried in emails, and public keys in DNS TXT records the usage of already standardized algorithms is limited. For compatibility reasons, signers that want post-quantum security are expected to add a PQ signature to a message in addition to a traditional signature, using separate DKIM-Signature header fields. The existing RSA and Ed25519 algorithms remain unchanged.¶
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 (DKIM) [RFC6376] signs email messages by hashing selected header fields and the message body and signing the resulting header hash with a digital signature. Recipients obtain the verification key from the Domain Name System (DNS). DKIM defines RSA [RFC8017] and, in [RFC8463], Ed25519 as signing algorithms. Neither is resistant to attacks by a cryptographically relevant quantum computer (CRQC) running Shor's algorithm [SHOR].¶
For DKIM, the relevant threat is forgery: an attacker with a CRQC could derive a private signing key from a published public key and sign messages in the name of a domain. This matters for keys that remain published for a long time and for archived messages whose signatures are still checked later.¶
This document discusses the use of post-quantum (PQ) signature algorithms for DKIM1 (DKIM version 1, "v=1" as specified in [RFC6376]). Four candidates are compared: ML-DSA, FN-DSA, SLH-DSA, and SQIsign. Three parameter sets of the first two families are considered in detail: ML-DSA-44, ML-DSA-65 [FIPS-204], and FN-DSA-512 [FIPS-206]. In parallel, standardization of DKIM2 [I-D.ietf-dkim-dkim2-spec] with PQ support is ongoing; DKIM1 currently has no PQ signature algorithm. This document does not define new algorithm identifiers, tags, or registry entries, and it does not modify [RFC6376] or [RFC8463]. The key words of BCP 14 are used only in Table 1, which is a proposal for implementation requirements and not a standard. It does not update [RFC6376], [RFC8301], or [RFC8463], and it does not define algorithm identifiers.¶
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.¶
This section describes the PQ signature schemes considered in this document. All are designed to resist attacks by a CRQC. Their public keys or signatures are larger than those of RSA and Ed25519, and the public keys of the lattice-based schemes do not fit in DNS over UDP responses.¶
ML-DSA [FIPS-204] is a lattice-based signature scheme built on the Fiat-Shamir with aborts paradigm. Its security rests on the presumed hardness of the Module Learning With Errors (Module-LWE) and Module Short Integer Solution (Module-SIS) problems. This document considers ML-DSA-44 and ML-DSA-65. Because these schemes are comparatively new, ML-DSA signatures are intended to be used together with a separate traditional DKIM signature.¶
FN-DSA [FIPS-206] is a lattice-based signature scheme following the hash-and-sign paradigm. Its security rests on the presumed hardness of the SIS problem over NTRU lattices. FN-DSA has smaller public keys and signatures than ML-DSA. This document considers FN-DSA-512, which is likewise intended to be used together with a separate traditional DKIM signature. FN-DSA is not yet a final standard at the time of writing.¶
SLH-DSA [FIPS-205] is a stateless hash-based signature scheme. Its security is based on the security of hash functions. SLH-DSA was standardized with 12 different parameter sets yielding different security levels, artifact sizes, and performance. In general, SLH-DSA has larger signatures, smaller public keys, and poorer performance compared to lattice-based alternatives. SLH-DSA-SHAKE-128f is used as a representative in this document, because it has the fastest signing of the small-key sets; the "s" variants have smaller signatures but slower signing.¶
SQIsign [SQISIGN] is an isogeny-based signature scheme. Its security rests on the presumed hardness of finding isogenies between supersingular elliptic curves, a problem that differs fundamentally from the lattice and hash-function assumptions above. SQIsign has the smallest public keys and signatures of all schemes considered, but has poorer performance compared to lattice based schemes. SQIsign is a candidate in NIST's additional signature process and therefore not standardized.¶
DKIM supports multiple digital signature algorithms. RFC 6376 defines rsa-sha256 and RFC 8463 defines ed25519-sha256. This document discusses the use of mldsa44-sha256, mldsa65-sha256, and fndsa512-sha256. The suggested implementation requirements for signers and verifiers are given in Table 1.¶
The suffix "-sha256" in the algorithm names denotes the hash function used by DKIM to compute the header and body hashes ([RFC6376], Section 3.3) and is independent of any hash function used internally by ML-DSA or FN-DSA.¶
For mldsa44-sha256, mldsa65-sha256, and fndsa512-sha256, the signer applies the signing algorithm of the respective scheme directly to the DKIM header hash as message, using the pure variant (not HashML-DSA) and an empty context string. The algorithm names mldsa44-sha256, mldsa65-sha256, and fndsa512-sha256 are used in this document as working names only. This document does not register them with IANA and does not define new "a=" tag values.¶
DKIM has some key factors, which are relevant for the implementation of post-quantum secure algorithms. These key factors are mainly performance, public-key size and signature size. In short, none of the algorithms mentioned in Section 2 fits all of the three key factors.¶
DKIM signatures are signed by the sending server and verified by the receiving server. Calculations are performed on the server, so faster is better. The already standardized algorithms RSA and Ed25519 perform well in sign and verify operations. The PQ alternatives SLH-DSA-SHAKE-128f and SQIsign-I are ~51 and ~49 times slower than RSA-2048 with the sign operation, and ~80 and ~1021 times slower with the verify operation. ML-DSA-44 (~11 times faster sign; nearly the same verify time), ML-DSA-65 (~7 times faster sign; ~2 times slower verify) and FN-DSA-512 (~3 times faster sign, nearly the same verify time) perform better while signing and have about the same verify times. All values are based on calculations by [PQSHIELD].¶
Public DKIM keys are stored as DNS TXT records. Typically these public keys are retrieved using DNS UDP responses, and the traditional maximum UDP size is 512 bytes (smaller is better). RSA-2048 (~256 bytes) and Ed25519 (32 bytes) keys encoded in Base64 fit in such 512 byte packets, PQ alternatives mostly do not. SLH-DSA public keys are 32, 48 or 64 bytes in size, the keys of SQIsign 83, 129 or 169 bytes. SLH-DSA and SQIsign are compatible in this case. ML-DSA (1312, 1952, 2592) and FN-DSA (897, 1793) keys exceed this limit and would need a TCP fallback for the DNS response.¶
DKIM signatures are transmitted in the header of emails and are currently based on RSA and Ed25519. Typically the signature is stored in the email on several devices, like sending and receiving server, and one or more clients (smaller is better). The mentioned traditional algorithms use 64 bytes (Ed25519) up to 256 bytes (RSA-2048), which has no significant impact on email sizes. The PQ alternatives mostly have significantly larger signatures (ML-DSA-44 2420 bytes, ML-DSA-65 3309 bytes, FN-DSA-512 666 bytes, SLH-DSA-SHAKE-128f 17088 bytes), but SQIsign-I in this case has more or less the same signature size (200 bytes). Larger signatures, especially encoded in Base64, mean more space needed for storing emails, which could be a problem especially for the SLH-DSA variants.¶
Based on the key factors discussed in Section 3.1, none of the mentioned PQ alternatives fulfills all requirements. SQIsign matches most of the key factors but has poor performance and, more importantly, is not standardized. SLH-DSA would increase the email size by at least 17 kilobytes with the first fast variant and also has poor performance. ML-DSA-44, ML-DSA-65 and FN-DSA-512 are the most suitable algorithm variants. They show good performance, but their public keys exceed the 512 byte UDP limit, which makes TCP fallbacks necessary. Their signatures, from 666 bytes (FN-DSA-512) up to 3309 bytes (ML-DSA-65), increase email sizes only moderately. Larger sets (ML-DSA-87, FN-DSA-1024) have larger keys and signatures and exceed the size limits discussed below even further.¶
For rsa-sha256, the key size for signers should be at least 2048 bits (instead of 1024 bits defined in [RFC8301]), due to newer attacks on smaller key sizes [RSAFORGE]. For the PQ algorithms, the key size is fixed by the parameter set.¶
RSA and Ed25519 are vulnerable to Shor's algorithm [SHOR]. To obtain post-quantum security, a signer needs to add both a traditional signature (rsa-sha256 or ed25519-sha256) and a PQ signature (mldsa44-sha256, mldsa65-sha256, or fndsa512-sha256) to the message, as described in Section 6, to get a hybrid construct with two separate signatures. This is more compatible (the traditional algorithm is also used), and if one algorithm is broken, the other part still verifies. A composite construct (one signature combining both algorithms) would break compatibility with the current DKIM system. PQ public keys can exceed the size of a UDP DNS response, so verifiers need to be able to retrieve keys over TCP.¶
This section illustrates how DKIM signatures and keys could look if the algorithms discussed here were defined for DKIM. It is informational and does not update [RFC6376] or [RFC8463].¶
The "a=" tag ([RFC6376], Section 3.5; [RFC8463], Section 4.1) could be extended by adding the following alternatives to the rule sig-a-tag-k:¶
sig-a-tag-k =/ "mldsa44" sig-a-tag-k =/ "mldsa65" sig-a-tag-k =/ "fndsa512"¶
The "k=" tag ([RFC6376], Section 3.6.1; [RFC8463], Section 4.2) could be extended by adding the following alternatives to the rule key-k-tag-type:¶
key-k-tag-type =/ "mldsa44" key-k-tag-type =/ "mldsa65" key-k-tag-type =/ "fndsa512"¶
The "p=" value would be the base64-encoded public key of the respective scheme, without further encapsulation. See Appendix A.2 for sample key records.¶
Section 3.3 of [RFC6376] describes DKIM's hash and signature algorithms and [RFC8463] extends them. Table 1 lists the proposed implementation requirements for DKIM signing algorithms. They are a proposal only, to be adopted, if at all, by a Standards Track document. Algorithms marked as PQ-secure provide post-quantum security only in combination with a traditional signature and only if verifiers require the PQ signature to be valid (see Section 3.4). ML-DSA-65 offers a higher security level than ML-DSA-44 (NIST category 3 instead of 2) at the cost of larger keys and signatures (several kilobytes); it is therefore only advisable where such higher security needs exist. Some implementations limit the size of individual header fields or of the whole header, which could be a problem for ML-DSA based signatures. Such limits have not been evaluated in this document and need to be checked in an implementation.¶
| Algorithm (a=) | Key size | Signer | Verifier | PQ-Secure | Reference |
|---|---|---|---|---|---|
| rsa-sha256 | < 1024 bits | MUST NOT | MUST NOT | No | [RFC8301] |
| rsa-sha256 | 1024 bits | SHOULD NOT | MUST | No | [RFC8301] |
| rsa-sha256 | 2048 bits | MUST | MUST | No | [RFC8301] |
| rsa-sha256 | 4096 bits | MAY | MUST | No | [RFC8301] |
| rsa-sha256 | > 4096 bits | MAY | MAY | No | [RFC8301] |
| ed25519-sha256 | fixed | SHOULD | MUST | No | [RFC8463] |
| mldsa44-sha256 | fixed | MUST | MUST | Yes (hybrid only) | [FIPS-204] |
| mldsa65-sha256 | fixed | SHOULD (1) | MUST | Yes (hybrid only) | [FIPS-204] |
| fndsa512-sha256 | fixed | SHOULD | SHOULD | Yes (hybrid only) | [FIPS-206] |
A signer that adds a PQ signature to a message needs to also add a traditional signature (rsa-sha256 or ed25519-sha256), so that verifiers without PQ support can still validate the message. Because a selector can publish only one key record in the DNS, the two signatures need to use different selectors; they can use the same d= and, if present, i= values. Without the traditional signature, verifiers that do not support PQ algorithms would treat the message as unsigned. Without the PQ signature, the message would gain no protection against a CRQC (see Section 3.4). The deployment of PQ signatures is expected to follow that of ed25519-sha256, which is not yet supported by all verifiers. A verifier that supports PQ algorithms validates both signatures; a valid traditional signature alone does not provide PQ security (see Section 3.4). Since a verifier cannot know whether a domain signs with PQ algorithms, requiring the PQ signature is only possible for domains for which this is known, for example through local policy.¶
This document has no IANA actions. The algorithm names used here are working names only (see Section 3). Registration of key types and signature algorithms would have to be requested in a separate Standards Track document.¶
The security considerations of [RFC6376] apply in addition to those below.¶
The algorithms discussed in this document are intended to provide authenticity of DKIM signatures against an adversary with a CRQC. They do so only if a verifier requires both a traditional and a PQ signature as described in Section 3.4. If a verifier accepts a message with only a valid traditional signature, an attacker can remove the PQ signature and forge the traditional one (downgrade).¶
Large public keys and signatures increase DNS response sizes and header lengths; see Section 3.4 for the TCP fallback. FN-DSA is not yet a final standard at the time of writing, and its implementation needs particular care, because the floating-point operations used in signing can leak information through side channels.¶