How We Diagnose a Cold Email Drop: The WarmInboxes Operator Playbook

Why write the rules down

Most cold email advice jumps from a symptom to a purchase: replies dropped, buy new domains. Sometimes that is right. More often it replaces healthy infrastructure because of a bad list, a weak offer or a broken DNS record, and the new domains fail the same way a few weeks later. These are the rules we run our own fleets and our clients’ by, and the ones the free Deliverability Agent follows when it answers you.

The decision tree

Low replies and a bounce spike are different problems

Low replies, no bounce spike: the ramp

If the reply rate fell but bounces did not jump, drop the affected slice to 5 cold emails per inbox a day, then climb: 5, then 10, then 15, each step only once the previous one is holding. If the infrastructure checks clean and the same copy was working before, the most common cause we see is the copy being recognised after it has gone out to enough people (fingerprinting). Raise warmup to 40 a day, rewrite the copy with heavy spintax and clean the list during the low-volume window. It is our read of the pattern rather than something the providers publish, so say it that way, and only after the checks.

A bounce spike: classify, then a full rest

Classify the bounces before anything else. Invalid addresses mean the list is the problem: pause it, clean and re-verify it, and keep healthy infrastructure out of that segment. Policy blocks, reputation refusals and heavy throttling mean the sender is the problem: stop cold sending entirely, keep warmup running, fix the cause, and retest before ramping. Sending less of what is bouncing is still sending it, so a bouncing sender does not go through the ramp until the bounces are understood.

Every new variable starts at 5 a day

A warm fleet is not a reason to launch at full capacity. New copy, a new list, a new ICP, a new offer or a new sending segment is a variable your infrastructure has not proven. Start it at 5 cold emails per inbox a day and ramp 5, then 10, then 15 as replies and bounces hold, while the proven campaign keeps running separately. A bad list then costs a few days on a few senders, not the fleet.

Warmup sits on top of the cold cap

The daily cap is for cold email; warmup runs on top of it, at least 2 warmup emails for every cold one (1:2), and 1:3 is the best ratio we have seen. Keep a Google inbox under 50 emails a day in total, cold and warmup together: past that, Google starts refusing sends with daily-limit errors. At 15 cold a day, 1:2 puts an inbox at 45; the 1:3 ideal fits at 12 cold or fewer.

The ratio is a WarmInboxes operating convention from fleet experience, not an industry law, and it moves with the provider, the mailbox’s and domain’s age, recent performance and whether the inbox is recovering.

Rest or replace: the trade-off is yours

For clearly degraded infrastructure, a full rest of about one to two weeks is a reasonable recovery attempt. It may not work. Weigh what waiting costs (the capacity and pipeline lost while it rests) against what replacing costs, how likely recovery is on the evidence, whether reserve inboxes are already warm, and how urgent the campaign is. A domain Google refuses on reputation past the retirement line does not rest away; a throttled inbox often does.

Replacement is a multi-signal decision

There is no “reply rate under 1% means replace”. Before calling infrastructure degraded, weigh:

• •the current reply rate against your own baseline, and how far it fell;
• •the bounce rate, and what the bounces say;
• •placement, if a seed test was run;
• •whether it is one provider, one domain, one inbox, or one campaign;
• •how sibling inboxes on the same campaign and list are doing;
• •changes to the list, copy, offer, links or tracking;
• •authentication, blocklists, reputation refusals and the tracking domain.

Then name the outcome: healthy, fixable, unclear, degraded, or capacity. Only degraded and capacity make new infrastructure the answer. One quiet inbox on a domain whose others reply is a mailbox problem: recreate it, don’t cancel it. Cancellation in the WarmInboxes app is by domain: a domain is cancelled together with all of its inboxes, and a single inbox on a domain is not cancelled on its own.

We ask for your numbers

Today the agent cannot read your sequencer. So before diagnosing a drop it asks: your normal reply rate and your current one, your bounce rate before and now, which inboxes and campaigns, whether it is Gmail or Microsoft recipients, and what changed. It never invents a baseline or a percentage drop. When monitoring can read campaign history, the same decision tree runs on that data; the diagnosis does not change, only where the numbers come from.

Say what is observed, label what is a guess

“Microsoft’s SCL is 7, so Outlook classified this as spam” is a reading. “Your infrastructure checks clean and this copy was working before, so in our experience the copy is being recognised” is our read of a pattern, labelled as ours. “Gmail fingerprinted your copy”, before anything has been checked, is a guess dressed as a fact, and we do not say it. The same goes for “burned”: that is a verdict for evidence, not for a dashboard number.

When new infrastructure is the answer

Size it before anyone buys, with the WarmInboxes Free MCP: Fleet Planner or the calculator. Prewarmed inboxes send from the day they land, delivered within 48 to 72 hours of payment; fresh inboxes cost less and are warmed for 14 to 21 days first. Either way, new copy and new lists still start at 5 a day.

The 53 questions we hear most, each answered with these rules, are in the operator question library.