Don’t trust us. Check the math.

Unlike Mail is a client for the mailbox you already own. On the web, your browser talks to our Rust server and our server talks to Google, Microsoft or Zoho on your behalf — a courier, and we designed the job so the courier carries the safe but never holds a key to it. The native apps go further and skip the courier: they talk to your provider directly (§ 07). Either way, everything we persist is ciphertext sealed under keys that only exist on your devices.

A mailbox reached over IMAP — Fastmail, iCloud, your company’s server, your own — takes the direct path and only the direct path. That connection is authenticated with a permanent full-mailbox password rather than a revocable token, so it belongs on your machine and nowhere else: the desktop app opens the socket itself, and our server never learns the host, the port, the password, or a single byte of the mail. It is the one provider arm the courier is not allowed to touch, which is also why it is desktop-only.

Security claims get slippery when they blur what, exactly, is being protected. We protect two distinct things, with two distinct mechanisms:

• The credential that can read your mailbox. To act as your client we hold an OAuth token for your provider — long-lived, full-mailbox scope. It is the crown jewel, and Part I is how we store it so that even we can’t use it without you.
• The mail itself. Messages between Unlike Mail users are sealed end-to-end with post-quantum cryptography — Part II. Mail you exchange with people not on Unlike Mail is ordinary email, and we say so out loud (see what we can’t protect).

Every key that matters is derived or unwrapped on your device, and wraps the next key down. The server participates in exactly one way: it stores blobs it cannot read.

The KEK (key-encryption key) is derived from your passphrase with Argon2id — deterministic given the stored salt, so the same passphrase yields the same KEK on any device, and no key ever needs to be transferred between devices. The KEK wraps a random DEK (data-encryption key), which seals what we store. Each of your devices additionally wraps the KEK under its passkey’s PRF output, so day-to-day unlocking is one biometric gesture — no secret typed, nothing to keylog.

Who holds what

The guarantee ladder

“Encrypted” is doing a lot of work in most marketing. Here’s the actual ladder, and where we sit on it:

Inside the browser: one room holds the keys

Encrypting at rest isn’t enough if page scripts can read your keys while you’re unlocked. All key material lives in a dedicated crypto worker — a separate JavaScript realm the page can’t reach into — holding non-extractable WebCrypto keys. The app window can ask it to unlock or seal; it can never read the keys, and secrets travel only to our same-origin server.

The model is the one that made PGP legendary — every user has a keypair; you seal to the recipient’s public key; only their private key opens it. We kept the idea and replaced the math: ML-KEM-1024, the NIST-standardized post-quantum key-encapsulation mechanism (FIPS 203), hybridized with AES-256-GCM for the payload.

• At account creation, your device mints a unique ML-KEM keypair.
• Your public key goes into the server-side key registry — that’s what a public key is for.
• Your private key is wrapped under your KEK and only ever unwrapped on your devices. The registry holds locks, never keys.

To your provider, a sealed message is an ordinary email whose contents happen to be noise. They transport it, store it, and learn nothing. Decapsulation happens on the recipient’s device — the shared secret is never on the wire and never on our server.

Why post-quantum, today

Encrypted traffic is being recorded now to be broken later — the “harvest now, decrypt later” problem. Classical key exchange will not survive a cryptographically relevant quantum computer; lattice-based ML-KEM is built to. Sealing with it today means the mail you send this year isn’t next decade’s breach. We’d rather future-proof now than apologize later.

Day-to-day, Unlike Mail unlocks with a passkey — your fingerprint, face, or security key, evaluated by hardware. The passkey’s PRF output unwraps your KEK; the KEK unwraps everything else. You type no secret, so there is no secret to phish, keylog, or reuse from a leaked password dump.

Enrolling a new device

• With your passphrase — enter it once; the new device derives the same KEK (same salt, same Argon2id), registers its own passkey, and never asks again.
• With a device you already trust — scan an authorization QR / code from any enrolled device and the credential is shared to the new one. No secret typed anywhere, trust flows hardware-to-hardware.

Every dependency pinned. Builds signed. The crypto core is Rust compiled to WebAssembly because we trust the browser’s sandbox, not a package registry’s supply chain. When you build a vault, you don’t use cardboard.

• Native everywhere (L4). Android and Windows already run the native model — keys in the OS keystore, direct provider calls, near-zero server dependency. iOS, macOS, and Linux join them next; on this path the web residuals above simply don’t exist, and the server shrinks toward a content-free relay: nothing to seize, nothing to subpoena.
• Origin hardening. Device-bound request signing, strict CSP and Trusted Types — shrinking the already-narrow live-tab residual.
• Provider reach (largely done). Google, Microsoft 365 and Zoho all sign in directly; the IMAP arm covers the long tail from the desktop app. What’s left is bringing IMAP setup to Android and running a compatibility pass across more hosted providers.
• Decentralized identity, eventually. Your keys, your address, no registry — not even ours.

Questions this page didn’t answer live in the FAQ, and the promises it makes are restated formally on Compliance & Trust.