# The email platform where you hold the keys

> The email platform where you hold the keys: BYOK with an instant revoke, opt-in at-rest message encryption, fail-closed DLP, and proof of delivery.

Canonical: https://emailfast.dev/enterprise

## Key custody is the whole question

Every email platform says "encrypted at rest." The question your security team should
ask is: **who holds the keys?** In our July 2026 survey the answer was always the
vendor — as of July 2026, none of the twelve competitor platforms we surveyed offers customer-held encryption keys for message content — the closest, a healthcare email provider, documents that its master keys live in its own cloud KMS.

Email Fast is built for the other answer:

- 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.
- 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.
- GDPR erasure by crypto-shred: destroying a key destroys the data it protected, without corrupting the tamper-evident audit ledger.

:::tradeoffs We'll tell you what it costs
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. If a vendor tells you encryption is free of tradeoffs,
they're describing encryption they can undo.
:::

## Proof of delivery, admissible-grade

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. Certificates support legal hold — retained even against deletion
requests when litigation requires it — and export in bulk via the API.
[The full mechanism →](/features/proof-of-delivery)

## Data loss prevention that fails closed

an outbound data-loss-prevention gateway that fails closed — card numbers, government IDs, and secrets can be blocked, redacted, or held for a second person's sign-off before anything leaves. Policy evaluation errors block rather than leak — fail-closed is a
design invariant, not a configuration option. [How the DLP gateway works →](/features/dlp)

## The boring controls, done properly

| Control | Status |
|---|---|
| Tenant 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 |
| Identity | SAML SSO, SCIM, passkeys, TOTP — [details](/features/identity) |
| Audit | Tamper-evident hash-chained audit log; auth event trail |
| Operator transparency | a vendor-access transparency log: a tamper-evident chain that records operator access, so “we never looked” is checkable, not promised |
| Secrets posture | a fail-closed boot guard: production refuses to start if any of 13 load-bearing secrets is weak or a dev default |
| Erasure & retention | GDPR crypto-shred; retention windows; consent and DPA tracking built in |
| Supply chain | 14 runtime dependencies — a dependency surface your team can actually review |

Running client workspaces under your brand? [Agency white-label →](/features/agencies)

## Our compliance posture, stated plainly

We publish exactly what is true on the [security page](/security): what we've built,
what we've verified ourselves and how, and which third-party attestations we do not
yet hold. *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.*

If your procurement process needs a vendor questionnaire filled in, send it —
[contact](/contact) goes to the people who wrote the code.

## Can Email Fast staff read our message content?

Not if your organization has flipped that switch — 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. Without it, content is protected but operator-readable, like every mainstream email platform — and a vendor-access transparency log: a tamper-evident chain that records operator access, so “we never looked” is checkable, not promised.

## What happens when we revoke our key?

Revocation fails closed, immediately, across every process: new sends for your organization are rejected, and stored encrypted content becomes permanently unreadable — to us included. It is a kill-switch, not a support ticket.

## Are you SOC 2 / ISO 27001 certified? HIPAA?

No, no, and we do not offer a HIPAA BAA today. We won't decorate this page with our cloud vendors' certificates and imply they're ours — a practice you will find at several competitors. What we have: a 19-stage adversarial security review, run to zero confirmed findings, 65 end-to-end verification suites and 351 unit tests, green at every commit, and this open security posture. Third-party attestation is on the roadmap and will be announced when an auditor is engaged, not before.

## How is tenant data isolated?

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 is enforced by the database engine itself, not by application-code convention, and a structural check fails the build if any new table is created without it.

## Do you support SSO and automated provisioning?

SAML SSO and SCIM on enterprise plans; WebAuthn passkeys and TOTP on every account — all built in, never sold as separate paid add-ons.