Security Per-workspace key isolation · encrypted credentials · audit logging

Security is
the product.

You're handing us the keys to your mailboxes and your clients' pipelines. That trust is the entire business. So security isn't a checkbox page here — it's how the system is built, from credential storage up to the access model.

SOC 2 Type II · in progressGDPR-ready · DPA availableTLS 1.2+ · AES-256
▸ The fundamentals

Encrypted everywhere. Isolated by default.

Two layers that are non-negotiable: nothing moves in plaintext, and nothing rests in plaintext.

Encryption in transit & at rest

Every connection — browser to app, app to mailbox provider, service to service — is encrypted. Data at rest is sealed with AES-256, including databases, object storage and backups.

  • Transit TLS 1.2+ enforced
  • At rest AES-256-GCM
  • HTTP HSTS, no plaintext
  • Backups Encrypted + tested
  • Key custody KMS-managed

Mailbox credential handling

The most sensitive thing we hold is your access to a mailbox. OAuth is always preferred over passwords. Whatever we must store is encrypted with a key unique to your workspace — and never written to a log line.

  • Connection OAuth preferred
  • Encryption Per-workspace keys
  • Token scope Send/read only
  • Logging Never logged
  • Revocation One-click, instant
▸ Credential handling

How a mailbox secret actually moves.

The honest version. For Gmail and Microsoft we never see a password at all — only a scoped OAuth grant you can revoke. For raw SMTP, the credential is sealed before it ever lands in storage.

OAuth first. Encrypted always.

When you connect a Gmail or Microsoft 365 mailbox, NuMail receives a delegated OAuth token — scoped to sending and reading mail, nothing more. We never ask for, see, or store your account password.

For SMTP/IMAP mailboxes that have no OAuth path, the credential is encrypted with your workspace's own data-encryption key the moment it arrives. Decryption happens in-memory, only at send time, only for the worker handling that job.

  • Per-workspace data keys are themselves wrapped by a master key held in a managed KMS — compromising one workspace's data never exposes another's.
  • Credentials and tokens are redacted at the logging layer, so they can't leak into traces, error reports, or support tooling.
  • Disconnect a mailbox and the stored secret is destroyed and the OAuth grant revoked at the provider — not just flagged inactive.
1
You connect a mailboxoauth grant · or smtp creds
2
Sealed at the edgeaes-256 · workspace data key
3
Key wrapped by KMSmaster key · never on disk
4
Decrypted only at sendin-memory · per worker · per job
▸ Infrastructure

Isolated workspaces. Least privilege.

Every workspace — and every agency sub-workspace — is a hard tenancy boundary. Services hold the narrowest grant that lets them do their one job, and everything they do is logged.

Tenancy
Workspace-isolated data

Every query is scoped to a workspace id at the data layer. Agency parent and sub-workspaces are separate tenancy boundaries — a sub-workspace cannot read another client's leads, mailboxes, or replies, and the parent only sees what the model explicitly grants.

Access model
Least-privilege services

The send worker can send. The reply detector can read inbound. The billing service can touch Stripe. No service carries a god-mode credential, and production secrets are injected at runtime — never committed, never baked into images.

Audit logging
Append-only audit trail

Sensitive actions — mailbox connects and disconnects, member invites and role changes, API key creation, data exports — are written to an append-only audit log with actor, timestamp, and source. Agency owners get the trail for every sub-workspace.

Network
Private by default

Databases and queues live on private networking with no public ingress. Only the application edge is internet-facing, behind TLS termination and rate limiting. Outbound to mailbox providers goes over their official, authenticated APIs.

Resilience
Encrypted, tested backups

Point-in-time backups are encrypted and restore-tested. The job engine is idempotent and retry-safe, so a node failure mid-campaign never double-sends and never silently drops a scheduled email.

▸ Access controls

Who can do what. Spelled out.

Role-based access on every plan. Single sign-on with SAML on the Agency tier, so your identity provider stays the source of truth.

All plans

Role-based access control

Invite teammates with a role, not a free-for-all. Roles map cleanly to what a person actually needs — a copywriter drafting sequences shouldn't be able to rotate API keys or pull a billing export.

OwnerAdminOperatorAnalystBilling
Agency tier

SSO & SAML

Connect your identity provider — Okta, Entra ID, Google Workspace, or any SAML 2.0 IdP. Provisioning and de-provisioning follow your directory, so off-boarding a team member there pulls their NuMail access with it.

SAML 2.0Enforced SSOSession policyPer-sub-workspace roles
▸ Compliance & data protection

The paperwork, handled.

Where we are today, stated plainly — no green checkmarks for things that aren't done yet.

In progress

SOC 2 Type II

We're mid-way through a SOC 2 Type II observation window with an independent auditor. Controls are implemented and being evidenced over time. Prospective customers under NDA can request the current status and the Type I report.

GDPR-ready

GDPR & data rights

Built for GDPR from the data model up: lawful processing, data-subject deletion via a hard-delete endpoint, suppression lists, and EU-aware data handling. We act as processor; you remain the controller of your contact data.

Available

DPA & subprocessors

A Data Processing Agreement is available for any customer who needs one — agencies signing it on behalf of their clients included. Our subprocessor list (hosting, AI inference, email infra) is published and kept current. Request the DPA →

▸ Responsible disclosure

Found something? We want to know.

Security researchers make this product safer. If you've found a vulnerability, report it — you'll have our attention and our safe harbor.

Report it. Safely.

Email us with a description and reproduction steps. We acknowledge reports quickly, keep you updated as we triage and fix, and credit researchers who want it. Good-faith research that follows this policy will not lead to legal action from us — that's our safe-harbor commitment.

✉ security@numail.ai
  • 01Test only against your own workspace and accounts — never another customer's data.
  • 02Don't run attacks that degrade service, exfiltrate data at scale, or affect other tenants.
  • 03Give us a reasonable window to remediate before any public disclosure.
  • 04Act in good faith and we'll treat your research as authorized — no legal pursuit.

Questions for our
security team?

Reviewing NuMail for an agency or an enterprise rollout? We'll walk through architecture, sign your DPA, and answer the questionnaire.