# Deliverability as engineering, not folklore

> An email deliverability platform on pipes we own: health-gated warmup, a reputation circuit breaker, VERP bounce classification, and per-tenant fair queueing.

Canonical: https://emailfast.dev/features/deliverability

## The parts, and how they connect

An email deliverability platform earns trust with mechanisms you can name and
inspect. Start with the foundation: Email Fast runs its own mail transfer agent, warmup engine, reputation breaker, and per-tenant fair queue — the pipes are ours, not resold. Everything below builds on
owning that path.

## How it works

| Mechanism | What it does |
|---|---|
| IP warmup | Health-gated ramp per receiver group — volume grows only on green signals. Arms with live sending |
| Reputation circuit breaker | Throttles or suspends a deteriorating stream before mailbox providers do it for you |
| Blocklist monitoring | Watches listings and shifts traffic off a listed IP automatically. Arms at launch |
| Bounce classification | VERP-based; hard, soft, or block — and a policy block never suppresses a deliverable address |
| Complaint loops | FBL reports become instant suppressions. Arms at launch |
| Report ingestion | DMARC aggregate and TLS-RPT reports, parsed and surfaced |
| Fair queueing | Per-tenant — one tenant's blast can't delay another tenant's password reset |

Every send is inspectable individually — the
[delivery inspector](/features/observability) reconstructs any message's full story.

## Proof and protocol hygiene

Two details that punch above their weight: one-click unsubscribe per RFC 8058, with the headers signed under DKIM so stripping them in transit breaks the signature. And when a delivery
needs to be provable rather than just observable: 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.

## The evidence

:::panel Why "block" is its own bounce class
```
550 5.7.1 Service unavailable; client [203.0.113.7] blocked
```
That's a policy block — a statement about the sending IP's standing, not the
address's validity. Classify it "hard" and you delete a deliverable subscriber.
We classify it `block`, fix the standing, and the address survives.
Misclassification here is how platforms quietly shred good lists.
:::

## Honest limits

:::tradeoffs No numbers without history
The pieces that need live traffic — warmup, complaint loops, blocklist shift-off —
arm at launch, and we publish no delivery-performance figures until real history
exists to back them. Also true: no engine rescues bad sending. A purchased list or a
surprise blast will hurt on our infrastructure too. The machinery makes good sending
compound; it doesn't make bad sending safe.
:::

## Where to go next

Background reading: [what IP warmup is](/glossary/ip-warmup) and
[how DMARC works](/glossary/dmarc). For day-to-day sending practice, start at the
[creator door](/creators); for the guarantees and controls around delivery, the
[enterprise door](/enterprise). Leaving an incumbent over deliverability answers?
The [SendGrid comparison](/compare/sendgrid-alternative) is where to start.

## What works today and what arms at launch?

Built in now: the reputation circuit breaker, VERP bounce classification, DMARC aggregate and TLS-RPT ingestion, and per-tenant fair queueing. Arming with live sending: IP warmup. Arming at launch: blocklist monitoring with automatic traffic shift, and FBL complaint loops.

## Why VERP?

Variable envelope return paths give every send a unique bounce address, so a bounce identifies exactly which message to which recipient failed — no parsing guesswork, no misattributed suppressions.

## What's the difference between a hard bounce and a policy block?

A hard bounce says the address doesn't exist; a policy block says the receiving server objected to the sending IP or content at that moment. We classify them separately, and a policy block never suppresses a deliverable address.

## Can another tenant's sending delay mine?

Queueing is per-tenant and fair: one tenant's million-message blast can't sit in front of another tenant's password reset. Reputation problems are contained by the circuit breaker before mailbox providers react.