We see the dip before your reply rates do.
A console that reads first-party sending telemetry, scores reputation risk per inbox provider, and trips a failover before the complaint-rate cliff.
It looks healthy for months.
Then it collapses "overnight."
A sending domain reads green for 2–3 months, then deliverability craters. It wasn't overnight — reputation eroded the whole time, invisibly.
The sequencer dashboard stays green because it reports a lagging warmup score — fine right up until it isn't.
Three facts make late detection inevitable.
Google wants bulk senders under 0.10% spam complaints and never at 0.30%. At cold-email volume, a handful of clicks crosses it.
Postmaster updates late, and counts only inbox-delivered mail. Once filtering starts, complainers never see it — the reported rate can fall as reputation craters.
Damage lands in days; recovery takes 4–8 weeks (Gmail wants 7 straight clean days). A miss costs weeks — a false alarm costs a day.
Stop watching the complaint rate.
The complaint rate is the last thing to break. By the time it spikes, the domain is already gone.
A flat dashboard. A line already falling. ≈ 10 days of runway.
One readable, time-boxed warning — early enough to act, specific enough to trust. That window is the difference between a preemptive save and a churned customer.
A leading risk score — per provider, smoothed, projected.
Smoothing turns a noisy daily complaint rate into one stable signal you can act on; a slope-to-cliff projection turns that trend into a date.
The earliest signal isn't Postmaster. It's the send itself.
| Layer | Signal | Source |
|---|---|---|
| LEADING | Deferrals · 4xx/5xx throttle & spam codes · bounce reasons | First-party MTA accounting-webhook telemetry, captured at send |
| LEADING | Inbox vs. spam placement | Seed-list panel |
| CONFIRMING | Spam rate · domain / IP reputation | Google Postmaster + Microsoft SNDS / JMRP |
The leading layer only exists because sending.ac owns the sending infrastructure. It already emits this telemetry — the same first-party stream warm.ac is built on.
A competitor layered on someone else's platform is blind to it.
A circuit breaker, then a hot-standby failover.
Because a miss costs weeks and a false alarm costs a day, the policy is a conservative breaker that trips on weak early signals.
A runnable console. Real engine, simulated data.
Synthetic 30-day scenario
A full timeline of a domain decaying at Gmail — with a Healthy ⇄ Critical toggle to replay either path.
The live risk engine
Beta-Binomial smoothing, slope projection, and per-ESP scoring — running in the browser, not faked.
The failover state machine
Healthy → Watch → Throttle → Failover → Cooldown, rendered with the standby pool and alert feed.
From synthetic console to automated failover.
Engine + console
- Risk engine on synthetic data
- Per-ESP scoring & lead-time view
- Failover state machine, visualized
Live ingest · real alerts
- Live MTA webhook for one ESP
- Postmaster / SNDS confirmation
- Real alerts to customers
Automated failover
- Automated failover execution
- Standby-pool orchestration
- Hands-off circuit breaking
See the dip before your reply rates do.
A leading, per-ESP early-warning console with a built-in failover plan — turning a churn-causing surprise into a preemptive save.
Live demo dewsentinel.vercel.app