이메일 검증 API

호출 시점에 수신자 경로가 검사 요청을 수락했습니다. 제품에서 적용하는 동의 규칙에 따라 가입을 승인하고 연락처를 저장하거나 메시지를 대기열에 넣으세요.

무료 이메일 검증 API 는 무료 티어와 유료 대량 사용에서 같은 상태 필드를 반환하므로, 무료 크레딧으로 테스트한 동작을 그대로 제품에 적용할 수 있습니다.

API 의 영구 실패는 해당 주소가 하드 바운스된다는 뜻입니다. 가입 양식에서는 API reason code 와 함께 필드를 다시 표시하세요. 백그라운드 작업에서는 원래 값을 삭제하지 말고 해당 레코드를 제외 처리하세요.

도메인을 자동 수정하지 마세요. 검증 API 는 주소가 실패했다는 사실은 알려 주지만, 사용자가 어떤 주소를 의도했는지는 알 수 없습니다.

Risky 는 메일박스가 메일을 수락할 수 있지만 제품에서 중요하게 볼 플래그가 있다는 뜻입니다. reason code 를 확인하세요. 유료 가입의 일회용 제공자와 지원 양식의 역할 주소는 전혀 다른 문제입니다.

무료 이메일 검증 API 를 호출하는 지점에서 정책을 한 번만 구현해 제품의 모든 화면이 같은 API 플래그를 동일하게 처리하도록 하세요.

수신 제공자가 API 에 아무것도 입증하지 못하는 응답을 보냈습니다. 사용자를 차단하거나 데이터베이스에 잘못된 음성 판정을 기록하지 말고, 이후 API 호출을 위해 주소를 대기열에 넣으세요.

가입 흐름 안의 실시간 이메일 검증 API 는 이 상황을 무리 없이 처리해야 합니다. 사용자를 통과시키고 비동기로 다시 검증한 뒤 두 번째 API 결과에 따라 조치하세요.

메일박스가 수락했다는 사실만으로는 누가 이를 관리하는지, 어디에서 일하는지, 연락에 동의했는지 알 수 없습니다. 공유 별칭, 전달 주소, 오래된 보강 데이터는 모두 잘못된 사람에게 연결된 deliverable API 결과를 만들 수 있습니다.

신원에는 자사 데이터를 사용하고 동의 정보는 자체 기록 시스템에 보관하세요. 어떤 검증 API 도 둘 중 어느 것도 제공할 수 없습니다.

SMTP 수락은 API 호출 시점의 수신자 경로를 설명합니다. 캠페인이 받은편지함에 도착하는지는 발신자 평판, 인증, 콘텐츠, 신고 이력에 달려 있습니다 — 모두 API 가 관찰하지 않는 발신자 측 요소입니다.

검증은 주소 수준의 실패를 제거합니다. 메시지 자체의 전달 가능성은 별도 지표로 관리해야 하는 별개의 프로그램입니다.

catch-all 도메인은 모든 local part 를 수락하므로 어떤 무료 이메일 검증 API 도 그곳에 추측한 주소 하나가 실제로 존재한다고 입증할 수 없습니다. 코드에서 이를 추론하지 않아도 되도록 API 가 정확히 해당 플래그를 반환합니다.

catch-all 결과를 deliverable 에 포함하지 말고 검토 대상으로 보내세요. 이름 패턴으로 만든 B2B 목록에서는 특히 중요합니다.

메일박스는 폐쇄되고 별칭은 사용 중단되며 도메인은 매일 이전됩니다. API 는 호출 중 사실이었던 내용을 보고하며, 그 사실은 API 가 응답하는 순간부터 오래되기 시작합니다.

하위 시스템이 증거가 너무 오래되어 사용할 수 없는 시점을 판단하도록 상태 옆에 검사 시각을 저장하세요.