Skip to content
Sortmailsortmail
Help · Privacy & security

Zero body retention, explained

Updated 28 September 2026 · 3 min read

"We do not store your email" is a claim every mail tool makes. Here is what it means here, precisely enough to check.

The lifecycle of one message

A message arrives. We fetch it. It exists as an object in a worker process’s memory. We compute a fingerprint from it. We decide a category — from a rule, from header signals such as a mailing-list header, or by sending a truncated extract to a model. We write a label to your mailbox. We write the fingerprint to our database. The worker discards the message object. Nothing that contained the body is ever written to disk.

When you open a message in Sortmail, the worker fetches it again from your mailbox, passes it to your browser, and discards it. It is not stored on the way.

What "fingerprint" means

Sender, sender domain, list id, an HMAC of the normalised subject, and a set of booleans. The HMAC is keyed with one secret that Sortmail holds outside the database, the same for every account. It is one-way — it cannot be turned back into the subject — and without that key nobody can even test a guess against it.

How it is enforced

  • The schema has no body, snippet, attachment or raw-subject column, and a test fails the build if one appears.
  • Queue payloads are schema-checked with unknown fields rejected, so a body cannot ride along in a job.
  • The logger writes only allowlisted fields, so a body cannot reach a log even in an error path.
  • A test plants a canary string in a message body and asserts it appears nowhere in the stored row, the logs, the queue payload or an error’s stack trace.

The one exception, stated plainly

Sorting by model is on by default, shown as a ticked box when you choose your categories while connecting, and switchable per mailbox in Settings. Turn it off and only headers are fetched: your rules (except Body contains) and header signals still sort, and anything they cannot place goes to System.

When a rule cannot decide and header signals cannot either, a truncated extract — the sender's address, the subject, and at most the first 400 characters, with obvious card numbers and one-time codes masked — goes to our model provider, or to our backup provider if the first is down. Both are contractually barred from retaining it or training on it. That, and showing a message to you when you open it, are the only times any part of your mail leaves our memory, and both are disclosed in the sub-processor list.