ほとんどのリストで必要なのは、アドレスを1件ずつ検証することではなく、まとめて一度に検証することです。メールアドレスの一括検証とは、すでに手元にあるリスト全体を取り込み、すべてのアドレスに同じ到達率チェックを1回のバッチで実行して、次の配信前に対応できるアドレスごとの判定結果を受け取る方法です。引き継いだリード一覧のスプレッドシートがある場合、1年間配信していないセグメントをもう一度使う場合、大きなキャンペーンの前にリストをきれいにしたい場合に役立ちます。このガイドでは、一括検証とは何か、リアルタイム検証ではなく一括検証を選ぶ場面、CSVからクリーンなリストに至るまでの流れ、返ってくるすべてのステータスとサブフラグの意味を解説します。
メールアドレスの一括検証とは#
一括検証では、アドレスを並べたファイルを受け取ります。多くの場合、メール配信プラットフォームやCRMなど、リストが保管されている場所からエクスポートしたCSVです。各アドレスは、リアルタイムのリクエストではなくバッチジョブとして、完全な検証パイプラインに通されます。どのアドレスにも、1件ずつ確認した場合と同じ4つの結果が返ります。ステータス（deliverable、risky、undeliverable、unknown）、機械で読める理由コード、0～100の信頼度スコア、そしてアドレスの性質を示すサブフラグ（disposable、role、free、catch-all）です。違いはチェックの内容ではありません。数千から数百万のアドレスを非同期で一度にチェックするため、コードを組み込まなくてもリスト全体をクリーニングできる点です。
この分野が初めての方は、基本をメールアドレス検証とはで確認してください。この記事では、バッチ処理によるリストのクリーニングに絞って説明します。
一括検証とリアルタイム検証の違い#
アドレスを検証するタイミングは2つあり、それぞれ解決する問題が異なります。
リアルタイム検証（取得の時点）。 誰かがサインアップフォームやチェックアウトでメールアドレスを入力した瞬間に、APIで検証し、その結果にすぐ対応します。明らかな入力ミスを拒否する、修正案を提示する、不正なアドレスが保存される前にデータベースへの混入を防ぐ、といった対応です。不良アドレスを見つけるには、この時点が最も低コストです。組み込み方はサインアップ時のメールアドレス検証で解説しています。リアルタイム検証は、新しいアドレスを入口でクリーンに保ちます。
一括検証（すでにあるリスト）。 リアルタイム検証は、すでにアカウントに入っているアドレスには何もしません。取得時のチェックを導入する前に集めたアドレスや、その後に無効になったアドレスです。こうしたアドレスには一括検証が必要です。リストをエクスポートし、バッチジョブで検証し、判定結果に応じて対応します。一括クリーニングは、時間とともに劣化したアドレスを取り除くもので、大規模な配信の前に行う標準的な作業です。
一括検証を使う場面#
一括クリーニングが役立つのは、繰り返し起こる次のような場面です。
- リストをインポートした、または引き継いだ場合。 購入したリスト、同僚から受け取ったスプレッドシート、旧システムから移行したコンタクトは、品質が分かりません。最初の配信の後でバウンスを見てからではなく、配信の前に検証してください。
- セグメントが古くなった場合。 転職、受信トレイの放棄、アカウントの失効は日常的に起こるため、一度クリーンだったリストも劣化します。休眠セグメントに再アプローチする前にクリーニングしてください。休眠リストは、無効なアドレスやスパムトラップが集中しやすい場所です。
- キャンペーン前のクリーニング。 大規模な一斉配信の前に検証を一通り行えば、バウンスしやすいアドレスを取り除けます。これによりバウンス率が守られ、その結果として送信者レピュテーションも守られます。
- 定期的なメンテナンス。 リストは絶え間なく劣化します。定期的にクリーニングすれば、配信の合間にバウンス率がじわじわ上がることを防ぎ、低い水準を保てます。
一括検証の流れ#
どのプラットフォームから送信する場合でも、リストのクリーニングは同じ4つの手順で進みます。エクスポート → 検証 → 対応 → 再インポートまたは抑制です。プラットフォームを問わない手順の全体はメールリストのクリーニング方法にあります。また、多くのメール配信サービス（ESP）には、エクスポートと抑制のための専用の手順があるので、お使いのツールのものに従ってください。以下は全体の流れです。
1. CSVにエクスポートする。 ESPやCRMからコンタクトをCSVに書き出します。検証サービスに最低限必要なのは、メールアドレスの列1つだけです。ただし、IDや名前の列も一緒に残しておくと、再インポートのときに判定結果をレコードへ対応付けやすくなります。
2. アップロードして検証する。 ファイルを検証サービスにアップロードし、バッチを開始します。大きなリストはバックグラウンドで処理されます。所要時間はリストの大きさに比例し、数百件ならすぐに終わりますが、数百万行のリストは時間がかかり、別の作業をしている間も非同期で実行されます。接続を開いたままにしたり、ジョブを見張ったりする必要はなく、完了した結果を後から確認するだけです。
3. 判定結果に対応する。 これで各行に、ステータス、理由、信頼度スコア、サブフラグが付きました。ここで判断を行います。deliverableのアドレスは残し、undeliverableのアドレスは除外し、その中間のケースは意図を持って判断します。具体的なやり方は、次の2つのセクションで説明します。
4. 再インポートまたは抑制する。 クリーニングしたリストをプラットフォームに戻します。そして重要なのは、取り除いたアドレスを削除するだけでなく抑制することです。抑制リストがあれば、次回のインポートやフォーム入力で不良アドレスが再び紛れ込むのを防げます。
ステータスとサブフラグの意味#
検証結果は単なる有効か無効かではありません。現実は二択で割り切れないからです。各アドレスには、見出しとなるステータスに加えて、理由コード、信頼度スコア、該当するサブフラグが付きます。ステータスは取るべき対応を示し、それ以外の情報は、どの程度確信してよいか、そしてその理由を示します。
| ステータス | 意味 | 一括クリーニングでの対応 |
|---|---|---|
| Deliverable | メールボックスが存在し、メールを受け付けます。 | 残します。安全に送信できます。 |
| Risky | 届く可能性はありますが、キャッチオールドメイン、容量超過のメールボックス、低品質のシグナルなど、既知のリスクがあります。 | 確認します。通常の配信では残し、重要な配信では抑制します。 |
| Undeliverable | アドレスが不正です。該当するメールボックスがない、ドメインが存在しない、構文が無効、のいずれかです。 | 除外して抑制します。送信するとバウンスします。 |
| Unknown | メールサーバーが時間内に明確な回答を返しませんでした（グレーリスティング、タイムアウト）。 | 後で再検証します。どちらとも確定したものとして扱わないでください。 |
理由コードは、ステータスの背後にある機械で読める「なぜ」です。invalid_domain、rejected_email、low_deliverabilityといった値があり、判定結果だけでなく原因でも大きなエクスポートを絞り込めます。信頼度スコアは、同じステータスの中でアドレスを順位付けします。最も確実なdeliverableのアドレスを優先したり、最も弱いriskyのアドレスを精査したりできます。そしてサブフラグは、ステータスとは別に、アドレスの性質を表します。
- Disposable： 使い捨てメールサービスが発行する、一時的な受信トレイです。
- Role： 個人ではなく、
info@やsupport@のような共有メールボックスです。 - Free： GmailやOutlookなどの一般消費者向けプロバイダーです。
- Catch-all： ドメインがあらゆるアドレス宛てのメールを受け付けるため、メールボックスを個別に確認できません。
role、disposable、freeのアドレスは、自動的に不良というわけではありません。いずれも運用ポリシーの判断であり、役割アドレス、使い捨てアドレス、フリーメールアドレスで扱っています。キャッチオールは最もつまずきやすい項目であるため、専用の解説を用意しています。riskyのキャッチオールという結果は、ドメインが特定のメールボックスを確認しなかったという意味であり、そのアドレスが確実に不良という意味ではありません。
結果に基づく対応#
リスト全体にスコアが付いたら、判定結果をもとに、残す、除外する、確認するのいずれかを決めます。
- deliverableのアドレスは残す。 確認済みで安全なアドレスです。クリーニング後のリストの中心になります。
- undeliverableのアドレスは除外して抑制する。 バウンスするアドレスです。取り除いたうえで抑制リストに追加し、次回のインポートで戻ってこないようにします。
- riskyとキャッチオールのアドレスは、意図を持って確認する。 通常のニュースレターなら残してもかまいません。コールドメールのシーケンス、再エンゲージメントの施策、ドメインのウォームアップなど、レピュテーションへの影響が大きい配信の前には、安全のために抑制します。信頼度スコアが、その線引きに役立ちます。
- role、disposable、freeのアドレスは、ポリシーに従って扱う。 BtoBの送信者は
info@のような役割アドレスを除外し、BtoCのストアはGmailのアドレスを歓迎するかもしれません。万能の正解はないので、一度決めて一貫して適用してください。
エクスポートをステータスと理由で並べ替えれば、この作業は1行ずつの手作業から、いくつかの一括操作に変わります。残すか除外するかの判断をコストの面から考えたい場合、つまり無料のスポットチェックで足りる場面と、フルバッチのチェックに費用をかける価値がある場面については、無料と有料の比較にまとめています。
一括検証サービスの選び方#
一括クリーニングで重要なチェックは、どの場面でも共通です。SMTPによるメールボックスの確認を実際に行い、キャッチオールドメインを検出するか。ステータスと理由コードをどれだけ明確に報告するか。ジョブを見張らなくても大きなファイルを処理できるか。精度、データの取り扱い、料金体系を含む判断の枠組みの全体は、メールアドレス検証サービスの選び方にあります。具体的なベンダーを比べるなら、ZeroBounceとの比較やNeverBounceとの比較のような比較ページで、推測に頼らず並べて確認できます。
返信する前に確かめたいリード1件のような最小規模の作業なら、バッチは不要です。無料メールチェッカーを使えば、ブラウザー上で1件のアドレスを確認できます。一括検証は、それを超えるすべての作業向けです。リスト全体を一度に処理し、問題が起きる前にクリーニングします。
よくある質問
01メールアドレスの一括検証とは何ですか？
メールアドレスの一括検証は、アドレスのリスト全体を1回のバッチで確認する方法です。CSVをアップロードすると、サービスがすべてのアドレスを非同期で完全なパイプラインに通し、アドレスごとのステータス（deliverable、risky、undeliverable、unknown）に加えて、理由コード、信頼度スコア、サブフラグが返ります。ブラウザーで1件ずつ確認したり、サインアップ時にリアルタイムで検証したりするのではなく、すでにあるリストをクリーニングするためのものです。
02一括検証とリアルタイム検証は何が違いますか？
同じチェックを異なるタイミングで行います。リアルタイム検証は、サインアップフォームやチェックアウトなど、取得の時点で1件ずつAPIを通して実行するため、不良アドレスを保存する前に拒否または修正できます。一括検証は、すでにあるリスト全体を一度に実行し、もともと入っていたアドレスや、その後に無効になったアドレスを取り除きます。多くの送信者は両方を使います。新しいアドレスの品質はリアルタイムで保ち、残りは定期的に一括でクリーニングします。
03メールアドレスの一括検証にはどのくらいかかりますか？
所要時間はリストの大きさに比例します。数百件ならすぐに終わり、非常に大きなリストは時間がかかり、バックグラウンドで処理されます。ジョブを開始してタブを閉じ、完了した結果を後から確認できるので、何かを開いたままにしておく必要はありません。バッチジョブは非同期で実行されるため、大きなリストでも処理中に作業が止まることはありません。
04「risky」やキャッチオールの結果はどう扱えばよいですか？
自動で残したり自動で除外したりせず、確認してください。riskyの判定は、多くの場合メールサーバーが個別のメールボックスを確認しないキャッチオールドメインで、アドレスを確実には確認できなかったことを意味します。確実に無効という意味ではありません。通常の配信なら残してもかまいませんが、レピュテーションへの影響が大きいキャンペーンの前には、バウンス率を守るために抑制します。信頼度スコアが、それぞれの線引きに役立ちます。
すでにあるリストをクリーニングする準備はできましたか？料金プランから一括検証を始めましょう。すべてのアドレスにステータス、理由コード、信頼度スコア、サブフラグが付いて返るため、次の配信の前に、どのアドレスを残し、除外し、確認するかが正確に分かります。
