Quantum-Safe Encryption: What It Means for Email
Quantum computing has been a theoretical concern for encryption for years. It is now a practical engineering concern, because standards bodies have published post-quantum algorithms and browsers have begun deploying them. The question for anyone running email infrastructure is no longer whether this matters, but which parts of your stack it touches and when.
The actual threat, stated precisely
The concern is not that a quantum computer will break into your mailbox. It is harvest now, decrypt later: an adversary records encrypted traffic today and decrypts it whenever sufficiently capable quantum hardware exists.
That reframes the urgency. Anything with a long confidentiality requirement, such as records that must remain private for a decade, is already exposed if it is transmitted under key exchange that a future machine can break. Anything that expires in a week is not.
The algorithms at risk are the ones in current widespread use: RSA and elliptic curve cryptography, which underpin TLS key exchange and the digital signatures in email authentication. Symmetric encryption is less affected, since a quantum computer offers a smaller speedup against it, which is why the practical response focuses on key exchange and signatures rather than on cipher choice.
What this changes for email specifically
Email has two distinct cryptographic layers, and they are affected differently.
Transport encryption (TLS). When mail moves between servers, it is usually protected by opportunistic TLS. This is the layer that post-quantum key exchange addresses directly, and it is where the standards work is furthest along. The upgrade happens in the TLS libraries your mail infrastructure uses, which in most cases means it arrives through your provider or your server's TLS stack rather than through anything you write.
Message-level authentication (DKIM). DKIM signs messages using RSA or elliptic curve keys. A future quantum computer could forge signatures, which matters because a forged DKIM signature would allow mail to appear to come from your domain. The migration here is to post-quantum signature algorithms, and it is slower because DNS record formats and receiving-server support must both move.
Note what is not in this list: your email's body content. Ordinary email is not end-to-end encrypted. It is encrypted in transit and at rest on servers that can read it. Post-quantum cryptography does not change that, and it is worth being clear because "quantum-safe encryption" can imply a confidentiality guarantee that standard email does not provide at any key size.
What is actually deployable now
Post-quantum key exchange is available and shipping in major browsers and TLS libraries. Deploying it is largely a matter of keeping your TLS stack current, and in most hosted environments it happens without you doing anything.
Post-quantum signatures for DKIM are earlier in their lifecycle. Supporting them requires both publishing a new kind of DNS record and having receiving servers that verify it. Until adoption is broad, the practical approach is to publish additional records alongside your existing ones rather than replacing them, so verification works for both old and new receivers.
This is a useful general pattern for cryptographic transitions: run the new mechanism alongside the old, verify both work, and retire the old one only when the ecosystem has moved.
What to do this year
- Inventory how long your data must stay confidential. Anything with a multi-year requirement deserves earlier attention than anything with a short one.
- Keep TLS current. Post-quantum key exchange arrives through library updates, so an up-to-date stack gets much of the benefit for free.
- Get your existing email authentication right first. SPF, DKIM and DMARC protect against domain spoofing today, with today's computers. A misconfigured DKIM record is a live problem; post-quantum signatures are a future one.
- Follow DKIM algorithm changes rather than implementing them early. The standards are still settling, and building custom signing before receiving support exists creates work you will redo.
- Do not let the topic distract from the basics. The overwhelming majority of email security incidents are not cryptographic. They are compromised credentials, unauthenticated senders and mailing lists that were never cleaned.
Where Cresca fits
Cresca sends from your own authenticated domain, so the DKIM keys involved are published and controlled by you rather than shared with other senders. That means a future DKIM algorithm transition is something you can adopt on your own schedule. Credentials for sending are scoped to your domain through DNS records, and API access uses tokens you can revoke.
Transport encryption between Cresca and receiving mail servers is handled by the sending infrastructure's TLS stack. Your email content is stored on our servers and is not end-to-end encrypted, which is the case for any platform that needs to generate, template or analyse campaign content.
The honest position
Post-quantum cryptography is a real migration and it is happening on a timescale measured in years, not weeks. It is not a reason to change platforms, and no email marketing platform gains a meaningful advantage from it today. What matters is that your provider keeps TLS current and that your own authentication records are correct, because the second of those is actionable now and the first is largely automatic.
Pricing
Authentication, TLS and API access are included on every plan:
| Plan | Price | Contacts | Emails / month |
|---|---|---|---|
| Free | $0 | 50 | 50 |
| Professional | $29/mo | 5,000 | 5,000 |
| Premium | $49/mo | 25,000 | 25,000 |
| Ultra | $99/mo | 55,000 | 55,000 |
What "post-quantum" does and does not change about trust
Encryption algorithms protect confidentiality. They do not address the other things email security depends on, and it is worth separating them because a migration to post-quantum algorithms is sometimes presented as a comprehensive fix.
Spoofing. Someone sending mail that claims to be from your domain. Today this is addressed by SPF, DKIM and DMARC, not by key length. A future quantum computer could eventually forge a DKIM signature, but a misconfigured DMARC policy lets someone spoof you right now.
Account compromise. An attacker with credentials to your sending platform can send as you regardless of algorithm. This is the most common cause of a domain being used for spam, and no cryptographic transition affects it.
Metadata. Who emailed whom, when, and from where. Encryption of the message body and transport does not hide this, and it is often the more sensitive information.
Questions worth asking a provider
- Is TLS kept current, and does it negotiate post-quantum key exchange where the receiving server supports it?
- Are DKIM keys ours or shared? Keys you publish mean you control the transition to new algorithms on your own schedule.
- Can credentials be revoked independently, so a single compromised token does not require a wholesale rotation?
- What is retained, and for how long? Data with a long retention period has a long confidentiality requirement, which is where harvest-now-decrypt-later applies.
The short version
Quantum-safe encryption matters primarily because of harvest-now-decrypt-later, which affects data with long confidentiality requirements. Post-quantum key exchange is deployable now through TLS library updates; post-quantum DKIM signatures are earlier and should be adopted progressively alongside existing records. Standard email is not end-to-end encrypted regardless of algorithm, so do not read a quantum-safe claim as a confidentiality guarantee.
Fix your SPF, DKIM and DMARC configuration first, because that is a live risk rather than a future one, and remember that account compromise and metadata exposure are unaffected by any algorithm change.
Continue learning
Related Cresca resources
External references