How Warmbly protects
your mailbox.
We hold mailbox credentials, message bodies, and recipient lists. That is a serious responsibility. This page documents the encryption model, the worker boundary, the abuse controls, and how to reach our security team.
Backend, workers, consumer and frontend are public.
Edge terminates on Cloudflare. Origin requires TLS 1.2 or above.
Per-organization data keys, AES-256-GCM application layer.
Plain-English privacy policy and data processing terms on request.
Controls in place. Audit window opens with our auditor.
Under evaluation. No certification claimed today.
We do not claim certifications we do not hold. SOC 2 and ISO 27001 are listed as planned because they are honestly not in place yet.
Envelope encryption, with AWS KMS at the root.
Mailbox tokens, IMAP credentials and other sensitive fields are sealed at the application layer before they touch a database. The key that does the sealing is itself protected by KMS, so a database snapshot in isolation is not enough to read a single byte of plaintext.
Customer Master Key lives in KMS and never leaves it. KMS generates a 32-byte data encryption key for each organization on first use.
The plaintext DEK is returned briefly to the application. The encrypted DEK blob comes back in the same call and is the only long-term copy.
Sensitive fields like mailbox tokens and IMAP credentials are sealed with AES-256-GCM using the user DEK, then base64 encoded.
Ciphertext is stored in Postgres. The encrypted DEK blob lives in the user_encrypted_keys Postgres table. Plaintext DEKs are cached in Redis with a TTL.
Workers do not touch your database.
Workers are the execution plane. They send and sync mail across many machines with separate network identities. They receive commands from Kafka and publish results to Kafka. They never open a PostgreSQL connection.
That boundary matters. A worker compromise does not expose the relational store. Sensitive payloads stay encrypted in transit and are only opened against KMS-backed primitives.
Read the architectureWhat we hold, and what we refuse to hold.
Specifics, not slogans. If you do not see something on the left, we are probably not collecting it. If something on the right ever moves, we will say so on /changelog/.
- Account profile: email, name, organization.
- Mailbox credentials, encrypted at rest: OAuth tokens, IMAP and SMTP secrets.
- Sent and received message bodies for connected mailboxes, encrypted at rest.
- Recipient lists you upload or sync.
- Deliverability signals: bounces, complaints, replies, opens, clicks, suppression.
- Billing metadata via Stripe. Card data never touches our servers.
- Operational logs scoped to debugging. Customer message bodies are not logged.
- Plaintext passwords. We store password hashes only, and never store mailbox passwords in plaintext.
- Plaintext DEKs at rest. The encrypted DEK is what persists.
- Card numbers, CVCs, or full PAN. Stripe holds the payment instrument.
- Recipient browsing or off-platform behavior. Tracking covers your campaign mail only.
- Customer message bodies inside error reports. Sentry payloads are scrubbed.
- Cross-customer data sharing. Tenancy is enforced at the query layer.
Layered controls, not one brittle gate.
A cold email platform is only as safe as the slowest line of defense. We block early, dedupe everywhere, and keep an audit trail of admin actions.
Every warmup email carries a verification token. Missing, expired or malformed tokens are recorded against the sending mailbox.
Three or more invalid warmup-token attempts in 24 hours, or a spam score above 50, removes a mailbox from the shared warmup pool.
Bounces, complaints and unsubscribes are written to suppression and enforced at send time. Campaigns skip suppressed recipients automatically.
Cloudflare Turnstile gates login, registration, password reset and confirmation flows. Challenge freshness and remote IP are validated server-side.
API and WebSocket traffic are rate-limited per user against Redis-backed counters, with category-specific budgets per plan.
Tracking events deduplicate via in-memory and persistent caches. Deliverability events and Stripe webhooks carry idempotency keys.
Who else touches your data.
The infrastructure and operational providers Warmbly relies on to run.
We give 30 days notice before adding any subprocessor that processes customer Personal Data.
Found something. Tell us first.
We welcome reports from security researchers and operators. Send a description, a proof of concept, and any logs to hello@warmbly.com. We will acknowledge quickly, triage in the open, and keep you posted until the fix ships.
Please avoid testing that degrades service for other customers, accesses data that is not your own, or relies on social engineering of employees or contractors. Good faith research is welcome.
Want the full security package?
Data processing terms, security questionnaire, and architecture deep dive on request. Replies from a human within one business day.