ESP-Aware Routing
Pick the mailbox most likely to land in inbox for each recipient's email service provider
What ESP-Aware Routing Is
Superkabe knows which Email Service Provider (ESP) the recipient uses — Gmail, Outlook/Microsoft, Mimecast, or a generic SMTP host — by classifying their MX records on first ingest and caching the result. When dispatching a sequence step, the sequencer doesn't pick a mailbox at random; it picks the mailbox most likely to inbox for that specific ESP, based on a weighted formula that combines remaining daily capacity with each mailbox's historical performance against that ESP.
The result: a Gmail-strong mailbox gets fed Gmail recipients. An Outlook-strong mailbox gets fed Outlook recipients. Performance signals stop being averaged into mush.
In one sentence
Score each candidate mailbox as 0.6 × capacity + 0.4 × per-ESP performance, pick the highest, send.
Why This Matters
Different ESPs run different filters. Gmail's spam classifier weights different signals than Microsoft's SmartScreen. Mimecast looks at things neither of them care about. A mailbox with a stellar reputation against Gmail can be silently spam-foldered by Outlook — and you'd never see it from a uniform pool average.
Single-pool routing — picking the "next mailbox in rotation" with no awareness of the recipient's ESP — wastes the strongest signal you have: which mailbox actually performs against which inbox provider. ESP-aware routing keeps that signal alive and acts on it every send.
Supported ESPs
Every recipient domain falls into one of four buckets. Mailbox performance is tracked separately for each bucket.
| Bucket | Domains / Detection | Notes |
|---|---|---|
| Gmail | gmail.com, googlemail.com + Google Workspace MX (aspmx.l.google.com) | Largest bucket for most B2B lists |
| Microsoft | outlook.com, hotmail.com, live.com + Microsoft 365 MX (*.protection.outlook.com) | Strictest filtering; reputation-sensitive |
| Mimecast | Detected via MX (*.mimecast.com) | Common in regulated industries |
| Generic / Custom SMTP | Everything else — Proofpoint, Zoho, custom self-hosted, etc. | Catch-all bucket; broad but less predictable |
ESP classification happens once per recipient domain and is cached on the domain insight record. Re-classification fires on MX-record change.
The 60/40 Score
For each candidate mailbox attached to the campaign, Superkabe computes a routing score:
score = (0.6 × capacity) + (0.4 × esp_performance)| Component | Weight | What It Measures |
|---|---|---|
| Capacity | 60% | Sends remaining today vs. daily cap, normalized 0-1. A mailbox with 200/250 remaining scores 0.80; a mailbox at its cap scores 0. |
| Per-ESP performance | 40% | Rolling 100-send window of bounce rate, reply rate, and engagement signals — for this mailbox, against this specific ESP only. |
The mailbox with the highest combined score wins the next send. Capacity is weighted more heavily because pushing a mailbox over its cap is an immediate, unambiguous risk; performance is a slower-moving signal. The 40% performance weight is enough to consistently steer traffic toward the right mailbox-ESP pairings without letting a single bad day starve the queue.
Worked example
Recipient is on Gmail. Three candidate mailboxes:
- – Mailbox A: 0.90 capacity, 0.95 Gmail performance → score = 0.54 + 0.38 = 0.92
- – Mailbox B: 1.00 capacity, 0.60 Gmail performance → score = 0.60 + 0.24 = 0.84
- – Mailbox C: 0.50 capacity, 0.95 Gmail performance → score = 0.30 + 0.38 = 0.68
Mailbox A wins. B has more headroom but a worse Gmail track record; C is a Gmail star but nearly tapped out.
Bucket Health
A mailbox can be excellent at Gmail and terrible at Outlook. Superkabe doesn't want to lose a great Gmail sender just because Outlook is mad at it.
When a mailbox's per-ESP performance crosses an unhealthy threshold — for example, bounce rate above 2% within the last 100 sends to that ESP — Superkabe stops routing that ESP's traffic to that mailbox. The mailbox stays fully active for every other ESP it's healthy against.
Per-ESP suspension, not full pause
This is different from the platform-rules state machine, which pauses an entire mailbox when global bounce thresholds breach. Per-ESP suspension is finer-grained: one bad bucket doesn't kill the whole mailbox. Global pauses still apply on top.
Bucket Bypass / Override
Most teams should leave routing on auto. But for specialist campaigns there's a campaign-level override that constrains which buckets a campaign's mailboxes can serve.
Example: a campaign tuned specifically for Outlook recipients can be set to only route Outlook traffic to a designated set of Outlook-strong mailboxes. Gmail or Mimecast recipients matched to that campaign will be routed elsewhere or held.
Campaign Settings → Advanced Routing → Restrict to ESP buckets: [Microsoft]When a Bucket Has No Healthy Mailboxes
If every mailbox on the campaign is suspended for the recipient's ESP — or simply doesn't have any with a healthy track record there yet — Superkabe falls back in this order:
- Generic SMTP fallback: route to the next-best mailbox in any bucket — typically a generic SMTP mailbox with broad cross-ESP performance — provided capacity is available.
- Hold + alert: if no healthy fallback exists, keep the lead in
heldstate and post a Slack notification to the operator with the ESP, the campaign, and the suspended mailboxes.
The held lead is automatically retried on the next dispatcher tick. As soon as a mailbox comes back healthy for that ESP — or the operator attaches a new one — sending resumes without intervention.
Visibility in the Dashboard
Two pages surface the routing system:
/dashboard/mailboxes— per-mailbox detail page shows a four-column ESP performance grid: bounce rate, reply rate, engagement, and current health status (healthy / suspended) for Gmail, Microsoft, Mimecast, and generic SMTP./dashboard/load-balancing— aggregate view: bucket health across the org, recent routing decisions with the chosen mailbox and its score breakdown, and any bucket-bypass overrides currently active.
Per-Mailbox Capacity
Capacity is a separate concept from ESP performance. Every connected mailbox has a daily send cap configured at provider level:
| Provider | Default Cap | Notes |
|---|---|---|
| Gmail (free) | 250 / day | Hard provider limit |
| Google Workspace | 500 / day | External recipient limit |
| Microsoft 365 | 300-2,000 / day | Tenant-dependent; conservative default 300 |
| SMTP / custom | configurable | Set by operator on connect |
Capacity available = daily cap − sends already dispatched today, with warmup ramps applied for new or recovering mailboxes. ESP routing operates strictly within capacity: a mailbox that's tapped out for the day is simply not a candidate, regardless of its per-ESP performance.
Interaction with Protection Mode
Superkabe runs in two modes for outbound:
- Native sequencer: Superkabe dispatches directly through your connected Gmail, Microsoft 365, or SMTP mailboxes. ESP-aware routing runs in the dispatcher itself — every send is scored and assigned in real time.
- Protection mode (Smartlead, Instantly, EmailBison): when a third-party platform owns the actual sending, Superkabe enforces ESP routing at the protection layer instead. Superkabe selects the right mailbox per recipient and instructs the platform to use it, rather than letting the platform's own (uniform) rotation pick. The 60/40 logic is identical; only the dispatch transport changes.
Either way, mailbox-by-ESP performance keeps accumulating from delivery and engagement signals, so the routing model improves over time regardless of which transport you use.