What we mean by “never”
The homepage makes three absolute promises. Absolutes deserve definitions, so here is exactly what each one means, how it works, and where its edges are.
Facts verified 2026-07-19 — corrections: hello@emailfast.dev
We keep the bold sentence — "no email gets lost, none gets sent twice, and nobody who unsubscribed ever hears from you again" — because it's true. Here is precisely what each clause promises, and the assumptions it rests on. These definitions map to the same claims the site is built from, and are subject to the liability caps in our Terms.
"No email gets lost"
What it means: a 202 from the API means the send is committed to a durable, partitioned outbox before we answer — a crash can't lose it, and a retry with the same idempotency key can't double-send. Once the API returns 202, the message is recorded in a durable, partitioned outbox before we answer, so a process crash or a restart cannot silently drop it — it resumes.
The assumptions. "Accepted" is the boundary of this promise: it covers messages we have accepted (a 202), not requests that failed validation, were rejected by policy, or never reached us. After acceptance, a message can still legitimately bounce or be suppressed — that is delivery reality, reported to you as an event, not a lost message. Durability is of the committed message; catastrophic simultaneous loss of the primary datastore and its backups is outside any single-service promise (see our disaster-recovery posture on the security page).
"None gets sent twice"
What it means: every send — REST, SMTP, browser SDK, compatibility endpoints, broadcasts, automations — passes through one admission gate: idempotency, suppression, quota, and content policy in a single checkpoint no ingress can skip. Every send passes one admission gate, and a retry carrying the same idempotency key cannot create a second send — the first committed result is returned instead.
The assumptions. De-duplication is keyed on the idempotency key you supply (or, for some ingress paths, one we derive) within its retention window. Two genuinely distinct sends — different keys, or the same recipient in two separate campaigns you deliberately send — are not "the same" email and will both go out. Send the same key to get exactly-once; send different keys to send different mail.
"Nobody who unsubscribed ever hears from you again"
What it means: an unsubscribe is enforced at the admission gate for every ingress path — API, SMTP, SDK, broadcasts, automations — not just the one that sent the original message, and one-click unsubscribe per RFC 8058, with the headers signed under DKIM so stripping them in transit breaks the signature — so an unsubscribe link can't be stripped in transit without breaking the signature.
The assumptions. Suppression is scoped to the sending project and, where you use them, to a message stream or topic — so a person can unsubscribe from your marketing list while still receiving the transactional receipts they asked for, which is the law and the right behavior. If that same person later re-consents (fills in your signup form again, opts back in), that is a new, recorded consent — honoring it is you acting on their fresh request, not us leaking past an unsubscribe.
Found a case where one of these didn't hold? That's exactly what our corrections policy is for.