メール検証 API

呼び出し時に受信サーバーが宛先を受理しました。製品が定める同意ルールに従って、サインアップを受け入れ、連絡先を保存するか、メッセージをキューに入れてください。

無料メール検証 API は、無料枠でも有料利用でも同じステータスフィールドを返します。そのため、無料クレジットで確認した挙動をそのまま本番で利用できます。

API から恒久的エラーが返った場合、そのアドレスはハードバウンスします。サインアップフォームでは、API の理由コードとともに入力欄を再表示してください。バックグラウンドジョブでは、元の値を削除せず、そのレコードを送信対象から除外します。

ドメインを自動訂正しないでください。検証 API はアドレスが失敗したことは伝えられますが、本人が意図したアドレスは伝えられません。

risky は、メールボックスがメールを受け取れる可能性はあるものの、製品側で考慮すべきフラグが付いていることを意味します。理由コードを確認してください。有料サインアップでの使い捨てメールと、サポートフォームでの役割アドレスでは、問題の性質がまったく異なります。

当社の無料メール検証 API を呼び出す箇所にポリシーを一度だけ実装し、製品内のすべての画面で同じ API フラグを同じように扱えるようにします。

受信プロバイダーから、有効性を判断できない応答が API に返されました。ユーザーをブロックしたり、偽陰性をデータベースに記録したりせず、後で API を再呼び出しするためにアドレスをキューに入れてください。

サインアップフロー内のリアルタイムメール検証 API は、ここでユーザー体験を損なわないよう処理すべきです。ユーザーを先に進め、非同期で再検証し、2 回目の API 結果に基づいて対応します。

メールボックスが受信を受け入れても、その管理者、勤務先、連絡への同意までは分かりません。共有エイリアス、転送アドレス、古い補完データはいずれも、別人に紐づいた deliverable の API 結果を生む可能性があります。

身元にはファーストパーティデータを使い、同意は自社の記録システムに置いてください。どちらかを供給できる検証 API はありません。

SMTP での受理は、API 呼び出し時点における受信者パスの状態を示します。キャンペーンが受信箱に届くかどうかは、送信者の評判、認証、コンテンツ、苦情履歴に左右されます — いずれも API では観測できない送信側の要因です。

検証で除外できるのは、アドレス単位のエラーです。メッセージ自体の到達性は別の取り組みであり、使う指標も異なります。

catch-all ドメインはすべてのローカルパートを受け入れるため、推測したアドレスがそこに存在することを証明できる無料メール検証 API はありません。API がそのフラグを返すのは、コード側で推論しなくてよいようにするためです。

catch-all 結果は deliverable に折り込まずレビューへ回してください。とくに氏名パターンから組み立てた B2B リストではそうです。

メールボックスは日々閉鎖され、エイリアスは廃止され、ドメインは移行されます。API が報告するのは呼び出し時点の事実であり、その情報は API が応答した瞬間から古くなり始めます。

checked-at 時刻をステータスの横に保存し、下流システムが証拠が古すぎて行動できない時点を判断できるようにします。