Security

Built to sit on top of your email without getting in the way of it

Mailex adds a shared queue on top of Gmail. Your email stays in Gmail, we take the narrowest access that makes that work, and everything your team does on top of it is isolated, encrypted, and logged.

Your team authenticates through Google OAuth with their own accounts. Mailex never sees or stores a password, so there is no shared credential to leak.

Least-privilege Gmail access

We request the gmail.modify scope and nothing broader. No access to Drive, Calendar, or Contacts. You can revoke Mailex from your Google account at any time.

Per-workspace data isolation

Every row in the database is scoped to your workspace and enforced by row-level security in Postgres. A query for one org can never read another org’s conversations.

Encrypted in transit and at rest

All traffic runs over TLS. Data and Gmail refresh tokens are encrypted at rest. Tokens are held server-side and never exposed to the browser.

Untrusted email is sandboxed

Inbound HTML is sanitized on ingest and rendered inside a sandboxed iframe, so a malicious message cannot run scripts or reach the rest of the app.

Full audit trail

Every assign, reply, note, and permission change is logged with the actor and timestamp, retained for two years and exportable on the Scale plan.

How the data actually flows

Gmail is the transport; our database is the source of truth for the collaboration layer. The design keeps a hard line between what the browser can do and what only the server can.

Two write paths, both server-side
The browser reads with a scoped, read-only client. Changes go through authenticated server functions or the sync worker. There is no third path that lets the client write your data directly.
Tokens never touch the browser
Gmail refresh tokens live encrypted server-side and are used only by the sync worker. The app you load in the tab has no way to read them.
Idempotent, verified sync
The Gmail webhook verifies Google’s signed token before doing anything, and message ingest is idempotent, so a replayed or duplicate event cannot corrupt a thread.

Found something? Tell us.

We welcome reports from security researchers. Email the details and we will acknowledge within one business day and keep you posted through the fix. SOC 2 Type II is in progress; we can share our current controls and subprocessor list under NDA for Scale evaluations.

Report a vulnerability

security@mailex.ai

Please don’t run automated scans against production. Include steps to reproduce.