この動画について

この動画のレスポンスは、実際の API のレスポンスです。API キーには有料アカウントが必要です。

動画の文字起こし

1. 00:00サーバーでチェックする

   サインアップフォームが送信されたら、サーバー側でアドレスをチェックし、メールを受け取れないものは断ります。サインアップフォームが送信されると、サーバーはアドレスを /verify/single に送り、status を読み取って判断します。ブラウザが API と直接やり取りすることはありません。シンプルなルールがあります。invalid は拒否します。そのメールボックスは存在しないからです。disposable は拒否します。使い捨ての受信箱だからです。role、catch-all、unknown は通します。これらは実在の人のものかもしれません。なぜサーバーなのでしょうか。ブラウザのコードに入れたキーは、すべての訪問者に配信され、誰でもそれであなたのクレジットを使えてしまいます。キーは有料アカウントで発行されるので、自分のキーは非公開にしてください。

2. 00:41Next.js

   Next.js では、チェックをルートハンドラーに置きます。サーバーの環境変数からキーを読み取り、メールを送信し、status が invalid または disposable のときはメッセージ付きで 422 を返します。落とし穴に注目してください。呼び出しが失敗したりタイムアウトしたりすると、status は空になり、このコードはサインアップを通します。これは、この例での選択です。ブロックしたい場合は、そこでエラーを返してください。

3. 01:04React

   React はブラウザで動くので、キーを持つことはありません。フォームは自分のルートに送信し、422 が返ってきたらメッセージを表示します。Django では、フォームの clean_email から Python SDK を呼び出します。invalid または disposable のときはバリデーションエラーを出すと、Django がフィールドの横に表示します。

4. 01:21Laravel

   Laravel では、バリデーションルールを書きます。HTTP クライアントが、設定ファイルのキーを使ってアドレスを送信し、ルールは同じ 2 つの status で失敗します。接続エラーはそのまま戻るので、フォームはそのまま通ります。

5. 01:34Go

   Go では、標準ライブラリで足ります。このハンドラーは、API を呼び出し、結果をログに記録し、invalid または disposable なら 422 で応答します。実際に動かしてみましょう。4 件のサインアップが入ります。support と Leo のアドレスには、ウェルカムが届きます。でっち上げの Gmail アドレスと Mailinator のアドレスには、422 のメッセージが返ります。サーバーログには理由が出ています。role、catch-all、invalid、disposable です。そして、どの行も credits_used は 0 です。この 4 つのアドレスは、今日の早い時間に、このアカウントですでにチェックしていました。同じアドレスが 24 時間以内にもう一度来ても、二重に課金されることはありません。パスワード欄の打ち間違いを直して再送信したユーザーに、追加の費用はかかりません。

6. 02:15次のステップ

   5 つとも、同じ 1 つのエンドポイントを使います。フィールドとステータスは billionverify.com/docs に記載されています。アカウントを使う日は毎日 20 クレジットが無料で、月最大 600 クレジットまで利用できます。クレジットカードは不要です。billionverify.com から始めましょう。

この動画で紹介したツール

• ユーザー登録時のメールアドレス検証：UX ベストプラクティスと実装ガイド
• 2026年にユーザー登録メールを検証することが重要な理由