There's a lot of marketing around email encryption that doesn't match reality, and most of it is from companies that should know better. Here's a plain-language walk through how Mailcedar actually handles the cryptography, what email's underlying protocols make impossible, and what we'd ask other providers to be honest about.
What email looks like under the hood
SMTP — the protocol that delivers a message from one server to another — was designed in 1982. It's gone through some upgrades but the core shape is the same. When you send a message from jordan@mailcedar.com to aaron@gmail.com:
- Your client (webmail or Apple Mail or whatever) sends the message to our SMTP server over TLS 1.3.
- Our SMTP server looks up the MX records for
gmail.com. - It opens a connection to Google's mail server, ideally with TLS, and hands the message over.
- Google stores the message in its own systems.
- Aaron's client fetches it from Google over TLS.
The crucial thing: during step 4, the message exists in Google's systems unencrypted at the protocol level. They can encrypt it at rest with their own keys, but the keys are theirs and they can decrypt it whenever they want. This is just how email works.
This is why claims like "we encrypt every email end to end" from a single mail provider are usually exaggerated. The provider can only control what happens on their own servers. The recipient's servers are an entirely separate thing.
What we actually do
Mailbox storage
Every message in your Mailcedar account is encrypted at rest with AES-256-GCM. The data-encryption key is wrapped by a key-encryption key, which is itself derived from your password using Argon2id with parameters chosen to take about a second on a phone.
We don't store your password anywhere. We store the Argon2id hash, and the wrapped key, and a salt. When you sign in, your client (or our server, in the webmail case) does the Argon2 derivation, unwraps the key, and uses it to decrypt your mail.
What this means in practice: if someone broke into our data centre and walked off with a hard drive, they would have a pile of encrypted blobs. Without your password, those blobs are noise. Without you, no one — including us — can decrypt them.
Mail in transit between Mailcedar accounts
If both ends of a conversation are on Mailcedar, the situation is much nicer. We can keep the message encrypted on both mailboxes' storage with their respective keys, and the routing only happens internally. There's no third party to leak metadata to.
This is the most "private" your email gets without going to OpenPGP. It's not end-to-end encrypted in the strict cryptographic sense — we still handle the routing — but it doesn't leave our infrastructure in plaintext, and neither mailbox can be read without its owner's password.
OpenPGP for mail to other providers
For mail that has to leave our network — to Gmail, Outlook, your bank, your dentist — OpenPGP is the only way to get true end-to-end encryption. You generate a keypair, you publish your public key (we make this easy via Web Key Directory), and people who care can use it to encrypt mail to you that even we can't read.
The catch: most people don't care, and won't. PGP after 30 years still has terrible UX, and we won't pretend otherwise. It's there if you need it. We don't push it on anyone.
What we can see
Here's the part that mail providers tend to gloss over. Even with everything above, there's a list of things we can see if we want to, or if we're compelled to:
- Account existence. We know that
jordan.lee@mailcedar.comis a Mailcedar account. - Sign-in metadata. When you sign in, from which IP, in which approximate location. We delete this after 7 days.
- Mail in flight to/from non-Mailcedar accounts. The envelope (sender, recipient, timestamp, size) is visible to us during routing. The subject and body are usually visible too, because the other end requires it. Once delivered to your mailbox, it's encrypted with your key, but the brief moment of routing is not opaque to us.
- Backups. Encrypted blobs of your mailbox exist on backup tapes for 60 days. Same encryption story — useless without your password.
We don't log message contents. We don't index anything cross-customer. We don't have an analytics pipeline that aggregates mail data. But the architectural truth is that during routing, there's a window where the mail is technically in our memory in plaintext.
What we'd ask others to be honest about
If you read a competing mail service's marketing and see phrases like "your email is encrypted end-to-end," ask three questions:
- Encrypted between whom and whom?
- If the recipient is on a different provider, how is that physically possible?
- Who holds the decryption keys, and when can they be compelled to use them?
The honest answer for any provider that doesn't require PGP is some variation of "we encrypt within our walls, and the other end is on its own." That's fine. It's the same answer we just gave. It's only a problem when it's dressed up to look like something stronger.
What we're working on
We're shipping native Web Key Directory in Q3 — publishing PGP keys at https://openpgpkey.mailcedar.com/.well-known/openpgpkey/... automatically when you upload a key. We're also looking at making PGP encryption / decryption happen client-side in the webmail so that even the brief routing window doesn't see plaintext for users who opt in. That second one is months out and may not ship at all if we can't make the UX better than current implementations.
Comments, corrections, and "you're wrong about this and here's why" are very welcome at hello@mailcedar.com.