Email Verification for lemlist: A Workflow Guide

lemlist has a strong following in the agency and growth-hacking community for good reason: liquid-syntax personalisation, multi-channel sequences (email + LinkedIn + call steps), dynamic image personalisation, and detailed campaign analytics. The people who use lemlist are not casual cold emailers — they are running sophisticated, high-effort outreach campaigns where every sequence step costs real time to build.

That investment makes list quality especially important. A well-crafted lemlist sequence running on a list with a 10% bad-address rate is not just wasting bounce budget. It is wasting the time of the person who built the sequence, the personalisation data attached to each contact, and the sending reputation of the domain behind the campaign.

Verification before import protects that investment.

The lemlist-specific deliverability context

lemlist has built-in features that affect how list quality plays out:

Sender reputation management — lemlist monitors sending domain health and can throttle or pause sends when deliverability signals degrade. A clean list means the system is protecting real performance, not managing damage from bad data.

Personalisation accuracy — lemlist users invest heavily in personalisation data: custom variables, LinkedIn profile enrichment, company data, custom icebreakers. A verified list means that personalisation effort is applied to addresses that exist. An unverified list means some fraction of highly personalised step-1 emails go to mailboxes that bounce immediately.

Multi-channel coordination — when a sequence includes LinkedIn connection requests or phone steps alongside email, the contact record is valuable beyond just the email address. Verifying the email and flagging the bad rows lets you make a decision about each record: remove from email but keep in LinkedIn-only track, or remove entirely. That is a decision you can make with evidence; you cannot make it without verification.

Agency multi-client sending — lemlist is popular with agencies managing campaigns for multiple clients. Bad list quality from one client can, depending on your sending setup, create cross-contamination effects on shared infrastructure. Verification before import is a defensible quality-control step you can document for clients.

What verification covers

The surface layers

Syntax validation — catches broken-format addresses. Every tool does this.

Domain and MX records — confirms the domain has mail servers configured. Reliable negative signal: no MX = definitely undeliverable. Passing MX tells you nothing about individual mailboxes.

Typo detection — gmial.com, outlok.com, transposition errors from data entry. Common in manually researched lists.

Disposable and role address detection — throwaway inbox services and role addresses (info@, contact@, marketing@). Role addresses are a significant cold-outreach risk: they reach shared inboxes monitored by teams, not individuals. The spam complaint risk from a role address in a cold sequence is higher than from a personal inbox. For lemlist campaigns built on personalised emails addressing "Hi [First Name]," role-address sends are also a personalisation mismatch.

SMTP mailbox probing

MailCull opens a direct SMTP connection to the receiving mail server, performs an EHLO handshake with a properly configured sending identity (matching PTR and A records), and issues RCPT TO for each specific address.

Server responses:

• 250 OK — the mailbox accepts mail. Deliverable.
• 550 (various codes) — user unknown, mailbox not found, account does not exist. Hard bounce. Remove before import.
• 4xx — temporary deferral. Greylisting, rate-limiting, server congestion. Inconclusive — mark as risky, include with monitoring.

Every 550 caught before import is a bounce event prevented and a step-1 personalised email not wasted.

Microsoft 365 HTTP enumeration

For B2B cold outreach targeting business email addresses, M365 is the most important edge case in verification. A large fraction of corporate addresses — especially at mid-market and enterprise companies — are on M365 tenants.

Microsoft's EOP layer accepts RCPT TO for any address on a tenant, including non-existent ones. A standard SMTP probe returns 250 OK for an address that does not exist. That address hard-bounces on actual send.

MailCull's engine runs a three-step HTTP cascade for M365 domains:

1. GetUserRealm — confirms the domain routes to M365
2. GetCredentialType — checks whether the specific username has an active M365 account
3. Autodiscover v1 — cross-references account presence

When the cascade confirms an active account and SMTP agrees, the verdict is high-confidence deliverable. When the cascade says no active account but SMTP returned 250 OK — the classic M365 false-positive — the address is marked risky with a m365_smtp_disagreed reason.

In a lemlist agency context, where campaigns often target mid-market and enterprise buyers with high concentrations of M365 accounts, this layer alone can meaningfully shift the deliverable percentage on a list.

Catch-all domain detection

Domains configured to accept all RCPT TO regardless of mailbox existence are flagged as catch-all. Individual mailbox verification is impossible for these. MailCull marks them as risky rather than deliverable.

In practice, catch-all domains are common at smaller companies and startups — exactly the kind of prospect that appears in lemlist agency campaigns targeting SMB buyers. Catch-all risky does not mean the address is bad; it means you cannot confirm it is good. In a high-effort personalised sequence, you may choose to include catch-all addresses in a lower-personalisation track rather than excluding them entirely.

The evidence chain for per-contact decisions

Every verified address in MailCull includes an evidence chain that records the specific signals that drove the verdict. This is particularly useful for lemlist agency workflows where you may want to make different decisions for different reason codes.

An example result:

{
  "email": "[email protected]",
  "status": "risky",
  "reason": "role_address",
  "confidence": 0.71,
  "evidence": {
    "smtp": { "code": 250, "accepted": true },
    "role": { "detected": true, "pattern": "procurement" }
  }
}

With this, you can route the contact into a "role-address track" in lemlist — perhaps a sequence that does not use first-name personalisation and positions the message as a team-level offer rather than an individual pitch.

The workflow: MailCull + lemlist

Step 1: assemble the contact list

Pull contacts from your sourcing stack. lemlist users commonly source from:

• Clay enrichment workflows
• Apollo or ZoomInfo exports
• LinkedIn Sales Navigator + Phantombuster scrapes
• Manual research for high-value ABM contacts
• Client-provided prospect databases

Export as CSV. Include all the columns you need for lemlist variables — first name, last name, company, title, personalisation fields, LinkedIn URL.

Step 2: verify in MailCull

Upload to Verify List. The full check stack runs: syntax, MX, typo, disposable/role, SMTP probe, M365 HTTP cascade, catch-all detection.

Free: 1,000 rows/month (no credit card) Pro: 100,000 rows/month at $9/month Scale: 500,000 rows/month at $49/month

Step 3: route by status and reason

For a lemlist campaign with significant personalisation investment:

The routing into separate tracks is a lemlist strength — you can build different sequences for different risk profiles rather than making a binary include/exclude decision.

Step 4: import into lemlist

Import each segment into the appropriate lemlist campaign. Because your high-personalisation sequence is going to verified deliverable addresses only, the first-send bounce rate should be materially lower and the personalisation investment is not wasted on bounces.

Step 5: use the evidence for client reporting

For agency users: export the MailCull verification report alongside the campaign results. When a client asks why their list yielded 78% deliverable addresses, you can show them the breakdown:

• X addresses: user unknown at SMTP level (employee turnover)
• Y addresses: M365 false-positives detected (stale corporate data)
• Z addresses: catch-all domains (confirm but uncertain)
• W addresses: role addresses removed (shared inboxes)

That breakdown tells a data story about source quality. It is useful for justifying data sourcing recommendations and demonstrating professional diligence.

What to expect on common lemlist list sources

These are rough benchmarks, not guarantees. Source quality varies by vertical, list age, and how recently the data was refreshed. Verification tells you the actual number for your specific list.

---

You came here to protect the investment you make in personalised lemlist sequences. MailCull verifies every address at the SMTP level, handles the M365 edge cases that affect B2B list accuracy, and gives you the evidence to make smart routing decisions.

Verify your lemlist prospect list in MailCull — free up to 1,000 rows →