📧 이메일 일괄 검증

한 줄에 한 개씩 대량 이메일을 일괄 검증. RFC 5322, 일회용 도메인, 역할 계정, 중복, 대소문자 차이 검출. CSV 내보내기.

완전 무료 가입 불필요 브라우저 완결 5 개 언어 다크 모드

🔒 개인정보 보호 (중요)

・모든 검증은 브라우저 JavaScript 로 완결
・입력한 이메일은 서버로 전송되지 않습니다
・브라우저에서 MX 조회 불가, DNS 확인은 대상 외

이메일 (한 줄 한 개)

📖 자주 걸리는 지점

메일 주소를 1 행 1 건으로 붙여 넣으면 RFC 5322 의 형식 · 일회용 도메인 · 역할 계정 · 중복 · 대소문자 차이를 한꺼번에 판정합니다. 처리는 브라우저 안에서 끝나고 유효한 것만을 CSV 로 내보낼 수 있습니다. 여기서 판정할 수 있는 것은 형식이 타당한가까지이고 도달하는가는 알 수 없습니다 — 형식적으로 완벽한 주소의 상당수가 퇴직 · 도메인 실효 · 오타로 도달 불가능합니다. 브라우저에서는 MX 레코드도 조회할 수 없습니다.

사례	무슨 일이 일어나는가	어떻게 하면 되는가
정규식으로 올바른 주소를 판정하려 한다	RFC 5322 에 완전히 준거한 정규식은 수천 자가 됩니다 — 따옴표가 붙은 로컬부, 주석, IP 주소 리터럴까지 포함하기 때문입니다. 그리고 그만큼 써도 배송할 수 있는가는 전혀 알 수 없습니다 — `a@b` 는 형식적으로 유효하지만 실재하지 않습니다. 반대 방향의 실패 쪽이 실해가 크며 너무 엄격한 검증은 정당한 주소를 튕깁니다 — `user+tag@example.com` 의 플러스 기호(Gmail 의 에일리어스 기능), `.photography` 같은 긴 gTLD, 국제화 도메인, 로컬부의 점. 튕겨진 사람은 이유를 모르므로 그대로 이탈합니다.	폼의 검증은 @ 가 하나 있고 그 뒤에 점이 있다 정도로 그치세요. 이것으로 튕길 수 있는 것은 명백한 오타뿐이지만 그것으로 충분합니다 — 실재 확인은 확인 메일을 보내는 것으로밖에 할 수 없고 그것을 한다면 형식 검증을 엄격하게 할 의미가 없습니다. 판단의 근거는 비대칭성에 있습니다 — 잘못 튕긴 정당한 주소는 이쪽에서 영원히 보이지 않는 손실인 반면 잘못 통과시킨 무효한 주소는 확인 메일이 도달하지 않음으로써 확실히 검출됩니다. HTML 의 `type="email"` 은 브라우저가 타당한 범위에서 검증해 주므로 먼저 이것을 쓰세요 — 직접 만든 정규식보다 느슨하고 그리고 올바른 구현입니다.
일회용 도메인 목록을 지나치게 믿는다	일회용 메일의 도메인은 매일 늘어납니다 — 독자 도메인을 취득해 몇 시간만 쓰는 서비스도 있으므로 어떤 목록도 늘 낡았고 목록에 없다 = 일회용이 아니다는 성립하지 않습니다. 반대 방향의 문제도 있어 일회용 주소를 정당한 이유로 쓰는 사람이 있습니다 — 일시적인 자료 청구, 프라이버시를 지키고 싶은 등록, 그리고 Apple 의 나의 이메일 가리기 기능이나 Firefox Relay 처럼 OS 나 브라우저가 공식으로 제공하는 전송 주소입니다. 이들은 실재하고 확실히 도달하며 게다가 목록에 따라서는 일회용 취급됩니다.	일회용 판정은 경고에 그치고 거부로 하지 마세요. 이 구별이 실무상 가장 중요합니다 — 거부하면 정당한 잠재 고객과 프라이버시에 민감한 사용자를 잃습니다. 판정을 써야 할 장면은 마케팅 발송의 목록에서 제외하기(바운스율을 낮출 목적) 나 무료 체험의 중복 등록을 검지하기 같은 이후의 취급을 바꾸는 용도이지 입구를 닫는 것이 아닙니다. 정말로 실재하는 계정만을 모으고 싶다면 확인 메일의 클릭을 필수로 하는(더블 옵트인) 것이 유일하게 확실한 방법입니다 — 일회용 주소라도 클릭은 할 수 있지만 그 사람은 적어도 지금 이 순간 받을 의사가 있다는 것을 확인할 수 있습니다.
대소문자와 표기 흔들림으로 중복을 놓친다	사양상 @ 앞의 로컬부는 대문자와 소문자를 구별합니다 — 즉 `Taro@example.com` 과 `taro@example.com` 은 엄밀하게는 다른 주소입니다. 그런데 실제로는 거의 모든 메일 서버가 구별하지 않고 같은 수신함에 도착합니다. 도메인부는 사양상으로도 구별하지 않습니다. 이 사양과 실태의 어긋남이 그대로 중복의 누락이 됩니다 — 대소문자만 다른 두 행을 다른 사람으로 등록하면 같은 사람에게 같은 메일이 두 통 도착합니다. 나아가 Gmail 은 로컬부의 점을 무시하고 `+` 이후도 무시하므로 겉모습이 다른 복수의 주소가 같은 수신함을 가리킵니다.	저장과 중복 판정 전에 반드시 소문자화하세요 — 사양상은 대소문자를 구별하지만 구별하는 구현이 사실상 존재하지 않으므로 소문자화해 다루는 것이 현실적인 정답입니다. 표시할 때만 원래 입력을 남기면 사용자의 경험도 해치지 않습니다. Gmail 의 정규화(점과 `+` 의 제거)까지 할지는 목적으로 정하세요 — 부정 이용의 검지에는 유효하지만 지나치면 다른 사람을 동일시할 위험이 있습니다(모든 제공자가 점을 무시하는 것은 아닙니다). 데이터베이스에는 `UNIQUE` 제약을 소문자화한 열에 거는 것이 확실합니다 — 애플리케이션 쪽의 체크만으로는 동시 요청에서 중복이 들어갑니다.

발송 전 클리닝에서 정말로 잘 듣는 것은 형식 체크가 아니라 바운스의 관리입니다. 형식이 완벽해도 퇴직 · 도메인의 실효 · 메일함 가득 참 · 입력 시의 오타로 도달하지 않는 주소는 방치한 목록이라면 연 20~30% 발생합니다. 그리고 바운스율이 5% 를 넘으면 송신 도메인의 평판이 떨어져 정당한 메일까지 스팸 폴더에 들어가게 됩니다 — 즉 무효한 주소에 계속 보내는 것의 대가는 그 주소뿐 아니라 목록 전체에 미칩니다. 따라서 필요한 것은 더블 옵트인으로 입구를 좁히고 하드 바운스는 즉시 목록에서 제거하며 열람도 클릭도 없는 구독자를 정기적으로 정리하는 것입니다. 이 도구는 명백히 무효한 것을 사전에 떨어뜨리기 위한 것이지 목록의 품질을 보증하는 것이 아닙니다 — 품질은 운용으로밖에 만들 수 없습니다. 덧붙여 MX 레코드의 확인은 브라우저에서는 할 수 없습니다(DNS 를 직접 조회할 수 없기 때문) — 필요하면 서버 쪽에서 하세요.

📖 사용법

1

리스트 붙여넣기

한 줄에 한 개씩 붙여넣기.
2

검증 버튼 클릭

RFC 5322, 일회용, 역할, 중복, 대소문자 검사.
3

CSV 내보내기

유효 항목만 CSV 로 다운로드.

❓ 자주 묻는 질문

일회용 이메일 검출 방법?

주요 30+ 도메인 내장 리스트로 매칭. 상용 API 보다는 제한적.

MX 확인 가능합니까?

브라우저에서 DNS 조회 불가. 서버측 도구 필요.

역할 계정이란?

팀 공유 주소. 일괄 마케팅 시 스팸 판정 위험.

🔗 관련 도구

🐛 이 도구에서 문제가 발생했나요?

무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.