Security
Last updated: 19 September 2026
This page states what Cloakmail encrypts, what it does not, where keys live, and where the data sits. It is meant to be falsifiable against the privacy notice and the running software, not a slogan.
Envelope encryption (AES-256-GCM)
Stored message bodies and attachments are envelope-encrypted before they are written to MinIO object storage. Each payload gets a fresh 256-bit data key (DEK) and a 96-bit IV. The DEK is wrapped with AES-256-GCM under a key-encryption key (KEK). Authenticated associated data binds ciphertext to a field context and key version so rows cannot be swapped.
The KEK is injected from the environment (APP_ENCRYPTION_ROOT_KEY). It is not in git. Previous KEKs can be loaded as decryption-only keys during rotation. API and worker refuse to start without the active root key.
What is not encrypted
This is not end-to-end encryption. Cloakmail decrypts mail when you open it in the product, and when it forwards to a destination you verified. Envelope metadata required to deliver, list, and filter spam is processed: sender, subject timing, size, attachment count, and a spam verdict are not the encrypted payload.
If a threat model needs a sealed mailbox whose keys never leave your device, this is the wrong product.
Tracking and remote images
HTML mail can contain tracking pixels. Remote images stay blocked unless you allow them. That setting is on by default.
Passwords, sessions, recovery secrets
Account passwords are stored as Argon2id verifiers. Session tokens are stored hashed. A Glint recovery secret is shown once; Cloakmail stores a verifier, not the secret in plaintext. Anyone who has the secret can reopen that mailbox until it expires.
Where it runs
The application, PostgreSQL, Redis, MinIO, and mail intake run on the operator’s own infrastructure in the European Union. Premium billing uses Stripe as a processor. The named controller is Nordiqo Einzelunternehmen, Delmenhorst — see the Imprint.