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 while active: held certificates survive deletion requests for as long as litigation requires, and normal erasure resumes when the hold lifts.
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.
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. 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.