개요
경고에는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 발송(최초 발송 1회 + 재전송 1회,email_max_retries)입니다.EMAIL_IN_BLOCKLIST— 주소가 Lists API를 통해 관리되는 차단 목록에 포함되어 있거나, 이전에 승인된 이메일 인증 중 차단 목록에 등록된 항목과 일치합니다.UNDELIVERABLE_EMAIL_DETECTED— 잘못된 구문, 존재하지 않는 도메인, 누락된 DNS(MX) 레코드 등으로 주소에서 메일을 수신할 수 없거나, OTP 이메일이 전달되지 않았습니다. 이 단계는 코드 확인을 실행하지 않고 즉시Declined로 종료됩니다. 예외: 사용자가 주소를 직접 입력한 경우(세션 생성 시 사전 입력되지 않음), 발송이 불가능하면 거부되는 대신 다른 주소로 재시도할 수 있도록 인라인 오류가 반환됩니다.
구성 가능한 위험
다음 각 위험은DECLINE, REVIEW 또는 NO_ACTION으로 구성할 수 있는 설정(워크플로 노드별 또는 독립형 검사 endpoint 호출별)에 매핑됩니다:
중복 감지는 동일한 애플리케이션 내에서 이전에 승인된 이메일 인증만 고려하며,
vendor_data를 기준으로 그룹화됩니다. 동일한 vendor_data를 공유하는 인증은 동일한 최종 사용자로 간주되어 제외됩니다. vendor_data를 비워 두면 모든 세션이 별개의 사용자로 처리됩니다. 해당 주소가 이메일 허용 목록에 있는 경우 중복 작업은 건너뛰고 대신 EMAIL_IN_ALLOWLIST가 생성됩니다.
인증 시도 한도
이메일 인증 기능은 오남용을 방지하기 위해 OTP 시도 횟수에 엄격한 한도를 적용합니다:- 코드 입력 시도 —
email_max_check_attempts, 기본값 2: 잘못된(또는 만료된) 코드가 두 번째 입력되면 단계가 종료됩니다. - 발송 시도 —
email_max_retries, 기본값 총 2회 발송(최초 발송 + 재전송 1회): 추가 재전송 요청이 발생하면 단계가 종료됩니다.
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 — 목록 —
EMAIL_IN_BLOCKLIST에서 사용하는 이메일 차단 목록을 관리합니다.