Help Scoutでメールアドレスを検証し、配信不能のものにタグを付ける方法

サポートメールはトランザクションメールの一種であり、到達率がそのまま成否を左右します。Help Scoutでチケットに担当者が返信すると、その返信はお客様宛てのメールになります。アドレスが無効なら返信はバウンスし、お客様には届かず、チケットは静かに再オープンされるか、SLAの期限を超過します。Help Scoutアカウント内のアドレスを検証すれば、こうした行き止まりを、対応の機会を失う前に見つけられます。このガイドでは、Help Scoutがコンタクトについて保存している情報、顧客リストをエクスポートして検証する方法、配信不能なアドレスにタグを付ける方法、新しいコンタクトをリアルタイムで確認する方法を順に説明します。

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

マーケティング用のリストなら、多少の無効なアドレスは許容できます。しかしサポートの受信トレイでは許容できません。メッセージの1通ごとが、回答を待っている特定の相手との約束だからです。

サポートの返信がバウンスしても、担当者にはほとんどの場合、その失敗が見えません。Help Scoutはメッセージを送信基盤に渡し、キューに入ったという応答を受け取って、コンバーセーションを回答済みにします。バウンスは非同期で届き、数分後のこともあれば、受信側サーバーが黙って破棄した場合はまったく届かないこともあります。お客様から見れば、何も起きていません。質問したのに、返ってきたのは沈黙だけです。その沈黙が、再問い合わせのチケットやチャージバック紛争、公開レビューにつながり、チームが対応したにもかかわらず、初回応答と解決のSLAにも不利に働きます。

もう1つ、時間をかけて効いてくるコストがあります。共有のサポート受信トレイとマーケティングの送信元は、同じドメインで認証されていることがよくあります。サポートメールで発生したハードバウンスや迷惑メール報告は、他のメールが受信トレイに届くかどうかを左右する同じドメインのレピュテーションに反映されます。メールプロバイダーはいま、このレピュテーションを厳しく見ています。仕組みは、GoogleとYahooの送信者ガイドラインのまとめと、より広い視点のメール到達率ガイドをご覧ください。返信先のアドレスをクリーンにすることが対策の1つで、返信元のドメインを認証することがもう1つです。Help Scoutからの送信にSPF、DKIM、DMARCをまだ設定していない場合は、検証と並行して、Help Scoutの認証（SPF/DKIM/DMARC）の手順で設定してください。

Help Scoutがコンタクトについて保持する情報#

Help Scoutは、誰かが受信トレイに初めてメールを送ると、顧客プロフィールを自動で作成します。手動で作成することもできます。各プロフィールには、1つ以上のメールアドレス、名前、会社、定義済みのカスタムプロパティのほか、その人に紐づくコンバーセーションの全履歴を保存できます。

検証にあたって重要な点が2つあります。1つ目は、プロフィール上のメールアドレスが、お客様が最初に連絡したときに入力した文字列そのままだということです。Help Scoutは基本的な形式以外の検証をしません。gmial.comのような入力ミス、billing@のような役割アドレス、長く放置されたメールボックスも、正常なアドレスと見分けがつかない状態で顧客データに残ります。2つ目は、Help Scoutに「検証済み」や「到達率」を示す組み込みのフィールドがないことです。コンバーセーションが配信されたかどうかは追跡し、個々のスレッドにバウンスの状況を表示しますが、リスト全体で絞り込みに使える恒久的なフラグは保持しません。このギャップを埋めるのがタグです。たとえばundeliverableのようなタグをお客様のコンバーセーションに付けておけば、後から絞り込みや検索ができます。基本的な概念に不慣れな場合は、メールアドレス検証とはで、以下で使う用語を確認できます。

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

手順：コンタクトをエクスポートし、検証して、配信不能のものにタグを付ける#

以下の手動の手順は、どのHelp Scoutプランでも使えます。最後のタグ付けまで、本番のデータには手を加えません。

1. 顧客をエクスポートします。 Help ScoutでManage → Customersを開き、必要に応じて絞り込み（たとえば過去1年間に作成された顧客）をかけて、エクスポート機能でCSVを生成します。ファイルへのリンクがHelp Scoutからメールで届きます。ファイルを開き、メールアドレスの列があることを確認します。

2. CSVをQualisendにアップロードします。 バルクジョブを作成し、メールアドレスの列を指定します。1つのジョブで最大1,000,000件のアドレスを処理でき、重複は1回分しか課金されません。同じアドレスから3件のチケットを送ってきたお客様の分を、二重に支払うことはありません。試してみるだけなら、無料プランに100クレジット（一度限り）が含まれており、期限切れにはなりません。

3. 判定を確認します。 すべてのアドレスは、deliverable、risky、undeliverable、unknownのいずれかで返され、それぞれに理由コードと、キャッチオール、使い捨て、役割アドレス、メールボックス満杯のサブフラグが付きます。MXプロバイダー、SMTPプローブの結果、0～100の信頼度スコアも確認できます。deliverableの行は残します。undeliverableは、返信を止めて問題ないものとして扱います。riskyはサブフラグで判断します。キャッチオールアドレスはSMTPの段階ですべてを受け付けるため存在を確認できませんが、メールボックス満杯は後で解消される場合があります。

4. Help Scoutで配信不能のアドレスにタグを付けます。 結果のCSVを、undeliverable（必要ならriskyも）のアドレスだけに絞り込みます。Help Scoutに戻り、顧客をそれらのアドレスで検索または絞り込んで、undeliverable-emailのようなタグを付けます。タグは、Help Scoutに本来ない、恒久的で絞り込める目印になります。担当者は返信が届きにくいことをひと目で把握でき、別のチャネルで連絡できます。

この手順は繰り返し実行できますが手作業で、反映されるのはエクスポートした時点の状態だけです。常に最新の状態を保つには、次の連携を接続してください。

新しいコンタクトをリアルタイムで検証する#

QualisendのネイティブHelp Scout連携は提供中です。Help Scout連携を接続すると、既存の顧客リストをその場でクリーニングできます。Qualisendが各アドレスを検証し、結果をHelp Scoutに書き戻します。その後は、新しいコンタクトが届くたびにリアルタイムで確認するため、次にエクスポートを思い出したときではなく、お客様が初めて連絡してきた時点で、問題のあるアドレスにフラグが立ちます。これが最も手早い方法で、多くのチームでは、CSVによる手順をこれで完全に置き換えられます。

コネクターを追加できないプランの場合や、独自のワークフローに検証を組み込みたい場合も、上記のCSVの手順は引き続き使えます。さらに、次の2つの方法でカバーできます。

• API。 自社のミドルウェアからQualisendの検証APIを呼び出し、顧客プロフィールが作成された時点でアドレスを確認します。スコープ付きのキーを使い、レート制限があり、Webhookにも対応しているため、結果に非同期で対応できます。リクエストの形式と判定のスキーマは、開発者向けドキュメントをご覧ください。
• ノーコード。 Zapier、Make、n8nを使い、Help Scoutの「新しいコンバーセーション」または「新しい顧客」のイベントで検証を起動し、判定結果で分岐して、顧客にタグを付けたり担当者に通知したりします。コードは不要です。

どの方法を選んでも、検証と認証は併せて行ってください。クリーンなアドレスなら返信が受け付けられ、正しく署名されたドメインなら迷惑メールに振り分けられずに済みます。効果はメールのバウンス率ベンチマークで追跡し、サポートの受信トレイにとって「良い」状態がどの水準かを把握してください。