DKIM and Post-Quantum Cryptography: Keep Calm and Fix the Basics

Post-quantum cryptography is a real issue, but not every part of the email security stack is exposed in the same way. A lot of commentary collapses the whole topic into “store now, decrypt later”: attackers collect encrypted traffic today, wait for a cryptographically relevant quantum computer, and decrypt it later. That’s a serious concern for encrypted content (PGP, S/MIME, TLS, VPNs, backups, archives), but it is not the right model for DKIM.

DKIM is not a confidentiality mechanism. It does not encrypt the message. It is an authentication signal evaluated when a receiver processes the email. The receiver checks the DKIM-Signature header against a public key published under a selector in DNS, and that result feeds into local policy as well as DMARC. The post-quantum concern for DKIM isn't that today's signed emails will be decrypted later. The concern is future forgery. If RSA-class signatures become breakable, an attacker could create apparently valid DKIM signatures for spoofed mail unless the ecosystem has moved to quantum-resistant signature schemes.

That matters, but the urgency is different. NIST has standardized post-quantum digital signature algorithms such as ML-DSA, and standards bodies are discussing algorithm agility and future extensibility in email authentication. But there is not yet a broadly deployed, interoperable, production DKIM post-quantum profile that people should rush to bolt onto their domains.

There is also a practical implementation reality. Hybrid DKIM migration may eventually mean running classical and post-quantum signing material in parallel. That makes sense in theory, but in DKIM, signatures live in message headers while DNS publishes selector-scoped public keys. The real work isn’t just “putting post-quantum signatures in DNS.” It is agreeing algorithms, key formats, selectors, DNS record handling, verifier behavior, failure semantics, and DMARC alignment treatment.

DKIM is simpler than encryption in one way because it doesn’t need to protect message content over time, but it is also difficult to change at internet scale. DNS has to carry the public keys, and DNS transport has practical size and reliability constraints that become more important if post-quantum public keys are substantially larger than today’s RSA keys. Receivers process massive volumes of mail and continuously evaluate signatures, so verifier performance matters too. That means the industry has to solve not only the cryptographic design question, but also the engineering questions around key size in DNS, signature size in headers, lookup behavior, caching, throughput, and backward compatibility.

For now, the right focus is getting the email authentication basics right. That means strong DKIM keys where supported, disciplined selector management, authenticated and aligned sending sources, DMARC moved beyond monitoring into enforcement, and continuous visibility into failures and unauthorized senders. That's exactly where OnDMARC helps: managing SPF, DKIM, DMARC, BIMI, and MTA-STS, identifying misconfigurations, and keeping teams on a clear path to enforcement rather than treating email authentication as a one-off DNS project.

The more urgent post-quantum work is elsewhere. Inventory where you're using public-key cryptography, especially where confidentiality has a long shelf life. TLS certificates, VPNs, encrypted backups, long-term archives, code signing, S/MIME, private PKI, and machine identities all deserve attention before speculative DKIM changes. That work starts with visibility: what certificates exist, where they are deployed, what algorithms and key exchanges they use, who owns them, and how quickly they can be rotated.

Red Sift Certificates handles that side. It covers discovery and monitoring of public cryptographic assets across domains, subdomains, certificates, and exposed services, including TLS configuration and certificate details. That gives teams a practical starting point for post-quantum readiness. Build the inventory, understand exposure, prioritize long-lived confidentiality risks, and improve cryptographic agility before a forced migration arrives.

Our recommendation? Keep calm and carry on. Use OnDMARC to harden DKIM and DMARC with today’s standards. Ask ESPs and mail vendors for their roadmap on DKIM algorithm agility and future post-quantum support. Clients should also track IETF DKIM2 work as part of the broader move toward DKIM algorithm agility and stronger message-handling semantics, while treating it as standards work in progress rather than a deployable post-quantum control today. Use Red Sift Certificates to begin the broader cryptographic inventory and certificate-readiness work now.