Engineering · Post-Quantum

Every email we send now proves itself.

KXCO Mail signs every outbound message with ML-DSA-65 and writes its hash to Armature L1. There is nothing for the sender to install, no keys to exchange, and no need to ask us for anything to check it. The proof travels with the message and outlives the conversation.

post-quantum email on-chain attestation KXCO Engineering 17 August 2026 ~10 min read

Every other record KXCO touches carries a proof. Documents signed on Meridian carry one. Credentials issued to institutions carry one. Deals moving through the CRM carry one. Email did not, and email is where most business actually happens. As of today, every message sent from a KXCO mailbox is signed with ML-DSA-65 and its hash is anchored on Armature L1. Not as an option a user can enable. On every message, automatically, at the platform.

01The last unproven channel

Email already has authenticity machinery, and it is weaker than most people assume. DKIM signs outbound mail, which is genuinely useful, but it is built for a narrow job: the receiving mail server checks the signature at delivery, decides the message is probably legitimate, and moves on. The proof is consumed at the door. Nobody can hand you a DKIM signature two years later and settle an argument about what a message said.

It is also classical. DKIM keys are RSA or Ed25519, both of which a sufficiently capable quantum computer breaks. A signature is a promise about the future, so the interesting question is not whether it verifies today but whether it still means anything in 2040. Anything harvested now can be attacked later, and email archives are exactly the sort of thing that gets kept for decades.

End-to-end schemes like PGP and S/MIME answer part of this, and thirty years of near-zero adoption is the verdict on how they answer it. They push key generation, key exchange and key hygiene onto individual people. Ask a busy director to manage a keyring and the honest forecast is that it does not happen.

So we took the other route: put the cryptography in the platform, where it can be guaranteed rather than encouraged.

02What happens when you press send

The signing step sits directly in the outbound path of the mail server, before the message is handed to SMTP. It hashes the message exactly as it will be delivered, headers and body together, asks an internal signing service for a signature over that digest, and attaches the result as four headers. The whole exchange is local to the machine and adds no meaningful latency to a send.

# headers on a delivered message, read back out of the mailbox
X-KXCO-PQ-Signature: 7c27e79d46c8bf2bfbbc470d974f0356a5b63119376f4e60...
X-KXCO-PQ-Kid: 1623999978e28714
X-KXCO-PQ-Alg: ML-DSA-65
X-KXCO-PQ-Digest: sha256=0c2f435088947d19136e2532e3dab3e566460af6ee8f228e...

Four headers carry everything a verifier needs: the signature, which key made it, the algorithm, and the digest that was signed. Nothing about the message is hidden from the recipient, and nothing extra about the message is revealed to anyone else.

03Why ML-DSA-65 and not RSA

ML-DSA-65 is the NIST-standardised module-lattice signature scheme from FIPS 204, at Category-3 parameters. It is the same primitive KXCO uses to sign documents, issue institution credentials and attest CRM events, which means email is now inside the same trust model as everything else rather than beside it. Signatures are larger than RSA. For an email header that is an irrelevant cost, and it buys a signature that does not become worthless the day a cryptographically relevant quantum computer exists.

Mail has its own dedicated signing identity, key 1623999978e28714, generated for this purpose alone. Its private key lives only on the mail server and was deliberately not copied from the document-signing platform, so the two systems cannot impersonate one another and a compromise of either does not spread. Every signing system on the KXCO estate gets its own key and its own published identity, which is what makes a signature attributable to a system rather than merely to the company.

04A record that outlives the conversation

Signing proves who sent a message and that it has not been altered. It does not, on its own, prove when it existed, and it does not survive the sender quietly reissuing history. So the SHA-256 of every message is also written to Armature L1 under the purpose kxco-mail-attestation.

Only the hash goes on-chain. No subject line, no recipients, no body, no metadata about who was talking to whom. A hash is a one-way commitment: it proves a specific message existed at a specific block without disclosing anything about it. Hold the original and you can demonstrate the match to anyone. Hold only the chain record and you learn nothing at all.

// a real anchored message, verifiable on the public explorer
purpose  kxco-mail-attestation
tx       0xe750594413bee508d05dd8932866e77330ac650dc591902d173785053ddfc37e
block    2780590

The mail server holds no wallet, no chain private key and no balance. It signs an ML-DSA-65 intent and posts it to the KXCO relay, which validates the post-quantum signature and submits the transaction itself. The mail platform gets a permanent public record without ever becoming a piece of financial infrastructure, and gas handling stays entirely out of the mail path.

05Verifying it without asking us

A proof that only its issuer can check is not a proof. The public keys are published at a stable, conventional location, the same convention KXCO uses across its other origins, so verification requires no account, no API key and no conversation with us.

# the signing keys, fetchable by anyone
curl https://mail.kxco.ai/.well-known/pq-keys

# then: read the kid from the header, select that key,
# sha256 the message as delivered, verify the signature
npm i kxco-post-quantum   # or kxco-verify, browser-safe, zero deps on us

That endpoint currently publishes three keys: the KXCO platform identity, the Meridian signing platform, and now the mail platform. Superseded keys stay listed permanently, because retiring a key must never invalidate the signatures it already made. A recipient checking a message from four years ago should not care that we have rotated since.

06Internal mail never leaves the building

One property of KXCO-to-KXCO mail is worth stating precisely, because it is stronger than the usual assurance. When a KXCO mailbox writes to another KXCO mailbox, the message is handed from the mail transfer agent to the delivery agent over a local Unix socket and written straight to the recipient's store. It never touches a network interface. There is no server-to-server hop, so there is no leg across the public internet to intercept, and no third-party relay that has to be trusted to behave.

# from the delivery log of an internal message: a socket, not a network
relay=mail.kxco.ai[/var/run/dovecot/lmtp]

Combined with the signature and the anchor, an internal KXCO message is authenticated at origin, provably unaltered, timestamped on a public chain, and never exposed to a network in transit.

07The connection itself, now post-quantum

Signatures and anchors answer authenticity: who sent this, and has it changed. Confidentiality is a separate problem living one layer down, in the session between a browser and the server. Every webmail session on mail.kxco.ai now negotiates X25519MLKEM768, a hybrid of classical X25519 and ML-KEM-768 from FIPS 203.

The hybrid construction is the part worth understanding. The session secret is derived from both halves at once, so the result is never weaker than X25519 on its own even if the lattice half were later found wanting, while a recording captured today cannot be unlocked by a quantum computer that arrives in a decade. Traffic is being collected now and stored against the day it can be broken, which is precisely why this is worth doing before it becomes fashionable rather than after.

Getting there was not a version bump. The host's OpenSSL is 3.0, which offers no ML-KEM group at all, and native support does not appear until 3.5. Rather than hand-build a bespoke cryptographic library underneath a production mail server, we moved TLS termination to Caddy, whose Go TLS stack offers the hybrid group by default. The blocker was sidestepped instead of climbed, and the mail server itself was never touched.

# anyone can confirm this, with an OpenSSL 3.5 or newer client
openssl s_client -connect mail.kxco.ai:443 -groups X25519MLKEM768

# Negotiated TLS1.3 group: X25519MLKEM768

Clients that do not know the hybrid group are unaffected and still negotiate X25519 as before, so nothing was traded away to gain this. Same certificate, same mailboxes, a stronger key exchange for everyone whose browser can use it, which today is every current mainstream browser.

08Cryptography that never stops the mail

A proof system that can take down email is a proof system that gets switched off within a week. The architecture reflects that, and this is the part we would point a reviewer at first.

Signing happens inline because it is local and fast. Anchoring is asynchronous. A send enqueues the message hash and returns immediately; a sweep settles it on-chain shortly afterwards. The queue is idempotent per message hash, so a retry can never double-anchor, and failures carry an attempt counter and the recorded error, with a cap so a permanently broken item is visible rather than retried forever.

The consequence is the property that matters operationally: if the chain, the relay or the network is unavailable, proofs are delayed and mail is not. The same discipline governs signing, which fails open and logs rather than blocking delivery. Nobody's message is held hostage to cryptographic bookkeeping.

09What is different about this

Individually these are known techniques. The combination, running on ordinary company email rather than in a demo, is what we have not seen elsewhere.

  • Post-quantum, not classical. ML-DSA-65 under FIPS 204, so a signature made today is still meaningful after classical signatures stop being.
  • Signed by the platform, not the person. Nothing to install, no keyring, no training. Coverage is total because it does not depend on anyone remembering.
  • Verifiable by anyone, indefinitely. Keys are published at a conventional path, superseded keys are retained, and the proof does not expire at the recipient's mail server.
  • Timestamped on a public chain, content-free. Existence and ordering are provable from the chain while the chain itself carries nothing but a hash.
  • One key per system. Mail has its own identity, distinct from document signing, so signatures attribute to a specific system and compromise does not propagate.
  • No wallet in the mail path. Anchoring goes through a relay against a signed intent, so the mail server never holds keys to anything of value.
  • Internal mail with no network hop at all. KXCO to KXCO is delivered over a local socket, verified in the logs rather than assumed from the topology.
  • Post-quantum on the wire as well as in the record. Webmail sessions negotiate a hybrid X25519 and ML-KEM-768 key exchange, so the content is protected in transit by the same generation of cryptography that signs it.
  • Fails open by design. Cryptography that cannot interrupt delivery is cryptography that survives contact with a real business.

The wider point is the one KXCO keeps arriving at from different directions. Trust should not be a claim in a datasheet; it should be a thing the other party can check. We applied that to our cryptography libraries, to documents, to credentials, and now to the most ordinary and most used channel we have. An email from KXCO is no longer something you have to take on faith.

Signing keys: mail.kxco.ai/.well-known/pq-keys · verification libraries: kxco-post-quantum, kxco-verify · anchored records: chain.kxco.ai. KXCO is a software company; regulated services are operated by licensed institutions. Cryptographic posture reflects NIST FIPS 203/204/205 alignment at Category-3 parameters; KXCO does not claim CNSA 2.0.