# What a delivery certificate proves

> What a signed delivery certificate proves and what it does not — plus how legal hold works: what's preserved, in what format, and for how long.

Canonical: https://emailfast.dev/legal/certificate-scope

> This scope note is being finalized with counsel before general availability. It
> describes what our systems record; it is a technical and product statement, not legal
> advice about how any given tribunal would weigh it.

## What a certificate attests

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. A certificate is a signed record of **what our systems observed** at
send time:

- the **receiving mail server** that accepted the message (its hostname / MX),
- the **transport security** negotiated on that hop (TLS version and cipher),
- the receiving server's **SMTP response** (e.g. `250 2.0.0 OK …`),
- the **timestamps** for injection and the server's acceptance,
- the recipient, stored only as a **keyed hash** — never plaintext in the certificate.

Each certificate is signed with our published key and chained into a tamper-evident
ledger, so anyone can verify it was issued by us and hasn't been altered — without
trusting us to be honest about it after the fact.

## What a certificate does not prove

Being clear about the edges is the point:

- It does **not** prove a human **read** or acted on the message — only that a receiving
  server accepted it. Opens and clicks are separate, weaker signals we report honestly.
- It is **not** a qualified or government-registered electronic-delivery service, and we
  don't claim equivalence to one.
- It does **not** decide how any court or regulator would weigh the record — that is
  theirs to judge. We describe what we recorded and how to verify it; we don't
  characterize its legal effect.

## Legal hold (Enterprise)

"Legal hold" on the Enterprise plan has a precise meaning:

- **What is preserved:** for a held subject, the signed delivery certificates (content-free
  — the recipient is a keyed hash, and no subject or body is in a certificate) and the
  delivery-evidence records — the recipient records and the SMTP delivery transcript —
  retained against both routine retention-expiry and the evidence-scrub of a data-subject
  erasure, for as long as the hold is active.
- **Format:** the same signed-certificate + event JSON the API returns, exportable in
  bulk.
- **Duration:** the hold stays in place **until an authorized operator on your account
  explicitly releases it** — there is no fixed expiry period.
- **Export:** on demand via the certificate export endpoint, or as a packaged archive on
  request.
- **Erasure interaction:** a legal hold **supersedes erasure for the delivery *evidence*** —
  a held subject's recipient records and delivery transcript are retained, not scrubbed,
  until the hold is released. One precise limit, stated plainly: a data-subject erasure
  still crypto-shreds that subject's per-message encryption key even under a hold, so if the
  organization uses at-rest message encryption, the encrypted message *bodies* become
  unreadable regardless. A hold therefore preserves the content-free delivery evidence and
  the record that a message existed — not the continued readability of subject-encrypted
  content. This precedence is deliberate and disclosed; see the [DPA](/legal/dpa).

Questions about certificate scope or legal hold for a regulated workload:
[talk to us](/contact).