# Your keys, held by you — with a revoke that means it

> BYOK email encryption with an instant fail-closed revoke, at-rest message encryption under keys you hold, crypto-shred erasure, and a vendor-access log.

Canonical: https://emailfast.dev/features/encryption

## 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: GDPR erasure by crypto-shred: destroying a key destroys the data it protected, 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

:::panel 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

:::tradeoffs 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](/features/proof-of-delivery) — evidence without exposure — and
with the [compliance machinery](/features/compliance) for erasure and retention. Our
full posture and disclosure policy live on the [security page](/security); the
[enterprise door](/enterprise) has the wider picture. For how customer-held custody
differs from a compliance-first provider's, see the
[Paubox comparison](/compare/paubox-alternative).

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