The Lemlist Deliverability Problem at Scale (and How to Fix It Without Switching)

TLDR. Lemlist's deliverability ceiling at scale is an infrastructure ceiling — shared IPs, shared domain pools, and Lemwarm's diluted signal at high volume. The fix is dedicated infrastructure underneath Lemlist: isolated Azure tenants, dedicated IPs per workspace, automated SPF/DKIM/DMARC, and a hard per-mailbox cap of 2 outbound + 2 warmup = 4/day. Per-mailbox infra pricing runs $1.00/$0.85/$0.70/$0.55 by volume tier. Two- to four-hour setup, 14-day money-back. Lemlist's personalization tokens, liquid syntax, dynamic landing pages, and unified inbox stay exactly as they are.

Lemlist built one of the better cold email senders in the market. The personalization tokens, the dynamic landing pages, the campaign builder UX — all of that is real engineering and worth the subscription if you use them.

What Lemlist doesn't build is the infrastructure underneath your mailboxes. Your sending IPs, your domain reputation, your DNS authentication, your warmup network — those are bought from third parties, bundled into the Lemlist subscription, and shared across thousands of other Lemlist customers.

That shared layer is where Lemlist users hit their deliverability ceiling. The fix isn't to leave Lemlist. The fix is to swap the infrastructure for dedicated-per-customer infrastructure and keep Lemlist as the sender on top.

The 30-second answer

The pattern: Lemlist the application works. The infrastructure tier Lemlist routes through is what's broken at cold-email scale.

How Lemlist's stack works (what's theirs, what's not)

Lemlist's product is the campaign manager + personalization engine + unified inbox + warmup network membership. That's what their team builds and maintains.

What Lemlist uses (but doesn't fully control):

• The mailboxes themselves — connected from your Google Workspace, Microsoft 365, or third-party SMTP. Lemlist authenticates against them but doesn't operate them.
• The sending IPs — when you use Lemlist's bundled SMTP, those IPs come from a shared pool. Other Lemlist customers send through the same IPs.
• The DNS / SPF / DKIM / DMARC setup — Lemlist documents what to add but doesn't provision it on your domain.
• The Lemwarm warmup network — Lemlist-managed, shared across thousands of users. Useful, but the shared network's signals get noisy at scale.

The shared parts are fine at low volume. Past ~150 mailboxes, the cracks show.

The Google Workspace + Lemlist combo (most common, hits walls fastest)

The most common Lemlist setup pairs it with Google Workspace mailboxes ($6/user/month × N mailboxes). Lemlist sends through Gmail's SMTP as if you were sending from your own Gmail account.

This works fine at modest scale. Past a few hundred mailboxes, three things start to break:

1. Google Workspace's daily limits become the constraint. 2,000 outbound recipients/day per paid user. At cold email's 2-sends-per-mailbox/day cadence (which is what ColdRelay enforces specifically because higher volume tanks deliverability), the limit isn't the bottleneck. But at higher rates, you hit it.

2. Domain reputation pools across all senders on your workspace domain. If multiple campaigns share one Workspace domain, one bad campaign drags down everyone's reputation. There's no isolation.

3. Workspace suspension risk. Google's TOS prohibits "spam-like" sending behavior — and cold email IS spam-like to their classifier, regardless of intent. Past a certain volume, individual accounts (or the whole tenant) can get suspended. Recovery takes days; sometimes accounts don't come back.

The cost math gets bad too: 500 mailboxes × $6/mo = $3,000/month just for Workspace user licenses, before Lemlist subscription or list cost. The infrastructure isn't even isolated for that price.

The Lemlist-bundled-SMTP problem (different ceiling, same outcome)

The alternative — Lemlist's bundled SMTP provisioning — has a different but parallel issue. Multiple customers send through the same SMTP infrastructure. Sending IPs are shared. One customer's bad campaign — over-aggressive ramp, untargeted list, complaint spikes — drives down the IP's reputation for everyone using it.

You can be doing everything right and watch your inbox placement collapse because of someone else's mistake on the same IP block. This is the neighbor problem; you don't control your neighbors, and you wear their reputation.

Diagnostic test: open Google Postmaster Tools, check IP Reputation. If you see "Medium" or "Low" when you know your own sending is clean, you're sharing an IP with bad actors. (How to read Postmaster Tools →)

Lemlist-specific failure modes (beyond shared infrastructure)

Beyond the shared-IP and shared-domain walls, Lemlist operators hit four configuration-specific failure modes that compound the underlying problem. Each one shows up as "lower reply rate" in the dashboard with no obvious cause.

1. Liquid-syntax personalization tokens silently failing. Lemlist's {{ }} liquid syntax breaks elegantly when a variable doesn't resolve — the campaign sends, but with {{firstName}} as literal text in the subject or body. Gmail's classifier reads broken personalization tokens as a spam signal (template-not-merged). The fix is enabling Lemlist's "Skip if missing" toggle on every personalization token AND running 10 sample sends through Mail-Tester before launch to verify tokens resolved.

2. Lemwarm enabled at the workspace level but inactive per-mailbox. Lemwarm runs as a workspace-level subscription, but each individual mailbox must be enrolled in Lemwarm separately. Operators see the Lemwarm badge in their plan and assume every mailbox is warming. Mailboxes that were never enrolled cold-start on first send and get evaluated as cold senders. The fix is auditing every mailbox in Settings → Email Providers and confirming each one's Lemwarm status individually, not just at the plan level.

3. Custom domain tracking misconfigured for click and open tracking. Lemlist requires a custom tracking domain (CNAME pointing at tracking.lemlist.com) for click and open tracking. Operators who skip the SSL step or misconfigure the CNAME end up with broken tracking links — clicks 404, pixels fail to load. Spam classifiers flag broken links aggressively. The fix is validating end-to-end before any campaign uses the tracking domain: CNAME resolves, SSL valid, redirect chain clean. The Email Deliverability Test catches broken tracking domains in the link-audit step.

4. Multi-step sequence pacing too tight, triggering rate-limit deferrals. Lemlist's sequence builder lets operators set send delays between steps (Step 1 → 2 days → Step 2 → 3 days → Step 3). Operators sometimes tighten delays to compress the campaign, ending up with the same mailbox sending to the same domain multiple times per day. Gmail's per-sender per-recipient rate limit kicks in at ~3 messages per day to a single recipient address; receivers will defer or reject above that. The fix is leaving step delays at 2-4 days minimum and confirming no two steps for the same prospect land on the same day.

5. Sending domain not separated from corporate domain. Operators new to Lemlist often connect their primary corporate mailbox (founder@company.com) and send cold campaigns from it. The corporate domain absorbs all the negative reputation signal from cold sends; six months later, customer-facing emails from the same domain start hitting spam folders. The fix is using a separate sending domain (e.g., company.io or company-team.com) for all cold sequences, and reserving the primary corporate domain for warm pipeline work.

Diagnostic checklist: run before contacting Lemlist support

Before opening a Lemlist support ticket, run through this ordered checklist. Most Lemlist deliverability issues trace back to one of these and support will ask about them anyway.

1. Confirm Lemwarm is active per-mailbox, not just at the plan level. Settings → Email Providers → individual mailbox → Lemwarm status badge.
2. Run the Email Deliverability Test on your sending domain. SPF, DKIM, DMARC misconfigurations stop deliverability work before any campaign tweak helps.
3. Check the sending IPs against the Blacklist Checker. Spamhaus, Barracuda, SORBS — any listing explains the inbox-rate drop without further diagnosis. If listed, follow the blocklist removal playbook.
4. Open Google Postmaster Tools. Domain Reputation below High on a previously-High domain is the infrastructure-side signal.
5. Pull per-mailbox bounce rate over 30 days. Above 3% with stable list quality means the receiver is rejecting reputation-driven. Cross-reference any 5xx SMTP codes against the SMTP error library — codes like 550 5.7.1 SPF fail at Gmail, 550 5.7.1 DMARC fail at Gmail, or 550 5.7.1 message identified as spam point to different root causes.
6. Audit per-mailbox daily send caps. Lemlist's UI defaults are higher than the deliverability-safe cap of 2 outbound + 2 warmup = 4/day. Anything above 5/day is burning reputation.
7. Sample 10 sends through Mail-Tester.com. Score below 8/10 means content or authentication needs work before infrastructure work helps.
8. Verify the custom tracking domain end-to-end. CNAME, SSL, redirect chain. Broken tracking domains trigger spam classifiers reliably.
9. Confirm sending domain is separate from corporate domain. If you've been sending cold from a corporate domain, the reputation damage may have spread. Migrate to a dedicated sending domain immediately.
10. Check Lemlist's IMAP connection status. Drifted credentials silently break reply detection — operators see "low reply rate" without realizing replies are arriving but Lemlist can't see them.

Related deliverability fixes

The infrastructure ceiling shows up across every cold-email sender. Same fix architecture, different connection details:

• Instantly deliverability fix — closest competitor; same shared-IP and Workspace ceiling.
• Smartlead deliverability fix — canonical long-form on campaign-vs-infrastructure decoupling.
• EmailBison deliverability fix — AI-first sender; same infrastructure layer underneath.
• Saleshandy deliverability fix — cost-conscious sender; infrastructure dominates total cost.

How to know if Lemlist's infrastructure is your bottleneck

Five diagnostic signals. Two or more = you're hitting the wall:

1. Inbox rate at 50 mailboxes was 85%+; at 200 mailboxes it's 60% or below. The classic shared-infrastructure scaling curve. Individual mailboxes test fine; the pool tests bad.

2. Reply rates dropped while open rates stayed the same. Counterintuitive but diagnostic. Opens often come from spam-folder skim-readers. Replies require landing in primary inbox and feeling legitimate. Same opens + fewer replies = more spam-folder placement.

3. Google Postmaster Tools shows Domain Reputation drift from High to Medium. Read it directly in Postmaster Tools. Without a content change, that drift means infrastructure-side reputation is sliding.

4. SMTP "temporary deferral" errors on a meaningful percentage of sends. Lemlist's logs will surface these. A few percent is normal. Double-digit percent means receivers are starting to throttle you.

5. Bounce rate creeps above 2% despite list quality being stable. Reputation-driven rejection codes look like bounces but are infrastructure problems wearing list-quality clothing. (Why bounce rate matters →)

The fix: dedicated infrastructure under Lemlist

The architecture is a clean split:

The two layers compose. Lemlist becomes the campaign manager (which it's good at). ColdRelay becomes the deliverability backbone (purpose-built for it). You don't lose Lemlist's UX; you gain the infrastructure layer Lemlist doesn't operate.

The migration: keep Lemlist, swap the infrastructure

Concrete steps:

1. Provision domains + mailboxes through ColdRelay. Setup takes 60 minutes, fully automated — domains purchased, DNS configured, IPs provisioned, mailboxes ready to authenticate.
2. Push the new mailboxes into Lemlist. Lemlist supports adding custom SMTP/IMAP mailboxes directly; ColdRelay's dashboard exports a Lemlist-formatted CSV or pushes via Lemlist's API if you've connected your key.
3. Migrate active campaigns to the new mailboxes (or run new campaigns alongside while old ones finish — Lemlist handles parallel mailboxes fine).
4. Pause sending on the old infrastructure for 7 to 14 days while the new domain reputation builds. ColdRelay's per-customer isolation means the new domains don't inherit any reputation from old shared-pool history.

Cost math compared to Google Workspace + Lemlist's bundled add-ons:

The deliverability lift comes on top of the cost reduction. Same Lemlist subscription, same Lemlist campaigns, ~90% lower infrastructure cost, dedicated-IP-level reputation control.

What about Lemwarm?

Lemwarm is Lemlist's built-in warmup network. Useful for the first few weeks of a brand-new domain, when any warmup signal helps. At scale, the shared-network signals dilute and ColdRelay's infrastructure-level warmup (which runs at the SMTP layer using your dedicated IP) is more targeted.

You can run both in parallel — Lemwarm contributes to the warm-up email exchange volume, while ColdRelay's infrastructure-level warmup makes sure the IP and domain history accumulate cleanly. No conflict.

FAQ

Will I lose my Lemlist campaigns or templates?

No. Lemlist data — campaigns, sequences, templates, personalization tokens, lead lists, unified inbox history — all stays in Lemlist. You're only changing which mailboxes Lemlist routes through.

Does Lemlist support custom SMTP/IMAP mailboxes?

Yes. Lemlist has a "Custom email provider" option in their mailbox connection flow. You enter the SMTP/IMAP host, port, username, password — same as you would for any third-party provider. ColdRelay's dashboard generates these credentials per mailbox and exports them in Lemlist's CSV format for bulk import.

How long until I see the deliverability improvement?

7 to 14 days for the first signal (Domain Reputation in Postmaster Tools stabilizing at High). Reply-rate improvement typically lands in week 3 to 4 as the new mailboxes' reputation matures and the old infrastructure stops dragging averages down.

What if I'm only using Lemlist for personalization, not for warmup or analytics?

Even better. The migration is simpler — connect the new mailboxes, retarget your campaigns, done. ColdRelay's per-mailbox engagement data shows up in your dashboard too if you want it.

Can I A/B test old infrastructure against ColdRelay?

Yes. Most customers run a parallel split for the first 30 days — old campaigns continue on old infrastructure, new mailboxes provision on ColdRelay, traffic gradually shifts. No hard cutover required. Side-by-side reply-rate data lets you verify the lift before fully migrating.

What about other sending tools — Smartlead, Instantly, EmailBison, Saleshandy?

Same pattern. ColdRelay has one-click push integration with Smartlead, Instantly, EmailBison, and Saleshandy. The infrastructure layer underneath is identical regardless of which sender sits on top.

Why is the daily cap 2 outbound + 2 warmup = 4/day per mailbox? Why not higher?

The cap isn't about infrastructure capacity. It's about Gmail's and Outlook's complaint-rate tolerance. Above 5 sends per mailbox per day, the rate of complaints (even at low single-digit percentages) crosses the threshold where Gmail's classifier flags the mailbox as a spam source. Below 5, complaint volume stays under the threshold even when list quality dips. The cap is what protects deliverability; scale comes from adding more mailboxes, not raising the cap. Lemlist's UI lets you set higher caps, but doing so burns mailbox reputation in weeks.

Is there a contract or commitment?

ColdRelay's billing is monthly. The pricing tier you're on (based on mailbox count) updates automatically as you scale up or down. There's a 95% deliverability guarantee with refund in your first 14 days — if the infrastructure doesn't hit that bar, you're out at no cost.

Microsoft 365 vs Google Workspace mailboxes — does it matter for Lemlist deliverability?

Both have shared-domain reputation pools, so both hit the same wall at scale. The failure modes differ slightly: Microsoft 365 silently rate-limits at lower volumes before any individual mailbox hits its hard cap; Google Workspace has higher limits but more aggressive TOS enforcement (Google occasionally suspends accounts whose patterns match their spam classifier, regardless of caps). The structural fix is the same — dedicated infrastructure outside the corporate tenant. Dedicated infrastructure on the Microsoft 365 side has the added benefit of Microsoft's deliverability advantage to other Microsoft 365 recipients (alignment between sender and receiver tenants).

What metrics should I monitor weekly once I'm on dedicated infrastructure?

Five metrics, weekly cadence. (1) Postmaster Tools Domain Reputation — should hold High. (2) Per-mailbox bounce rate — alert at 3%. (3) IP reputation via the Blacklist Checker on every sending IP. (4) Reply rate by campaign — drops signal content or deliverability issues. (5) IMAP polling status in Lemlist — drift breaks reply detection silently. The Email Deliverability Test consolidates the first three into one weekly run.

When should I consider switching infrastructure (not just within Lemlist)?

When you see three or more of: domain reputation Low for 21+ days, multiple sending IPs on major blocklists, bounce rate consistently above 5%, account suspensions on Workspace mailboxes, or a sustained reply-rate decline below 1% on previously-working campaigns. Tactical fixes inside Lemlist don't recover from these — fresh domains on dedicated infrastructure is the structural move. The 14-day money-back window covers the migration trial.

Lemlist is a good campaign manager. Pair it with infrastructure that's purpose-built for cold email at scale, and the deliverability ceiling moves out by an order of magnitude.

See ColdRelay + Lemlist in action → Try ColdRelay free · Test your current setup → Free deliverability test