Apollo Deliverability

---
name: apollo-deliverability
description: "Protect the sending asset on Apollo: mailbox health, warmup, volume limits, bounce and incident response, sending schedule. Use before launching and whenever deliverability looks off."
---

# Apollo Deliverability & Send (Infrastructure)

Keep the sending asset alive. Deliverability is the one place this library is firm rather than advisory, because a burned domain hurts the operator and does not come back quickly. Everything here protects the machine that makes outbound possible.

This phase assumes the sending stack already exists. If you have no dedicated domains or mailboxes yet, build them first with `sending-infrastructure` (Infrastructure), then come back here to keep them healthy.

## When to use

- Before launching (confirm the setup is safe).
- Weekly, as a health check (see `weekly-rhythm`).
- The moment bounces spike or replies fall off a cliff (see `references/incident-response.md`).

## Preflight: check the mailboxes

Run `apollo_email_accounts_index` (or `apollo email-accounts list` on the CLI). For each connected sending mailbox, confirm:
- It is a **dedicated sending domain**, not the company's primary domain, and it redirects to the main site.
- Warmup is on and has been running long enough.
- Reputation and daily send state look healthy.
- SPF, DKIM, and DMARC pass for its domain. For mailboxes connected to Apollo, read the stored verdicts with the domain diagnosis tool described in `sending-infrastructure`, and check how old they are.

## The rules that keep domains alive (firm)

- **Warm up 14 days minimum, 21 optimal, before any cold send.** Warmup never turns off; it runs in parallel with campaigns forever.
- **Up to 25 cold sends per mailbox per day.** Ramp from 5 to 10/day to the ceiling over 4 to 5 weeks.
- **Verify 100% of emails before sending.** Unverified equals bounce, and bounces kill domains.
- **Bounce rate under 2%.** 2 to 4% is a warning. At 4%, pause the campaign now and investigate.

### Read the configured daily limit instead of assuming it

The most common cause of "the campaign is barely sending" is not a broken campaign, it is a per-mailbox daily limit left at its warmup value and never raised. It is invisible unless you look, because everything reports as active and healthy.

**Read the limit from the mailbox itself.** `apollo email-accounts list` (CLI) returns each mailbox's `email_daily_threshold` (the daily cap), `max_outbound_emails_per_hour`, `seconds_delay_between_emails`, `limits_editable`, and its warmup status. **Do not use the analytics metric `email_daily_limit` as the ceiling:** on 2026-09-14 it reported 775 for a mailbox whose own setting was 25. Use analytics for what was actually sent, and the mailbox record for what is allowed.

**Changing a mailbox limit is a UI job.** No MCP tool or CLI command edits it. To cap one campaign without touching the mailbox, set `max_emails_per_day` on the sequence with `apollo_sequences_update`, and echo every step, touch, and template back, because that update deletes anything you leave out.

The arithmetic is worth doing explicitly at every review: **mailboxes × daily limit = your real ceiling**, regardless of how many contacts are enrolled. A stack of 200 mailboxes still capped at 1 per day from warmup sends 200 a day, not the 5,000 the mailbox count implies. If observed volume matches a suspiciously round number, that number is almost certainly a limit rather than a coincidence.

Read this before diagnosing list size, copy, or scheduling. It is a five-second check that explains most volume complaints.

### Bounce Guard: turn it on, then tighten it

**New Apollo feature, confirmed live 2026-08-31.** Apollo now pauses a sequence automatically when its bounce rate gets too high. It is **account-wide**, applying to every active sequence, and it is configured in the UI under deliverability settings. Turn it on first, then change the numbers, because the defaults are looser than they should be.

| Setting | Apollo default | Use instead | Note |
|---|---|---|---|
| Warning threshold | 4% | **3%** | 3 is the floor. Apollo will not accept a lower value, so 2% is not available even though it would be better. |
| Auto-pause threshold | 6% | **4%** | 6% is far past the point where a domain is taking damage. |
| Minimum volume | 200 emails | 200 (fixed) | **The trap. See below.** |
| Time range | Past 7 days | Past 7 days | |

**The minimum-volume gate is the thing to understand.** Bounce Guard does not evaluate at all until the sequence has sent **200 emails inside the time window**. Below that it is inert. So the protection is absent exactly when a new sending stack is most fragile: the first few days of a ramp, a small test cohort, or a low-volume campaign that never reaches 200 in seven days may **never** trigger the guard no matter how badly it bounces.

Two rules follow:

- **A small send is not a protected send.** If you are testing with 5, 20, or 50 contacts, Bounce Guard will not save you. Verify the list independently before sending and watch the results by hand.
- **Bounce Guard is a backstop, not the control.** It catches a disaster after roughly 8 bounces in 200 sends. Verifying the list before it goes near a sequence prevents them. Treat the guard as the thing that limits the damage from a mistake you have already made.

**Readable per sequence, not settable.** Probed 2026-08-31: `bounce_guard`, `bounce_guards`, `email_bounce_guard`, `settings/bounce_guard`, `email_deliverability_settings`, and `team_settings` all return 404 on REST, and there is no dedicated MCP tool. **But since 2026-09-14 every sequence object returned by the MCP** (`apollo_sequences_create`, `apollo_sequences_update`, `apollo_emailer_campaigns_show`) carries `auto_pause_enabled` and `auto_pause_config`, for example `{"evaluation_window_days": 7, "min_volume": 200, "warning_threshold_pct": 3.0, "auto_pause_threshold_pct": 4.0}`. So an agent can confirm the guard is on for a given sequence and read its thresholds before activation. Changing them headlessly is still unverified, so **set them in the UI as part of onboarding any account**, then read them back from the sequence.
- **Plain text only.** No HTML, images, tracking pixels, or link-heavy footers for cold.
- **Send business hours, weekdays, in the prospect's timezone.** Set this with `apollo_emailer_schedules_index`.
- **Keep backup infrastructure ready.** Run spare mailboxes, warmed and waiting: a few for an in-house team, closer to double for a large program or an agency. When something degrades you swap instead of stopping. This is the lesson that separates operators who scale from operators who stall.

## Sending schedule

Use `apollo_emailer_schedules_index` to pick or confirm a schedule that sends only in business hours on weekdays, in the target timezone. A sequence with no schedule uses the workspace default, so check it rather than assuming.

## Monitoring

Watch bounce rate and mailbox reputation continuously. Apollo's Data Health Center and inbox-placement tooling live in the UI (see `../operator-context/references/apollo-kb-map.md`); point the operator there for the deeper checks the MCP does not expose. If anything looks off, stop optimizing copy and fix deliverability first. You cannot out-write a reputation problem.

## Common mistakes

- Sending cold from the primary domain. Never.
- Launching before warmup is done to "save a week." You lose the domain instead.
- Optimizing copy while bounces are high. Deliverability gates everything.
- No backup mailboxes, so one bad week stops all sending.