Email Fast Apply for early access
Features

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

  1. Enroll a key and manage its lifecycle: rotate on your schedule, suspend for a reversible pause, revoke to end it — terminally.
  2. 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.
  3. Erasure follows custody: 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.
  4. 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

The lifecycle, spelled out
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

What "we can't read 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. 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?

Two questions. Can a person read it? Not with at-rest encryption 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 operator-readable, and a vendor-access transparency log: a tamper-evident chain that records operator access, so “we never looked” is checkable, not promised. Is it machine-screened for abuse before it sends? Yes by default — 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 — with one 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. At-rest encryption protects stored content; it does not, by itself, remove the in-flight abuse screen.

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

See it for yourself

Sandbox keys run the real pipeline dry — real validation, real events, a hosted inbox, no email sent. Early access is onboarding now.