Most providers mean disk encryption, where the operator holds the key. Ours means your stored mail is encrypted with your own OpenPGP or S/MIME key, so there is nothing to hand over but ciphertext. The three costs, stated plainly, including the one that trades away search.
"We cannot read your mail" is a claim almost every provider makes and almost none of them can back. Usually it means the disks are encrypted, which protects you from someone stealing a disk out of a datacentre, and protects you from precisely nothing else. The operator holds the key. The operator can read the mail. The claim is technically true and practically empty.
Encryption at rest at email.eu means something narrower and much stronger: your stored mail is encrypted with a key we do not have. Not a key we promise not to use. A key that only exists on your side.
This post is how it works, what it costs you, and the honest boundary of what it protects.
You paste in a public key. Either an OpenPGP public key or an S/MIME certificate, whichever your world already uses. From that moment, every message that arrives in your mailbox is encrypted with it before it is stored.
The private half never leaves your possession. You do not upload it, we never ask for it, and there is no field for it anywhere in our system. Which means the messages sitting on our servers are unreadable to us, to anyone who compromises us, and to anyone who serves us a legal order. There is nothing to hand over except ciphertext.
Your mail client, holding the private key, decrypts messages when you read them. This is the same OpenPGP and S/MIME machinery that has existed for decades, applied to storage rather than to transport.
You turn it on yourself, from your own account page. No admin approval, no support ticket, no configuration call with us.
This is not end-to-end encryption, and calling it that would be dishonest.
Mail arrives from the outside world over an encrypted connection, and at the moment it arrives it is readable, because that is what the sender sent. We encrypt it on delivery, as it is written to storage. So there is a moment, in memory, in transit through our servers, where the message is plaintext.
What that means in practice: this protects your mail history, which is where almost all the risk lives. Years of correspondence sitting on a server is a far larger target than any individual message in flight. It does not protect a single message from someone who has fully compromised the mail server at the exact moment it arrives.
If you need true end to end, that is OpenPGP or S/MIME between you and your correspondent, which any standard client can do and which works fine on top of this. Different problem, different tool.
| Threat | Protected |
|---|---|
| Someone obtains a copy of the stored mailbox | Yes, it is ciphertext without your key |
| A legal order served on us for your mail history | Yes, we can only hand over ciphertext |
| An operator or intruder reading years of stored correspondence | Yes |
| An intruder inside the mail server at the moment a message arrives | No, it is plaintext for that instant |
| The sender's own copy, or the recipient's | No, that is between you and them |
Every real security feature has costs. Here are ours, and you should decide with them in front of you.
If you lose the private key, that mail is gone. Not gone in the sense that support can restore it. Gone in the mathematical sense. We hold ciphertext and no key, which is exactly the property you asked for, and it cuts both ways. Back up your key somewhere serious before you turn this on.
It only applies from the moment you enable it. Mail that already arrived stays as it was. There is no retroactive pass, because performing one would mean us reading your entire history in order to encrypt it, which is the thing we are trying to make impossible. So turn it on early if you want it.
Search stops reaching inside your messages. A server that cannot read your mail cannot index it, so with encryption on, only the headers of a message go into the search index. In practice that means searching by sender, recipient, subject and date keeps working exactly as before, and searching for a word you remember from the body of a message does not. Some clients keep their own local index of what they have decrypted, which softens it further, but you should expect search to reach less far than it did.
For a lot of people that is a smaller loss than it sounds, because most searching is "that thread with Anna about the contract" rather than a phrase from deep inside a message. For anyone who genuinely searches by body text, it is the reason to leave this off.
That last one is the reason this is off by default rather than on. It is the right choice for people handling material where confidentiality outweighs convenience, and the wrong choice for a lot of ordinary teams. We would rather you chose it deliberately.
There is a real tension here and we made a real decision about it.
Spam filtering works by learning from the mail you receive. Encrypt everything on arrival and the filter goes blind, and your spam filtering gets worse over time in a way that is slow enough that you will blame something else.
So when you enable encryption there is a checkbox, on by default, that lets the spam filter learn from a message before it is encrypted. The plaintext is used in that moment and never stored. Turn it off and nothing readable is ever touched, at the cost of filtering that degrades.
We could have hidden this decision, defaulted it either way, and said nothing. It is exactly the kind of detail that a security page glosses over. It is also exactly the kind of detail that determines whether the promise is real, so it is a visible checkbox with an explanation next to it.
Encryption at rest is part of the Business plan, alongside single sign-on for your own applications and the audit trail.
One deliberate exception worth knowing. The plan controls whether you can turn it on. It does not control whether it stays on. If you enable it on Business and later move down a plan, your mailbox keeps its encryption, and you can always turn it off yourself. A billing change should never silently convert an encrypted mailbox back to plaintext without the owner deciding that. That would be a security downgrade delivered by an invoice, and no one would notice until it mattered.
If you are evaluating this for a regulated environment and want to go through the specifics before committing, talk to us. We would rather walk through the real behaviour, costs included, than hand you a feature list.