Zero-knowledge email: what it means and how it works
Zero-knowledge email means the provider never holds your key, so it literally cannot read your mail. How zero-knowledge encryption differs from encryption at rest.
Dvir Atias
Founder
Zero-knowledge email is email where the provider has zero knowledge of your message contents because it never holds the key that could decrypt them. In a zero-knowledge model, the private key is generated on your own machine and stays there. The server stores and relays ciphertext only, so neither the provider nor its cloud host can turn that ciphertext back into readable mail. This is a stronger promise than "we encrypt your data," because the party making the promise has removed its own ability to break it.
The rest of this guide explains what zero-knowledge means for email, how it differs from encryption at rest and from TLS in transit, the honest tradeoffs of holding your own key, and how AgenticEmail implements a zero-knowledge model in practice.
What zero-knowledge means for email
The word "zero-knowledge" here is used in the practical sense the storage and messaging industry uses it: the service provider has no knowledge of your plaintext because it never possesses the decryption key. It is not the formal zero-knowledge proof from cryptography theory, though both share the idea of delivering something without revealing the underlying secret.
For email, that means the flow is inverted from a normal provider. Instead of your message arriving at the server as plaintext and getting encrypted there under a key the server manages, the message is encrypted before it ever leaves the client, and the key that would decrypt it is generated locally and never transmitted. The server's job is reduced to holding and forwarding an opaque blob. If someone subpoenas the provider, compromises the database, or the cloud host inspects the disk, all they get is ciphertext with no matching key anywhere in the provider's control.
This is exactly the property that makes zero-knowledge different from the encryption most email services advertise. Understanding that difference is where most confusion lives.
Zero-knowledge vs encryption at rest vs TLS in transit
People conflate these three because vendors use "encrypted" for all of them. They protect against different threats, and only one removes the provider from the trust equation.
| Layer | Who holds the key | Protects against | Provider can read it? |
|---|---|---|---|
| TLS in transit | Negotiated per connection | Network eavesdroppers between hops | Yes, at each endpoint |
| Encryption at rest | The provider | Someone stealing the raw disks | Yes, the provider decrypts on demand |
| Zero-knowledge | You, on your own machine | The provider itself, its host, a subpoena | No |
TLS in transit encrypts the connection while a message moves between mail servers. It is essential and nearly universal, but it only protects data on the wire. Once the message lands, it is decrypted and sits as plaintext.
Encryption at rest means the stored data is encrypted on disk, but the provider holds the keys and decrypts whenever it needs to serve, search, or scan your mail. It defends against a stolen hard drive. It does nothing against the provider itself, a rogue employee, a legal order, or a breach that reaches the live system with its keys.
Zero-knowledge encryption is the only one of the three where the provider cannot read your content, because it never had the key. Encryption at rest asks you to trust that the provider guards its keys well. Zero-knowledge asks you to trust nothing, because there is no key to guard on the provider's side. That is the whole point, and it is why the two should never be described with the same word.
For a wider treatment of the client-to-client model this sits inside, see end-to-end encrypted email.
The honest tradeoffs of holding your own key
Zero-knowledge is not free. Moving the key to your side moves the responsibility there too, and there are real costs worth stating plainly before you opt in.
- You own key custody. The private key lives on your machine or in your own secret store. That is the source of the guarantee and also the thing you now have to protect and back up.
- Lose the key, lose the mail. There is no provider-side reset. If the private key is gone, the ciphertext it protected is unrecoverable, by design. A provider that could recover it for you would, by definition, not be zero-knowledge.
- No server-side features on encrypted messages. Anything that needs plaintext cannot run on the server. Full-text search over encrypted bodies, AI auto-replies, and attachment parsing all stop working on messages the server can only see as ciphertext. You can still do these things on your own machine after decrypting, but the server will not do them for you.
These are not bugs to be patched later. They are the direct consequence of the server not holding your key. The right way to think about it is a deliberate trade: you give up convenience features that require plaintext in exchange for a provider that is mathematically unable to read the content.
How AgenticEmail's zero-knowledge model works
AgenticEmail is API-first email infrastructure for AI agents. Its end-to-end encryption is opt-in and agent-to-agent, meaning it applies only between two AgenticEmail inboxes that have each published a key. Plaintext is the default, and you cannot end-to-end encrypt to an external Gmail or Outlook address, because those inboxes have no published key in the system. Within that scope, the model is genuinely zero-knowledge. Here is the flow.
- Client-side key generation. When you enable encryption for an inbox, the SDK or CLI generates the keypair on your own machine. The private key is written to your local key store and never sent to AgenticEmail's servers.
- Public key published for discovery. Only the public key is uploaded, where it acts as the discovery record other agents look up to encrypt mail to you. Publishing a public key reveals nothing about your messages.
- Sender encrypts to your public key. A sending agent fetches your published public key and encrypts the message locally before transmitting. AgenticEmail uses JOSE: JWE with ECDH-ES over P-256 and AES-256-GCM for the content, with an Ed25519 JWS signature so the message is signed then encrypted.
- Server sees only ciphertext. The encrypted blob is stored and relayed as-is. The server has no private key for the recipient, so it cannot decrypt, index, or scan the body.
- Sender verified against the published key. On receipt, your client checks the JWS signature against the sender's published public key, so you know the message came from the agent it claims to and was not altered.
Because the private key never reaches the server, AgenticEmail and its cloud provider are both outside the trust boundary for encrypted content. That is the zero-knowledge guarantee, delivered for the agent-to-agent case it is designed for.
To send your first encrypted message this way, follow how to send encrypted email. If you are coming from PGP, PGP encryption and a modern alternative covers why the JOSE stack is easier to automate. And for the agent-specific context, see encrypted email for AI agents.
Frequently asked questions
Is all AgenticEmail mail zero-knowledge encrypted?
No. Encryption is opt-in and works agent-to-agent, only between two AgenticEmail inboxes that have published keys. The default is plaintext, and you cannot end-to-end encrypt to external providers like Gmail or Outlook.
Can AgenticEmail read my encrypted messages?
No. For opted-in encrypted mail, the private key is generated and kept on your machine and never reaches the servers. AgenticEmail stores and relays ciphertext only, so it cannot decrypt the content.
What happens if I lose my private key?
You lose access to any mail encrypted to that key. There is no provider-side recovery, because a recoverable key would mean the provider held a copy, which would break the zero-knowledge guarantee. Back up your key like any other critical secret.
Why can't I search or run AI on encrypted messages?
Those features need plaintext, and the server only ever sees ciphertext for encrypted mail. Search over bodies, AI auto-replies, and attachment parsing run on the server, so they work on plaintext messages but not on end-to-end encrypted ones by design.
Ready to try it? Grab a key from the dashboard and read the docs to generate a keypair and send your first zero-knowledge message.