Security, stated plainly

This page is deliberately open: static, crawlable by anyone or anyone's AI, and specific. It says what we built, what we verified and how, and exactly which attestations we do not yet hold. No borrowed badges.

Facts verified 2026-07-17 — corrections: hello@emailfast.dev

Architecture

One admission path. every send — REST, SMTP, browser SDK, compatibility endpoints, broadcasts, automations — passes through one admission gate: idempotency, suppression, quota, and content policy in a single checkpoint no ingress can skip. This single-writer property is the foundation for every other guarantee on this page: suppression, quota, DLP, and encryption cannot be bypassed by a forgotten side door, because there are no side doors.

Database-enforced isolation. 75/75 tenant tables under database-enforced row-level isolation, with a structural guard that fails the build if a new table ever lacks it. Isolation lives in the database engine, not in application-code discipline — a category of bug we removed rather than promised to avoid.

Durable by construction. a 202 from the API means the send is committed to a durable, partitioned outbox before we answer — a crash can't lose it, and a retry with the same idempotency key can't double-send.

Small, reviewable supply chain. 14 runtime dependencies. Every dependency is pinned and the count is extracted from the manifest at build time — the number you just read cannot drift from reality.

Encryption & key custody

In transit — TLS on every hop we control; mail delivery uses opportunistic TLS with per-message records of protocol and cipher (they appear in delivery certificates).

At rest — the database and backups are encrypted; DKIM private keys and all stored credentials are envelope-encrypted with rotation support and dual-read, so key rotation never requires downtime.

Customer-held keys (BYOK/HYOK) — organizations can bring their own encryption keys — enroll, rotate, suspend, or revoke — and revocation fails closed: new sends are rejected and stored secrets become unreadable, to us included.

At-rest message encryption — BYOK organizations can additionally enable at-rest message encryption: recipient, subject, and body stored as ciphertext under per-recipient keys wrapped by the customer's key — revoke the key and the stored content is unreadable everywhere, instantly. The tradeoff is stated wherever the feature is: encrypted sends give up click-tracking, send-time optimization, and per-recipient analytics — that is what “we can't read it” costs, and we say so.

Crypto-shred erasure — GDPR erasure by crypto-shred: destroying a key destroys the data it protected, without corrupting the tamper-evident audit ledger.

Operator transparency — a vendor-access transparency log: a tamper-evident chain that records operator access, so “we never looked” is checkable, not promised.

Operational security

• a fail-closed boot guard: production refuses to start if any of 13 load-bearing secrets is weak or a dev default.
• Fail-closed defaults everywhere a policy evaluates: DLP errors block sends; residency violations refuse writes; revoked keys reject admissions.
• Webhook and outbound HTTP hardened against server-side request forgery: private-network targets are refused at connect time, with DNS-rebinding protection.
• Backups run on a leader-scheduled ledger with integrity hashes — and restore drills are actually performed, not assumed.
• Full metrics coverage with alerting on worker stalls, split-brain, and backup staleness. We don't operate email blind.

What we've verified, and how

a 19-stage adversarial security review, run to zero confirmed findings — an adversarial process (independent finder and refuter agents, then fixes, then re-review at higher scrutiny until a clean pass) across tenant isolation, authentication surfaces on every process, template injection, SSRF, migrations, crypto, and the deliverability engine. Before it, a separate four-stage adversarial code review. Backing both: 65 end-to-end verification suites and 351 unit tests, green at every commit.

That review was internal and adversarial — a documented find→refute→fix→re-verify loop — not a third-party audit. We say exactly which one we have.

Compliance posture — the honest table

You will find competitor security pages that display their cloud providers' certificates as if they were their own. We think that practice tells you more about a vendor than any badge does.

Vulnerability disclosure

Email security@emailfast.dev. Machine-readable details live at /.well-known/security.txt. Good-faith research is welcome: don't access other tenants' data, don't degrade the service, give us reasonable time to fix. We acknowledge in 48 hours and credit researchers who want it.

The subprocessor list

Short, by design — see subprocessors. Our infrastructure is dedicated hardware we operate; message content is not shared with analytics vendors, advertising systems, or model-training pipelines. Ever.