# What we mean by “never”

> The precise meaning behind our strongest promises — no email lost, none sent twice, no one who unsubscribed hears from you again — with the assumptions stated.

Canonical: https://emailfast.dev/legal/definitions

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](/legal/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](/security)).

## "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](/legal/corrections) is for.