What an email receipt should look like

A dashboard row is an assertion. A receipt is evidence. The fields a delivery certificate needs, and the reasons behind each one.

Published 2026-07-17

Somewhere today an agency is telling a client that the campaign went out, and the client is asking how they know. What the agency has is a dashboard: a row that says delivered, rendered by the same vendor whose performance is in question, stored in that vendor's database, editable by that vendor's engineers. As a record of work done, it is fine. As evidence, it is testimony — an interested party's assertion that nobody else can check.

Most of the time, testimony is enough. Then a dispute arrives: a client contesting an invoice, a compliance team asked to prove a required notice went out, a legal process that turns on whether a notification happened. The question changes from "what does the dashboard say?" to "why should anyone believe it?" — and the industry's standard answer collapses, because the answer is "because the sender says so."

An email receipt should survive that question. On Email Fast, 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. Each of those fields is there for a reason, and the reasons are the argument.

The recipient, as a keyed hash

Receipts travel: into reports, ticket threads, audit files, court exhibits. If a receipt carries the bare address, every hop leaks personal data. Stored as a keyed hash, the receipt still does its job. A party who already knows the address can confirm the receipt refers to it; a party who doesn't learns nothing. Proof for the people in the dispute, silence for everyone else.

The verbatim SMTP response

This is the load-bearing field. When a mail server accepts a message it says so in its own words — a 250 line, often carrying the receiving system's own queue identifier. Recording that response verbatim, rather than a summary like delivered, changes the nature of the record. It is no longer our characterization of what happened; it is the counterparty's own statement, which the receiving operator can correlate against their own logs. A dashboard paraphrases. A receipt quotes.

The connection facts

The receiving server's name, the TLS version and cipher, and the timestamps pin the event to a specific machine, a specific encrypted channel, a specific moment. Vague evidence invites vague disputes. Specific evidence narrows what can be contested.

The signature

A signature over the certificate makes the document self-authenticating: anyone can check it against our published key, and any alteration breaks it. The receipt no longer depends on being fetched fresh from our dashboard. It can sit in a case file for years and still verify.

The chain

A signature proves who issued a document, not when. An issuer could still quietly mint a flattering receipt after the fact, or delete an inconvenient one. Chaining certificates into a tamper-evident ledger closes that gap: each entry commits to the ones before it, so history is append-only in a way an outsider can check. Rewriting the past stops the chain from verifying.

The property all of this buys

Independent verifiability. Every field is chosen so that a third party — an auditor, an opposing counsel, a skeptical client — can check the receipt without asking us to vouch for ourselves. That is the line between evidence and testimony, and it is the property the industry's dashboards do not have. Evidence that requires trusting its issuer is just testimony with formatting.

What a receipt does not prove

Honesty requires the other half. A delivery certificate proves that the receiving mail server accepted the message over an authenticated, encrypted connection at a recorded time. It does not prove the message landed in the inbox rather than the spam folder, and it does not prove a human read it. No honest receipt can — those events happen inside systems the sender does not control, and a vendor who implies otherwise is selling the dashboard again.

But notice what most disputes are actually about: was it sent, when, and to whose server. The handoff. That is exactly the ground the certificate nails down, with the receiving side's own words inside it.

The next time a platform tells you a message was delivered, ask the only question that matters: could I verify that without trusting you? If the answer is no, you have a dashboard. We built the other thing.