공개 가입은 맞지 않는 사용자를 끌어들입니다
승인된 사용자만 원하지만 공개 등록은 악용과 부적합 계정을 통과시킵니다. 수동 검토는 시간이 걸리고 놓치기도 합니다.
1개 필드
허용/거부 결정용 (`block`)
2가지 규칙 유형
정확한 이메일과 전체 도메인
켜짐 또는 꺼짐
정책 변경 시 화이트리스트 모드
실시간
검증 응답의 정책 확인
화이트리스트는 비용이 큰 정책 실수를 줄입니다
승인된 사용자와 수신자만 플로우에 남기고 결정을 하나의 API 응답으로 모읍니다.
허용 목록 로직이 서비스마다 중복됩니다
가입, CRM, 캠페인은 같은 정책이 필요하지만 구현이 달라져 시간이 지나며 어긋납니다.
원하지 않은 대상에게 보내는 비용을 치릅니다
특정 고객만 이메일을 받아야 할 때 넓은 리스트는 예산을 낭비하고 지표를 희석합니다.
화이트리스트 흐름
화이트리스트 작동 방식
누가 허용되는지 한 번 정의한 뒤, 각 검증 결과의 한 필드로 정책을 결정합니다.
01→
화이트리스트 규칙 추가
[email protected] 같은 정확한 주소나 company.com 같은 도메인을 추가해 허용 대상을 정의합니다.
02→
필요할 때 화이트리스트 모드 켜기
목록에 있는 이메일과 도메인만 허용할 때 켭니다. 엄격한 허용 전용이 필요 없으면 끕니다.
03✓
검증 후 `block`으로 결정
API 응답의 `block` 필드를 사용합니다. `block: true`는 거부, `block: false`는 허용.
검증 API 응답 예시
GET /v1/[email protected]\nX-API-Key: your-api-key\n\n{\n "valid": true,\n "block": false,\n "domain": "customer.org"\n}화이트리스트에 넣을 수 있는 것
정확한 이메일
선택한 사용자만 통과할 때 하나의 주소만 허용.
도메인
partner.com 또는 customer.org 등 승인된 도메인의 모든 사서함 허용.
프로덕션에서 화이트리스트 API를 쓰는 팀
실제 팀이 온보딩을 보호하고 캠페인 타겟을 좁히며 정책 로직을 앱 코드 밖에 둡니다.
DR
Daniel Reed
Founder, B2B SaaS
“엔터프라이즈 트라이얼에 화이트리스트를 켜자 무작위 가입이 바로 멈췄습니다. 영업은 실제로 타깃하는 계정만 상대합니다.”
SM
Sofia Martinez
Lifecycle Marketing Lead
“파트너 전용 캠페인에서는 승인 도메인을 화이트리스트해 잘못된 대상에게 보내지 않습니다. 낭비 발송이 줄고 지표가 좋아졌습니다.”
ML
Marcus Lee
Product Manager, Marketplace
“예전에는 여러 서비스에 허용 로직이 있었습니다. 이제 각 플로우가 같은 `block`을 일관되게 읽습니다.”
화이트리스트 API 자주 묻는 질문
허용/거부에 어떤 필드를 쓰나요?
검증 응답의 `block` 필드입니다. `block`이 true면 거부, false면 허용.
정확한 이메일과 전체 도메인을 모두 화이트리스트할 수 있나요?
네. 정확한 주소나 `company.com` 같은 도메인을 추가해 해당 도메인의 모든 사서함을 허용합니다.
정책을 켜고 끌 수 있나요?
네. 화이트리스트 모드를 켜거나 꺼서 플로우에 필요할 때만 엄격한 허용 전용을 적용합니다.
커스텀 허용 목록 로직이 필요 없어지나요?
네. 규칙을 한 번 관리하고 여러 백엔드에 매칭을 복제하는 대신 API 응답에서 `block`을 읽습니다.
화이트리스트와 블랙리스트에 모두 있으면?
블랙리스트가 우선입니다. 블랙리스트가 맞으면 화이트리스트에 있어도 `block`은 true로 유지됩니다.