Question 1

Where are encryption keys stored?

Accepted Answer

Per-user DEKs are stored encrypted by a KEK in a dedicated KMS (currently backed by a hardware-isolated service). The KMS is the only component that ever holds KEKs in memory; application servers never see them. Key rotation happens automatically on a rolling schedule without any downtime.

Question 2

How does AI Emaily connect to Gmail or Google Workspace?

Accepted Answer

Gmail and Google Workspace connect with one-click Google sign-in (OAuth) — you approve access on Google's own screen and Google hands us a revocable token, so AI Emaily never sees your password. We request only least-privilege mailbox access (read, send, folder management), never contacts, Drive, or admin data, and AI Emaily is CASA-certified for those Gmail scopes. You can revoke access at any time from your Google security settings. If you prefer, an IMAP + SMTP app-password fallback is also available. Either way the credential is envelope-encrypted at rest, exactly like every other secret.

Question 3

How are my OAuth tokens and passwords stored?

Accepted Answer

Every credential — OAuth tokens, IMAP/SMTP passwords, BYOK keys — is envelope-encrypted. Each value is wrapped with a per-user data encryption key (DEK), which is itself encrypted by a key encryption key (KEK) held in a dedicated KMS. The DEK is never stored next to the ciphertext it protects, and plaintext credentials never reach application logs, error reports, or analytics pipelines. They’re decrypted only inside an isolated worker at the moment of use.

Question 4

Is my email encrypted in transit and at rest?

Accepted Answer

Yes on both. Traffic between your device and our servers uses TLS 1.2 or higher with modern cipher suites; older TLS fallbacks are rejected at the load balancer. At rest, message bodies, metadata, and summaries are encrypted with AES-256 at the storage layer, and message-body blobs carry an additional per-object KMS-managed key — so a compromised storage layer alone can’t produce plaintext without also breaching the KMS.

Question 5

What is envelope encryption and why use it?

Accepted Answer

Envelope encryption means a secret is encrypted with one key (the DEK), and that key is itself encrypted by another (the KEK) held in a KMS. The benefit: the encrypted secret and the key that unlocks it are never stored together, and you can rotate the KEK without re-encrypting every record. It limits blast radius — stealing the database doesn’t reveal credentials, because the KEK lives only in the KMS.

Question 6

How does AI Emaily stop one user from reading another’s data?

Accepted Answer

Through object-level authorisation. Every database row, storage blob, and function invocation carries an owner ID, and requests without a matching verified JWT are rejected at the data layer — not just the API layer. So even a bug in API routing cannot leak one account’s data to another, because the database query itself filters on the authenticated user ID and the storage policy refuses cross-user blob reads.

Question 7

How often are encryption keys rotated?

Accepted Answer

Key rotation runs automatically on a rolling schedule with no downtime. KEKs are rotated inside the KMS, and per-user DEKs can be re-wrapped without re-encrypting the underlying ciphertext, so rotation is cheap and continuous rather than a risky bulk migration. Application servers never hold KEKs in memory — only the KMS does — which keeps the rotation surface small and contained.

Question 8

How do you prevent duplicate sends on a flaky connection?

Accepted Answer

Every mutating API call — send, archive, label, delegate — accepts an idempotency key. If a connection drops after the server has accepted the request, retrying with the same key is a no-op rather than a second action. This matters most for send: a dropped response can’t turn into a duplicate email, because the server recognises the repeated key and returns the original result instead of acting again.

Question 9

Does AI Emaily store my credit card details?

Accepted Answer

No. Card data never touches AI Emaily servers. Billing runs through Stripe’s hosted checkout and Elements, which handle the card directly under their PCI-compliant infrastructure. We store only the Stripe customer ID and your subscription status — enough to manage your plan, and nothing that could expose your payment details if our systems were compromised.

Question 10

How are inbound webhooks kept secure?

Accepted Answer

Webhooks from Stripe, Gmail Push Notifications, and Microsoft Graph are validated with HMAC signatures before any payload is processed; replayed or tampered requests are silently dropped and logged. The web app also ships a strict Content Security Policy that blocks inline scripts, restricts fetch targets to our own domains and known API hosts, and disallows third-party framing, with per-route CORS limited to production and staging origins.

Encryption & key handling

Encryption in transit and at rest

Least-privilege everywhere

Webhooks, CORS, and CSP

Idempotency and safe retries

Frequently asked