이 영상 소개

이 영상의 주소는 예시입니다. 파일 검증에는 유료 계정이 필요합니다.

영상 스크립트

1. 00:00「받았다」가 증거가 아닌 이유

   catch-all 도메인은 실제로 있든 없든 어떤 주소로 온 메일이든 받습니다. 그러면 「받았다」는 응답의 가치가 달라집니다. 한 도메인에 있는 주소 세 개를 생각해 보세요. 하나는 실제 사람의 것입니다. 하나는 퇴사한 사람의 것이었습니다. 하나는 만든 적이 없습니다. 메일 서버에 각각 물어보면 같은 응답이 돌아옵니다. 그것이 단순한 「받았다」의 문제입니다. 메일함이 실제로 있다는 뜻일 수 있습니다. 이 도메인이 절대 거절하지 않는다는 뜻일 수도 있습니다.

2. 00:28탐지 방법

   그래서 두 번째 테스트를 합니다. 같은 서버에 아무도 갖지 않을 가짜 주소에 대해 물어봅니다. 이메일은 보내지 않습니다. 서버가 거절하면 그 도메인은 catch-all이 아닙니다. 받아들이면 catch-all입니다. 테스트가 차단되거나, 서버가 나중에 다시 시도하라고 하거나, 응답이 불분명하면 어느 쪽이든 증거가 없습니다. 이제 두 답을 합쳐 봅니다. 테스트는 거절되고 내 주소는 수락되면 유효입니다. 테스트는 거절되고 내 주소도 거절되면 무효입니다. 테스트가 수락되고 내 주소도 수락되면 catch-all입니다. 테스트는 수락되었는데 내 주소가 수락되지 않으면 결과는 알 수 없음입니다. 사유를 보면 어떤 종류인지 알 수 있습니다. Catch-all deliverable이 주된 것입니다. Catch-all inferred는 근거가 캐시되었거나 간접적이었다는 뜻입니다. 일부 Microsoft 365 도메인은 내부에서 중계하며 모든 수신자를 받습니다. 일부 보안 게이트웨이도 마찬가지입니다. 그리고 전달 별칭에서는 최종 수신자를 알 수 없습니다. 이 모든 것에는 실시간 SMTP 검사가 필요합니다. 기본으로 실행됩니다. API에서는 check_smtp를 false로 하면 건너뛰며, 대부분의 주소가 알 수 없음으로 돌아옵니다. MCP 도구는 기본값이 false이므로, 이 테스트를 원하면 거기서 true로 설정하세요.

3. 01:41보내야 할까

   그러면 catch-all 결과는 실제로 무엇을 알려 줄까요? 그 도메인이 메시지를 받는다는 것입니다. 그 주소 뒤에 실제 메일함이 있는지는 확인할 수 없습니다. 그래서 판단이 필요하며, 메일의 종류가 결정합니다. 가치가 높은 메일이나 거래 메일은 대개 보내도 됩니다. 콜드 대량 발송이라면 직접 따져 보세요. 어느 쪽이든 이런 주소는 유효 목록에 넣지 마세요. 파일 작업에서는 결과를 상태로 필터링해 catch-all만 따로 내보내세요. 이제 눈에 보이는 결정이 됩니다. 그 파일에서 조심할 점이 하나 있습니다. catch-all 도메인의 역할 주소는 catch-all이 아니라 역할로 표시되고, catch-all 플래그는 그대로 켜져 있습니다. 전부 찾으려면 CSV를 ev_is_catchall로 필터링하세요. 재시도로 결론이 난다고 기대하지 마세요. 재시도 가능으로 표시되는 것은 알 수 없음 결과뿐입니다. catch-all 결과는 유효와 똑같이 크레딧 하나를 씁니다. 같은 계정에서 24시간 안에 그 주소를 다시 검증해도 두 번째 청구는 없습니다. API로 강제 새로고침을 하면 다시 청구됩니다. 그러니 catch-all에는 자기만의 자리를 주세요. 유효도 아니고 무효도 아닙니다. 도메인이 「받았다」고 한 것이고, 나머지는 여러분의 결정입니다.

4. 02:53무료로 시작하기

   계정을 사용하는 날은 매일 무료 크레딧 20개를 받고, 월 최대 600개까지 쓸 수 있습니다. 신용카드는 필요 없습니다. billionverify.com에서 시작하세요.

이 영상에 나온 도구

• Catch-All 이메일
• 주소가 valid 대신 catch-all으로 표시되는 이유는 무엇입니까?