# Security, stated plainly

> The open security page: architecture, key custody, what we verified and how, the attestations we don't yet hold — stated plainly — and how to report a bug.

Canonical: https://emailfast.dev/security

## 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

| Attestation | Status |
|---|---|
| SOC 2 (any type) | **Not held.** Not claimed. On the roadmap; will be announced when an auditor is engaged |
| ISO 27001 | **Not held.** Not claimed |
| HIPAA BAA | **Not offered** today |
| PCI-DSS | **Not applicable** — we never touch card numbers; reader payments are processed by Stripe |
| Independent penetration test | **Not yet performed.** Planned alongside the audit roadmap |
| GDPR | Engineered for: crypto-shred erasure, consent records, retention windows, DPA available, EU data location |

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](/.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](/legal/subprocessors). Our infrastructure is
dedicated hardware we operate; message content is not shared with analytics vendors,
advertising systems, or model-training pipelines. Ever.

## How do I report a vulnerability?

Email security@emailfast.dev (see security.txt ). We acknowledge within 48 hours, we don't take legal action against good-faith research, and we credit reporters who want credit.

## Where does data live?

On dedicated infrastructure in the EU (Germany), operated by us — not on a hyperscaler tenancy. Data-residency tagging is built into the schema; additional regions are on the roadmap and will be announced when real, not before.

## Why should a small company be trusted with email?

Don't trust — check. That's the design goal: delivered messages can mint an Ed25519-signed delivery certificate — receiving mail server, TLS details, the server's SMTP response, and timestamps, with the recipient stored only as a keyed hash — chained into a tamper-evident ledger and verifiable without trusting us; a vendor-access transparency log: a tamper-evident chain that records operator access, so “we never looked” is checkable, not promised; 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. A small team can't out-badge incumbents, so we built a platform whose claims are independently checkable instead.