Trust

How Warmbly protects your mailboxes and your data.

We hold mailbox credentials, messages and contact lists. This page describes how they are encrypted, who can reach them, and how to tell us if you find a problem.

Report a vulnerability Audit the code

At a glance

  • Open source and auditableThe backend, workers and dashboard are public.In place
  • TLS 1.2 or later in transitEvery connection is encrypted on the way.In place
  • Encryption at restA data key per workspace, AES-256-GCM.In place
  • GDPR-aligned handlingPlain-English privacy policy, data processing terms on request.In place
  • SOC 2 Type IIControls in place. The audit window opens with our auditor.Planned
  • ISO 27001Under evaluation. No certification claimed today.Planned

Encryption

Warmbly uses envelope encryption. A key management service holds the root key, every workspace gets its own data key, and sensitive fields are sealed with that key before they reach the database. Mailbox credentials are sealed separately, with a dedicated credentials key.

Figure 1. Envelope encryption. The root key stays inside the key management service, each workspace has its own data key, and only that key's encrypted copy is ever stored.
  1. 01

    Key management service

    The root key never leaves it. It creates a 32-byte data key for each workspace.

  2. 02

    A key per workspace

    Only the encrypted copy of that key is stored. The plain key is used briefly and cached for a short time.

  3. 03

    Sealed fields

    Message content and integration tokens are sealed with AES-256-GCM under that key before they are written.

Accounts and sign-in

Figure 2. Settings > Security. Two-factor status and every device signed in to your account. Signing out the other sessions ends them everywhere at once.
  • Passwords are hashed with Argon2id and checked against a list of known breached passwords.
  • Sign-in, sign-up and password reset are protected by a CAPTCHA.
  • Two-factor codes can only be used once.
  • Changing your password or signing out other sessions ends those sessions everywhere, including live connections.
  • Every API response carries strict security headers, including HSTS and a default-deny content policy.

What we store, and what we never store

We store

  • Your account: email, name and workspace.
  • Mailbox credentials, encrypted at rest.
  • Messages from connected mailboxes, encrypted at rest.
  • The contacts you upload or sync.
  • Sending signals: bounces, complaints, replies, opens and clicks.
  • Billing details, through Stripe.

We never store

  • Passwords in a form that can be reversed.
  • Card numbers. Stripe holds the payment details.
  • What your recipients do outside your own emails.
  • Message content inside error reports.
  • Anything shared between workspaces. Every query is scoped to yours.

The worker boundary

Workers are the machines that sign in to your mailboxes. They are kept deliberately small: no database connection and no cloud credentials. Anything privileged goes through the control plane, one request at a time.

Figure 3. The worker boundary. A worker talks to the control plane only through the event bus and single requests, and otherwise only to your mailbox provider. It never connects to the database.
Database
Never connects to it
Commands and results
Over the event bus
Decryption
Asks the control plane, holds no cloud key
File storage
One signed operation at a time

Abuse controls

A shared warmup pool and shared infrastructure only work if nobody can abuse them, so the controls are layered rather than one gate.

Figure 4. The audit log. Owners and admins see every change made in the workspace, who made it and the address it came from, as it happens.

Verified warmup

Every warmup email carries a single-use token tied to its recipient, so warmup can’t be faked, replayed or redirected.

Strict pool rules

High complaint or bounce rates take a mailbox out of the shared pool, well before providers would act.

Suppression at send time

Bounces, complaints and unsubscribes are checked before every send, across the whole workspace.

Rate limits

API and live connections are limited per user, with budgets by plan.

Duplicate protection

Tracking, deliverability and billing events are de-duplicated, so nothing is counted or charged twice.

Admin oversight

Accounts that abuse the platform can be banned, and every enforcement action is recorded.

Subprocessors

The services Warmbly Cloud relies on to run. New subprocessors are announced 30 days before they start. A self-hosted instance uses none of them unless you choose to.

ServiceUsed forRegion
AWSCompute, key management, storage, databasesus-east-1, eu-west-1
CloudflareEdge network, DDoS protection, CAPTCHAGlobal
StripeBilling and taxUnited States
PostmarkAccount emailUnited States
PostHogProduct analytics and error reportingUnited States
SentryError reporting, content scrubbedUnited States

Reporting a vulnerability

We welcome reports from researchers and from people running Warmbly themselves. Send a description, a proof of concept and any logs to [email protected].

  1. We acknowledge your report
    within 1 business day
  2. We triage it
    within 3 business days
  3. We update you
    every 7 days until it’s fixed
  4. We credit you publicly
    on request, once the fix ships

Need the full security package?

Data processing terms, a security questionnaire and an architecture walkthrough, on request. A person replies within one business day.

Email us Read the code