테스트용 가짜 이메일 주소: 가입 양식에 안심하고 쓰는 주소

게시일: 2026-05-26 · 수정일: 2026-10-23

웹사이트를 만들거나 테스트하다 보면 양식에 이메일 주소를 끊임없이 넣게 됩니다. 절대로 일어나면 안 되는 일은 하나뿐입니다. 테스트 메일이 모르는 사람의 진짜 받은편지함에 들어가는 것. 이 페이지는 테스트 종류마다 어떤 가짜 이메일 주소를 써야 하는지 — 그리고 언제 메일이 정말 도착해야 하는지 — 알려 드립니다.

먼저 메일이 도착해야 하는지 정하세요

이 질문 하나가 모든 것을 정합니다. 분명하게 물어볼 만합니다. 답이 “아니요”인 경우가 생각보다 많기 때문입니다.

메일이 도착하면 안 될 때: 예약된 이름

바로 이 목적으로 존재하며 절대로 누구의 것도 되지 않는다고 보장된 도메인이 있습니다. example.com과 그 형제인 example.net, example.org(RFC 2606으로 예약), 그리고 .test 끝자리 전체입니다.

이 도메인의 주소는 예시 데이터, 초기 데이터, 부하 테스트에 맞는 답입니다. 보낸 어떤 것도 사람에게 닿을 수 없습니다. 거기엔 아무도 없으니까요 — 운이 아니라 국제적인 약속에 따라서입니다.

메일이 도착해야 할 때, 수동으로

여기서 주소를 받아 절차를 실행하고, 애플리케이션이 실제로 무엇을 보냈는지 읽어 보세요 — 헤더, 링크, 그리고 내 메일 프로그램이 아닌 곳에서 보일 때의 모습. 로컬 메일 수집기로는 못 잡는 두 가지가 보입니다.

• 진짜 배달. 메시지가 진짜 메일 경로를 지나므로, 잘못 설정된 발신자는 운영 환경이 아니라 여기서 실패합니다.
• 낯선 사람에게 보이는 모습. 내 세션에서만 되는 링크, 끝내 안 뜨는 이미지, localhost를 가리키는 수신 거부 링크 — 바로 보입니다.

애플리케이션이 파일을 보낸다면 첨부 파일 경고도 보세요. 사용자들이 보게 될 바로 그 경고입니다.

자동화해야 할 때

대신 페이지를 긁어 오는 것은 된다 해도 손해입니다. 깨지기 쉽고, 문서도 없고, 결국 차단되는 바로 그런 트래픽이기 때문입니다.

거부되는 경우 테스트하기

흥미로운 실패는 “유효한 주소가 된다”가 아닙니다. 다뤄 볼 만한 것들:

• MX 레코드가 없는 도메인의 주소 — 주소는 제대로 쓰였는데 배달이 실패합니다. 코드는 이 둘을 구별해야 합니다. 어느 쪽인지 확인하기.
• 국제화 도메인을 Unicode 형태와 xn-- 형태 둘 다. 대부분의 검증기는 하나를 거부하고 다른 하나를 받아들이는데, 대개 거꾸로입니다 — 변환기.
• 점과 더하기를 쓴 Gmail 변형. 중복 검사가 문자열을 그대로 비교한다면, 한 사람이 계정을 끝없이 만들 수 있습니다. 먼저 정규화하세요 — 그 페이지가 여러분의 검사가 해야 할 일을 그대로 합니다.
• 아주 긴 @ 앞부분. 표준은 64자까지 허용하지만, 많은 양식이 조용히 20자에서 자르고 어디로도 이어지지 않는 것을 저장합니다.

테스트할 것이 아니라 만들어야 할 것

여러분의 제품이 가짜 이메일 주소를 받지 않는다면, 분명하게 거부하세요. 완전히 유효한 주소에 “잘못된 이메일”이라고 띄우는 것은 이 분야에서 가장 헷갈리게 하는 오류입니다. 사용자는 철자를 확인하고, 다시 입력하고, 같은 메시지를 받습니다. “가짜 이메일 주소는 받지 않습니다”는 같은 자리를 차지하면서 혼란을 끝냅니다.

전체 글 보기