Deliverability · 7 min read
Your warmup dashboard is probably lying to you
Two domains, same setup. One captured 17 replies from 134 sends. The other captured zero from 99 and reported nothing wrong. How to tell which one you have.
Mukesh Yadav
Founder, Raechly
We had two sending domains warming at the same time. Same schedule, same pool, same code path.
One of them was working: 134 warmup messages out, 17 replies captured. The other showed 99 messages out and zero replies in. No error. No warning. The warmup counter incremented happily every hour, the mailbox progressed through its ramp, and the dashboard was perfectly content.
The second domain was not warming at all. It had never warmed. Every reply sent to it had bounced with “Address not found” for weeks, and nothing in the system knew.
What actually broke
The domain was getbee.app, and its MX records pointed at Google Workspace. That is correct and intentional, because real company mail arrives there. But warmup reply capture in our setup runs through Cloudflare Email Routing, which needs the MX to point at Cloudflare.
So the loop looked like this. We sent warmup mail out through SES. The pool account received it and replied. The reply arrived at rankflow@getbee.app, hit Google Workspace, found no such mailbox, and bounced. The reply never reached our capture worker, so it was never recorded.
From inside the platform, sends succeeded. That was the only thing being measured.
Meanwhile vizuals.co, whose MX was on Cloudflare, captured 17 replies from 134 sends and was genuinely building history.
Why this is a category-wide problem
Our version of this bug was ours. The shape of it is not.
Warmup is sold as a number. You are shown threads sent, replies received, a health percentage, maybe a little graph trending up. In almost every platform on the market, the inboxes generating those replies belong to the vendor’s network. You cannot open them. You cannot verify a single one.
That means the reply count is an assertion, and you have no way to check it. If the inbound path breaks — MX change, routing rule deleted, subdomain misconfigured, provider migration — the sending half keeps working perfectly. Sends are easy. Sends almost never fail. The number that would tell you something is wrong is the one you cannot independently confirm.
You find out weeks later, when placement on a real campaign is bad and you have no idea why.
The diagnostic
Ignore the health score. Look at two numbers and compare them:
- Warmup messages sent
- Warmup replies received
If sends are climbing and replies are flat at or near zero, the loop is broken. That is not a slow start and it is not a quiet week. Warmup with no inbound is a mailbox talking to itself, and no amount of additional volume will fix it, because volume was never the mechanism. Engagement was.
A working ratio looks roughly like ours on vizuals.co: 134 out, 17 back. You do not need one reply per send. You need the count to be meaningfully non-zero and to grow with sends.
What we changed
Three things, in order.
We made reply capture explicit. Every mailbox now carries a reply_capture flag. It is not inferred from configuration or assumed at creation; it is reconciled hourly against the routing provider, and it is either true or it is not.
We gated sending on it. A mailbox without verified reply capture does not send. Not campaign mail, not warmup. This is the part that makes the flag worth having, because a warning nobody reads is the same as no warning. If the loop cannot be verified, the platform refuses rather than proceeding with numbers it cannot stand behind.
We stopped warming from domains we should never have warmed from. getbee.app is where our real mail lives. Enabling Cloudflare Email Routing on it would have hijacked the MX away from Google Workspace and taken down company email to fix a warmup problem. The correct answer was not to make it work. The correct answer was to never warm from that domain in the first place, which is also just good practice.
Warmup now runs only on domains where inbound is genuinely captured.
What to do about your setup
You probably cannot inspect your vendor’s warmup network. You can still run three checks.
Send a message to your sending address from an unrelated inbox. Use a personal account, something outside your organisation entirely. If it does not arrive somewhere you can see, replies from real prospects are not arriving either. This takes two minutes and catches most of it.
Check the ratio, not the score. Find warmup sends and warmup replies as raw counts. If your platform only shows a percentage, that is itself informative.
Confirm which domain your MX serves. If your sending domain is also your company domain, inbound is going to your corporate provider, and whatever your platform believes about reply capture is probably wrong. This is the single most common version of the bug.
The broader point
Deliverability tooling has a measurement problem. The things that are easy to count are sends, and sends are the thing that essentially always works. The things that decide placement — engagement, reply behaviour, whether a human ever interacted — are harder to observe and much easier to report optimistically.
When you are evaluating any platform, the useful question is not what it measures. It is what it refuses to do when it cannot measure. A tool that keeps sending from a mailbox whose inbound path is unverified has chosen to show you a number over telling you the truth.
We spent weeks warming a domain that was never warming. The cost was not the wasted sends. It was the confidence.
Related reading: reply capture, email warmup, and why you should never send cold email from your primary domain.