Lemlistでメールアドレスを検証する：コールドメールの到達率ガイド

コールドメールでは、バウンス率の悪化が容赦なく響きます。ハードバウンスは見込み客を1人失うだけではありません。確認できないアドレスにメールを送っているというシグナルがメールプロバイダーに伝わり、それが重なると、数週間かけてウォームアップした送信ドメインのレピュテーションが静かに崩れていきます。Lemlistはこの点を理解しており、独自のバウンス保護を備えています。ただし、その組み込みのチェックはあくまで最低限の備えであり、それだけで十分とは言えません。このガイドでは、Lemlistの保護が実際に何をするのか、コールドメールの送信者がそれでも独自に検証する理由、そして無効なアドレスをシーケンスに入れず、送信コストを発生させないための「エクスポート → 検証 → 除外」の流れを解説します。

Lemlistのバウンス保護の仕組み#

Lemlistは、処理するコンタクトに対してメールアドレス検証のステップを実行し、不正なアドレスや配信停止済みのアドレスにメールが送られないよう、除外の仕組みを保持しています。リードをアップロードしたとき、またはLemlist自身のリード検索で取り込んだときに、配信不能と判断したアドレスにフラグを立て、キャンペーンから外すことができます。実行中のシーケンスでもバウンスを追跡し、失敗したアドレスへの送信を止めます。一見すると、明らかに無効なものを送信前と送信中に取り除く、実質的な保護です。

問題は、対象範囲と深さです。Lemlistの検証は、送信ツールに付属する便利な機能であり、専用の検証エンジンではありません。構文が壊れたアドレスや、明らかに存在しないメールボックスは検出しやすい一方で、グレーゾーンはほとんど見えません。SMTPの段階であらゆるアドレスを受け付けるキャッチオールドメイン、info@やsales@のような役割アドレス、使い捨てドメイン、技術的には有効でも満杯のメールボックスなどです。コールドアウトリーチでは、まさにこうしたグレーゾーンのアドレスにレピュテーション低下の原因が潜んでいます。信頼度スコアも理由コードもない、有効か無効かだけの判定では、アドレスがなぜ通過したのかが分かりません。コールドリストでは、その「なぜ」がすべてです。

上記のLemlistの動作は、2026年8月時点のLemlistのドキュメントで確認したものです。

それでも独自に検証すべき理由#

コールドメールの成否は、バウンス率とドメインのレピュテーションという2つの数値で決まります。この2つは連動しています。ハードバウンスは1件ごとに送信ドメインへの不利な評価となり、メールプロバイダーは、受信者と過去のやり取りがない送信者に対して、その評価を重く見ます。コールドの見込み客は、定義上すべてがそれに当たります。未検証のリストを一気に送るだけで、バウンス率が、受信トレイへの配置が崩れるしきい値を超えることがあります。そうなると、影響を受けるのは1つのキャンペーンにとどまりません。信頼を取り戻すまで、そのドメインとメールボックスから送るすべてのキャンペーンが影響を受け、回復には数週間かかることもあります。コールドメールの送信者が意識すべきなのは、この非対称性です。誤った送信の悪影響は長く残る一方で、それを防ぐコストは1アドレスあたり数セントです。毎回検証するほうが得になる理由は、コールドメールのためのメールアドレス検証の解説で、レピュテーション面はコールドメールの到達率のガイドで詳しく説明しています。

独自の検証は、付属のチェッカーでは得られない粒度も与えてくれます。Qualisendは、すべてのアドレスについて、deliverable、risky、undeliverable、unknownの4つの判定のいずれかを返し、それぞれに理由コードと、キャッチオール、使い捨て・役割・フリーメールのアドレスのサブフラグ、およびメールボックス満杯のフラグを付けます。各結果には、MXプロバイダー、SMTPプローブの結果、0～100の信頼度スコアも含まれます。この詳細があるから、コールドのリードについて、コイントスではなく根拠のある判断ができます。付属の検証では通過してしまうキャッチオールドメインも、理由付きでriskyと判定されるため、一斉に送るのではなく、小さなテストバッチに絞って送信量を抑えられます。ウォームアップを終えたばかりのインフラから送る場合は、検証と適切なドメインのウォームアップを組み合わせることで、新しいドメインをトラブルから守れます。避けたい失敗をプロバイダーがどう採点するかは、バウンス率が重要な理由で詳しく説明しています。

手順：エクスポートして検証し、無効なアドレスをシーケンスに入れない#

原則は単純です。検証は、見込み客がシーケンスに入った後ではなく、入る前に行います。 リードが稼働中のケイデンスに入ってしまうと、バウンスはすでに送信され、すでにカウントされています。検証のゲートは、キャンペーンの手前に置く必要があります。

最も手早い方法は、ネイティブコネクターです。QualisendのLemlist連携は提供中です。一度連携すれば、Qualisendがリストをその場でクリーニングします。既存のLemlistコンタクトを検証して判定結果を書き戻し、新しく追加されたコンタクトにはリアルタイムでチェックを実行するため、インポートしたばかりのリードやリード検索で取り込んだリードも、シーケンスに入る前にスコアが付きます。間にスプレッドシートを挟まずに、この流れが完結します。設定は/integrations/lemlistから行えます。

プランやワークフローの都合でコネクターが合わない場合も、CSVを使った手順ならどこでも使えます。

1. Lemlistからキャンペーンのリードをエクスポートします。 キャンペーンのリード、またはこれからキャンペーンに入るセグメントをCSVに書き出します。シーケンスを有効にする前か、インポートしたばかりのバッチに対して行います。
2. リストをQualisendで処理します。 CSVをアップロードします。バルクジョブは1回の実行で最大1,000,000件のアドレスを処理でき、重複は1回分しか課金されないため、重なり合うキャンペーンのエクスポートでも二重に支払うことはありません。すべての行に、deliverable、risky、undeliverable、unknownのいずれかと、理由コード、サブフラグ、信頼度スコアが付いて返されます。
3. 判定ごとに結果を分けます。 deliverableの行はシーケンスに残します。undeliverableの行は完全に除外します。これが、防ぎたいバウンスです。riskyとunknownの行は、メインの送信ではなく、別の小さなテストバッチに回します。キャッチオールやメールボックス満杯のアドレスが、全体のバウンス率を押し上げないようにするためです。
4. Lemlistで無効なアドレスを一時停止またはスキップします。 Lemlistに戻り、undeliverableのアドレスをアクティブなキャンペーンに入れないようにします。該当のリードを一時停止するか、シーケンスから外すか、最初から追加しないようにします。Qualisendがundeliverableと判定したアドレスには、一切送信しないことが目的です。
5. 新しく送信するたびに再検証します。 コールドのリストは劣化が速く、スクレイピングしたリードや購入したリードはとくに速く劣化します。新しいバッチは、ケイデンスに入る前に毎回同じゲートを通してください。検証は一度きりのクリーンアップではなく、送信ごとの習慣です。

この作業を完全に自動化したいチームは、手動のエクスポートを省き、Qualisendの検証APIを使えます。同じ4つの判定結果を、スコープ付きのキー、レート制限、Webhookとともに返し、Zapier、Make、n8nなどのノーコードツールにも接続できます。よくあるパターンは、リードが作成された時点で検証を起動し、deliverableの結果だけをLemlistのキャンペーンに同期する方法です。エンドポイントとWebhookのペイロードは、開発者向けドキュメントで確認できます。コールドメールの送信者がいま満たすべき受信トレイ配置のルールについては、メール到達率ガイドとGoogleとYahooの送信者ガイドラインも併せてご覧ください。

本格的に利用する前に、この流れ全体を試すこともできます。Qualisendの無料プランには、期限切れにならない100クレジット（一度限り）が含まれており、実際のテストバッチを検証して、自分のリードの理由コードを確認するには十分な量です。