Sailthruのリストをクリーニング：検証、オプトアウト、送信可能な状態の維持

Sailthruは、リストの衛生管理のうち2つをすでに自動で行っています。ハードバウンスしたアドレスへの送信を止めること、そしてオプトアウトを尊重することです。どちらも実際に機能しており、何かに手を付ける前に理解しておく価値があります。ただし、どちらも「事後対応」です。送信と失敗が起きるか、本人が配信停止をクリックして初めて働きます。送信者レピュテーションをひそかに傷つけるのは、そのどちらも起きていないアドレスです。インポートや登録で入った一度も送信していない無効なアドレス、使い捨ての受信トレイ、失効したメールボックス、すべてを受け付けるのに何も確認できないキャッチオールドメインがそれにあたります。このガイドでは、Sailthruが自動でクリーニングする範囲、仕組み上どうしても見つけられない範囲、そして残りを検証して無効なアドレスをオプトアウトする方法を説明します。ネイティブのコネクターを使ってその場で行う方法と、どのプランでも使えるCSVの手順があります。

Sailthruがすでに行っていること#

Sailthruは現在Marigoldのクロスチャネル向けスイートの一部であり、ユーザーベースに対して、何もしなくても基本的な衛生管理を行っています。

• ハードバウンスは抑制されます。 アドレスが恒久的な失敗を返すと、Sailthruはそのユーザーをhardbouncedとしてフラグ付けし、以降の送信から除外します。除外のために手作業で取り除く必要はありません。
• オプトアウトはアカウント全体で尊重されます。 誰かが配信停止すると、Sailthruはそのユーザーにオプトアウトのステータスを記録し、設定したオプトアウトのレベルに応じてキャンペーンから外します。確認済みの無効なアドレスを取り除くときに使うのも、この同じ仕組みです。新しい抑制の方法を考え出すのではなく、Sailthruがすでに動かしている仕組みにデータを渡すだけです。
• 迷惑メール報告も反映されます。 メールプロバイダーからのフィードバックループの報告があると、オプトアウトと同じように、そのユーザーは送信可能なオーディエンスから外れます。

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

ユーザーベースがすべて確認済みの登録で作られ、継続的に配信されているなら、これだけで十分かもしれません。ただ、多くのSailthruのリストはそうではありません。インポート、リード獲得、集客キャンペーンで増えており、まさにそこに死角が生まれます。

Sailthruでは見つけられないもの#

上記の仕組みはどれも、バウンス、配信停止、迷惑メール報告といった「イベント」が起きて初めて働きます。そのため、送信で実害が出るまで、Sailthruが何のシグナルも持たないアドレスが残ります。

• 一度も送信していない無効なアドレス。 以前のメール配信サービス（ESP）からインポートした連絡先、登録時に集めたアドレス、取得時の入力ミス（jane@gmial.com）は、Sailthruが一度も送信していないため、Sailthruでバウンスしたことがありません。最初のキャンペーンが届くまで、健全なユーザーと見分けがつきません。
• 使い捨てアドレス。 登録時に使われる一時的な受信トレイは、割引を受け取るあいだだけ機能し、その後は存在しなくなります。きれいにバウンスしないことが多く、単に意味をなさなくなっていきます。
• 役割アドレス（info@、sales@、billing@）。チームで読まれる実在のメールボックスです。領収書には問題ありませんが、マーケティングには向かず、オーディエンスの作成に使うエンゲージメント指標を歪めます。なぜ振る舞いが違うのかは、役割アドレス、使い捨てアドレス、フリーメールアドレスをご覧ください。
• 失効したメールボックス。 転職や受信トレイの放棄は日常的に起こります。来月ハードバウンスになるアドレスも、今日のSailthruでは生きているアドレスと区別できません。
• キャッチオールドメイン。 すべてのアドレス宛てのメールを受け付けて後から振り分けるドメインがあり、SMTPチェックでは特定のメールボックスの存在を確認できません。こうしたアドレスは盲目的に信頼せず、送信数を絞って扱う必要があります。考え方はキャッチオールの解説で説明しています。

インポートには特に注意が必要です。別のプラットフォームにあったリストは、バウンスの履歴が取り除かれた状態で届きます。以前のサービスでバウンスしていたアドレスや抑制されていたアドレスも、他のアドレスとまったく同じ見た目で入ってきて、Sailthruはそのすべてに一度は送信してしまいます。その1回のキャンペーンで、メールプロバイダーは送信者への第一印象を決めます。だからこそ、順序は逆ではなく、先に検証し、後からインポートするのが正しいのです。

手順：エクスポート、検証、オプトアウト#

最速の方法は、ネイティブのコネクターです。Sailthruと連携すると、Qualisendがユーザーベースを検証し、結果をその場で書き戻します。ファイルのやり取りは不要です。新しいコンタクトにはリアルタイムでチェックが走るため、無効なアドレスや使い捨てアドレスがそもそもリストに入りません。連携を使いたくない場合や、CSVのほうが簡単なプランをお使いの場合は、次の手動の手順がどこでも使えます。ほとんどのリストで15分ほどで終わります。

1. Sailthruからエクスポートします。 クリーニングしたいリストを開いてエクスポートのオプションを選ぶと、SailthruがユーザーのCSVを生成して届けます。初回のクリーニングではリスト全体をエクスポートします。メンテナンスでは、オーディエンスのセグメント（たとえば一定の日付より前に作成されたユーザーや、一度もエンゲージしていないユーザー）にすると、ジョブを小さく保てます。
2. ファイルを検証します。 CSVをQualisendの一括クリーニングにアップロードするか、アドレスを直接貼り付けます。1ジョブあたり最大1,000,000件まで処理でき、重複は1回分しか課金されません。無料プランには、有効期限のない100クレジットが1回限り付いており、この手順を最初から最後まで試すのに十分です。
3. 結果を確認します。 すべてのアドレスがdeliverable、risky、undeliverable、unknownのいずれかで返され、理由コードとサブフラグ（キャッチオール、使い捨て、役割、容量超過）、ドメインのMXプロバイダー、SMTPプローブの証拠、0～100の信頼スコアが付きます。判定の列が付いたクリーニング済みのファイルをダウンロードしてください。
4. undeliverableをオプトアウトします。 結果をundeliverableに絞り込み、配信停止のリストを処理するときと同じ方法で、Sailthruでそのユーザーをオプトアウトします。アドレスをインポートして、オプトアウトのステータスに設定します。これで、ユーザーのレコードと履歴を削除せずに、今後のすべての配信から外せます。disposableのフラグが付いたアドレスも抑制してください。その受信トレイは、使い捨てを前提に作られています。
5. 中間の判定は慎重に扱います。 riskyかつキャッチオールのアドレスは、専用のセグメントに移し、全量で送信せず、送信数を絞ります。unknownの結果は有効のままにして、次のサイクルで再検証します。不確定なプローブが1回あっただけ（多くはグレーリスティングやレート制限）では、そのメールボックスへの判定とは言えません。
6. 次のキャンペーンのバウンス率を確認します。 リストがクリーンになれば、ハードバウンス率はゼロに近づくはずです。その後もバウンスが続く場合、原因の多くは残っているキャッチオールのセグメントです。これは検証の問題ではなく、送信ポリシーの問題です。

特定のプラットフォームによらない全体の方法は、メールリストのクリーニング方法をご覧ください。不要なアドレスを恒久的に締め出すには、取得時点で検証APIを使って検証してください。入力ミスや使い捨てのアドレスがSailthruに届くことはなくなります。

Sailthruのクリーニングはどのくらいの頻度で行うか#

誰にでも当てはまる頻度はありません。劣化の統計を作り上げて急かすこともしません。実際の判断材料は、ユーザーベースの増える速さと増え方です。確認済みの登録で増えるリストの劣化はゆっくりですが、インポート、リードマグネット、有料の集客で増えるリストでは、不要なアドレスが常に溜まっていきます。多くの送信者には、次の3つのきっかけで足ります。

• 重要な配信の前。 大きなローンチやブラックフライデーのキャンペーンは、リストの劣化に気づくべきタイミングではありません。
• 大量インポートの後、 そのユーザーに最初のキャンペーンを送る前。
• 送信量に合わせた周期。 大量に送る送信者は月次、小規模なリストは四半期ごとが目安です。定期的なクリーニングの間は、キャンペーンごとのバウンス率を警戒ラインにします。バウンス率が警告のしきい値に近づく傾向なら、待たずに今すぐクリーニングしてください。どちらも詳しくは、バウンス率が重要な理由とリストをクリーニングする頻度をご覧ください。

Sailthruは、多くの場合ユーザーベースの規模に応じて設定されるエンタープライズ契約で提供されます。そのため、到達できないアドレスを削減することは、到達率のための施策であるだけでなく、更新の協議でリストのうち実際に送信可能な割合を正直に示せるようにする、データ衛生の習慣でもあります。