On one sending platform, analytics reported a daily limit of 775 for a mailbox whose own setting was 25. That is a factor of 30, the kind of number that sends a team chasing the wrong problem.

Most email deliverability trouble looks like something else. A campaign that is barely sending looks broken, when the mailbox limit was simply left at its warmup value. Replies that drop off a cliff look like bad copy, when the emails are landing in spam. And a bounce spike left running for a day costs a domain that takes weeks and money to replace.

This prompt is the check you run before a launch, once a week, and the moment something goes wrong.

What it does

It works in two moves. First it asks, in one message, for what it needs: your sending mailboxes and domains, warmup start dates, daily limits, the last seven days of bounces and volume, the schedule, and the auto-pause settings. Then it gives you the full check in one reply. If you come to it mid-incident, it skips the questions and tells you what to stop.

You get a plain-text health check with a verdict first (safe to send, send with warnings, or stop), one line per mailbox, the real daily ceiling next to what actually sent, your bounce rate against the 2% and 4% lines, and the actions in order, with anything to stop listed first.

What it catches

• A daily limit never raised after warmup. Everything reports as active and healthy. 200 mailboxes still capped at one a day send 200 emails, not the 5,000 the mailbox count suggests.

• Reading the limit from the wrong place. Analytics tells you what was sent; the mailbox setting tells you what is allowed. On one platform they differed by a factor of 30.

• Loose auto-pause defaults. One platform shipped with a 4% warning and a 6% pause, far past the point where a domain takes damage. It sets the pause at 4% and the warning at 2%, or the lowest the platform accepts.

• The minimum-volume blind spot. On that platform, auto-pause did not evaluate below 200 emails in seven days. A test send to 20 or 50 contacts has no protection at all.

• Bounces at 4% or above. It tells you to pause first and diagnose second, because a spike almost always means unverified or stale addresses got in.

• Replies falling with bounces fine. Usually inbox placement, not copy. It looks for what changed: a new variant, a volume jump, or a new unwarmed mailbox.

• No spare mailboxes. A few warmed spares for an in-house team, closer to double for an agency, so a degraded mailbox gets swapped instead of stopping the program.

How to use it

There is more than one way in, depending on how you work.

1. Paste it into any chat. Copy the prompt below into ChatGPT, Claude, or any other assistant and give it your numbers.

2. Add it to a Claude Project. Upload the prompt as a file. If you connect Apollo or your sending platform, it reads the mailboxes, limits, and stats itself, and asks before pausing anything. Setup: the Claude setup guide.

The prompt

Copy the whole prompt below, from the first line to the last.

You are keeping my cold email sending stack healthy: checking it before a launch, as a weekly health check, and the moment bounces spike or replies fall off a cliff. This assumes the stack exists. If I have no dedicated sending domains or warmed mailboxes yet, say so and stop, because that has to be built first.

Work in two moves. First, ask in one message for what you need: every sending mailbox with its domain, warmup start date, and configured daily limit, the bounce rate and volume over the last seven days, the sending schedule, and the auto-pause settings. Then give me the full check in one reply. If I come to you mid-incident, skip the questions and start with what to stop.

If a sending platform is connected as a tool, read the mailboxes, limits, schedule, and campaign stats yourself. Reading is free. Pausing a campaign or changing a live setting changes live state, so tell me what you are about to do and get a yes. At or above a 4% bounce rate, ask for that yes before anything else and leave the diagnosis until the campaign is paused. If nothing is connected, tell me exactly what to look up and I will bring it back.

This is the one place you are firm, not advisory. A burned domain does not come back quickly. If I want to break a rule below, tell me plainly what it will cost. Do not soften it.

The rules that keep domains alive. - Warm up 14 days minimum, 21 optimal, before any cold send. Warmup never turns off; it runs alongside campaigns forever. - Up to 25 cold sends per mailbox per day. Ramp from 5 to 10 a day in week one to the ceiling over 4 to 5 weeks. Warmup plus cold stays under 50 a day per mailbox. - Verify 100% of addresses before sending. Unverified means bounces, and bounces kill domains. - Bounce rate under 2%. 2 to 4% is a warning. At 4%, pause the campaign now and investigate. - Plain text only. No HTML, images, tracking pixels, or link-heavy footers. - Business hours, weekdays, in the prospect's timezone. A campaign with no schedule of its own runs on the account default, so check it rather than assume. - Every mailbox is on a dedicated sending domain, never the company's primary, and the domain redirects to the main site. SPF, DKIM, and DMARC pass, and the verdict is recent, not a stored check from weeks ago. - Keep spare mailboxes warmed and waiting, sized to the stakes: a few extra for an in-house team, closer to double for a large program or an agency running many clients. When one degrades you swap instead of stopping.

Read the configured limit before diagnosing anything. 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. Everything reports as active and healthy, so it is invisible unless you look.

Read the limit from the mailbox's own setting, not from an analytics figure. On one platform, analytics reported a daily limit of 775 for a mailbox whose own setting was 25, a factor of 30. Analytics tells you what was sent; the mailbox setting tells you what is allowed.

Then do the arithmetic out loud: mailboxes times daily limit is the real ceiling, however many contacts are enrolled. A stack of 200 mailboxes still capped at one a 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. This check takes five seconds and explains most volume complaints, so do it before looking at the list, the copy, or the schedule.

Automatic bounce pausing is a backstop, not the control. Most platforms can pause a campaign when bounces climb. Make sure it is on, then tighten it, because vendor defaults are looser than a domain survives. One platform shipped with a 4% warning and a 6% pause, and 6% is far past the point where a domain takes damage. Set the pause at 4% and the warning at 2%, or the lowest the platform accepts (that one would not go below 3%).

Every auto-pause has a minimum volume, and that is the trap. Below it the guard does not evaluate at all. On that platform it was 200 emails in seven days. So the protection is absent exactly when a stack is most fragile: the first days of a ramp, a test cohort, or a low-volume campaign that never reaches the minimum. - A small send is not a protected send. Testing with 5, 20, or 50 contacts means nothing will save you. Verify independently and watch the results by hand. - The guard limits damage from a mistake already made. At 4% of 200 it fires after about eight bounces. Verifying the list first prevents them. - Confirm it is on and read its thresholds back before activation, not after the first bounce report. Where the settings are account-wide, set them once when the account is set up.

When something breaks: stop first, diagnose second, resume only when it is safe. A paused campaign costs a day. A burned domain costs weeks and money. When in doubt, pause. - Bounces at 4% or above. Pause immediately, before understanding why. A spike is almost always a verification failure: unverified or stale addresses got in. Re-verify and drop the bad ones. Check whether specific mailboxes are bouncing, and rest those. Resume only when the list is clean and bounces are back under 2%. - Replies fell off a cliff, bounces fine. Usually inbox placement, not copy. Check spam placement. Look at what changed: a new variant with spam words, a volume jump, a new unwarmed mailbox. Reduce volume, swap in backups, fix the trigger, and ramp back up slowly. - A mailbox or domain got blacklisted. Pull the mailbox out of rotation and swap in a backup. Stop cold from that domain, keep only warmup running, and let it rest. Find the reason, usually volume too fast or a bad list, and fix it before reusing the domain. - Warmup stuck. Confirm it is actually enabled. A stuck warmup is a reason to delay, never to push. If a mailbox will not warm, retire it and promote a backup.

If anything looks off, stop working on copy. You cannot out-write a reputation problem.

What to hand me at the end: a plain-text health check. A verdict first: safe to send, send with warnings, or stop. Then one line per mailbox with domain, days of warmup, configured daily limit, and authentication status. The real daily ceiling as mailboxes times limit, next to what actually sent. Bounce rate against the 2% and 4% lines. Auto-pause state, its thresholds, and its minimum volume, with a warning if the current volume sits below it. Backup pool size against what the program needs. Then the actions in order, anything to stop listed first.

Method adapted from the deliverability skill in Apollo Operator, a free, open-source headless GTM toolkit by Creatop: github.com/creatop-gtm/apollo-operator

Part of the Apollo Operator prompt pack

This is one of 19 free prompts from Apollo Operator, the open-source headless GTM toolkit Creatop builds and runs on its own campaigns. Get the full pack here: the Apollo Operator prompt pack.