Sign inStart sending
Security

Security & compliance

Email is an abuse surface and your sending reputation is an asset. Here is what we actually do, what we have not done yet, and who we share data with.

Controls we operate

Encrypted in transit and at rest

Every connection is TLS 1.2 or better. API keys and DKIM private material are held in Cloudflare secret storage and are never written to D1, KV, R2, or application logs. Passwords are hashed with a memory-hard function.

Multi-factor authentication

TOTP-based MFA is available on every account, with recovery codes generated at enrolment. Password-only sign-in is not the intended end state — we will require MFA for anyone holding a privileged platform role.

Role-based access control

Tenant roles scope what a user can do (owner, billing, developer, read-only). Platform operators are separated into super-admin, support-admin, and billing-admin capabilities, so the person who can reset a password cannot also issue a refund.

Immutable audit log

Privileged actions — plan changes, quota overrides, credit adjustments, impersonation, suspension — are written to an append-only audit log with the acting account, the target, and a before/after detail payload. It is not editable through the application.

Scoped, rotatable API keys

Keys can be scoped to a single sending domain and to specific capabilities, so a key leaked from one integration cannot send from every domain you own. Keys can be rotated with an overlap window and revoked instantly.

Rate limiting and quota isolation

Every public entry point is rate-limited per tenant by a Durable Object, with a per-minute burst limit and separate daily and monthly send quotas. One tenant's traffic cannot consume another's allowance or the platform's SES quota.

Abuse controls on account creation

Signup is protected by Cloudflare Turnstile. Sends are additionally gated on verified sending domains, which prevents an unverified account from using us as an open relay.

Never logging what we shouldn't

Logs record identifiers and metadata — message ids, tenant ids, status transitions, counts. Message bodies, recipient addresses, and API key secrets are not written to logs or analytics.

Data retention

Retention is enforced by a scheduled purge, not left to operator discipline — rows past their window are deleted whether or not anyone remembers to clean them up.

  • 90 days — Message and event history, including delivery status and webhook attempts
  • 180 days — Aggregate DMARC reports, retained as deliverability evidence
  • Account lifetime — Domains, templates, contacts, and configuration
  • Indefinite — Audit log entries for privileged administrative actions

Account deletion removes domains, templates, contacts, and configuration. Audit entries are retained so that a deletion performed by a human remains auditable after the fact.

Subprocessors

We use a small number of processors, listed in full. Each is bound by a data processing agreement. Email content passes through AWS SES and message metadata through Cloudflare; payment data passes to our payment processor and never touches our systems.

  • Cloudflare — Compute (Workers), D1, KV, R2, Durable Objects, Queues, DNS, Turnstile
  • Amazon Web Services — Email delivery via SES, including DKIM signing and bounce handling
  • Stripe — Subscription billing, metered usage invoicing, and payment method storage
  • Paddle / Razorpay — Alternative payment processing where selected as your billing provider

Compliance posture — stated plainly

We would rather tell you what is in progress than imply a certification we hold. As of today:

  • SOC 2 Type II — not yet certified. The controls on this page are being formalised into an audit programme. If your procurement process requires a current report, ask us and we will tell you where it actually stands.
  • GDPR — supported, not certified. We provide data processing terms, a subprocessor list, retention limits, and deletion on request. We do not yet hold an independent certification.
  • Penetration testing — external testing is part of the audit programme above. We will share a summary letter once it exists.

Found something? Report it to security@emitd.com and we will acknowledge receipt and triage.