What we protect — and what we can't.
Most email sites don't have a page like this. Ours does, because the honest version is the selling point. Here is exactly what is encrypted, what isn't, and what a server compromise would and wouldn't expose. No superlatives. No hand-waving.
Three different guarantees. Stated separately, on purpose.
"End-to-end encrypted" means different things depending on where mail goes. Collapsing them into one claim is how other providers overstate. We keep them distinct.
End-to-end encrypted
Zero-access at rest
Encrypted when possible
Your keys live in a signed directory. When you encrypt to another account, you fetch its public key from a directory we sign — so a casual swap can't go unnoticed. A fully verifiable transparency log, where you wouldn't have to trust us at all, is not yet built. It's marked below.
If a Thelemail server were compromised.
The test of a security model isn't the happy path — it's what an attacker gets when things go wrong. Here's the honest accounting.
What stays safe
Even with full access to our servers, the things that matter most to you remain unreadable.
- The contents of your stored mailbox
- Mail exchanged between Thelemail accounts
- Your password and the keys derived from it
What's visible no matter what
Some things are inherent to how email works. We'd rather tell you than let you assume otherwise.
- Envelope metadata — sender, recipient, timestamps
- Plaintext mail after it leaves for an outside server
- Subjects of external mail without a published key
One consequence worth stating plainly. Because your stored mail is encrypted with a key derived from your password, losing your password and your recovery method means even we cannot restore your mailbox. That is the zero-access guarantee working as intended.
What we haven't built yet.
A page that only listed strengths would be marketing. These are real limitations, named plainly, marked coming until they're real.
Public client source
Our apps aren't open source yet. We're cleaning up the code before we publish it, because “open” should mean readable, not announced. The server will remain closed and there is no self-hosted option — the published client is how you check what we encrypt, not how you run your own.
Independent third-party audit
We have not commissioned an external security audit, and we won't imply one until the report exists and we can link to it. When our client code is public, independent researchers will be able to review it directly — and we'll point to their findings, good or bad.
Key transparency log
We sign the key directory today. A tamper-evident, publicly verifiable log — so you wouldn't have to trust us not to swap a key — is designed but not deployed.
Metadata minimization
Envelope metadata is visible by design. Techniques to reduce what we can see are research-stage here, not shipped.
Formal compliance certifications
We run in the EU and say so. We don't hold SOC 2 / ISO certifications yet, so we don't claim them.
The rule we hold ourselves to: every claim on this site maps to a mechanism that exists. If it's aspirational, it's phrased as intent and marked coming — never stated as accomplished fact.
Verifiable, not just claimed.
Every promise on this site maps to a mechanism that exists. The threat model spells out exactly what's encrypted, what isn't, and what a server compromise would and wouldn't expose — in plain words.