The email platform where you hold the keys
Customer-held encryption keys with an instant revoke kill-switch. Fail-closed data-loss prevention. Cryptographic proof of delivery. Database-enforced tenant isolation. Claims your team can verify — not badges to take on faith.
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.
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 →
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 →
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 |
| 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 →
Our compliance posture, stated plainly
We publish exactly what is true on the security page: 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 goes to the people who wrote the code.
Questions, answered plainly
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.