リクルーター向けメールアドレス検証で候補者に確実に届ける

採用活動のアウトリーチは、オプトインしていない相手に送るのが前提です。LinkedInのエクスポート、古いATS、求人サイトのリード一覧、履歴書データベースから候補者を集め、メールアドレスを補完したり推測したりして送信を始めます。ところが、そうしたアドレスのかなりの割合は、間違っているか、古くなっているか、2年前に退職した勤務先のものです。リクルーター向けのメールアドレス検証は、この推測頼みの運用が、初回メールのバウンス、送信者レピュテーションの悪化、募集中のポジションを知らないままの候補者につながるのを防ぐための手段です。このガイドでは、収集した候補者リストの一括検証、個人アドレスと勤務先アドレスの扱い、応募フォームや紹介フォームでの入力時検証、候補者データが劣化していく中でATSをクリーンに保つ方法を取り上げます。

結論#

送信前にリストを検証し、候補者が入ってくるたびに検証を続けてください。収集した候補者リストは、あらゆるリストの中で最も状態が悪くなりがちです。アドレスは補完されたもの、推測されたもの、何年も前のものであり、勤務先アドレスの持ち主は、見つけた後に転職しているかもしれません。収集したリストは最初のアウトリーチの前に一括でクリーニングし、無効なアドレスがバウンスしないようにします。応募、紹介、タレントネットワークへの登録があった時点でアドレスをリアルタイムに検証すれば、ATSの入口からクリーンに保てます。さらに、既存のデータベースも定期的に再検証してください。採用関連のデータは、ほかのほとんどのリストよりも速く劣化します。リアルタイム検証は不良アドレスの流入を防ぎ、一括クリーニングはすでに入り込んだものを取り除きます。

リクルーターにとってメールアドレス検証が特別な理由#

ほとんどの送信者は、自分から情報を受け取りたいと考えた相手にメールを送ります。リクルーターは逆で、登録した覚えのない相手に、こちらから先に連絡します。しかも、直接取得したのではなく、見つけたり、補完したり、購入したりしたアドレスを使うことがほとんどです。これが特に危険な理由は3つあります。

• メールアドレスは、提出されたものではなく収集したものです。 リスト上の候補者のアドレスは、LinkedInのエクスポート、企業のアドレス形式（first.last@company.com）を推測した補完ツール、求人サイトのリード、スクレイピングした履歴書データベースのいずれかに由来します。推測した形式は頻繁に外れ、間違ったアドレスは確実にハードバウンスになります。
• 候補者データは急速に劣化します。 人は転職します。それは採用ビジネスの前提そのものです。半年前に見つけた勤務先アドレスは、候補者がすでに退職した会社のものかもしれません。その場合はバウンスするか、さらに悪いことに、そのメールボックスを引き継いだ別の人に届きます。これほど速く劣化するリストは、ほかにありません。
• 大量のコールドメールを送ります。 メールプロバイダーから見ると、採用のアウトリーチはコールドメールと同じです。相手は面識がなく、過去のエンゲージメントも少なく、送信量は一定しています。そのため送信者レピュテーションは傷みやすく、1つの不良リストによるバウンスの急増が原因で、反応のあった候補者も含め、全員への送信が迷惑メールフォルダーに振り分けられることがあります。

検証を行えば、収集しただけの推測の山を、実際に送信できるリストに変えられます。

不良な候補者アドレスのコスト#

「メールアドレスを検証しましょう」は、ありきたりな基本の助言のように聞こえます。しかし、無効なアドレス1件が実際のシーケンスの中でどうなるかを追うと、印象は変わります。リクルーターが、ぴったりの候補者のアドレスとしてp.nguyen@oldcorp.comを見つけ、リストに加えたとします。Nguyenさんは1年前にOldCorpを退職しています。この後、次の4つのことが起こり、どれも好ましくありません。

• 候補者がポジションを知らないままになります。 求人に最も合う人に、メッセージが届きません。これは購読者を1人失うという話ではありません。採用の機会を逃し、候補者体験も悪化します。どちらも、チームが評価される指標です。
• ハードバウンスが記録されます。 アドレスは無効なので、最初のメールはすぐにバウンスします。収集したリスト全体でこれが続くと、バウンス率が上昇し、プロバイダーがスパム送信者の特徴とみなす水準に達します。
• 送信者レピュテーションが低下します。 プロバイダーは送信者の行動で評価します。コールドメールで継続的にバウンスが出る状態は、送信者レピュテーションを最も急速に損なう原因の1つです。大量に送るリクルーターにとって、これはすでに最も傷みやすい資産です。
• 反応のある候補者のメールも迷惑メールに入ります。 プロバイダーが送信ドメインを信頼しなくなると、関心を持っている候補者宛ての個別メッセージまでフィルタリングされます。待っている返信が来ないのは、アウトリーチが受信トレイに届いていないからです。

収集したリストは最初の送信前にすべて一括検証する#

最も効果の大きい習慣は、収集したリストを送信対象にする前に検証することです。スクレイピングしたエクスポート、購入したリードファイル、ATSから取り出したバッチなど、出どころが何であれ、検証するまでは未検証として扱ってください。実際に未検証だからです。

手順は、エクスポート、検証、対応という標準的な流れです。リストをCSVにエクスポートし、すべてのアドレスをまとめて一括検証にかけると、各アドレスについて、deliverable、risky、undeliverable、unknownのいずれかのステータスが、理由、0～100の信頼スコア、使い捨て、役割、フリーメール、キャッチオールのサブフラグとともに返ってきます。undeliverableのアドレスは除外し、riskyとキャッチオールのセグメントは方針を決めて扱い、最初のメールは、実際に届くアドレスにだけ送ります。具体的な手順はメールリストのクリーニング方法にあり、大きなファイルについては一括メール検証で説明しています。そこには、リスト内の重複アドレスは1回分しか課金されないという点も書かれています。人気の高い候補者が、収集した3つのエクスポートに重複して現れるような場合に役立ちます。初めての方は、まず無料メールチェッカーに数件のアドレスを貼り付けて、実際の結果に含まれるステータス、理由、スコア、フラグを確認してみてください。

個人アドレス、勤務先アドレス、役割アドレス、キャッチオール#

採用のリストには、ほかの送信者がほとんど扱わない種類のアドレスが混在しています。それぞれにどう対応するかを決めるところで、検証の価値が出ます。「ブロックするか残すか」という一律のルールでは、よい候補者を失います。各結果のサブフラグを使えば、もっと細かく判断できます。

• 勤務先アドレスは、候補者がその会社にいる間は有効ですが、退職した時点で使えなくなります。それはいつ起きてもおかしくありません。また、キャッチオールドメインにあることも多くあります。企業のサーバーがあらゆるアドレス宛てのメールを受け入れるため、検証ツールは個別のメールボックスを確認できず、deliverableではなくriskyを返します。だからといって除外する理由にはなりません。慎重に扱い、可能であれば個人アドレスと組み合わせてください。
• 個人アドレス（GmailやOutlookなど）は、転職しても候補者についてきます。そのため、長期的な候補者との長期的な関係づくりには、こちらのほうが確実です。検証ではこれらにfreeのフラグが付きますが、採用では想定どおりで問題ありません。BtoBの営業リストでは警戒すべきフラグですが、ここでは違います。
• 役割アドレス（careers@、hr@、jobs@など）は、特定の候補者個人のものではない共有の受信トレイです。個別化したアウトリーチにはほとんど向きません。残すか除外するかの判断は、役割アドレス、使い捨てアドレス、フリーメールアドレスの解説にまとめています。

共通する考え方はこうです。ステータスとサブフラグを組み合わせれば、連絡可能な候補者を残し、劣化しやすい勤務先アドレスよりも長持ちする個人アドレスを優先し、キャッチオールのアドレスは、そのまま送ったり除外したりせず、慎重に扱う枠に回せます。

応募フォームと紹介フォームで入力時に検証する#

すべての候補者をリスト収集で見つけるわけではありません。多くは、自社で管理する流入チャネルから来ます。求人ページの応募フォーム、社員紹介フォーム、「タレントネットワークに登録」などです。不良なアドレスを見つけるには、これらの場面が最も低コストです。本人がまだページ上にいて、修正できるからです。

これにはリアルタイム検証が有効です。アドレスが入力された時点で検証APIを呼び出し、リクエスト内でステータスを受け取って、フローの中で処理します。応募時に@gmial.comと入力してしまった候補者には、「gmail.comではありませんか？」とやんわり確認を促します。この確認がなければ、フォローアップがすべてバウンスして、候補者が選考パイプラインから黙って消えてしまいます。摩擦を増やさずにフォームへ組み込むパターンは、サインアップ時のメール検証で紹介しています。エンドポイント、キーのスコープ、レート制限は開発者向けドキュメントにあります。レート制限はワークスペース単位で1分ごとに適用され、すべてのキーで共有されます。プランでキーを複数作成できる場合（Freeは1つ）は、採用サイト専用のキーを用意しておくと便利です。ほかの連携に影響を与えずに、そのキーだけを失効させられます。

これが裏目に出ないようにするためのルールは、一律にブロックせず、フラグを立てることです。応募フォームの目的は、候補者を獲得することです。ドメインの入力ミスや使い捨てアドレスなど、明らかに不良なアドレスには修正を促します。一方、結果が曖昧なunknown（メールサーバーの応答が遅かっただけということも多くあります）は通します。一時的な不調のために、本物の応募者を断ってはいけません。

ATSのリストをクリーンに保つ#

入力時のリアルタイム検証は、新しい候補者を守ります。しかし、すでにATSに入っている数千件には効果がありません。劣化の大半が隠れているのは、そのデータベースです。最後にメールを送ってから転職した候補者は、今や古い勤務先アドレスのままです。充足済みのポジション向けに作ったタレントプールも、気づかないうちに古くなっています。候補者データベースは、手入れをしなければ価値が下がります。

そのため、定期的に再検証し、パッシブ層への大規模な再アプローチの前には必ず実施してください。送信予定のセグメントをエクスポートし、一括検証にかけてステータスを更新します。これは、新しく収集したリストに使うのと同じエクスポート、検証、対応の流れを、すでに保有しているデータベースに適用するものです。検証は、確認した時点での状況のスナップショットです。再実行することで、古いプールに再び連絡した途端にバウンスするのを防げます。入口でクリーンにし、収集したリストは送信前に検証し、データベースは定期的に再検証する。この循環が、採用チームが本物の受信トレイに届き続けるための仕組みです。

収集した候補者リストを、実際に連絡できるリストに変えましょう。まず無料メールチェッカーで手軽に確認し、その後、料金ページでクレジットを購入して、お手元のATSのエクスポートを一括クリーニングしてください。最初のメールが届き、レピュテーションが保たれ、適切な候補者にポジションが伝わります。