キャッチオールは有効と同じではない。
ドメインがキャッチオールとして設定されている場合、特定のメールボックスが存在するかどうかに関わらず、すべての受信メッセージを受け入れる。検証ツールは、john.smith@company.com が実際に誰かのものかどうかを、ドメインレベルの受け入れを超えて確認することができない。ドメインは受け入れる。メールボックスは存在しない可能性がある。
これがキャッチオール結果を確認済みの有効アドレスと同様に扱う場合の核心的な問題だ。メッセージは受け入れられた。しかしそれは実際の人物に届いたということではない。多くの場合、そのドメインはキャッチオール設定を実行しているのだが、それはまさに自社のメールボックスの正確なリストを管理できないからであり、存在しないアドレスへのメッセージは静かに破棄される。
逆の誤りは、すべてのキャッチオール結果をゴミとして扱い、完全に削除することだ。これは重要なセグメントを捨てることになる。多くのキャッチオールドメインには実際に届く本物のアドレスが含まれている。正しいアプローチは、すべてのキャッチオールレコードを無条件に受け入れることでも、すべて破棄することでもない — それらを独自の量とリスクルールを持つ管理されたセグメントに分離することだ。
キャッチオール検証でわかることとわからないこと。
| シグナル | 意味 | わからないこと |
|---|---|---|
| キャッチオール確認済み | ドメインはすべてのメールを受け入れる | 特定のメールボックスが存在するかどうか |
| MX 失敗なし | ドメインには動作するメールインフラがある | 受信者のアドレスが実際の人物に対応しているかどうか |
| ハード拒否なし | サーバーは接続を拒否しなかった | メッセージが配信されるか、静かに破棄されるか |
| 使い捨てフラグなし | ドメインは既知の一時メールサービスではない | メールボックスが監視されているか、アクティブかどうか |
キャッチオール結果は有効と無効の間のリスク帯に位置する。確認済みの有効とも、確認済みの無効とも同じではない。バイナリな「保持か削除か」の判断ではなく、個別のルーティング判断が必要だ。
キャッチオールに関するよくある 3 つの間違い。
検証結果にキャッチオール結果が含まれると、ほとんどのチームは次の 3 つのパターンのいずれかに陥る。
キャッチオールを有効として扱う。 チームはすべてのキャッチオールレコードを確認済みの有効アドレスと並べてメインキャンペーンにインポートする。それらのレコードがバウンスや低エンゲージメントを生み出すと、チームはインポート時のリスト品質の判断ではなく、送信者やコピーを責める。
キャッチオールを無効として扱う。 チームはインポート前にすべてのキャッチオールレコードを破棄する。医療、金融、中規模 B2B 企業などの一部の業界ではキャッチオール設定が一般的で、破棄されたレコードは実際の連絡先を表している可能性がある。チームはポリシー上の根拠もなく到達可能なプロスペクトを失う。
キャッチオールを完全に無視する。 チームはキャッチオールのステータスでまったくフィルタリングしない。キャッチオールレコードは確認済みの有効なアドレスと静かに混在してメインキャンペーに入る。リストが最初からきれいでなかったため、バウンスのパターンが診断しにくくなる。
標準的なキャッチオールワークフロー。
ポリシーベースのアプローチは、レコードが送信者に入る前に、キャッチオールを独自のセグメントに分離する。そのセグメントは異なるルールを持つ:少量、より密な監視、そして現在のキャンペーンに含まれるべきか保留キューに入れるべきかの判断。
キャッチオールセグメントは破棄場所ではない。監視されるセグメントだ。一部のキャッチオールレコードは返信を生む。その他はバウンスするか、エンゲージメントがない。キャッチオールセグメントへの最初の少量送信は、そのドメインの実際の動作に関する本物のシグナルを提供する — 検証だけでは得られない情報だ。
インポート前に各結果を振り分ける。
| BillionVerify の結果 | インポート前のアクション |
|---|---|
| 有効 | メインキャンペーンリストにインポートする |
| 無効 | インポートしない — サプレッションファイルに追加する |
| キャッチオール | 別セグメント、少量、有効と混在させない |
| 役職ベース | 共有受信ボックス向けメッセージの別キャンペーン |
| 不明 | 手動レビュー — メインキャンペーンから除外する |
| リスクあり・使い捨て | インポートしない |