Your keys, held by you — with a revoke that means it
Bring your own encryption keys, optionally encrypt message content at rest under them, and hold a kill-switch that fails closed across every process, instantly.
Custody, not ceremony
BYOK email encryption here means custody with consequences: 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.
How it works
- Enroll a key and manage its lifecycle: rotate on your schedule, suspend for a reversible pause, revoke to end it — terminally.
- Optionally turn it on for your organization: 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 follows custody: GDPR erasure by crypto-shred: destroying a key destroys the data it protected, without corrupting the tamper-evident audit ledger.
- And access stays accountable: a vendor-access transparency log: a tamper-evident chain that records operator access, so “we never looked” is checkable, not promised.
The evidence
enroll -> rotate (repeatable) -> suspend (reversible) -> revoke (terminal)Revocation propagates cross-process immediately: new sends for the organization are rejected and stored secrets become unreadable, to us included. There is no grace window in which "revoked" means "mostly revoked."
Honest limits
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. And the kill-switch cuts both ways: revoke a key and the stored ciphertext is gone as data — everywhere, instantly, unrecoverable by anyone including us. That finality is the security property. Treat revocation with the gravity it was built to have.
Where to go next
At-rest encryption pairs naturally with proof of delivery — evidence without exposure — and with the compliance machinery for erasure and retention. Our full posture and disclosure policy live on the security page; the enterprise door has the wider picture. For how customer-held custody differs from a compliance-first provider's, see the Paubox comparison.
Questions, answered plainly
Can Email Fast staff read our message content?
Not if your organization has turned it on — 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 — and a vendor-access transparency log: a tamper-evident chain that records operator access, so “we never looked” is checkable, not promised.
What happens the moment we revoke our key?
It fails closed, instantly, across every process: new sends for your organization are rejected and stored secrets become unreadable — to us included. Revocation is a state change you control, not a support ticket you file.
What's the difference between BYOK and at-rest message encryption?
BYOK is custody: your key protects your organization's stored secrets, with enroll/rotate/suspend/revoke in your hands. At-rest message encryption is the optional layer on top — recipient, subject, and body stored as ciphertext under per-recipient keys wrapped by your key.
Can we rotate keys?
Yes — rotation is part of the lifecycle and happens on your schedule, alongside suspend (a reversible pause) and revoke (terminal).