キャッチオールメールとは？ 率直に解説するガイド

要点を先に#

キャッチオールドメイン（アクセプトオールドメインとも呼ばれます）は、そのドメインのあらゆるアドレス宛てのメールを、実在するかどうかにかかわらず受け付けるように設定されています。検証ツールが特定のメールボックスの存在をメールサーバーに問い合わせても、キャッチオールのサーバーはすべてに「はい」と答えるため、その答えからは何も分かりません。そのアドレスは実際に配信できるかもしれませんが、実際にメールを送らない限り、どのツールにも確認できません。Qualisendはこうしたアドレスを、riskyとして理由low_deliverabilityとキャッチオールのフラグ付きで報告し、「valid」とは決して報告しません。

最後の一文が、このガイドの編集方針のすべてです。キャッチオールドメインのメールボックスは確認できません。そうでないと説明する製品や記事は、同じ不確かさに耳当たりのよい名前を付けているだけです。

キャッチオール検出の実際の仕組み#

キャッチオール検出は、検証パイプラインの段階7にあたるドメイン単位のテストで、手法は拍子抜けするほど素朴です。対象のアドレスと並行して、検証ツールは同じドメインに意図的にでたらめなメールボックス、つまり誰も登録しないような文字列をプローブします。サーバーがそれも受け入れた場合、そのドメインはすべてを受け付けており、そのサーバーからのメールボックス単位の答えは信頼できません。

通常のドメインに対するSMTPのやり取りの該当部分を示します。サーバーは実際にメールボックスの一覧を確認しています。

> RCPT TO:<jane@example.com>
< 250 2.1.5 OK
> RCPT TO:<x9f2kq77c@example.com>
< 550 5.1.1 The email account that you tried to reach does not exist

でたらめなアドレスに対する550があるからこそ、jane@に対する250に意味があります。このサーバーは存在しないメールボックスを拒否するため、受け入れは本当の答えです。

次に、キャッチオールドメインに対する同じプローブです。

> RCPT TO:<jane@example.com>
< 250 2.1.5 OK
> RCPT TO:<x9f2kq77c@example.com>
< 250 2.1.5 OK

どちらも250が返ります。サーバーは存在し得ないアドレスにも「はい」と答えたため、jane@への「はい」は何も証明しません。jane@example.comは実在する有効なメールボックスかもしれませんし、キャンペーンを送った途端にバウンスする入力ミスかもしれません。検証の時点では、外部からこの2つを区別することはできません。

検出自体が確定しないことがある理由#

実際には、2つのきれいなやり取りのようにはいかず、もっと複雑です。メールサーバーは、見知らぬ相手からの問い合わせに対して積極的に防御します。見慣れない送信者をグレーリスティングして4xxの一時的な保留を返したり、同じIPからの繰り返しのプローブをレート制限したり、意図的に応答を遅らせたり（タールピット）、やり取りの途中で接続を切ったりします。企業のフィルタリングゲートウェイには独自の挙動もあります。多くはSMTPの入口ですべてを受け付け、受信者の評価をあとで行うため、その背後のメールボックスがどう答えるかにかかわらず、外部からはキャッチオールに見えます。

ここから2つのことが言えます。1つ目は、同じアドレスでも日によって異なる判定が出ることがあるという点です。変わったのはメールボックスではなく、サーバーの機嫌だからです。2つ目は、誠実な検証ツールには、確定的な答えに至らなかったやり取りのために、timeoutやunavailable_smtpなどの理由を伴うunknownという判定が必要だという点です。unknownは「後で再試行」と扱うべきで、黙ってvalidかinvalidに分類してはいけません。「unknown」を一度も返さないツールが正確なのではありません。同じネットワークの現実に対して、誠実さが低いだけです。

検証ツールごとにキャッチオールの判定が異なる理由#

同じBtoBリストを複数の検証ツールにかけると、業界内の静かな見解の相違が見えてきます。あるツールはアドレスを「valid」とし、別のツールはキャッチオールと呼び、3つ目のツールは説明のない87というスコアを付けます。どれも同じSMTPの挙動を見ています。違うのは、各ツールがその挙動について何を主張するかです。

動機の問題は単純です。「valid」は「分からない」よりも売りやすいのです。リストの95%をdeliverableと報告する検証ツールは、70%をdeliverable、25%をriskyと報告するツールより正確に見えます。キャンペーンを送信してバウンスが届くまでは、です。ベンダーによっては、これに乗じて、「キャッチオールの解決」をうたったり、AIによる信頼度スコアで確認できないアドレスを黙って送信可能な側に切り上げたりします。

第三者によるテストでも、この問題は実際に確認されています。BtoBのリストで127,000件のチェックを行った2026年の実地比較では、テストされた7つのツールのうち3つが、既知のキャッチオールアドレスのうち15～42件を「valid」と判定しました。いずれも、テスト担当者が確認不能なものとして意図的に仕込んだアドレスです。当社に好意的な情報源を含め、どの情報源にも当てはまる注意点があります。比較テストは、たいてい何かを販売している企業が公開しています（この比較も営業自動化ベンダーによるものです）。順位ではなく、カテゴリー別の生データの表と方法論を読んでください。

スコアのごまかし#

説明のない信頼度スコアには注意してください。キャッチオールのアドレスに付いた「87/100」は正確に見えますが、誰も尋ねていない問いに答えています。重要な問いは「このメールボックスは存在するか」であり、キャッチオールドメインについては答えが分かっています。確認できない、です。それを2桁の数字で包んでも情報は増えず、問題の分類が隠れるだけです。スコアが役に立つのは、何から算出されたかが見える場合だけです。そのためQualisendは、すべての判定でその入力を公開しています。ステータス、理由コード、サブフラグ、ドメインのMXプロバイダー、そしてSMTPのやり取りが実際に返した内容です。読める根拠は、信じるしかない数字に勝ります。

Qualisendの方針は地味なものです。キャッチオールのアドレスはriskyとして、理由low_deliverability、キャッチオールのフラグ、中間帯の信頼度スコアとともに報告し、deliverableに切り上げることは決してありません。すべての判定には根拠（ドメインのMXプロバイダーとプローブの詳細）が付くため、数字をただ信じるのではなく、その判定になった理由を確認できます。当社と他社のキャッチオールの扱いは、Qualisend vs ZeroBounceやQualisend vs NeverBounceなど、比較ページで確認できます。

比較ページで言及している競合他社の動作は2026年7月時点で確認したものです。

検証ツールを選ぶ際は、次の3つの質問をすると、宣伝文句の裏がすぐに見えてきます。

• キャッチオールドメインについて、具体的に何を報告しますか？ 答えが「valid」や単なるスコアなら、そのツールが他の場面でも不確かさをどう扱うかが分かります。
• アドレスごとの根拠を確認できますか？ MXレコード、プロバイダー、SMTPの応答は確認できる事実です。それらのない判定は意見にすぎません。
• 「unknown」を返すことはありますか？ 毎回すべてのアドレスに確定的な答えを出せると主張するベンダーは、存在しないネットワークを語っています。

キャッチオールドメインはどのくらい一般的か#

出典が明確な公開数値で最も信頼できるのは、ZeroBounce自身の集計データです。2025年に処理した約110億件のアドレスのうち、9%超がキャッチオールとして返されました。また、大企業が多いBtoBリストでは30%以上になることも多いと説明されています。他のベンダーは、BtoBアドレスの40～60%という高い数字を公表していますが、たいていデータソースを示していません。出典のない普及率の数字は、宣伝と考えてください。率直にまとめると、全体では約10件に1件、企業向けのBtoBリストではその数倍です。そして重要なのは、自分のリストの数字だけであり、それは検証すればすぐに分かります。上記の数値は2026年7月時点で確認したものです。

これらの数字の背景は次のとおりです。キャッチオールの設定は、一般消費者向けのリストよりBtoBのリストではるかに多く見られます。Google WorkspaceとMicrosoft 365はどちらも、キャッチオールのルーティングを管理者設定で簡単に有効にでき、多くの企業が、綴りを間違えたアドレス（john.smith@ではなくjhon.smith@）でも誰かに届くようにするために有効にしています。企業のセキュリティゲートウェイがもう1つの層を加えます。先にメールを受け付けてからフィルタリングする機器は、背後に実在のメールボックスがあっても、SMTPの時点ではすべてを受け付けるように動作します。一方、大手の一般消費者向けプロバイダーは、RCPTの時点で存在しないメールボックスを拒否します。gmail.comはキャッチオールドメインではありません。

実用上の結論は次のとおりです。企業向けに販売しているなら、どの検証ツールを使っても、リストのかなりの部分がrisky/キャッチオールとして返されます。送信戦略には、その部分への答えが必要です。ラベルを付け替えるだけのツールでは解決しません。

この割合は、リストの作られ方によって変わります。Gmail、Outlook.com、Yahooのアドレスが大半を占める一般消費者向けのニュースレターのリストでは、キャッチオールの判定はごくわずかです。名刺のスキャン、勤務先のメールアドレスでのウェビナー登録、企業ドメインを対象にした営業のプロスペクティングで作ったリストでは、はるかに多くなります。リストが古いほど、アドレスを収集してからメールプロバイダーや設定が変わったドメインの割合も増えます。

キャッチオールのアドレスに送信すべきか#

正直なところ、可否を単純に答えることはできません。適切な判断は、そのアドレスの入手元、いまバウンスが与える影響の大きさ、送信者レピュテーションにどのくらい余裕があるかによって決まります。どんな場合にも不適切な唯一の答えは、全量配信でキャッチオールのアドレスを確認済みのアドレスとまったく同じように扱うことです。

「レピュテーションの余裕」は、多くの送信者が見落としている変数のため、説明しておきます。クリーンな送信の長い実績と高いエンゲージメントがあるドメインなら、キャッチオールのバウンスの一群をノイズとして吸収できます。新しいドメインや新しいIP、迷惑メールフォルダーに入った状態から回復中の送信者は、そうはいきません。同じバウンスが乏しい実績に積み重なり、評価を大きく動かします。現在の立場が危ういほど、リストの確認できない部分には厳しく対処すべきです。

どの方針を選ぶ場合でも、キャッチオールの送信は専用のセグメントに分けてください。そのセグメントで発生するハードバウンスは、遅れて届いた本当の答えです。どのキャッチオールのアドレスが最初から存在しなかったかを教えてくれます。また、レピュテーションへの悪影響が、リスト全体に薄まらず、封じ込められて測定できる形で現れます。どのくらいのバウンスによる影響に耐えられるか分からない場合は、バウンス率こそメールプロバイダーが実際に見ている指標である理由をお読みください。

自分をごまかさずにキャッチオールのリスクを減らす方法#

次の手法のどれも、キャッチオールのアドレスを「検証」するものではありません。不確かさを時間をかけて縮め、学習している間の被害を抑えるためのものです。

• セグメントを分けて配信量を絞る。 キャッチオールのアドレスは専用の送信グループに分け、通常の配信量のごく一部だけ送信します。これにより、バウンスの状況を切り分けて把握でき、影響も封じ込められます。
• シード送信。 大規模なキャンペーンの前に、まずキャッチオールのセグメントの一部に送信します。バウンスの結果を確認してから、どこまで広げるかを決めます。
• エンゲージメントが唯一の実質的な確認。 キャッチオールとフラグが付いていても、過去に開封やクリックがあったアドレスは、実質的に確認済みです。背後に人がいるからです。エンゲージメントのあるキャッチオールを優先し、反応のないものは疑ってください。
• このセグメントのバウンス率を個別に監視する。 プロバイダーは、継続的なハードバウンス率を送信者の品質のシグナルとして見ています。キャッチオールのセグメントが全体の数値に埋もれないよう、通常のしきい値に照らして個別に追跡してください。
• サンセットポリシー。 何度か送信しても反応がないキャッチオールのアドレスは、リストから外してください。反応がないこともデータです。
• 入口を直す。 アドレスを取得する時点で検証すれば、企業ドメインの明らかな入力ミスをその場で防げます。登録時に綴りの崩れた勤務先アドレスを1つ拒否するごとに、将来のキャッチオールのセグメントに居座るアドレスが1つ減ります。

リストがKlaviyoにある場合は、ステップバイステップのクリーニングガイドで、このプレイブックをエクスポート、検証、除外、キャッチオールのセグメント分けまで一通り実践できます。

ロードマップについて正直に補足します。ヒューリスティックでキャッチオールのアドレスを品質の見込みで順位付けすることは可能です。ドメインのMXプロバイダー、ゲートウェイの種類、過去のエンゲージメントはいずれもシグナルになり、Qualisendはすでにその根拠をアドレスごとに表示しています。ただし、順位付けは確認ではありません。キャッチオールドメインの背後にあるメールボックスは、実際に送信する以外に確認する方法はありません。そうでないと主張するツールが売っているのは、事実ではなくラベルです。

キャッチオールと関連する判定の違い#

キャッチオールは、「完全には保証できない」状況のうちの1つで、状況によって取るべき対応が異なります。1つのカテゴリーや1つのスコアにまとめてしまうと、必要な情報がまさに失われるのはそのためです。容量超過のメールボックスはたいてい自然に解消し、使い捨てアドレスは解消せず、キャッチオールには送信ポリシーが必要で、タイムアウトは再試行すれば済みます。すべてを同じように除外すれば到達可能な購読者を失い、すべてを同じように送信すればバウンスを招きます。これらの状況が、Qualisendのステータスと理由コードにどう対応するかを示します。

実際に最も重要な違いは次のとおりです。riskyは「サーバーには到達でき、気になる情報が分かった」ことを、unknownは「今回は確定的な答えが得られなかった」ことを意味します。riskyなアドレスには送信ポリシーが必要で、unknownのアドレスはたいてい再試行が必要です。