What a delivery certificate proves

Delivery certificates are a strong, checkable record. Being precise about their scope is what keeps them trustworthy, so here is exactly what they do and don't attest.

Facts verified 2026-07-19 — corrections: hello@emailfast.dev

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.

Questions about certificate scope or legal hold for a regulated workload: talk to us.