# Delivery you can prove to someone who doesn't trust you

> Proof of email delivery you can verify without trusting us: Ed25519-signed certificates with the receiving MX, TLS details, and the verbatim SMTP response.

Canonical: https://emailfast.dev/features/proof-of-delivery

## What we can prove, we sign

Proof of email delivery here is cryptographic, not a screenshot of a dashboard:
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.

## How it works

1. A delivered message can mint a certificate recording the receiving MX, the TLS protocol and cipher of the session, the receiving server's verbatim SMTP response, and timestamps — with the recipient stored only as a keyed hash, so the certificate itself is PII-free.
2. Each certificate is appended to a hash-chained WORM ledger: write-once, append-only. History can be extended, never edited.
3. Anyone can verify a certificate against our published public key — offline, independently.
4. Bulk export is one call: `GET /v1/certificates/export`.

Legal hold is built in and supersedes erasure while active: held certificates
survive deletion requests for as long as litigation requires, and normal erasure
resumes when the hold lifts.

## The evidence

:::panel A certificate, abridged
```json
{
  "recipient": "keyed-hash:9f2c...",
  "mx": "aspmx.l.google.com",
  "tls": { "protocol": "TLSv1.3", "cipher": "TLS_AES_256_GCM_SHA384" },
  "smtp_response": "250 2.0.0 OK 1752741203 gsmtp",
  "accepted_at": "2026-07-17T09:14:03Z",
  "signature": "ed25519:...",
  "prev": "sha256:..."
}
```
The `prev` hash chains it into the ledger; the signature binds the contents; the
keyed hash keeps the recipient's address out of the artifact entirely.
:::

## Honest limits

:::tradeoffs What a certificate cannot prove
It proves the receiving server accepted the message over the recorded TLS session
and said so in the quoted response. It does not prove a human read it, and it cannot
prove which folder the message landed in — no email protocol offers either, and we
won't pretend otherwise. A `250` acceptance is the strongest artifact email can
produce; this makes that artifact portable, signed, and independently checkable.
:::

## Where to go next

Certificates pair with [customer-held keys and at-rest encryption](/features/encryption) —
evidence without exposure — and with the wider [compliance machinery](/features/compliance)
for retention, erasure, and hold. The [enterprise door](/enterprise) frames where
this fits; evaluating secure-email vendors? See the
[comparison](/compare/paubox-alternative).

## What exactly does a certificate prove?

That the named receiving mail server accepted this message over the recorded TLS session, said so in the quoted SMTP response, at the recorded time — signed by us, chained into a ledger that can't be edited afterward.

## Who can verify a certificate?

Anyone. Verification runs against our published Ed25519 public key — offline, without asking us, without trusting us. That's the point: evidence that survives our absence from the room.

## How does this square with GDPR erasure?

The recipient appears only as a keyed hash, so the certificate itself carries no readable personal data. When litigation requires it, legal hold supersedes erasure while active; when the hold lifts, normal erasure rules resume. Details on the compliance page .

## Can I export certificates in bulk?

Yes — GET /v1/certificates/export returns them in bulk, suitable for handing a complete evidence set to an auditor or counsel.