リアルタイムのメール検証では、ユーザーがまだフォーム上にいる間にアドレスをチェックします。「送信」と次の画面が表示されるまでの数百ミリ秒で実行され、1 つの疑問に答えます。このアドレスをデータベースに登録すべきか？ リアルタイムのメール検証 API が、その判断を代わりに行います。構文、ドメインとその MX レコード、使い捨てアドレスやロールアドレスのシグナル、catch-all の動作、そして要求した場合はメールボックス自体を確認します。その後、コードで処理できる構造化された結果を返します。
このガイドは、サインアップ、チェックアウト、またはリードフォームにそのゲートを追加する開発者向けです。各チェックの内容、API の呼び出し方、各ステータスをプロダクト上の判断に変換する方法、メールサーバーの応答が遅い場合でも高速性を保つ方法を解説します。例では BillionVerify メール検証 API を使用していますが、設計上のアドバイスはどのプロバイダーにも適用できます。
リアルタイム メール検証とは？
リアルタイム メール検証とは、アドレスが入力された瞬間に実行されるチェックであり、キャンペーン開始後の数日後に行うものではありません。ユーザーがアドレスを入力すると、フロントエンドまたはバックエンドがメールチェッカー API に送信します。API は valid、invalid、catchall などのステータスと、その判定の根拠となるシグナルを返します。その後、アプリケーションは登録を許可するか、入力をブロックするか、ユーザーにタイプミスの修正を求めます。
重要なのはタイミングです。ユーザーがまだフォームを操作している間なら、gmial.com のようなタイプミスは無料で修正できます。しかし、ウェルカムメールがバウンスした後では、同じタイプミスによって顧客を失うことになります。不正なアドレスは送信者レピュテーションにも悪影響を与えます。ハードバウンスが発生するたびに、メールボックスプロバイダーへ未確認のアドレスに送信していることを伝えてしまうためです。リアルタイム メール検証により、不正なアドレスを入口で阻止できます。
また、不正行為への対策にも役立ちます。リアルタイム チェックによって、アカウントが作成される前に使い捨ての受信トレイを検出できます。
リアルタイム検証と一括メール検証
どちらの方法も同じチェックを使用します。違いは、実行するタイミングと、かけられる時間です。
- リアルタイム検証は、ユーザーのリクエスト内で、一度に 1 件のアドレスを処理します。フォームの動作が遅いと登録者を失うため、通常は 1 秒未満という厳しい時間制限があります。不正なデータが入り込むのを防ぎます。
- 一括検証は、バックグラウンドでリスト全体を処理します。数分から数時間かかることがあり、画面の前で待つ人はいません。大規模なキャンペーンの前や CRM インポート後など、すでにシステム内にあるデータをクリーンアップします。
ほとんどのチームには、両方が必要です。リアルタイムチェックで新しいデータをクリーンに保ち、定期的な一括検証で、時間の経過とともに無効になったアドレス（退職した従業員のアドレスなど）を検出できます。詳しい比較については、リアルタイム検証と一括メール検証をご覧ください。
リアルタイムチェックで実際に検証される内容
メール検証 API は、低コストなものから高コストなものまで、一連のチェックを実行します。それぞれのチェックで、異なる種類の不正なアドレスを除外します。
構文
最初のチェックは形式です。@ はちょうど 1 つありますか？ローカル部は許可された文字で構成されていますか？ドメインはドメインらしい形式になっていますか？構文チェックでは、john@@example や jane.example.com のような明らかに無効な文字列を除外します。高速で、ネットワーク接続も必要ありません。ただし、構文が完全に正しくても、メールボックスが存在するかどうかはわかりません。
ドメインと MX レコード
次に、API は DNS でドメインを検索します。MX レコードがないドメインはメールを受信できないため、どれだけきれいに見えるアドレスでも役に立ちません。これにより、スペルミスのあるドメインや、消滅した企業ドメインを検出できます。BillionVerify は検出した MX ホストを mx_records に返します。また、ドメインが一般的なドメインのタイプミスに見える場合、domain_suggestion に推測される修正候補が含まれることがあります。
使い捨て・ロール・無料プロバイダーのシグナル
存在するアドレスでも、製品に適していない場合があります。
- 使い捨て アドレスは一時的な受信トレイサービスから提供され、通常は数時間以内に使えなくなります。使い捨てメールの検出方法をご覧ください。
- ロール アドレス（
info@やsupport@など）は個人ではなくチーム宛てです。通常はメール到達可能ですが、エンゲージメントは低くなりがちです。 - Gmail などの 無料プロバイダー のアドレスは消費者にとって一般的ですが、B2B フォームでは記録しておく価値があります。
API はこれらをフラグ（is_disposable、is_role、is_free）として返すため、製品ごとに判断できます。
キャッチオールドメイン
一部のメールサーバーは、実在するかどうかにかかわらず、そのドメインの任意のアドレス宛てのメールを受け入れます。このようなキャッチオールドメインでは、メールボックスチェックによって特定の受信トレイが存在することを証明できません。キャッチオールの結果は悪い結果ではありません。確実性が低いことを意味するため、ラベルよりもスコアが重要になります。キャッチオールメールの検出では、その仕組みと重要性を説明しています。
SMTP メールボックスチェック
最も詳細なチェックでは、受信者のメールサーバーに SMTP 経由で、メッセージを送信せずにメールボックスが受け入れるかどうかを確認します。元従業員の受信トレイのように、実在するドメイン上にあるものの、すでに存在しないアドレスを検出できます。また、他社のサーバーに依存するため、最も時間がかかるステップでもあります。BillionVerify では、check_smtp パラメーターで制御します。省略すると、API は SMTP チェックを実行します。スキップするには check_smtp: false を送信してください。
ドメインのレピュテーション
BillionVerify は、ドメインのメールサーバーの IP に関するブラックリスト結果を含む domain_reputation オブジェクトも返せます。これは情報提供のみを目的としたもので、ステータス、スコア、コストは変更しません。
リアルタイム メール検証 API の呼び出し方法
BillionVerify では、1 件のリアルタイム チェックが 1 回の HTTPS リクエストで完了します。ベース URL は https://api.billionverify.com/v1 で、API キーは BV-API-KEY ヘッダーに指定します。このキーはサーバー上で管理してください。ブラウザ コードに含めないでください。
最小限のリクエスト例を示します。API リファレンス に基づいています。
curl -X POST https://api.billionverify.com/v1/verify/single \
-H "BV-API-KEY: sk_xxx" \
-H "Content-Type: application/json" \
-d '{"email":"test@example.com","check_smtp":true}'
このリクエストには 3 つのパラメーターがあります。
| パラメーター | デフォルト | 内容 |
|---|---|---|
email | required | 検証するアドレス |
check_smtp | on | ライブ SMTP メールボックス チェックをスキップするには false を設定 |
force_refresh | false | キャッシュ済みの結果を使わず、新しい結果を新規チェックと同様に課金 |
成功したレスポンスでは、結果が標準エンベロープに含まれます。以下は、到達可能なアドレスの短縮例です。
{
"success": true,
"code": "0",
"message": "Success",
"data": {
"email": "user@example.com",
"status": "valid",
"score": 0.95,
"is_deliverable": true,
"is_disposable": false,
"is_catchall": false,
"is_role": false,
"is_free": false,
"domain": "example.com",
"mx_records": ["mail.example.com"],
"check_smtp": true,
"reason": "smtp_deliverable",
"domain_suggestion": "",
"response_time": 250,
"credits_used": 1
}
}
SDK を使う場合、BillionVerify は Node.js、Python、TypeScript、Go、PHP、Java 向けの公式 SDK を提供しています。Node.js では、npm install billionverify-sdk により verify メソッドを備えたクライアントを利用できます。Python では、パッケージ名は billionverify です。
レスポンスの読み方：ステータス、スコア、理由
status フィールドは、ほとんどのコード分岐で使用されます。各ステータスの意味と、サインアップフォームでの適切なデフォルト動作は次のとおりです。
| ステータス | 意味 | サインアップフォームのデフォルト |
|---|---|---|
valid | メールボックスが存在し、メールを受信できる | 受け付ける |
invalid | アドレスが存在しない、またはメールを受信できない | ブロックし、別のアドレスを求める |
disposable | 一時的な受信トレイ | ブロックするか、制限付きで受け付ける |
catchall | ドメインがすべてのアドレスを受け付ける | 受け付けて監視する |
role | info@ などの共有受信トレイ | 受け付け、営業向けにフラグを付けることを検討 |
unknown | メール到達率を確認できなかった | 受け付け、後で再確認する |
score は、0 から 1 の間でより細かなシグナルを示します。大まかな目安として、valid の結果は 0.85 から 1.0、catchall は約 0.55 から 0.75、unknown は 0.3 から 0.6、disposable は 0.1、invalid は 0 です。role の結果は、基になったチェックのスコアを保持します。このスコアを使って、境界線上のケースに対する独自のしきい値を設定できます。たとえば、価値の高いフォームでは、一定以上のスコアを持つ catch-all アドレスだけを受け付けることが可能です。
reason フィールドは、判定の理由を説明します。invalid の結果には、invalid_syntax、no_mx_records、mailbox_not_found のいずれかが付く場合があり、それぞれユーザーに表示するメッセージが異なります。構文エラーは「形式を確認してください」を意味します。メールボックスが見つからない場合は「この受信トレイは存在しません」を意味します。検証理由 ページにはすべての理由が一覧され、再試行する価値のある unknown の理由も記載されています。
2 つのフィールドがユーザーを直接サポートします。domain_suggestion は「gmail.com のことですか？」というヒントに利用でき、is_disposable は使い捨てアドレスが拒否された理由を説明します。
レイテンシー予算を中心にしたサインアップフローの設計
難しいのは、フォームの速度を落とさずにチェックを組み込むことです。まず予算を決めます。たとえば送信時にユーザーを待たせる時間を 300 ～ 500 ミリ秒に設定します。それ以外は、この数字を基準に決まります。
BillionVerify の製品説明では、キャッシュ結果は 200 ミリ秒未満、完全な SMTP チェックは平均 1 ～ 3 秒とされています。この差を踏まえると、適した設計は 2 つあります。
- タイムアウト付きの完全チェック。 SMTP を有効にし、タイムアウトを 2 ～ 3 秒に設定して API を呼び出します。ほとんどの結果は時間内に返り、
validまたはinvalidを明確に判定できます。タイムアウトした場合は、いったん通過させて後で再チェックします。 - 今すぐ高速チェックし、後で詳細チェック。
check_smtp: falseを指定して API を呼び出します。これで判定できるのは、明らかなケースだけです。つまり、不正な構文、MX レコードがないドメイン、使い捨てアドレス、ロールアドレスです。稼働中のドメインにあるアドレスは、理由smtp_unverifiableとともにunknownとして返されますが、これは想定どおりです。そのまま受け付け、バックグラウンドジョブから SMTP を有効にして 2 回目の呼び出しを実行します。メールボックスが存在しない場合は、アカウントにフラグを付け、ユーザーにアドレスの確認を求めます。
フロントエンドでは、次の習慣も役立ちます。
- すべてのキー入力ではなく、フォーカスが外れたときまたは送信時に検証する。
j、jo、johをチェックすると、呼び出しとクレジットを無駄にします。 - まずローカルで構文チェックを実行する。 明らかな入力ミスに対する通信を省けます。
- バックエンドから API を呼び出す。 API キーはサーバーで管理し、結果を記録します。ブラウザには結果だけを表示します。
文言、エラーの配置、ヒントを表示するタイミングなどの UX の詳細については、サインアップ時のメール検証をご覧ください。
フェイルクローズとフェイルオープン？タイムアウトと不確実な結果への対応
ほとんどの製品で機能するパターンは、明確なエラーではフェイルクローズし、不確実な場合はフェイルオープンすることです。
- フェイルクローズとは、登録をブロックすることです。API がアドレスを明らかに不正と示した場合に行います。たとえば、
invalidでinvalid_syntaxまたはno_mx_recordsが返された場合や、使い捨てアカウントが問題を引き起こすフォームでdisposableアドレスが使われた場合です。 - フェイルオープンとは、ユーザーを先に通し、後でフォローアップすることです。
unknownステータス、キャッチオール ドメイン、または API が回答する前に独自のタイムアウトが発生した場合など、結果が不確かなときに行います。
不確かなアドレスもブロックしてはいけないのでしょうか。実際のユーザーが、その多くのアドレスの背後にいるからです。企業のメール サーバーは SMTP チェックをグレーリスト化したり、レート制限したりすることが多く、それらをブロックすると実際の登録を失うことになります。受け入れたうえでレコードにタグを付け、後で再チェックしてください。
API 呼び出しには、レイテンシー予算に合わせたクライアント側タイムアウトを設定します。タイムアウトが発生したら、結果を unknown として扱います。受け入れ、フラグを保存し、バックグラウンドでの再チェックをキューに追加してください。unknown の結果はリクエスト内ではなく、後で再試行します。
例：Node.js のサインアップ時にメールアドレスを検証する
以下のスケッチは、サインアップハンドラーで高速チェック（設計 2）を実行する方法を示しています。文書化された REST エンドポイントとレスポンスフィールド、タイムアウト、上記のフェイルオープンまたはフェイルクローズのルールを使用しています。名前は使用するフレームワークに合わせて変更してください。
const BLOCK = new Set(['invalid', 'disposable']);
async function checkEmail(email) {
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), 400);
try {
const response = await fetch('https://api.billionverify.com/v1/verify/single', {
method: 'POST',
headers: {
'BV-API-KEY': process.env.BV_API_KEY,
'Content-Type': 'application/json',
},
body: JSON.stringify({ email, check_smtp: false }),
signal: controller.signal,
});
const body = await response.json();
if (!body.success) return { allow: true, recheck: true };
const { status, reason, domain_suggestion } = body.data;
if (BLOCK.has(status)) {
return { allow: false, reason, suggestion: domain_suggestion };
}
return { allow: true, recheck: status === 'unknown' || status === 'catchall' };
} catch {
// Timeout or network error: fail open and re-check in the background.
return { allow: true, recheck: true };
} finally {
clearTimeout(timer);
}
}
SMTP を使わない場合、実在するアドレスの多くは unknown として返され、recheck フラグが付与されます。アカウントの保存後、バックグラウンドジョブが recheck とマークされたすべてのレコードに対して、SMTP を有効にした同じエンドポイントを呼び出します。Node.js チュートリアルでは、公式 SDK を含む、より完全なセットアップ手順を説明しています。同じリクエストは、Python や HTTP クライアントを備えた任意の言語から実行できます。
レート制限、キャッシュ、コスト
リアルタイムチェックはサインアップ経路上で実行されるため、その制限がそのまま自社の制限になります。事前に計画してください。
レート制限。 BillionVerify は、アカウントごとの制限によってキャパシティを保護しています。制限に達すると、API はコード 1003 と Retry-After ヘッダーを含む HTTP 429 を返します。待機して再試行し、制限によって実際のユーザーがブロックされないよう、自社のフェイルオープンルールも設定しておいてください。
キャッシュ。 結果はキャッシュされるため、繰り返しのチェックは高速に完了します。過去 24 時間以内にアカウントで検証したアドレスを再チェックする場合、料金はかかりません。本当に最新の結果が必要な場合にのみ force_refresh: true を使用してください。キャッシュをスキップし、新規チェックと同じように課金されるためです。
コスト。 1 回のチェックでは通常 1 クレジットが消費され、credits_used に表示されます。unknown の結果はすべて無料で、構文エラーも無料です。入力のたびに検証するのではなく送信時に検証し、最近検証したアドレスを再チェックしないでください。BillionVerify では、ログインするたびに毎日 20 クレジットが無料で付与され、月 600 クレジットまで利用できます。これは、統合の構築とテストに十分な量です。有料クレジットパックは 料金ページ に掲載されています。
フォームを超えて: バッチ、ファイル、Webhook
リアルタイム検証では、新しいアドレスを 1 件ずつ検証します。それ以外の場合も、同じ API には別のエントリーポイントがあります。
- 小規模バッチ。
POST /verify/bulkは 1 回のリクエストで最大 50 件のアドレスをチェックできるため、CRM 同期やインポート画面に適しています。 - 大規模リスト。
POST /verify/fileは CSV、TXT、XLSX ファイルを受け付け、バックグラウンドで処理します。 - Webhook。 ファイルジョブをポーリングする代わりに、
file.completedとfile.failedイベント用の Webhook を登録します。署名チェックと再試行については、メール検証 Webhook のガイドをご覧ください。 - 使い捨てアドレスのみのチェック。
POST /verify/disposableは使い捨てアドレスかどうかだけを判定し、クレジットを消費しません。
一般的な構成は、すべてのフォームでリアルタイムチェックを行い、recheck とマークされたレコードに対して毎晩バッチを実行し、大規模なキャンペーンの前にファイルジョブを実行する方法です。
リアルタイム メール検証チェックリスト
公開する前に、次のリストを確認してください。
- API キーはサーバー上に保持し、ブラウザには決して置かない。
- API 呼び出しの前に、構文をローカルで確認する。
- リクエスト パスでは
check_smtp: falseを使用し、レイテンシー予算に合ったタイムアウトを設定する。 invalidとdisposableには、明確で具体的なエラー メッセージを設定する。unknown、catchall、タイムアウトはフェイルオープンにし、再チェック用にキューへ追加する。domain_suggestionで入力ミスのヒントを表示する。- 429 レスポンスではバックオフを行い、ユーザーをブロックしない。
- 後でバウンス率を測定できるよう、結果をユーザー レコードとともに保存する。
FAQ
リアルタイムのメール検証 API とは何ですか？
リアルタイムのメール検証 API は、ユーザーがフォームを送信するときに単一のメールアドレスを確認し、数分の 1 秒で判定結果を返します。構文、ドメイン、MX、使い捨て、ロール、キャッチオールのチェックを実行し、オプションで SMTP メールボックスチェックも行えるため、アドレスがデータベースに到達する前に、アプリで受け入れ、ブロック、またはフラグ付けできます。
リアルタイムのメール検証は一括検証とどう違いますか？
リアルタイムのメール検証は、ユーザーリクエスト内で一度に 1 件のアドレスをチェックし、すぐに回答する必要があります。一括検証はリスト全体をバックグラウンドでチェックするため、はるかに時間がかかる場合があります。新しいデータをクリーンに保つにはリアルタイムチェックを、すでに保有しているデータを整理するには一括チェックを使用してください。
すべてのサインアップで SMTP チェックを実行すべきですか？
レイテンシーの予算によります。メールボックスを確認するのが SMTP チェックなので、これを実行しない場合、ほとんどの実在するアドレスは unknown として返されます。2–3 秒待てる場合は、タイムアウトを設定して送信時に実行してください。待てない場合は、check_smtp: false で高速チェックを実行し、バックグラウンドジョブで SMTP チェックを行います。
キャッチオールと unknown の結果はどう扱うべきですか？
受け入れて、後で再チェックしてください。キャッチオールドメインはすべてのアドレスを受け入れるため、メールボックスチェックでは受信トレイの存在を証明できません。また、unknown の結果はチェックを完了できなかったことを意味します。これらのユーザーをブロックすると実在するサインアップを失うため、タグ付けして再チェックすれば、コンバージョンを損なわずにデータをクリーンに保てます。
ブラウザからメールチェッカー API を呼び出せますか？
いいえ。API キーが公開されてしまいます。API はバックエンドから呼び出し、判定結果だけを返してください。
リアルタイムのメール検証はどのくらい速いですか？
BillionVerify では、キャッシュ済みの結果は 200 ms 未満で返り、完全な SMTP チェックには平均で 1–3 秒かかります。そのため、SMTP なしの高速チェックはリクエスト経路に配置し、SMTP チェックはバックグラウンドで実行します。
メール検証 API の料金はいくらですか？
BillionVerify では、通常、1 回のチェックで 1 クレジットを使用し、unknown の結果はすべて無料です。ログインするたびに毎日 20 クレジット（1 か月あたり最大 600 クレジット）を無料で取得でき、有料クレジットパックは料金ページに掲載されています。force_refresh はキャッシュをスキップし、新しいチェックとして課金されます。
リアルタイムでメールを検証する
リアルタイムのメール検証により、バウンス、偽アカウント、タイプミスによって失われるユーザーを減らせます。リクエスト処理に高速チェックを組み込み、時間のかかるチェックをバックグラウンドに移し、明らかな失敗はブロックしつつ、不確実な結果は通過させましょう。無料の BillionVerify アカウントを作成し、API キーを取得して、上記のドキュメントから最初のメール検証 API 呼び出しを実行してください。