Delivery you can prove to someone who doesn't trust you
Ed25519-signed certificates for delivered messages, chained into a tamper-evident ledger, exportable in bulk, and verifiable against our published public key.
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
- 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.
- Each certificate is appended to a hash-chained WORM ledger: write-once, append-only. History can be extended, never edited.
- Anyone can verify a certificate against our published public key — offline, independently.
- Bulk export is one call:
GET /v1/certificates/export.
Legal hold is built in and supersedes erasure for the delivery evidence while active: for a held subject, the recipient records and delivery transcript are retained until an authorized operator releases the hold. Precisely what a hold preserves — and its one limit for at-rest-encrypted content — is in the delivery-certificate scope note.
The evidence
{
"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
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.
The full certificate scope note states exactly what a certificate does and does not attest — including that it is not a qualified electronic-delivery service and does not decide how any tribunal would weigh it.
Where to go next
Certificates pair with customer-held keys and at-rest encryption — evidence without exposure — and with the wider compliance machinery for retention, erasure, and hold. The enterprise door frames where this fits; evaluating secure-email vendors? See the comparison.
Questions, answered plainly
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. Legal hold supersedes erasure while active and stays until an authorized operator releases it; when it lifts, normal erasure rules resume. Details on the compliance page and the certificate scope note.
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.