메일을 보내지 않고 이메일 주소를 검증하는 방법

메일을 보내지 않고 검증하는 이유

이메일 주소를 테스트하는 가장 뻔한 방법은 메일을 보내서 반송되는지 보는 거예요. 효과는 있지만 최악의 방법이에요. 반송은 메시지가 이미 메일 제공업체에 도달한 뒤에 일어나므로, 실패가 이미 발신자 평판에 반영된 상태예요. 이런 식으로 리스트를 테스트하면, 어떤 주소가 나쁜지 알아내는 대가로 평판을 깎아 먹는 셈이에요. 실제 수신자가 실제 메시지를 받으니 조용히 테스트할 수도 없어요.

메일을 보내지 않는 검증은 이 순서를 뒤집어요. 캠페인을 보내기 전에 주소가 메일을 받을 수 있는지 확인해요. 받은편지함에 아무것도 도착하지 않고, 아무것도 반송되지 않으며, 평판도 그대로예요. 메일 시스템은 서버끼리 서로 질문할 수 있는 프로토콜로 만들어져 있어서, 검증 도구가 실제 전달까지 가지 않고도 그런 질문을 할 수 있기 때문에 가능해요.

간단한 형식 확인부터 수신 서버와의 완전한 대화까지 여러 방법이 있어요. 각 방법은 질문의 일부에만 답하므로, 각각이 무엇을 알려주고 무엇을 알려주지 않는지 이해하는 것이 잘 활용하는 핵심이에요.

방법 1: 구문 검증

가장 빠른 확인은 순수하게 구조만 보는 거예요. 이메일 주소 형식은 RFC 5322라는 사양이 정하고 있어요. 이 사양은 올바른 주소가 어떤 모습인지 정확히 정의해요. 로컬 파트, @ 기호, 도메인으로 이루어지고, 어떤 문자를 어디에 쓸 수 있는지 규칙이 있어요.

구문 검증은 주소가 이 규칙에 맞는지 테스트해요. @ 기호가 없거나, 공백이나 허용되지 않는 문자가 있거나, 도메인이 없거나 잘못됐거나, 로컬 파트가 사양에 어긋나는 주소를 잡아내요. 네트워크 연결이 전혀 필요 없어서 즉시, 무료로 실행되고, 데이터 입력 중 생긴 단순 오타를 중심으로 잘못된 주소의 상당 부분을 걸러내요.

한계는 근본적이에요. 구문 검증은 주소의 형식이 올바르다는 것만 증명해요. 주소가 존재한다는 것은 증명할 수 없어요. valid.but.fake@gmail.com이라는 주소는 구문상 완벽하게 올바르지만 실제 메일함이 아닐 가능성이 거의 확실해요. 구문 검증은 판정이 아니라 첫 번째 필터로만 다루세요.

방법 2: 도메인과 MX 레코드 조회

다음 단계는 주소에서 도메인으로 넘어가요. 이메일을 받을 수 있는 모든 도메인은 Mail Exchanger의 약자인 MX 레코드라는 DNS 레코드를 공개해요. 이 레코드는 도메인을 대신해 메일을 받는 서버를 지정해요.

MX 조회는 DNS에서 도메인의 MX 레코드를 찾아요. 도메인에 유효한 MX 레코드가 있다면 이메일을 받도록 설정되어 있고 연결 지점이 존재해요. MX 레코드가 없다면 메일을 전혀 받을 수 없고, 철자와 상관없이 그 도메인의 모든 주소는 유효하지 않아요. 이 단계는 죽은 도메인을 잡아내는 데 탁월한데, 회사가 문을 닫거나 브랜드를 바꾸면서 오래된 리스트에 계속 등장해요.

한계는 도메인 확인이 엉뚱한 수준에서 작동한다는 점이에요. gmail.com에 MX 레코드가 있다는 것은 Google이 메일을 받을 수 있다는 뜻일 뿐이에요. 특정 Gmail 메일함 하나가 존재하는지는 전혀 알려주지 않아요. 도메인과 MX 검증은 범위를 좁혀 주지만 개별 주소까지 판별하지는 못해요.

방법 3: SMTP 확인, 또는 핑

이 방법은 메일을 보내지 않고 특정 메일함을 실제로 확인해요. 흔히 이메일 주소에 핑을 보낸다고 부르지만, 오해하기 쉬운 이름이에요. 네트워크 진단에 쓰는 ICMP ping 명령과는 아무 관련이 없어요. 이메일 검증에서 핑은 수신 서버와 SMTP 대화를 나누는 것을 뜻해요.

SMTP(Simple Mail Transfer Protocol)는 메일 서버끼리 메시지를 주고받을 때 쓰는 언어예요. 일반적인 전달은 정해진 순서의 명령을 따라요. SMTP 확인은 이 순서를 그대로 밟되 한 단계 앞에서 멈춰요.

작동 방식은 이래요. 검증 도구가 MX 조회로 찾은 수신자의 메일 서버에 연결해요. EHLO 또는 HELO로 인사를 주고받으며 자신을 소개해요. MAIL FROM 명령으로 발신자를 밝혀요. 그다음 RCPT TO로 검증할 정확한 주소를 지정해요. 수신 서버는 상태 코드로 응답해요. 250 코드는 서버가 그 주소로 오는 메일을 받겠다는 뜻이에요. 550 코드는 주소를 거부한다는 뜻으로, 보통 메일함이 존재하지 않기 때문이에요. 검증 도구는 그 코드를 읽고 QUIT으로 연결을 닫아요. DATA 명령은 절대 보내지 않아요. DATA는 실제 메시지 본문이 전송되는 단계인데, 대화가 DATA 전에 끝나므로 이메일은 전혀 전달되지 않아요. 메일함은 확인됐고, 수신자는 아무것도 받지 않았어요.

이것이 메일을 보내지 않는 검증의 핵심이에요. 그리고 진짜 복잡한 문제가 시작되는 지점이기도 해요.

SMTP 확인이 어려움을 겪는 경우

SMTP 확인은 확실해 보이지만, 흔한 서버 동작 몇 가지 때문에 원시 수동 확인은 믿기 어려워요.

캐치올 도메인

일부 도메인은 캐치올로 설정되어 있어서, 메일함 존재 여부와 상관없이 해당 도메인의 모든 주소로 오는 메일을 받아요. 캐치올 서버는 실제 주소, 철자가 틀린 주소, 완전히 임의의 주소 모두에 250 코드를 돌려줘요. 그래서 캐치올 도메인에 SMTP 확인을 하면 답이 항상 예이기 때문에 메일함 수준에서 확실한 것을 알 수 없어요. 캐치올을 감지하려면 임의의 주소로 도메인을 확인해 그것도 수락되는지 봐야 해요. 이는 품질 점수가 아니라 감지이며, 해당 주소를 개별적으로 확인할 수 없다는 사실을 알려줘요.

그레이리스팅

일부 서버는 낯선 발신자를 처음 만나면 일부러 일시적 실패 코드를 돌려주고, 정상적인 메일 서버라면 곧 재시도할 것으로 기대해요. 이 일시적 코드를 영구 실패로 읽는 단순한 확인은 멀쩡한 주소를 유효하지 않다고 잘못 표시해요. 올바르게 처리하려면 일시적 코드를 알아보고 최종 답으로 취급하지 않아야 해요.

프로브 차단

이것이 수동 확인을 실제로 무력화하는 요인이에요. Google과 Microsoft 같은 주요 제공업체는 한 IP 주소에서 반복되는 SMTP 프로브를 감시하고, 이를 스패머가 유효한 주소를 캐낼 때 쓰는 정찰 행위로 간주해요. 그 대응은 프로브를 보내는 IP를 바로 차단하는 거예요. 그래서 자체 서버나 Telnet 세션에서 수동 SMTP 확인으로 리스트를 검증하려 하면, 몇 개의 답을 얻은 뒤 IP가 차단되고 나머지 확인은 엉뚱한 이유로 실패해요. 수동 SMTP 검증은 확장할 수 없고, 대량에서는 아예 작동하지 않아요.

방법 4: 전문 검증 서비스

위의 방법들은 각각 퍼즐의 한 조각만 검증하고, 단독으로는 저마다 분명한 약점이 있어요. 전문 검증 서비스는 이 모든 방법을 함께 실행하고, 예외 상황을 올바르게 처리하며, 수동 확인으로는 불가능한 규모로 운영하기 위해 존재해요.

VeriMails는 모든 주소에 모든 확인을 겹겹이 적용해요. RFC 5322 기준 구문 검증, MX 및 DNS 조회, 앞서 설명한 실시간 SMTP 핸드셰이크를 메시지를 전혀 보내지 않고 실행해요. 그 위에 캐치올 감지를 더해 전체 수신(Accept-all) 도메인을 잘못 유효로 보고하지 않고 정확히 식별하고, 일회용 도메인 감지로 임시 주소를 표시하며, 역할 기반 감지로 info@나 support@ 같은 주소에 라벨을 붙여요. 그레이리스팅과 기타 일시적 응답을 알아보고, 억지로 유효하지 않음으로 처리하지 않고 올바르게 분류해요. 또한 검증을 위해 설계된 인프라에서 실행되므로, 수동 확인을 무력화하는 프로브 차단 문제에 막히지 않아요.

그 결과 이메일을 한 통도 보내지 않는 실용적인 검증이 가능해요. 가입 폼 제출처럼 주소 하나를 실시간으로 검증할 때는 REST API 를 사용하고, 캠페인 전에 리스트 전체를 정리할 때는 대량 CSV 검증 을 사용하세요. 요금은 이메일당 $0.0019부터 시작하며, 10,000 크레딧은 $19, 패키지는 최대 500만 크레딧 $1,499까지 있고, 연간 결제 시 $12.50/월부터 시작하는 플랜도 있어요. 모든 계정은 가입 시 신용카드 없이 만료되지 않는 무료 크레딧 100개를 받으므로, 실제 이메일을 보내지 않고 실제 리스트를 검증해 차이를 직접 확인해 볼 수 있어요.

자주 묻는 질문