Skip to the documentation
Knowledge base

Encryption at rest

Every field of a message sealed before it is written down (body, subject, addresses and attachment bytes), so a copy of the database is ciphertext rather than mail.

Not yet

Only the credentials you hand us are sealed this way today; bodies, subjects and attachments are stored as they arrived, and the envelope that will seal them is built but deliberately wired to nothing.

Details

  • Not shipped. One thing is sealed before it is written down and nothing else is: a webhook signing secret. It is sealed under its own derived key so a ciphertext lifted out of one table cannot be opened as another, and that is the only place in the codebase where anything is sealed at all. No body, subject, contact, note, calendar entry or attachment passes through it.
  • It is a different claim from the two around it, and the difference is who holds the key. End-to-end encryption means the key is yours and the mail is unreadable here; encryption at rest means the mail is sealed on the way into storage under a key this server derives, so a dump of the database, a backup that goes astray or a query somebody should not have run is ciphertext, while the server itself can still open it to thread, search and summarise. The first protects you from us. The second protects you from everybody else, and that is the one that keeps happening to other people.
  • What is true today is worth saying plainly rather than leaving to be inferred: mail is stored on infrastructure that encrypts its own disks, no layer of our own sits on top of that, and we hold the keys, so the server can read what it stores, and the features that search and summarise your mail do exactly that. The privacy page has said so in those words since it was written, and it goes on saying so until this ships.
  • Every field means more than the body. The subject, the sender and recipient list and the snippet the list view renders sit in ordinary indexed columns, and so do the summaries generated from a message, the notes you attach to a thread, contact names, calendar titles and locations, and the name and type of every file. A card that said encrypted while the subject line stayed in the clear would be the padlock this product refuses to draw anywhere else.
  • What it costs was the open question, and the search half of it now has a number against it rather than an argument. Search today is a query over the first 4,000 characters of each thread’s newest message, held as plain text. Sealed, it becomes a decrypt and a scan inside the mailbox store that already holds the key, taken in chunks rather than a row at a time: on a synthetic corpus that is around 100 to 400 milliseconds across 50,000 conversations, and past about 200,000 it needs results that arrive progressively instead of all at once. That was measured on a development machine against generated mail, not on a live mailbox, so it is the shape of the cost rather than a promise about yours. So matching on any fragment of a word survives exactly as it does now, and nothing has to write an index of word hashes to disk for somebody to lift later. The same text is what the summariser, the phishing scorer’s body pass, the AI-writing check and any rule matching on words all read, and each of them opens it the same way, which is the honest shape of this claim: sealed against a copy of the database, never sealed against the server.
  • Before anything irreplaceable is sealed, the envelope has to carry its own version and its own key id. Every derived key hangs off one secret today, and rotating it costs you the webhook signing secrets; once bodies were sealed the same way, rotating it would cost the mail. That piece is built, and nothing has been sealed with it. Every envelope it makes carries its own version and the id of the key that made it, readable before anybody tries to open it, and binds itself to the exact row it belongs to: a value lifted out of one row and dropped into another does not open, and it says it was moved rather than failing like a bad key. Nothing calls it yet, and that is the point of building it first. The format is the commitment; adopting it, one field at a time, is the part that stays reversible.
  • One sentence decides what gets sealed, so that it can be applied to a column nobody has thought of yet: seal anything a person wrote or chose, leave anything the machine chose. A subject, a body, a thread note, a contact name, a calendar title, a filename, a rule you typed: those came from you. A message id, a queue state, a retry count, a row id: those were generated here, and sealing them buys nothing while costing every query that reads them. Two carve-outs sit on top of it. A value that is already irreversible, a hash or a token digest, is not made safer by being sealed as well. A value published on purpose stays readable, because sealing it would seal the one thing it exists to hand out.
  • Three things stay readable under that rule, and each is something the mailbox is built on rather than a corner left undone. Timestamps, because they are the sort key and the pagination cursor, and a mailbox that cannot order by date is not a mailbox. Your domain, because the query that reads it is how an inbound message finds the tenant it belongs to, before anyone is signed in and before any key is in hand. Published keys, because a sender looks yours up. Each of those says something about the shape of an account, and none of them is the content of your mail.
  • Sealing under a key the server derives is the first rung and the one being built. The second, sealing to your key as mail arrives so that no key here opens it, is a larger change and a different product: the body leaves search and the AI features permanently, and key custody and a recovery phrase move between you and your own mail. That is a choice to make deliberately rather than a switch to flip, and this card will say which one shipped rather than blurring the two.