概述
警告标记有功能标识EMAIL。它们显示在报告中的 email_verifications[].warnings[] 下,并遵循标准警告对象结构(feature、risk、additional_data、log_type、short_description、long_description、node_id)。每条警告还会路由到每个会话的日志中,从而在 Business Console 的邮箱部分显示。
某些警告属于硬性自动拒绝触发器,它们始终将功能状态设置为 Declined,并带有 log_type: "error"。其他警告则映射到按工作流节点或按 API 调用定义的可配置操作(DECLINE、REVIEW 或默认的 NO_ACTION),因此相同的风险代码可能会拒绝一个工作流,而仅对另一个工作流进行标记。配置的操作还会设置严重级别:DECLINE → error,REVIEW → warning,NO_ACTION → information。
自动拒绝条件
无论如何配置,以下警告始终会拒绝邮箱验证步骤:EMAIL_CODE_ATTEMPTS_EXCEEDED— 用户耗尽了 OTP 配额:默认情况下为 2 次错误验证码输入(email_max_check_attempts)或 2 次 OTP 发送,即初始发送加上一次重新发送(email_max_retries)。EMAIL_IN_BLOCKLIST— 该地址位于通过 Lists API 管理的黑名单中,或匹配了之前被列入黑名单且已通过的邮箱验证。UNDELIVERABLE_EMAIL_DETECTED— 该地址无法接收邮件:语法无效、域名不存在、缺少 DNS (MX) 记录,或者 OTP 邮件无法送达。该步骤会立即以Declined结束,绝不会运行验证码核验。例外情况:当用户自行输入地址(在创建会话时未预填)时,无法送达的发送会返回内联错误,以便用户可以使用其他地址重试,而不会被拒绝。
可配置风险
以下每种风险都映射到一个设置(按工作流节点配置,或在独立的核验 endpoint 上按每次调用配置),您可以将其配置为DECLINE、REVIEW 或 NO_ACTION:
重复检测仅考虑同一应用中先前已通过的邮箱验证,按
vendor_data 分组:共享相同 vendor_data 的验证将被视为同一个终端用户并被排除。若将 vendor_data 留空,则每个会话都会被视为不同用户。如果该地址位于您的邮箱白名单中,则跳过重复操作并改为发出 EMAIL_IN_ALLOWLIST。
验证尝试限制
邮箱验证功能对 OTP 尝试次数设置了硬性上限,以防止滥用:- 验证码输入尝试次数 —
email_max_check_attempts,默认 2 次:第二次输入错误(或过期)的验证码将结束该步骤。 - 发送尝试次数 —
email_max_retries,默认总共 2 次发送(初始发送加上一次重新发送):后续的重新发送请求将结束该步骤。
EMAIL_CODE_ATTEMPTS_EXCEEDED 并自动拒绝。您可以按工作流节点调整这两个上限。
生成的警告
每次尝试中,
EMAIL_IN_BLOCKLIST、DUPLICATED_EMAIL 和 EMAIL_IN_ALLOWLIST 最多触发其中一个:黑名单优先级高于重复,重复优先级高于白名单。
跨会话匹配
当某个地址在先前已通过的邮箱验证中或您的黑名单中被检测到时,这些命中项也会显示在email_verifications[].matches[] 下(最多 5 条记录)。每个匹配项都包含 session_id、session_number、vendor_data、verification_date、email、status、is_blocklisted、api_service,以及值为 session(另一项已通过的验证)或 list_entry(黑名单条目)的 source。如果当前地址位于您的邮箱白名单中,Didit 将保留匹配证据,但发出 EMAIL_IN_ALLOWLIST 而非执行重复邮箱操作。有关完整的匹配结构,请参阅邮箱验证报告。
示例
警告类型
根据您的应用配置,系统会为每个风险分配一个严重程度。严重程度分为三类:相关内容
- 邮箱验证概述 — 功能行为与定价。
- 邮箱验证报告 — 包含
lifecycle[]和matches[]的完整响应结构。 - 数据模型 — 邮箱验证 — 规范的逐字段结构。
- Management API — Lists — 管理供
EMAIL_IN_BLOCKLIST使用的邮箱黑名单。