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.
• 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.

Proof of delivery, independently verifiable

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 — held records are retained against deletion requests until an authorized operator releases the hold — and export in bulk via the API. Exactly what a certificate does and doesn't attest, and how legal hold works, is in the certificate scope note. 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 →

Content privacy: the only un-scanned lane

Every message on the platform is machine-screened for abuse before it sends — 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. That screen protects the shared reputation your delivery rides on, so it is deliberately not a self-serve setting a bad actor could switch off. Enterprise is the exception: 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. If your compliance posture requires that outbound content is never machine-inspected, we turn the screen off for your organization under a vetted agreement — and, like every operator action, the grant is recorded in the tamper-evident audit trail. Talk to us.

The boring controls, done properly

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 is built — encryption at rest, database-enforced isolation, signed delivery receipts — and which third-party attestations we do not yet hold.

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