Email authentication has an awkward post-quantum constraint: DKIM signatures travel inside messages while public keys are published through DNS TXT records. On November 2, an individual Internet-Draft on post-quantum cryptography in DKIM proposed adding a post-quantum signature alongside a traditional DKIM signature, using separate header fields so existing RSA and Ed25519 behavior can continue.
This is an individual proposal with no formal IETF standing, not a standard or endorsement. Its value is in exposing the operational boundary: PQC for email must fit message headers, DNS delivery, verifier behavior, forwarding paths, and coexistence policy at the same time.
Two signatures create more than two records
A parallel signature approach preserves compatibility, but it adds selectors, public keys, algorithms, policies, signing operations, and verification outcomes. A cryptographic inventory needs to connect the entire path.
For each signing domain and mail flow, teams should record:
- domain, selector, DNS owner name, TXT data, TTL, DNS provider, and authoritative owner;
- traditional and post-quantum signature algorithms, parameter sets, identifiers, and key sizes;
- signing-key fingerprint, generation, storage, custody, rotation, backup, and destruction;
- signing service, MTA, application, host, location, environment, version, and owner;
- canonicalization, signed headers, body-length behavior, timestamp, expiration, and policy;
- message and header size before and after signing, transport limits, and observed failures;
- recipient, gateway, forwarder, mailing list, security service, and verifier compatibility;
- verification result for each signature, Authentication-Results handling, and retained evidence;
- fallback, partial-success, downgrade, incident, and rollback behavior; and
- discovery source, observation time, scope, confidence, and coverage gaps.
Without these relationships, a team may prove that a signer can produce a PQ signature while missing that recipients cannot retrieve the key or accept the expanded message.
DNS size becomes a cryptographic constraint
Post-quantum public keys can be substantially larger than familiar DKIM keys. DNS TXT formatting, response size, fragmentation, TCP fallback, resolver limits, caches, security gateways, and DNSSEC overhead can all influence reliable retrieval.
The right test is not whether a key can be pasted into a zone. Teams should query it through representative recursive resolvers, networks, gateways, and receiving systems. They should verify the exact assembled value and preserve response and validation evidence.
DNS ownership also matters. Email security, infrastructure, marketing platforms, managed DNS, registrars, and suppliers may each control part of the chain. Stable domain and service identifiers help assign the correct owner and coordinate rotation.
Message size travels through the whole ecosystem
A larger signature header is carried through MTAs, filters, archives, journaling systems, forwarding services, mailing lists, mobile clients, and legal-retention platforms. Some intermediaries modify messages, fold headers, impose size limits, or re-sign content.
Testing should include real paths and transformations, not only direct delivery between two lab servers. Inventory should identify which systems preserve, verify, ignore, alter, or remove each signature. A successful classical result must not be misreported as proof that the post-quantum signature was verified.
Coexistence requires explicit policy
During migration, recipients may understand neither, one, or both signatures. Organizations need to decide what counts as success, how results affect filtering or reputation, when a missing PQ signature is acceptable, and how downgrade or stripping is detected.
Those rules should be time-bound and explainable. A dashboard should distinguish signed, key published, key retrievable, signature parsed, cryptographically verified, policy accepted, and operationally monitored. Collapsing those stages into “PQC ready” hides the exact failure teams need to fix.
The same discipline applies to suppliers. “PQ-capable email” should name algorithms, versions, limits, DNS requirements, verifier coverage, and evidence from the organization’s own paths.
What organizations should do next
First, build a canonical map of signing domains, selectors, DNS zones, mail services, gateways, forwarders, archives, owners, and suppliers.
Second, measure current DKIM header and DNS behavior before selecting a PQ algorithm. Include DNSSEC, common resolvers, message transformations, and maximum-size cases.
Third, define coexistence states and independent evidence for traditional and PQ verification. Test key rotation, selector rollover, fallback, stripping, partial failure, and rollback.
Finally, track the proposal’s standards status and broader ecosystem support. Do not deploy an individual draft as a universal requirement, and do not assume that successful signing establishes end-to-end verification.
How Vista Platform helps
Vista Platform is a self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through discovery, canonical inventory, evaluation, action, and proof. Teams can connect certificates, keys, algorithms, applications, devices, hosts, locations, owners, suppliers, policy, exceptions, and migration evidence.
Vista Core is source-available and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted rather than indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
The proposal is at its first individual-draft revision and may change substantially or never become a standard. Algorithm choices, encodings, DNS behavior, verifier adoption, interoperability, and policy treatment remain unsettled. Organizations should use it to sharpen inventory and testing questions, not to claim completed migration.
Source
- Post-Quantum Cryptography in DKIM, draft-buck-dkim-pq-dkim1-00, individual Internet-Draft, November 2, 2026.