メインコンテンツへスキップ
メールアドレス認証レポートは、メールOTPチャレンジの結果をすべて記録します。記録されるのは、メッセージの送信先、アドレスが使い捨てか配信不能か、既知のデータ侵害に含まれているか、ユーザーの試行回数、そしてブロックリストまたは他の承認済みユーザーとのセッション間の一致です。 このページでは、判定エンドポイントが返すJSONの構造を説明します。検証済みの各アドレスについて、OTPの結果、データ侵害の有無、リスクフラグを解析する際に参照してください。
OTPの結果、データ侵害情報、リスクフラグを表示したDiditのメールアドレス認証レポート

概要

メールレポートは、ワークフローのノードがメールアドレス認証機能を実行するたびに生成されます。各レポートは1つのアドレスに対する1回のOTPチャレンジを表し、次の内容を含みます。
  • 検証されたemailアドレス。
  • ブール値のリスクフラグ(is_breached、is_disposable、is_undeliverable)と、データ侵害インテリジェンスデータベースから取得した裏付けとなるbreaches[]配列。
  • OTP送信の試行回数(verification_attempts)と承認日時。
  • すべての送信、再試行、コード確認の試行を時系列で記録したlifecycle[]ログ。
  • 同じアドレスが他の承認済みメールアドレス認証やブロックリストに存在することを示すmatches[]配列。
  • 検証中に発生したリスクイベントを示すwarnings[]配列(メールアドレス認証の警告を参照)。
  • レポートを生成したワークフローグラフのノードを識別するnode_id(V3セッションのみ)。
ホスト型ワークフローセッションでは、OTPチャレンジはDiditの検証UI内で実行されるため、判定ペイロードから結果を読み取るだけで済みます。ホスト型フローを使わずにサーバー間でOTPを行う場合は、スタンドアロンのEmail APIを使用します。POST /v3/email/send/がコードを配信し、POST /v3/email/check/がユーザーの入力を検証します。確定したスタンドアロン検証も同じレポート構造で返されます。 ホスト型セッションでは、デフォルトでユーザーは誤ったコード入力は2回まで(email_max_check_attempts)、OTP送信は2回まで(初回送信と再送信1回)(email_max_retries)に制限されます。これらはワークフローノードごとに調整できます。いずれかの上限を超えると、ステップはEMAIL_CODE_ATTEMPTS_EXCEEDEDとともにDeclinedとして確定します。

APIレスポンスでの表示箇所

判定エンドポイント(GET /v3/session/{sessionId}/decision/)は、メールレポートを複数形の配列キーemail_verificationsで返します。この配列には、ワークフローグラフ内のメールアドレス認証ノードごとに1件のエントリが含まれます。通常は1件ですが、ステップアップフローでは複数になる場合があります。
nullの値は、メールアドレス認証ステップがまだ実行されていないことを意味します。ワークフローで複数のメールアドレスを収集する可能性がある場合は、email_verifications[0]を読み取るのではなく、配列を反復処理してください。

スキーマ

フィールドごとの正式なスキーマはデータモデルページにあります。
配信不能なアドレス(構文が無効、ドメインが存在しない、MXレコードがない、またはOTPの配信に失敗した場合)は、自動却下の警告UNDELIVERABLE_EMAIL_DETECTEDとともにステップをDeclinedとして確定させます。唯一の例外は、ユーザーが自分でアドレスを入力した場合(セッション作成時に事前入力されていなかった場合)です。この場合、送信が配信不能になるとインラインエラーが返されるため、ユーザーはすぐに却下されることなく、別のアドレスで再試行できます。

ステータス値

ライフサイクルイベントの種類

lifecycle[]は時系列順に並びます。各イベントにはtype、timestamp、details、および課金対象のfee(該当する場合)が含まれます。 detailsペイロードの内容はイベントの系統によって異なります。
  • 送信イベント(EMAIL_VERIFICATION_MESSAGE_SENT、EMAIL_VERIFICATION_RETRY_MESSAGE_SENT): { status, reason }。statusはSuccess、Retry、Undeliverableのいずれかです。reasonは送信に失敗した場合を除きnullです(失敗時はemail_can_not_be_delivered、認識できない旧形式の値の場合はunknown)。
  • チェックイベント(VALID_CODE_ENTERED、INVALID_CODE_ENTERED): { code_tried, status }。statusはApproved、Failed、Expired or Not Found、Declinedのいずれかです。
  • 最終ステータスイベント: nullです。ただしEMAIL_VERIFICATION_DECLINEDとEMAIL_VERIFICATION_IN_REVIEWは{ "reason": "<risk code>" }を持ちます(例: UNDELIVERABLE_EMAIL_DETECTED)。
statusがSuccessまたはUndeliverableの送信には、$0.02のメールアドレス認証の料金が記録されます。Retryの送信、チェックイベント、ステータスイベントは常にfee: 0です。

セッション間の一致

matches[]は、同じアプリケーション内の過去に承認されたメールアドレス認証(KYC、KYB、スタンドアロンAPIの各セッションを含む)で同じアドレスが使われた記録に加え、Management APIのリストで設定したブロックリストへの該当を記録します。現在のセッションと同じvendor_dataを持つ認証は除外され(同じエンドユーザーが自分自身と一致することはありません)、配列は最大5件で、古い順に並びます。アドレスがブロックリストに登録されているものの、一致したセッションのいずれもブロックリストに登録されていない場合は、source: "list_entry"を持つ合成エントリ(セッションのフィールドはすべてnull)が配列の先頭に追加されます。

例

承認済み: 情報レベルの違反を1件含む正常なOTP

却下: 配信不能なアドレス

事前入力されたアドレスが構文またはDNS(MX)の検証に失敗した場合、あるいはOTPメールを配信できなかった場合は、ただちにDeclinedとして確定します。コードがユーザーに届いていないため、コードチェックのイベントは表示されません。

却下: ブロックリストに登録された使い捨てメールアドレス

ユーザーはOTPによる認証を完了しましたが、アドレスがメールのブロックリストに一致しました(自動却下)。使い捨てメールのフラグも立っていますが、ここではdisposable_email_actionがデフォルトのNO_ACTIONのままのため、informationレベルになっています。

関連情報

最終更新日 2026年11月1日