開発者向け：メールアドレス検証APIの比較

メールアドレス検証APIの選定は、マーケティングの判断に見えて、実際には開発者が下すべき判断です。どのベンダーもREST APIと、精度の高さを並べたランディングページを持っています。連携の成否を実際に左右するのは、本番環境でのAPIの挙動です。判定結果をどう返すか、時間のかかる処理をどう扱うか、失敗時にどう振る舞うか。このガイドでは、重要な評価基準を整理し、各サービスを事実に基づいて比較します。

結論#

主要なメールアドレス検証サービスはどれもREST APIを提供しているため、「APIがあること」は差別化要因になりません。開発者にとっての違いは、もっと絞られた点にあります。レスポンスが機械的に扱える根拠なのか、不透明なスコアだけなのか。避けられない非同期のSMTPチェックをどう扱うか。一括処理の結果がポーリングで届くのか、署名付きWebhookで届くのか。リトライとレート制限の仕組み。そしてデータがどこで処理されるか。トップページの精度の数字ではなく、これらを基準に選んでください。競合各社の情報は2026年7月時点で確認したものです。実装前に、各ベンダーのAPIリファレンスで最新の内容を確認してください。

検証APIで本当に重要なこと#

評価に値する基準を、それぞれ見るべきポイントとともに挙げます。具体的な参考例として、QualisendのAPIでの対応も示します。

1. 根拠付きで、機械的に扱える判定結果#

レスポンスこそが製品です。コードで分岐できる小さく安定した判定結果と、その裏付けとなる根拠が必要です。信用するしかない0～100の数値だけでは足りません。4種類のステータス（deliverable | risky | undeliverable | unknown）に理由コードとサブフラグが付いていれば、実用的なロジックを書けます。「confidence: 87」のような単一の値では、しきい値を自分で決めることになります。

{
  "result": {
    "status": "deliverable",
    "score": 95,
    "reason": "accepted_email",
    "sub_flags": { "role": false, "disposable": false, "free_mail": false, "catch_all": false },
    "did_you_mean": null,
    "smtp": "cached"
  }
}

2. 同期か非同期か、その正直な扱い#

メールボックスの存在確認には、自分では制御できないサーバーへのSMTPのやり取りが必要です。そのため、SMTPの部分を確実に即時で返すことはできません。誠実なAPIはそれを明示します。QualisendのPOST /verifyは、ローカルチェック（構文、DNS、使い捨て、役割アドレス、入力ミス）の結果をすぐに返します。result.smtpがpendingの場合はSMTPプローブがキューに入っているので、GET /jobs/{job_id}をポーリングして確定結果を取得します（cachedまたはskippedは、判定がすでに確定していることを意味します）。すべてのアドレスについて「有効／無効」を同期的かつ即時に返すと謳うAPIには注意してください。その速さは、実際のプローブでは時間内に解決できないアドレスを推測で処理することから生まれている場合がほとんどです。

3. 一括処理と結果の受け取り方#

リストの検証では、非同期で処理され、完了を通知してもらえる仕組みが必要です。方法はポーリングとWebhookの2つで、優れたAPIは両方を備えています。QualisendのPOST /verify/bulkは最大1,000,000件のアドレスを受け付け、callback_urlを指定すると署名付きの完了Webhookを受け取れます。信頼する前にX-Qualisend-Signature（sha256=に本文のHMAC-SHA256を続けたもの）を検証してください。またはGET /jobs/{id}?include=resultsをポーリングします。

4. 再試行の安全性とレート制限#

ネットワークはリクエストの途中で失敗することがあります。二重課金や二重処理なしに再試行できなければなりません。Idempotency-Keyヘッダーと、わかりやすいレート制限ヘッダーがあるかを確認してください。Qualisendは、冪等なPOST（同じキーと同じ本文）をクレジットの再消費なしでリプレイします。すべてのレスポンスにX-RateLimit-Remainingが付き、429にはRetry-Afterが含まれます。

5. EUデータレジデンシー#

EUの個人データを扱う場合、検証がどこで行われるかは好みではなく、コンプライアンス上の事実です。ここはベンダー間で実際に差が出る部分です（下の表を参照）。

6. 料金モデルと実用的な無料枠#

利用状況に合った課金方式を選びます。安定した量なら1,000件単位のクレジットパック、急な増加なら従量課金です。また、実際のパイプラインを動かせる無料枠も必須です。契約前に精度を検証できるからです。SMTPプローブを省略する無料枠では、実際に料金を支払うことになる製品について何もわかりません。

7. 対応言語#

自社のスタックで使えるコピー＆ペースト用のサンプルがあると、連携が早く進みます。Qualisendのリファレンスには、cURL、Python、JavaScript、PHP、Go、Java、Rubyのサンプルがあります。

各検証サービスの比較#

ここで挙げたサービスはいずれもREST APIを備えています。そのため表では、実際に差が出る基準、つまりデータレジデンシー、料金モデル、無料枠でのテスト、数値スコアの有無を比較しています。Webhookの署名、冪等性、非同期モデルといった詳細なAPI仕様はサービスごとに異なり、一様には公開されていません。実装前に各ベンダーのリファレンスを確認してください。サービス別の比較ページでは、さらに詳しく解説しています。特定のツールからの乗り換えについては、次の代替サービスガイドをご覧ください。ZeroBounce、NeverBounce、Bouncer、Kickbox、Emailable、DeBounce、Clearout、Hunter。

開発者の視点での読み取りは次のとおりです。EUレジデンシーについては、Qualisend、Bouncer、Clearout、HunterがEUで処理しており、NeverBounce、Kickbox、Emailableは米国です。NeverBounceとDeBounceは数値スコアなしのカテゴリコードを返します。ステータスで分岐するなら問題ありませんが、ランク付けしたい場合は不便です。また、料金モデルはクレジットパックと純粋な従量課金に分かれます。自社の利用量の傾向がわかっているなら、表面的な単価よりもこの違いが重要になります。

QualisendのAPIを具体的に見る#

単一のチェックは、認証付きのPOSTを1回送るだけです。

curl https://app.qualisend.com/api/v1/verify \
  -H "Authorization: Bearer $QUALISEND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"jane@example.com"}'

検証とポーリングの一連の流れは、Node.jsとPythonのガイドで解説しています。アドレス取得時の検証は、サーバーレスのサインアップガイドをご覧ください。

このサイトの誠実な姿勢に沿って、トレードオフも挙げておきます。単一の/verifyは、SMTPの結果については非同期です。そのため、確定したメールボックスの判定をその場で必要とする場合は、1回の呼び出しではなくジョブをポーリングすることになります。また、プローブをグレーリスティングし続けるサーバーがあると、アドレスがunknownのままになることがあります。ただし、unknownの判定と重複した行は返金されます（1クレジット＝検証済み1アドレス）。すべてのアドレスについて、即時かつ同期的な「有効／無効」を求めても、誠実なAPIにはそれを提供できません。ただし、できるふりをするサービスはあります。

APIを試してみませんか。無料プランには、完全なパイプラインを動かせる100クレジットが含まれています。リファレンスでは、すべてのエンドポイントを7言語のコピー＆ペースト用サンプルとともに解説しています。