Security & privacy

Six pledges,
written in plain language.

What follows is not a marketing claim. It is the engineering posture of the product, what it will and will not do with the contents of your account, and where the beta honestly stands.

01 · The credential pledge

Credentials are encrypted, and stay encrypted.

IMAP and SMTP passwords are encrypted with AES-256-GCM under a per-deployment key. They are decrypted in memory only at connection time — never logged, never cached to Redis, never placed in job payloads, never shown in admin views. To rotate, reconnect the mailbox; a dedicated rotation flow is planned.

02 · The access pledge

No one reads across the line.

All user data is protected by PostgreSQL row-level security. Background workers use a service-role key, but every query is scoped to a specific user — there are no unbounded cross-user queries. Workspace data is scoped to members; one workspace cannot reach another’s mailboxes or messages.

03 · The admin pledge

Operators see health, not mail.

The admin console shows connection health, sync state, and aggregate counts. Message bodies, subjects, sender and recipient addresses, and credentials are never rendered in admin views — by code, not by policy document.

04 · The auth pledge

Sign-in is boring, on purpose.

Email and password sign-in with bcrypt hashing. TOTP two-factor with single-use backup codes. JWT sessions in HttpOnly, SameSite=Lax cookies with automatic refresh. SSO (SAML/OIDC) and SCIM provisioning are on the Enterprise roadmap — planned, not present.

05 · The transport pledge

TLS everywhere it matters.

All web traffic is TLS 1.2+ with HTTP redirected to HTTPS. IMAP and SMTP connections use SSL/TLS or STARTTLS with certificate verification enforced in production. DKIM and SPF live at your domain and provider — TELVRIX sends through your own SMTP, so your existing signing applies.

06 · The honesty pledge

Beta means beta.

No compliance certifications are in place during the closed beta. SOC 2 and a formal GDPR review are planned around general availability. Do not use TELVRIX for legally regulated email — PHI, PCI, or similar — until then.

Architecture, in one diagram

How a message moves through TELVRIX.

Mail enters TELVRIX over an authenticated, encrypted channel from your provider. It is synced into your deployment’s Postgres so the whole workspace can search and read it — under row-level security, with the credentials themselves stored only as ciphertext.

  • TLS 1.2+Transport — provider to app, app to browser.
  • AES-256Credential encryption at rest, per-deployment key.
  • RLSPostgres row-level security on every user table.
Your provider──TLS──>TELVRIX app

Synced over IMAP with your credentials — decrypted in memory only.

TELVRIX app──🔒 AES-256 creds──>Your Postgres

Messages indexed for search; credentials stored as ciphertext only.

Your Postgres──RLS──>Workspace members

Each member reads only what visibility and send grants allow.

Where compliance stands

The honest version of the badge wall.

SOC 2

Formal audit planned post-GA. Not certified during beta.

Roadmap

GDPR

Handling aligned with the principles; DPA before EU launch.

Planned

HIPAA

Not supported. Do not store protected health information.

Not available

SLA

Beta is best-effort. No uptime guarantee until launch.

Closed beta

The beta page lists exactly what works today; the privacy page lists exactly what is stored.

Questions a security team would ask

Send them. We answer with engineers,
not with sales decks.