STARTTLS Studio
Post-quantum email test
Mail between servers is encrypted with STARTTLS — but is the key exchange quantum-safe? This pins a real port-25 STARTTLS handshake to X25519MLKEM768 against every MX and tells you whether recorded mail traffic would survive a quantum computer.
Why mail is the classic harvest-now-decrypt-later target
Email is store-and-forward: a message crosses the internet between mail servers in a handful of SMTP hops, and those hops are exactly the kind of long-life, high-value traffic that gets recorded today for decryption later. A password reset, a contract, a medical letter — all of it keeps its value for years. The fix is the same hybrid ML-KEM key exchange the web is rolling out, applied to SMTP: Google's Gmail MX fleet already negotiates X25519MLKEM768 on port 25, and this test will show you that in the wild.
What this test does
For each MX record we open a real SMTP session from our probe server, issue STARTTLS, and upgrade the connection twice: once normally (the classical baseline), and once with the TLS 1.3 ClientHello pinned to X25519MLKEM768 only. If the pinned handshake completes, that MX negotiates post-quantum key exchange — there is nothing else it could have picked. A classical certificate on the MX is normal and irrelevant here; key exchange is what protects recorded traffic.
How to fix a "not yet quantum-safe" result
Post-quantum key exchange arrives with your MTA's TLS library. A mail server linked against OpenSSL 3.5+ offers X25519MLKEM768 by default; on Postfix the group list is configurable with tls_eecdh_auto_curves. If your mail is hosted (Google Workspace, Microsoft 365, etc.), it's your provider's stack — test them here and let the result do the talking. The web-facing version of this check lives at tls.studio's post-quantum TLS test, and the background reading — harvest now, decrypt later and ML-KEM explained — is in the TLS Academy.
Not sure your STARTTLS is solid in the first place? Start with the STARTTLS tester or the full mail server tester.