Deliverability as engineering, not folklore
Our own MTA, health-gated warmup, a reputation circuit breaker, honest bounce classification, and fair queueing — inspectable down to a single message.
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 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
550 5.7.1 Service unavailable; client [203.0.113.7] blockedThat'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
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 and how DMARC works. For day-to-day sending practice, start at the creator door; for the guarantees and controls around delivery, the enterprise door. Leaving an incumbent over deliverability answers? The SendGrid comparison is where to start.
Questions, answered plainly
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.