Zendeskのメール検証：返信がバウンスする前にサポートリストをクリーニング

サポートメールは、顧客が実際に返事を待っているメールです。ユーザーがチケットを作成すると、担当者の返信も「リクエストを受け付けました」という確認メールも、その後のやり取りもすべて、エンドユーザーのプロフィールに登録されたメールアドレス宛てに送られます。そのアドレスが入力ミスだったり、とうに使われなくなっていたり、誰も読まない役割アドレスだったりすると、返信はバウンスし、チケットは動かなくなります。原因はチームの対応の遅さではなく、メッセージが届いていないことです。このガイドでは、サポートツールにとってなぜ到達率が重要なのか、Zendeskが送信先の人物について何を記録しているのか、そしてQualisendでエンドユーザーを検証する方法を解説します。方法は、ネイティブコネクターを使うものと、どのプランでも使えるCSVエクスポートを使うものの2つです。

サポートメールの到達率が重要な理由#

マーケティングメールには数％のロスを吸収する余地がありますが、サポートメールにはありません。送信する通知はすべてトランザクションメールで、時間的な制約があります。

• チケットへの返信は顧客に届かなければなりません。 担当者が返信すると、Zendeskはその返信をリクエスターにメールで送ります。バウンスすると、顧客は回答を見ないまま、翌日に「その後どうなっていますか？」と問い合わせ、チケットが再オープンされます。すでに解決していた問題のために、返信時間や解決時間の指標が悪化します。
• バウンスした通知は、気づかないうちにSLAを損ないます。 初回返信や解決のSLAは、顧客が受け取った時点ではなく、担当者が対応した時点で達成と扱われます。配信に失敗していても、ダッシュボードでは目標を達成したことになり、顧客は何の連絡もないまま待たされます。自社側の誰も気づけないため、最も厄介な未達です。
• 配信不能なメールは送信者レピュテーションを傷つけます。 サポート用ドメインは、自動通知を大量に送信します。ハードバウンスが続くと、メールプロバイダーはリストの衛生状態が悪いと判断し、そのレピュテーションの低下によって、問題のない返信まで迷惑メールに振り分けられかねません。送信ドメイン認証も同じくらい重要です。ZendeskでSPF、DKIM、DMARCを認証する方法を参照してください。

共通するのは、バウンスしたサポート返信は、内部から見ると届いた返信と区別がつかないという点です。検証は、再オープンされたチケットや顧客からの強いクレームという形で損失が出る前に、この盲点をなくします。レピュテーションについては、メール到達率ガイドで詳しく解説しています。

Zendeskが連絡先について記録する情報#

Zendesk Supportでは、顧客はエンドユーザーとして管理され、各プロフィールには通知に必要な項目が含まれます。

• プライマリメールと、任意の数のセカンダリメール。Zendeskが実際に配信する宛先です。
• ユーザータグ。プロフィールに自由に付けられるラベルで、後からフィルター、セグメント化、トリガーの条件に使えます。
• 組織、ロール、言語、タイムゾーン、および管理者が定義したカスタムユーザーフィールド。

一方、Zendeskには連絡先ごとの到達可否のステータスがありません。通知がバウンスすると、Zendeskは該当するチケットに配信失敗のイベントを記録し、そのチケットのイベントで確認できますが、それをエンドユーザーのプロフィール上の「このアドレスは無効」というフィルター可能なフラグにまとめることはありません。そのため、10件の別々のチケットでバウンスしたメールボックスも、ユーザー一覧では正常なものと見分けがつきません。検証が埋めるのはこの空白です。チケットに失敗が表れたかどうかにかかわらず、アドレスそのものに対して継続的に使える判定を付けます。

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

手順：連絡先のエクスポート、検証、配信不能アドレスへのタグ付け#

最も早い方法はネイティブコネクターです。Zendesk連携を接続すると、Qualisendがエンドユーザーを検証し、結果をその場で書き戻します。リストを置いた場所のままクリーニングでき、CSVのやり取りは不要です。新しい連絡先もリアルタイムでチェックします（次のセクション）。プランや管理者のポリシーによりアプリを接続できない場合は、以下のCSVの手順で同じ作業を手動で行えます。この手順はどのZendeskプランでも使えます。

1. エンドユーザーをエクスポートします。 Admin CenterでAccount → Tools → Reportsを開き、Exportタブを選んでUserのエクスポートを実行します。ZendeskがユーザーのCSVを作成し、ダウンロードリンクをアカウントオーナーにメールで送ります。（リストを直接取得したい場合は、Support APIの/api/v2/usersエンドポイントがプログラムによる同等の手段です。Verification APIを参照してください。）
2. ファイルを検証します。 CSVをQualisendの一括クリーニングにアップロードします。1回のジョブで最大1,000,000件のアドレスを処理でき、重複は1回分だけ課金されます。アドレスを直接貼り付けることもできます。無料プランの100クレジット（1回限りで有効期限なし）で、最初のサンプルを試せます。検証が初めての方は、まずメールアドレス検証とはをご覧ください。
3. 結果を確認します。 各アドレスにはdeliverable、risky、undeliverable、unknownの4つの判定のいずれかが返され、理由コードとサブフラグ（キャッチオール、使い捨て、役割アドレス、メールボックス満杯）、MXプロバイダー、SMTPプローブの結果、0～100の信頼度スコアが付きます。クリーニング済みのCSVをダウンロードします。
4. Zendeskで配信不能アドレスにタグを付けます。 結果をundeliverableで絞り込み、該当するプロフィールにemail_undeliverableなどのユーザータグを付けます（Zendeskで一括編集するか、API経由で書き込めます）。削除せずにタグを付ければ、チケットの履歴を残したまま、担当者やトリガーが対応の根拠にできる情報を得られます。たとえば、バウンスするとわかっているメールを再送する代わりに、電話やチャットでのフォローアップに振り分けられます。
5. それ以外は判定ごとに対応します。 deliverableはそのまま残します。riskyはサブフラグを確認します。キャッチオールはメールボックス単位では確認できず、support@やbilling@のような役割アドレスは共有の受信トレイなので、フラグを付けて把握しておく価値があります。unknownのアドレスはそのままにして、次回の検証で再確認します。この判定は通常、存在しないメールボックスではなく、グレーリスティングや一時的なレート制限が原因です。

新しい連絡先をリアルタイムで検証する#

今日のリストをクリーニングしても、その時点の状態にすぎません。新しいエンドユーザーが作成された瞬間から、リストの劣化は始まります。新規顧客からのチケット、登録時の入力ミス、転送用のエイリアスなど、どれも新しい連絡先となり、Zendeskはそこにメールを送ろうとします。

ネイティブのZendesk連携を接続していれば、Qualisendは新しい連絡先が作成された時点で検証します。そのため、最初の自動通知が送られる前に、配信不能なアドレスにフラグが付きます。リストの衛生管理が、月に一度の作業から常時の保証に変わります。

アドレスがZendeskに書き込まれる前の、さらに早い段階で検証したい場合は、アドレスを最初に取得する箇所からVerification APIを呼び出します。たとえば、問い合わせフォーム、ヘルプセンターのユーザー登録、チケットを作成するミドルウェアです。スコープ付きAPIキー、レート制限、Webhookが用意されており、Zapier、Make、n8nを使えばノーコードでも同じチェックを組み込めます。入り口で不正なアドレスを止めれば、そのアドレスはZendeskに入らないため、バウンスした返信や再オープンされたチケットにつながることがありません。