SaaS向けメールアドレス検証：登録から受信トレイまで

SaaSプロダクトは、ほとんどの企業が意識しないほど深くメールに依存しています。ユーザーをログインさせるマジックリンク、ロックアウトされたアカウントを救うパスワードリセット、決済後の領収書、有料転換を左右する「トライアルはあと3日で終了します」という通知。これらはすべて、ユーザーが一度だけ、たいていは登録フォームで、急いで入力することも多いアドレスをきっかけに送られます。SaaS向けのメールアドレス検証は、プロダクトがそのアドレスに依存し始める前に、アドレスが実在することを確認するための手段です。これを怠ると、目に見えにくいのに高くつく失敗が起こります。アクティベーションメールが届かず、ユーザーはプロダクトが壊れていると考え、さらに、入り込んだ偽アカウントや入力ミスのアカウントが、ほかのすべてのユーザーのメールを支える送信者レピュテーションをじわじわと損ないます。このガイドでは、SaaSプロダクトのどこでメールが重要になるか、摩擦を増やさずに登録時に検証する方法、すでにあるユーザーリストをクリーンに保つ方法を取り上げます。

結論#

検証は2か所で行います。まず、登録時にリアルタイムで検証APIを呼び出し、アドレスが入力された時点で不良アドレスを見つけます。@gmial.comのような入力ミスや使い捨てアドレスを、ユーザーがまだ画面上にいるうちにフラグ付けすれば、存在しないメールボックスにマジックリンクやウェルカムメールが送られてバウンスするのを防げます。次に、すでにあるユーザーリストを定期的に一括クリーニングします。ユーザーは転職し、古い受信トレイを使わなくなり、何も言わずに離脱するため、アドレスは劣化するからです。リアルタイム検証は不良アドレスの流入を防ぎ、一括クリーニングはすでに入り込んだものを取り除きます。どちらも守っているのは同じもの、つまり、プロダクトの動作に欠かせないトランザクションメールとライフサイクルメールの到達率です。

SaaSでメールアドレス検証が特別な理由#

ほとんどの送信者は、アドレスを1つの目的で取得します。SaaSプロダクトでは、1つのアドレスが3つの目的を同時に担います。アドレスが間違っていると、それぞれが異なる形で影響を受けます。

1つ目はトランザクションメールと認証メールです。確認リンク、マジックリンク、パスワードリセット、領収書、2要素認証のコードなどです。ユーザーはこれらをのんびり読むわけではなく、届くまで先に進めません。マジックリンクが届かなければ、ユーザーはログインできません。「メールが届きません」は、サポートチケット、アクティベーションの失敗、あるいは気づかないうちに起きる離脱につながります。ここでのアドレスの誤りは、購読者を1人失うという話ではありません。実在する人が行き詰まる、壊れたプロダクト体験です。

2つ目はトライアルから有料への育成メールです。オンボーディングのシーケンス、機能のヒント、「トライアルがまもなく終了します」というリマインダーは、無料登録を売上に転換する役割を担います。これらが迷惑メールに振り分けられたりバウンスしたりすると、トライアルは静かに期限切れになり、本当の原因は配信にあるのに、失注の理由はプロダクトにあると考えてしまいます。

3つ目はプロダクトメールとライフサイクルメールです。利用状況のダイジェスト、通知メール、再エンゲージメントのキャンペーン、請求の警告などです。ここでは、不良アドレスはどの送信者の場合とも同じ動きをします。つまりバウンスし、十分な数になれば、送信元ドメインのレピュテーションを押し下げます。問題は、3つのメールがたいてい同じドメインを共有していることです。そのため、1つの経路から入り込んだ不要なアドレスが、残り2つの到達率まで下げてしまいます。

リアルタイムAPIで登録時に検証する#

不良アドレスを見つけるのに最も低コストなのは、データベースに入る前、つまりユーザーがまだ画面上にいて、修正できる間です。リアルタイム検証は、まさにそのためのものです。登録時にアドレスが送信された時点で検証APIを呼び出し、結果を読み取って、フローの中で処理します。

リアルタイムのチェックは、ステータス（deliverable、risky、undeliverable、unknown）に加え、理由コード、0～100の信頼スコア、使い捨て、役割、フリーメール、キャッチオールなどを示すサブフラグを返します。この結果の背後にあるパイプラインは、構文、ドメイン、MXレコード、メールボックス自体を確認するため、単なる形式チェックをはるかに超える結果が得られます。結果をどう扱うかは、登録ロジックで決めます。最も価値が高いのは、うっかりミスの救済です。ドメインが実在するプロバイダーに似た綴り違いだったためにundeliverableが返ってきた場合は、「gmail.comではありませんか？」とユーザーに確認を促します。確認メールがバウンスした時点で失っていたはずのアカウントを取り戻せます。

これが裏目に出ないようにするためのルールは、やみくもにブロックせず、フラグを立てることです。登録フォームの目的は、本物のユーザーを迎え入れることです。明らかに不良なアドレスに対して、修正できる穏やかな確認を表示するのはよいUXです。一方で、確認済みのdeliverable以外をすべて拒否する厳格なブロックをかけると、いずれ、メールサーバーの応答が遅かっただけの本物のユーザーを断ることになります。そのときの結果は不良アドレスではなくunknownです。登録時の検証をサーバーレスのフローに組み込み、レイテンシーや摩擦を増やさない方法は、登録時に検証するパターンで詳しく説明しています。また、Qualisendはスコープ付きのAPIキーを発行するため、登録連携専用のキーを作成し、そのアクセス範囲とレート制限を限定しておけます。

ブロックせずフラグを立てる：登録時の使い捨て、役割、キャッチオール#

SaaSの登録フォームには、特有の不要なアドレスが集まります。よくある間違いは、標準的でないアドレスをすべて「見つけ次第拒否」にしてしまうことです。種類ごとに判断が必要で、サブフラグがその判断材料になります。

• 使い捨てアドレス。 使い捨てアドレスは、登録時に厳しく止める価値がある唯一の種類です。多くは、実際のアドレスを渡さずに無料トライアルを使うために入力され、二度と連絡が取れず、アクティベートも課金もできないアカウントでユーザー数を水増しします。使い捨てのサブフラグを使えば、ユーザーテーブルの無効な行になる前に、登録を断るか、より厳格な検証の枠に回せます。
• 役割アドレス。 admin@、support@、billing@のような共有メールボックスは、個人ではなく会社が登録するときによく使われます。トランザクションの領収書には問題ありませんが、特定の誰かが所有しているわけではないため、個人向けのオンボーディングメールには向きません。送信するか除外するかの判断は、役割アドレス、使い捨てアドレス、フリーメールアドレスの解説にまとめています。
• キャッチオールドメイン。 キャッチオールドメインは、あらゆるアドレス宛てのメールを受け入れるため、検証ツールは個別のメールボックスが存在するかを確認できず、結果はdeliverableではなくriskyになります。キャッチオールドメインを使う正当な法人ユーザーは少なくないため、登録時にすべてをブロックすると、実在する有料アカウントを断ることになります。通過させたうえで、ライフサイクルメールの送信時に少し慎重に扱ってください。

ユーザーリストを定期的に一括クリーニングする#

リアルタイム検証が守るのは、新しい登録だけです。すでにいるユーザーには効果がなく、意外に多くのリスクが潜んでいるのはそのリストです。SaaSのユーザーリストは、見落としやすい形で劣化します。転職して登録時の勤務先アドレスを使わなくなる人、廃業する会社、何年も休眠する無料アカウントがあり、リストの一部は、登録時の検証を導入する前のものかもしれません。

そのためには一括クリーニングを行います。ユーザーリストをCSVにエクスポートし、すべてのアドレスをまとめて検証にかけると、各行について同じステータス、理由、スコア、サブフラグが返ってきます。undeliverableは除外し、残りは方針を決めて扱います。休眠アカウントへの再エンゲージメント、大きなプロダクト告知、料金改定など、大規模なライフサイクルメールの前には、これが標準的な作業です。具体的な手順はメールリストのクリーニング方法に、大きなリストを効率よく処理する方法は一括メール検証にあります。後者には、リスト内の重複アドレスは1回しかチェックされないため、水増しされたエクスポートでも同じアドレスに二重に課金されないことも書かれています。

頻度はリストの動きの速さによって決まります。ただ、アクティブなユーザー全体を定期的にクリーニングし、休眠セグメントは再開する前に再検証すれば、劣化が積み重なるのを防げます。リアルタイムと一括は、どちらかを選ぶものではありません。成長するSaaSには両方が必要です。一方は入力時に新しい登録をクリーンに保ち、もう一方は、その後に劣化したアドレスを取り除きます。

アプリドメインの送信者レピュテーションを守る#

ここまでの話はすべて、損ねることのできない1つの資産に行き着きます。プロダクトがメールを送信するドメインの送信者レピュテーションです。GmailやOutlookなどは、送信者の行動に基づいてスコアを付けます。バウンスや無効なアドレスが続く状態は、送信者レピュテーションを最も急速に損なう原因の1つです。このスコアが、メールが受信トレイに届くかどうかを決めます。偽アカウントや入力ミスの登録がたまると、バウンス率が上昇し、メールプロバイダーが警告のサインとみなす水準に達します。そうなれば、クリーンで必要とされているメールまで迷惑メールに入るようになります。

SaaSプロダクトでは、特に危険です。最もリスクにさらされるのがトランザクションメールだからです。プロバイダーが送信ドメインを信頼しなくなると、アクティブな本物のユーザーを先に進ませるパスワードリセットやマジックリンクこそが、フィルタリングされ始めます。ログインできないユーザーは、じっと待ってはくれません。離脱します。登録時の検証は、最も問題のあるアドレスがバウンスする前に入口で止め、定期的な一括クリーニングは、入った後で劣化したものを取り除きます。さらに、マーケティングとライフサイクルのリストには確認付きオプトインを組み合わせてください。どこまで厳格にするか迷っている場合は、シングルオプトインとダブルオプトインのトレードオフも参考になります。これで、プロダクト内のほかのすべてのメールが静かに頼っている資産を守れます。

実装する開発者のために#

SaaSの読者にとって、連携の実装は通常エンジニアの担当になります。登録ハンドラーからREST APIを呼び出し、レスポンスからステータスと理由を読み取って、自社のロジックで分岐します。修正を促す、使い捨てアドレスを断る、アカウントの作成を進める、といった具合です。スコープ付きAPIキーを使えば、連携ごとに別々のキーを発行し、それぞれを専用のレート制限の範囲内に収められます。公開の登録フォーム、社内の管理ツール、バッチジョブがすべてAPIを呼び出す場合に役立ちます。エンドポイント、レスポンスの構造、分岐に使うすべてのステータスと理由コードは、開発者向けドキュメントで確認できます。定期的なクリーニングは、CSVによる同じエクスポート、検証、対応の流れで行え、コードは不要です。

プロダクトのメールから不良アドレスを締め出す方法は2つあり、同時に使えます。開発者向けドキュメントを参考に登録時のリアルタイム検証を組み込み、無料メールチェッカーで実際の結果の形式を確認し、料金ページでクレジットを購入して、お手元のユーザーリストを一括クリーニングしてください。すべてのマジックリンクが届き、プロダクトを支えるドメインの信頼が保たれます。