Security, stated plainly

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

Facts verified 2026-07-18 — 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.

Abuse screening, on by default. every outbound message is machine-screened for abuse — spam, scams, phishing, brand impersonation, and malware links — at admission and again at send, on every self-serve plan; the screen is automated and runs before delivery, never a person reading your mail. It is the security counterpart to key custody: content is machine-inspected for abuse in flight — never a person reading your mail — which is how a scammer can't quietly ride the shared reputation the rest of our senders depend on. There is one place the default posture is deliberately relaxed — one lane switches that abuse screening off entirely — the sales-vetted Enterprise content-privacy tier — and it is the only way outbound content goes un-scanned; it is granted solely by an operator through the audited admin plane after vetting, never self-serve, and every grant is logged — operator-gated, vetted, and recorded in the audit trail.

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.

What we run, and what we procure. "We run our own" is a precise claim, so here's the boundary — Email Fast runs its own mail transfer agent, warmup engine, reputation breaker, and per-tenant fair queue — we run these ourselves, with no upstream ESP reselling us your delivery. Operated by us: the mail transfer agent, warmup engine, reputation and complaint-feedback systems, per-tenant queues, and the one admission gate. Procured (leased, like every sender): IP-address allocations, network transit, and physical hosting — dedicated servers in the EU. The point isn't that we own fiber and IP blocks; it's that there is no upstream email provider reselling us your delivery — the part every rented-pipe platform can't say.

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 — erasure by crypto-shred: destroying a key renders the data it protected unreadable — our approach to honoring GDPR erasure, documented in the DPA — 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's built in

• Encryption of message content at rest — recipient, subject, and body stored as ciphertext under per-subject keys, wrapped by keys the customer can hold and revoke.
• Tenant isolation enforced by the database itself — row-level security in the engine, not just application code.
• Passkeys, two-factor sign-in, and SSO — WebAuthn, TOTP, and SAML with SCIM provisioning, on the platform rather than sold as add-ons.
• Outbound content screening on every send — machine-screened for abuse at admission and again at send, before anything leaves.
• GDPR crypto-shred erasure — destroy the key and the data it protected is unreadable, without corrupting the audit ledger.
• TLS on every hop we control — with per-message records of protocol and cipher in delivery certificates.

Compliance posture — the honest table

Security reviewers: our policy corpus (information security, access control, incident response, change management, and nine more), risk register, and incident-response plan are maintained documents — summaries are available on request under NDA. Write to security@emailfast.dev; security questionnaires and review requests get a response within 2 business days.

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.

AI governance

Stated because security reviewers now ask, and because the answer is unusually clean:

• No AI system trains on your data. Message content, contact lists, and analytics are never shared with model-training pipelines — ours or anyone's.
• Every AI-powered feature ships disarmed. The platform contains narrow, optional seams for AI assistance (copy suggestions, deliverability diagnosis narration, inbound-reply classification). Each is off by default behind a zero-network stub; none is connected to a model provider today. Arming any of them is an explicit, announced step — and when armed, they will be per-tenant opt-in.
• The deterministic parts don't need AI. Copy-rule annotations, bounce classification, and delivery diagnosis run on plain, inspectable rules.

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.