使い捨てメール検知API：偽のサインアップを入口で止める

偽アカウントの多くは、同じところから始まります。明日にはもう存在しない受信箱です。使い捨てメールサービスは、確認リンクをクリックするためだけに短時間だけ有効なメールアドレスを発行します。寿命は10分、場合によってはそれ以下。その後は消えてしまい、その「ユーザー」に連絡を取る手段も一緒に失われます。SaaS企業にとって、その1つのメールアドレスは、無料トライアルの乱用、紹介報酬の不正取得、プロモーション悪用、スパム用の捨てアカウントへの入口になります。

使い捨てメール検知APIが答えるのは、まさにサインアップの瞬間に必要になる、たった1つの問いです。このメールアドレスは、一時的な受信箱を発行する事業者のものなのか。

なぜ使い捨てアドレスは不正のシグナルになるのか

使い捨てアドレスだからといって、ただちに悪意があるとは限りません。サービスをまだ信用しきれない段階で、プライバシー意識の高いユーザーが一時的な受信箱を使うことはありますし、それ自体は正当な選択です。ただし、全体の傾向として見ると、パターンはかなりはっきりしています。

• 無料トライアルの悪用。 1人で30回のトライアル。各トライアルには新しいメールアドレスが必要で、使い捨てメール事業者はそれをいくらでも発行できます。
• 紹介・プロモーションの量産。 自作自演の紹介は、すべての「友人」が別々のメールアドレスを持っているときに成立します。捨て受信箱は、その最も安い供給源です。
• 荒らし・不正用の捨てアカウント。 スパム、スクレイピング、嫌がらせ用のアカウントは、守るより作り直すほうが簡単です。そのため、誰も長く使うつもりのないアドレスを土台に作られます。
• リスト品質の劣化。 使い捨てアドレスは数時間でハードバウンスします。メーリングリストに1件入るたび、得るものがないまま送信者レピュテーションを傷つけます。

共通しているのは、そのユーザーが長期的な関係を持つつもりではない、という点です。ブロックすべきか、追加確認を求めるべきか、あるいは単にフラグとして記録するだけでよいのかは、プロダクトによって変わります。ただし、まず知っていなければ判断できません。

検知APIは実際に何を見ているのか

仕組みはあえてシンプルです。シンプルだからこそ高速に動きます。

• ドメインを抽出する。 見るべきなのは @ より後ろだけです。よく設計されたサービスはドメイン単位で照合し、メールアドレス全体は保存しません。ローカル部は個人データであり、検知には不要です。
• 使い捨てドメインのデータベースと照合する。 一時メール事業者、捨てアドレスサービス、ローテーション型エイリアスネットワークが運用する数万件規模のドメインと突き合わせます。
• 判定を返す。 disposable: true または false に加え、一致したドメインとタイムスタンプを返します。1回の呼び出しで、判断に使える1つのフィールドが得られます。

一般的な連携は次のようになります。

bash curl "https://guarda.net/api/public/v2/email/newuser@mailinator.com?key=YOUR_API_KEY"

{ "status": "ok", "email": "newuser@mailinator.com", "domain": "mailinator.com", "disposable": true, "checked_at": "2026-08-23T12:00:00.000Z" }

チェックは単一のHTTP呼び出しなので、組み込む場所を選びません。サインアップフォームの処理、決済エンドポイント、ニュースレター登録、既存リストを監査するバッチ処理など、どこにでも差し込めます。

あまり語られない誤検知の問題

この分野で厄介なのは、多くの検知サービスが頼っている公開ブロックリストにノイズが多いことです。広く使われているオープンソースのフィードの中には、本物の捨てアドレスサービスだけでなく、正規のフリーメール事業者まで混ざっているものがあります。それをそのまま取り込むと、いつか必ず、実在する受信箱を持つ本物の顧客に対して「このアドレスは使い捨てです」と告げることになります。しかも、その人がまさにあなたのサービスを使おうとしている瞬間にです。

解決策は見た目の調整ではなく、設計そのものにあります。常に優先される許可リストです。大手フリーメール、地域プロバイダー、ISP、大学など、正規性が確認された事業者を許可リストに固定し、独立したトラフィックランキングとも照合します。あるフィードがそれらのドメインを誤って危険視しても、許可リストが上書きします。検知品質とは、いくつのドメインをブロックできるかよりも、許可したドメインをどれだけ自信を持って「本物」と言えるかにかかっています。

鮮度も同じくらい重要です。一時メール事業者は、静的なリストを回避するためにドメインを次々と入れ替えます。先月ダウンロードしたデータベースは、肝心なところでもう古くなっています。複数のフィードから毎日同期し、各ドメインの出どころを追跡できるプロバイダーを選ぶべきです。そうすれば、判定結果だけでなく、なぜその判定になったのかも監査できます。

コンバージョンを傷つけずに組み込むには

使い捨てメールチェックの最悪の使い方は、陽性判定をすべて機械的にブロックし、ユーザーに行き止まりを見せることです。よりよい設計は、摩擦の小さい順に次のようになります。

• 静かにフラグを立てる。 シグナルとしてアカウントに記録し、後続の判断材料にします。たとえば、未認証の使い捨てメールアカウントには紹介ボーナスを付与しない、といった使い方です。
• 追加確認を求める。 価値の提供、たとえばトライアルアクセス、プロモーションコード、APIキーの発行の前に、メール認証を必須にします。本物のユーザーなら数秒で完了しますが、量産目的の不正利用者はそこで離脱します。
• 理由を示してブロックする。 捨てアドレスが正当化されにくい場面、たとえば支払い、請求、B2Bトライアルなどに限って強制拒否を使います。その場合も必ず理由を伝え、サポートへの導線を用意します。

そして、シグナルは組み合わせて見るべきです。使い捨てメールアドレスに加えてデータセンターIPからアクセスしている場合と、住宅回線からアクセスしている場合では、意味合いがまったく違います。メールインテリジェンスとIPインテリジェンスは、同じ問いの別々の半分に答えるものです。だからこそ、別々のツールとして扱うのではなく、同じリクエストフローの中に置くべきです。

検知でできないこと

限界を正直に理解しておくことは、過信を避けるうえで大切です。ドメインベースのチェックでは、次のものは検出できません。

• 使い捨て基盤上のカスタムドメイン。 新しく作られ、まだどのリストにも載っていないドメインでバーナーサービスが動いている場合、発見されるまでは通過します。これは発見競争であって、完全に解決済みの問題ではありません。
• Gmail型のエイリアス。 name+anything@gmail.com やドットの有無によるバリエーションは、同じ受信箱です。これは検知の問題ではなく、自社データベース側の重複排除の問題です。
• 本気で手間をかける人間。 自分で本物のドメインを登録し、実際にメールを受け取る意思のある相手は通過します。目標は完璧を達成することではなく、不正のコストを得られる利益より高くすることです。

使い捨てメール検知は、あくまで1つのレイヤーです。IP脅威シグナルや適切なチャレンジフローと組み合わせることで、最も安価で大量に発生する偽サインアップ、つまり自動化された不正を取り除けます。そして多くの場合、それこそが問題の大部分を占めています。

guarda.netの無料使い捨てメールチェッカーを使えば、アカウント登録なしで今すぐ任意のアドレスを試せます。運用に組み込む準備ができたら、APIをサインアップフローに接続できます。