There's a pattern we see constantly at Beanstalk. A team starts running cold email, picks Apollo.io because it does everything — prospecting, enrichment, sequencing, sending — and for a while it works fine. Then they try to scale. Reply rates drop off a cliff. Domains get flagged. Emails stop hitting the inbox. They spend weeks troubleshooting copy and subject lines, convinced the message is the problem. Most of the time, it's not the message. It's the infrastructure. Specifically, it's Apollo mail — the built-in email sending inside Apollo.io — being asked to do a job it wasn't designed for.
This post breaks down what Apollo mail actually is, where it works, where it falls apart, and what the right infrastructure play looks like when you're serious about cold email at volume.
What Apollo Mail Actually Is
Apollo.io is a sales intelligence and engagement platform. Its core product is the lead database — 275M+ contacts, prospecting filters, intent data, company enrichment. That part of Apollo is genuinely good. It's one of the better prospecting tools available.
Apollo mail refers to the email sending capability built directly into the platform. When you connect a mailbox to Apollo (Google, Microsoft, or SMTP), Apollo's sequencer sends outbound emails through that connection. You build sequences in Apollo, set the steps, and Apollo sends through your connected inbox.
What a lot of people miss: Apollo also offers its own domain and mailbox generation feature. You can spin up sending domains and inboxes directly inside Apollo without setting anything up externally. The pitch is convenience — one platform handles your contact database, your sequences, and your sending infrastructure.
That convenience is exactly where the problem starts.
Why Apollo Mail Works Fine at Low Volume
Look, for a small team doing low-volume prospecting, Apollo's email sending isn't going to cause you serious problems. If you're sending 20-30 emails a day from one connected mailbox to warm up contacts and close a handful of deals, Apollo's sequencer is fine. The tool does what it says.
The use case Apollo mail was actually built for: an SDR who needs one inbox, one sequence, and one platform to manage the whole workflow. Convenience is real. Not having to switch between five different tools has real value for a solo rep or a small team that isn't trying to run volume campaigns.
Where Apollo shines is what it was purpose-built for: data. The prospecting filters, enrichment waterfall, and contact database are strong. If your cold email workflow is "find contacts in Apollo, enrich them, send manually or low-volume," Apollo mail isn't your bottleneck. The infrastructure is not being pushed hard enough to fail.
The problems surface when you try to scale.
Why Apollo Mail Breaks Down at Scale
Here's the thing about cold email infrastructure: it's not just whether the emails send. It's whether they land in the inbox. And at volume, there are several compounding reasons why Apollo mail starts delivering bad results.
Shared IP Infrastructure
When you send through Apollo's sequencer, you're not the only one sending. Apollo has a massive user base — tens of thousands of teams all pushing emails through the platform. That creates a shared sending environment. If other Apollo users on the same IP pool are sending to bad lists, hammering inboxes with spammy sequences, or getting high complaint rates, their behavior affects your sender reputation.
This is one of the fundamental problems with any all-in-one tool at scale. The infrastructure is shared by design, because it's cheaper to operate that way. But it means you have zero control over who you're sharing reputation with.
What we actually see: identical emails with identical copy landing in inbox from a dedicated sending domain and hitting spam from an Apollo-connected mailbox. Same copy. Same list. Same targeting. Different infrastructure. The difference is the infrastructure, not the message.
Apollo Dropped Their Native Warmup
Apollo actually removed their built-in email warmup tool. They now recommend third-party warmup services. That's a significant problem if you're relying on Apollo as a one-stop shop, because warmup is not optional — it's the difference between a domain that lands in inbox and one that goes straight to spam.
The right warmup approach in 2026: 2 weeks minimum before sending any cold volume, gradual ramp from very low daily sends, and ongoing warmup running in parallel with your live sends. If you're managing this yourself on top of running your prospecting and sequences, that's three separate systems to keep track of.
Sending Limits That Cap Your Volume
Apollo's own recommendations cap you at 50 emails per mailbox per day, with a hard ceiling of 100 emails per domain including warmup volume. To give you an idea of what this means in practice: to send 2,000 cold emails per day through Apollo-connected inboxes, you'd need 40+ mailboxes across 20+ domains, all properly warmed, all with correct DNS. Managing that inside Apollo is possible, but it's not what the tool is built for.
For context, the realistic sending rates we work with at ScaledMail are 5-10 cold emails per day for Microsoft inboxes and 15-25 per day for Google — and that's with properly isolated, fully warmed infrastructure. The infrastructure caps aren't unique to Apollo. But the lack of tooling to manage that infrastructure at scale inside Apollo is the issue.
The ESP Matching Trap
There's a popular tactic called ESP matching — sending Google-connected emails to Gmail recipients and Microsoft-connected emails to Outlook recipients, on the theory that matching the ESP improves deliverability. Here's my take on this: it's a trap.
When you send from a Google inbox to a Google inbox, Google sees both sides of the transaction. They see your outbound sending reputation AND they can see how recipients are engaging with your emails on their inbound side. You're essentially giving Google a complete picture of your cold sending behavior. That's the last thing you want at volume. Spread your sends across Microsoft and Google inboxes without worrying about ESP matching — the signal you're trying to game isn't worth the data you're handing over.
The One-Stop Shop Trap
Apollo's pitch is a single platform for everything. That's a genuinely appealing value proposition. Less context switching, one invoice, one support relationship. I get why teams choose it.
But here's the thing — at some point you have to decide what you're actually trying to do. If you're trying to close deals, your primary constraint is volume and deliverability. And the all-in-one convenience of Apollo comes at a direct cost to both.
The one-stop shop design means Apollo's infrastructure has to serve a massive, diverse user base with wildly different sending behaviors. They can't build dedicated infrastructure for each customer — the economics don't work at that scale. So they build shared infrastructure that's good enough for most customers most of the time. That "good enough" threshold is fine at low volume. It's not fine when you're trying to run 10,000 emails a day.
The other problem with all-in-one is lock-in. When your domain health, your warmup, your DNS config, and your sequences all live inside one platform, switching any piece becomes expensive. If Apollo's deliverability degrades (which it does, periodically, usually due to abuse on shared infrastructure), you're stuck trying to troubleshoot inside a black box where you can't see what's actually happening at the infrastructure level.
We've had clients come to ScaledMail after torching three or four domains inside Apollo trying to figure out why they couldn't get through. The domains weren't the problem — the shared infrastructure was. But because everything was locked inside Apollo, they kept burning domains thinking the next one would be different.
What Dedicated Infrastructure Actually Gives You
The play isn't complicated. Use Apollo for what it's genuinely excellent at — finding and enriching contacts, building targeted lists, pulling intent signals. Then route those contacts into dedicated sending infrastructure that was built specifically for cold email volume.
Here's what dedicated infrastructure actually means in practice:
- Your own isolated domains. Not shared with thousands of other senders. Your sending reputation is yours alone to build or burn — no one else's behavior can affect it.
- Proper DNS from the start. SPF, DKIM, and DMARC configured correctly on every domain before a single email goes out. Bad DNS is probably the fastest way to tank deliverability, and it's completely avoidable.
- Controlled warmup. A real warmup process — 2 weeks minimum — running before any cold volume, with ongoing warmup running in parallel with live sends to maintain sender reputation.
- Expert monitoring. Someone actually watching inbox health, blacklist status, and bounce rates. Not a dashboard you check weekly — active management by people who know what flagged accounts look like before they become a problem.
- Volume that actually scales. 217,600+ inboxes and 20 million+ cold emails per month is what proper infrastructure looks like at scale. The constraint isn't the platform — it's your list quality and copy.
How to Actually Set This Up: Apollo + ScaledMail
The thing is, you don't have to choose between Apollo and dedicated infrastructure. You can use both. The right setup looks like this:
Use Apollo for prospecting and enrichment. Build your lists, filter by ICP, enrich contacts, pull intent signals. Export your verified contacts. This is genuinely one of the better prospecting tools available and there's no reason to stop using it for what it's good at.
Route your contacts to dedicated infrastructure. ScaledMail provisions your Google Workspace, Microsoft 365, and SMTP inboxes on isolated tenant infrastructure. Full DNS setup on every domain. Managed warmup from day one. You can still use Apollo's sequencer — or switch to Instantly, Smartlead, EmailBison, whatever you prefer — because ScaledMail is not a sequencer. We're the infrastructure layer. You keep your sequencer choice.
Let the warmup run before you send cold volume. Two weeks minimum, ideally three. We set this up as part of onboarding and run it in parallel with your live campaigns once they're live. The warmup doesn't stop just because you started sending.
Monitor and adjust. Our team actively watches inbox health across all managed domains. When something starts drifting — bounce rate creeping up, engagement dropping, a blacklist flag — we catch it before it becomes a burned domain. That's the difference between managed infrastructure and a self-serve tool.
Setup takes 2-4 business days. If you're planning a campaign launch, the window is shorter than you think — get infrastructure sorted before you need it, not the day you want to start sending.
More on how we build cold email infrastructure: ScaledMail Blog.
Frequently Asked Questions About Apollo Mail
Can you use Apollo mail for cold email outreach?
Yes, you can. Apollo's built-in email sending works for low-volume cold outreach — 20-50 emails per day from a single connected mailbox is where it performs reasonably well. The problems surface when you push volume, when you're managing multiple domains, or when you need granular control over warmup and deliverability monitoring. For anything above a few hundred emails per day across a team, dedicated infrastructure handles it better.
Does Apollo have email warmup built in?
Not anymore. Apollo removed their native email warmup feature and now directs users to third-party warmup tools. If you're running campaigns through Apollo, you need to set up warmup separately — MailReach, Lemwarm, or similar. This is a significant gap if you bought into Apollo as an all-in-one sending platform.
Why are my Apollo emails going to spam?
A few common causes: shared IP reputation from Apollo's user base affecting your deliverability, incorrect or missing DNS records (SPF/DKIM/DMARC), insufficient warmup before ramping volume, or sending to unverified lists with high bounce rates. The first one — shared IP contamination — is the hardest to fix inside Apollo because you can't control what other users on the same infrastructure are doing. If you've ruled out DNS and list quality, the infrastructure itself is likely the issue.
What's a better alternative to Apollo mail for cold email sending?
The right approach is to separate prospecting from sending infrastructure. Use Apollo for what it's actually excellent at — finding and enriching contacts. For sending, use dedicated infrastructure (ScaledMail, or build your own on isolated Google Workspace and Microsoft 365 tenants) and connect it to whichever sequencer fits your workflow. This separation gives you control over each layer independently rather than being constrained by an all-in-one platform's infrastructure decisions.
How many emails can you send per day through Apollo?
Apollo caps daily sends at 50 emails per mailbox per day with a 100-email ceiling per domain including warmup volume. At dedicated infrastructure rates — 15-25 per day for Google inboxes, 5-10 per day for Microsoft — the math works out similarly, but with isolated reputation. To send meaningful cold email volume (1,000-10,000+ per day), you need multiple properly warmed domains regardless of which platform you're on. The difference is whether your domain health is isolated or shared with tens of thousands of other senders.
The Bottom Line on Apollo Mail
Apollo.io is a strong prospecting tool. The lead database, enrichment capabilities, and intent data are genuinely valuable and worth using. Apollo mail as a sending infrastructure for high-volume cold email is a different story. Shared IP pools, dropped native warmup, sending limits, and limited visibility into what's actually happening at the infrastructure level all create real deliverability constraints that compound as you try to scale.
The move isn't to abandon Apollo. It's to use it for what it does well — prospecting and enrichment — and pair it with infrastructure that was purpose-built for cold email volume. Infrastructure is the variable that determines whether everything else in your stack actually works. Get that right first.
If you're ready to dial in your sending infrastructure, start with ScaledMail. We handle the DNS, the warmup, the monitoring, and the domain management — you keep your sequencer and your Apollo workflow. Setup takes 2-4 business days. Book a call if you want to talk through the setup before committing.