QA용 테스트 이메일 계정 선택 방법

QA용 테스트 이메일 계정이란 무엇인가요?

테스트 이메일 계정, 즉 QA용 테스트 이메일 주소는 팀이 자사 애플리케이션이 보내는 이메일을 수신하고 검사하는 데 사용하는 주소입니다. 수동으로 민감하지 않은 가입 및 OTP 확인에는 임시 받은편지함을 사용하세요. 메시지 보관, 답장, 첨부파일이 필요하면 회사 메일함을 선택하고, 자동화 테스트가 사람 없이 이메일을 검사해야 한다면 SMTP 샌드박스나 호스팅 받은편지함 API를 선택하세요.

트일러가 이 블로그를 운영하니, 여기가 맞는 곳입니다. Tmailor는 웹, 안드로이드, iOS, 텔레그램 봇에서 제공하는 무료이자 수신 전용 임시 메일 서비스입니다. 첫 번째 경우에 적합합니다: 사람이 받은 편지함을 열고 가입을 실행한 뒤, 도착한 것을 읽습니다. 마지막 경우에는 별도의 Tmailor 임시 메일 API 를 통해 자동 테스트가 수신 전용 주소를 생성하고 코드에서 메시지를 읽을 수 있습니다. 메시지는 도착 후 약 24시간 동안 머무르고, 첨부파일은 받지 못하며, 주소는 전송이나 답장이 불가능합니다. 일회용 메일함에 익숙하지 않다면, 임 시 우편함이 어떻게 작동하는지 먼저 알아보세요.

• 이메일이 도착할 필요가 없는 경우(양식 검증, 픽스처, 단위 테스트): 예약된 예제 도메인을 사용하세요.
• 사람이 이메일을 읽고 그 안에 민감한 내용이 없는 경우: 임시 받은편지함이 가장 빠른 선택입니다.
• 민감한 데이터, 답장, 첨부파일 또는 반드시 보관해야 하는 증거가 있는 경우: 승인된 회사 관리 메일함을 사용하세요. 플러스 태그는 메일 시스템과 애플리케이션이 지원하는 경우에만 추가하세요.
• 사람이 지켜보지 않는 경우: 앱의 발신 메일 설정을 제어할 수 있다면 SMTP 캐처를, 앱이 평소 사용하는 제공업체를 통해 보내야 한다면 호스팅 받은편지함 API를 사용하세요.

수동 이메일 테스트 vs 자동 이메일 테스트: 의사결정 트리

네 가지 질문으로 어떤 테스트 이메일 계정이 필요한지 결정합니다. 이메일이 반드시 도착해야 하는지, 사람이 읽는지 코드가 읽는지, 민감한 데이터가 담기는지, 그리고 애플리케이션이 발신 메일을 어디로 보내는지 제어할 수 있는지입니다.

1. 테스트에 이메일이 도착해야 하나요? 형식 검사, UI 상태, 픽스처, 단위 테스트에는 보통 필요하지 않습니다. example.com, example.org, example.net의 주소를 사용하세요. 이 도메인들은 문서와 예제용으로 예약되어 있어 실제 사람에게 닿지 않습니다. 무작위 도메인을 만들어 쓰는 것은 피하세요. 누군가 소유하고 있을 수 있습니다.
2. 테스트 중에 사람이 메시지를 읽나요? 스모크 테스트, 수동 UAT, 데모, 탐색 세션에는 사람이 참여합니다. 회귀 테스트 모음과 CI 작업에는 보통 사람이 없습니다.
3. 누군가 사람이 읽는다면, 그 안에 민감한 내용이 있나요? 실제 고객 기록, 자격 증명, 규제 대상 데이터, 또는 감사 증거로 보관해야 하는 메시지는 임시 받은편지함에 두면 안 됩니다. 대신 회사 메일함을 사용하세요. 답이 '아니요'라면 임시 받은편지함으로 충분합니다.
4. 코드가 읽는다면, 테스트 환경이 테스트 SMTP 서버로 메일을 보낼 수 있나요? 가능하다면 SMTP 캐처가 모든 메시지를 전달하지 않고 가로챕니다. 불가능하다면, 즉 앱이 평소 이메일 제공업체를 통해 보내야 한다면 테스트가 API로 읽는 호스팅 받은편지함을 사용하세요.

다음 표는 다섯 가지 옵션을 나란히 비교합니다.

이메일 필드는 어떤 주소를 허용하거나 거부해야 할까?

메시지 전달과 별개로 폼 검증을 테스트하세요. 유효해 보이지만 실제로는 전달되지 않는 경우에는 user@example.com 같은 예약 주소를 사용하고, 플러스 태그가 붙은 주소와 서브도메인이 있는 주소를 포함하며, 로컬 파트가 없거나 도메인이 없는 등 형식이 잘못된 사례도 추가하세요. 기대 결과는 운영 시스템에서 실제로 사용하는 검증기와 일치하도록 유지하세요.

임시 수신함으로 충분할 때

임시 수신함은 한 사람이 한 번에 하나의 흐름을 확인하고, 메시지에 하루가 지나면 잃어도 괜찮은 내용만 담겨 있을 때 충분합니다. 이것이 QA를 위한 일회용 이메일의 전형적인 용도입니다. 즉, 폼을 직접 테스트할 때 필요한 것은 이메일 주소이지 장기 계정이 아닙니다. 대표적인 사례로는 출시 전 가입 폼 스모크 테스트, 새로운 온보딩 이메일에 대한 수동 UAT 점검, 계정 생성 판매 데모, 이상한 입력을 시도하며 앱이 보내는 내용을 관찰하는 탐색 세션 등이 있습니다.

장점은 속도입니다. IT에 요청할 계정도 없고 정리할 공유 메일함도 없습니다. 대신 통제권을 포기합니다. 메시지 확인 기간이 짧고, 첨부파일이 없으며, 코드가 아닌 사람이 읽는 수신함이라는 점이 그 대가입니다.

SMTP 캐처나 호스팅 수신함 API가 필요할 때

테스트가 무인으로 실행되면 수신함을 코드로 읽을 수 있어야 합니다. 이 요구를 충족하는 도구는 두 계열이며, 각각 다른 문제를 해결합니다.

SMTP 캐처와 샌드박스 는 테스트 환경에서 앱의 발신 메일 서버를 대체하고, 모든 메시지를 전달하지 않고 검사용으로 보관합니다.

• Mailpit은 직접 운영하는 무료 오픈 소스 도구입니다. 기본적으로 메일을 캡처하며, 통합 테스트를 위한 웹 UI와 REST API를 제공합니다.
• MailHog도 같은 방식으로 작동하지만 더 오래된 도구입니다. Mailpit 관리자들은 더 이상 유지보수되지 않는다고 밝히고 있으니, 도입하기 전에 상태를 확인하세요.
• Mailtrap Email Sandbox는 같은 개념을 호스팅 형태로 제공하는 서비스로, SMTP와 API 접근을 지원합니다. Mailtrap의 프로덕션 발송 제품과는 별개입니다.
• Ethereal은 주로 Nodemailer와 함께 사용하는 무료 가짜 SMTP 서비스입니다. 메시지는 미리보기용으로 수집될 뿐 실제로 전달되지는 않습니다.

호스팅 받은편지함 API는 벤더 도메인의 실제 주소를 테스트에 제공하므로, 앱은 평소 쓰는 공급자를 통해 메일을 보내고 테스트는 API를 통해 결과를 읽습니다. Tmailor의 자체 임시 메일 API도 이렇게 작동하며, Python, Node.js, PHP용 공식 SDK를 제공합니다.

• Mailosaur는 테스트 이메일 주소, API, 그리고 Cypress, Playwright, Selenium 같은 프레임워크와 연동되는 클라이언트 라이브러리를 제공합니다. SMS 코드도 지원합니다.
• MailSlurp는 API와 SDK를 통해 필요할 때마다 받은편지함을 생성합니다. 테스트는 메시지를 기다린 뒤 코드, 링크, 첨부파일을 추출할 수 있습니다.

벤더의 기능과 요금제는 바뀌므로, 테스트 스위트를 한 곳에 맡기기 전에 각 공식 사이트에서 최신 정보를 확인하세요.

플러스 태그가 붙은 회사 메일함이 더 나은 선택일 때

플러스 태그를 쓰면 하나의 회사 메일함으로 여러 주소 변형을 받을 수 있습니다. 회사 도메인의 qa+signup이나 qa+reset으로 보낸 메일은 qa 메일함에 도착하며, 태그별로 필터링할 수 있습니다. Google Workspace도 이를 지원하고, Microsoft는 Exchange Online의 플러스 주소 지정이 관리자가 끄지 않는 한 기본으로 켜져 있다고 문서에 밝히고 있습니다.

실제 고객 데이터를 다루는 플로우, 하루 이상 걸리는 플로우, 회신이나 첨부파일이 필요한 플로우, 또는 감사인이 요구할 수 있는 증거를 남겨야 하는 플로우라면 이 방식을 쓰세요. 한계도 염두에 두세요. 태그는 별도의 받은편지함이 아니라 하나의 메일함에서 파생된 변형이므로, 병렬로 진행하는 테스트가 서로의 메시지를 읽을 수 있습니다. 일부 가입 양식은 플러스 기호를 거부하고, 일부 앱은 태그가 붙은 변형을 같은 계정으로 취급합니다. 두 동작 모두 그 자체로 테스트 케이스로 삼을 만합니다.

임시 받은편지함으로 수동 가입 테스트를 실행하는 방법

임시 이메일을 사용하는 수동 가입 테스트에는 세 가지가 필요합니다. 새 주소, 테스트 중인 빌드, 그리고 받은 내용을 받은편지함 밖에 기록할 공간입니다. 소유하거나 테스트 권한을 받은 시스템에만 실행하세요.

1. 받은편지함을 여세요. 웹에서 무료 임시 받은편지함을 만들 하거나 Tmailor 앱 또는 텔레그램 봇을 사용해 주소를 복사하세요. 데스크톱에서는 Tmailor 브라우저 확장 기능을 사용해 테스트 빌드의 이메일 필드에 입력할 수도 있습니다.
2. 테스트 빌드에서 가입하세요. 스테이징이나 QA 환경에서 해당 주소를 사용하고, 양식을 제출한 시각을 기록하세요.
3. 이메일이 오는지 확인하세요. 어떤 메시지가 도착했는지, 발신자 이름과 발신 주소, 제목, 그리고 도착까지 걸린 시간을 확인하세요.
4. 단계를 완료하세요. 링크를 클릭하거나 코드를 입력하세요. 계정 상태가 한 번만 바뀌는지, 같은 링크를 다시 쓰면 명확한 메시지와 함께 실패하는지 확인하세요.
5. 증거는 다른 곳에 기록하세요. 링크, 코드, 타임스탬프, 스크린샷을 테스트 케이스에 복사하세요. 메시지는 도착 후 약 24시간만 보관되므로 받은편지함은 테스트 기록이 될 수 없습니다.
6. 다시 테스트할 계획이라면 액세스 토큰을 저장하세요. 토큰을 사용하면 나중에 같은 주소를 다시 열 수 있습니다. 예를 들어 비밀번호 재설정을 다시 실행할 때 유용합니다. 다만 이미 만료된 메시지는 복구되지 않으며, 분실한 토큰은 되찾을 수 없습니다.

무료 사용자, 체험 사용자, 초대받은 팀원처럼 한 세션에서 여러 페르소나가 동시에 필요할 때, 다중 인박스 뷰 는 브라우저 탭 하나에서 최대 다섯 개의 주소를 나란히 유지합니다. 각 페르소나가 고유한 주소를 받으므로 어떤 이메일이 어떤 계정에 속하는지 확인할 수 있습니다.

이 화면은 여전히 수동 방식입니다. 받은 편지함은 코드로 프로비저닝되는 것이 아니라 사람이 브라우저에서 직접 만들기 때문에, 병렬 무인 실행을 위한 호스팅 받은 편지함 API를 대체하지는 못합니다.

받은 편지함 하나일까, 테스트마다 주소 하나일까?

간단한 스모크 점검이라면 공유 받은 편지함 하나로 충분하지만, 금세 복잡해집니다. 여러 테스트가 동시에 실행되면 비슷한 제목 때문에 어떤 이메일이 어떤 스크립트에 속하는지 구분하기 어려워지고, 디버깅은 추측에 의존하게 됩니다.

테스트 케이스마다 주소를 하나씩 두면 이 문제가 해결됩니다. 로그, 스크린샷, 이메일이 서로 맞아떨어지고, 메시지가 누락되면 모든 시나리오가 아니라 특정 시나리오 하나를 가리키게 됩니다. 여러 임시 메일 받은편지함 운영 가이드에서 그 워크플로를 더 자세히 다룹니다.

일부 여정에서는 며칠 뒤에 같은 주소가 다시 필요합니다. 예를 들어 체험판이 유료로 전환되는 경우나 이탈한 사용자가 다시 돌아오는 경우입니다. 재사용 가능한 임시 우편 주소 는 Access Token을 통해 주소는 계속 사용할 수 있게 해 주지만 메일은 보관하지 않습니다. 각 단계가 실행될 때 필요한 링크와 코드를 저장하고, 이전 메시지에 의존하는 단계는 회사 사서함으로 옮기세요. 테스터가 페르소나 주소를 만들기 전에 무료 Tmailor 계정에 에 로그인하면 각 주소가 생성된 이메일 아래에 저장되므로, 토큰을 잃어버려도 더 이상 주소를 잃는 일은 없습니다.

가입 및 온보딩 이메일에서 확인할 사항

여정에서 발송될 수 있는 모든 이메일 목록을 먼저 만든 뒤, 각 테스트가 무엇을 검증할지 정하세요. 팀은 성장 실험이나 보안 변경으로 아무도 기록해 두지 않은 이메일이 추가된 경우, 테스트 도중에야 추가 이메일을 발견하는 일이 흔합니다.

일반적인 가입 여정의 이메일

• 인증 링크 또는 일회용 코드
• 환영 이메일과 빠른 시작 안내 시퀀스
• 매직 링크 로그인
• 비밀번호 재설정
• 이메일 주소 변경 안내(기존 주소와 새 주소 모두로 발송)
• 새 기기 또는 새 위치 보안 경고
• 완료되지 않은 가입에 대한 리마인더

각 항목마다 트리거, 예상 시점, 그리고 요금제·지역·언어처럼 이를 바꾸는 조건을 적어 두세요. 보편적인 기준값을 가정하지 말고 제품의 문서화된 요구사항에서 허용된 발송 시간대를 설정하세요. 즉시 발송되는 인증 메시지와 예약된 환영 시퀀스는 서로 다른 기대치가 필요합니다. 이런 기대치가 마련되면 모든 테스트는 구체적으로 검증할 기준을 갖게 됩니다.

각 테스트 이메일에서 검증할 항목

• 발신자와 수신자: 이름과 주소, 답장, 그리고 정확한 수신 주소까지.
• 제목과 본문: HTML과 일반 텍스트 버전 모두에서 올바른 이름, 요금제 세부 정보, 언어가 표시되는지.
• 링크: 목적지와 올바른 환경을 가리키는지 여부. 스테이징 이메일이 프로덕션으로 연결되면 실제 버그입니다.
• 코드: 형식, 길이, 만료 안내 문구, 그리고 명시된 만료가 서버가 실제로 적용하는 것과 일치하는지.
• 타이밍: 트리거 이후 메시지가 도착하기까지 걸린 시간.
• 첨부파일: 흐름이 PDF나 청구서를 보낸다면 회사 메일함이나 테스트 도구에서 테스트하세요. Tmailor는 첨부파일을 받지 않습니다.

렌더링에 관해 한 가지 주의할 점이 있습니다. 임시 받은편지함은 하나의 웹 뷰어가 HTML을 어떻게 표시하는지만 보여줍니다. 같은 이메일이 Gmail, Outlook, Apple Mail, 다크 모드, 작은 휴대폰 화면에서 어떻게 보이는지는 알려주지 않으므로, 이런 점검이 중요하다면 별도의 렌더링 확인을 계획하세요.

이메일 변경 및 계정 복구 흐름

복구 흐름은 가입보다 더 조용한 방식으로 깨집니다. 이메일 변경 시 새 주소로 확인 메일이, 이전 주소로 알림이 발송되는지, 사용한 재설정 링크를 다시 사용할 수 없는지, 새 링크를 보낸 뒤 이전 재설정 링크가 작동을 멈추는지, 그리고 두 번째 기기에서 링크를 열었을 때 사용자가 합리적인 상태에 도달하는지 확인하세요. OTP 흐름은 별도의 위험 검토가 필요하며, QA와 UAT의 OTP 위험 체크리스트 는 지표, 재전송 시간대, 소유권을 다룹니다.

OTP 및 인증 엣지 케이스 테스트 방법

OTP와 인증 흐름은 지연 발송, 재전송, 만료된 코드와 잘못된 코드, 다른 기기에서 열린 링크에 대해 테스트하세요. 각 사례에서는 서버 결과와 사용자에게 표시되는 메시지를 모두 확인해야 합니다. 이 테스트는 본인이 소유하거나 테스트 권한이 있는 시스템에서만 수행하세요. 좋은 OTP 테스트는 일부러 흐름을 끊습니다:

• 느린 도착: 받은편지함을 확인하기 전에 기다리며, UI가 상황을 설명하고 재전송 방법을 명확히 제공하는지 확인하세요.
• 재전송 동작: 두 번째 코드를 요청하고 첫 번째 코드가 무효화되는지 아니면 여전히 허용되는지 확인하세요.
• 만료: 명시된 유효 시간이 지난 뒤 코드를 입력하고 오류 메시지가 실제로 일어난 일과 일치하는지 확인하세요.
• 잘못된 코드: 시도 횟수 제한과 대기 안내 문구가 사용자에게 납득이 가는지 확인하세요.
• 기기 간 매직 링크: 노트북에서 링크를 요청하고 휴대폰에서 열어 사용자가 어디로 이동하는지 확인하세요.

어떤 코드가 임시 이메일함에 도달하고 어떤 코드가 도달하지 않는지 더 넓게 살펴보려면 OTP 코드에 관한 임시 메일 가이드를 참고하세요.

만약 제품이 일부러 일회용 이메일 도메인을 거부한다면, 그 경로를 직접 테스트해 보세요. 거절 메시지가 명확한지, 실제 또는 회사가 관리하는 주소가 여전히 가입을 완료하는지 확인하세요. 자신의 제품이나 다른 사람의 제품에서 다른 임시 도메인을 돌려 블록을 넘기지 마세요. 블록이 작동하는지 확인하는 것이 시험입니다; 그것을 무너뜨리는 것은 그렇지 않습니다. 이 웹사이트 가 임시 우편 도메인을 차단하는 이유 에 대한 이 설명에서는 그러한 필터의 이유를 다룹니다.

이메일 테스트가 무인으로 실행될 때 달라지는 점

아무도 지켜보지 않을 때는 테스트가 코드로 읽을 수 있는 받은편지함을 필요로 합니다. 즉 SMTP 캐처의 API나 호스팅된 받은편지함 API가 필요합니다. Tmailor 웹 받은편지함은 그런 도구가 아니지만, Tmailor 임시 메일 API는 그런 도구입니다. 테스트는 수신 전용 주소를 만들고, 메시지를 나열하고 읽으며, API가 찾아낸 일회용 코드나 인증 링크를 받을 수 있습니다. MCP 서버를 사용하면 Claude, Cursor, VS Code Copilot 같은 AI 에이전트가 자신이 소유하거나 테스트 권한이 있는 가입 흐름에서 같은 작업을 할 수 있습니다.

어떤 도구를 선택하든 무인 이메일 테스트를 안정적으로 유지하는 몇 가지 습관이 있습니다.

• 테스트 실행마다 고유한 주소와 상관 ID를 부여하여, 이전 실행에서 늦게 도착한 이메일이 엉뚱한 검증을 통과시키지 않도록 하세요.
• 전체 테스트 타임아웃과 별개로 이메일 도착을 기다리는 전용 대기와 적절한 백오프를 두고, 각 메시지가 얼마나 걸렸는지 기록하세요.
• "가장 최근 이메일"을 읽는 대신 수신자와 제목으로 정확히 일치하는 메시지를 찾으세요.
• 로그는 받은편지함보다 오래 남는 경우가 많으므로 CI 로그에서는 코드와 매직 링크를 가리세요.

또한 통과한 테스트가 무엇을 증명하는지도 분명히 하세요. "앱이 이메일을 생성해 전달했다", "호스팅된 테스트 도메인이 공용 이메일 인프라를 통해 수신했다", "Gmail이 스팸이 아닌 받은편지함에 넣었다"는 서로 다른 세 가지 사실입니다. SMTP 캐처는 첫 번째를 증명하고, 호스팅된 받은편지함 API는 처음 두 가지를 증명하며, 어느 것도 세 번째는 증명하지 못합니다. GitHub Actions, GitLab CI, CircleCI에서의 파이프라인 설정은 CI/CD 파이프라인에서 이메일 테스트 가이드를 참고하세요.

테스트 데이터를 안전하게 보관하고 규칙을 지키세요

임시 테스트 받은편지함에는 합성 신원과 민감하지 않은 콘텐츠를 사용하고, 자신이 소유하거나 평가 권한이 있는 시스템에만 가입 테스트를 실행하세요. QA 계정은 운영 분석에서 제외하고, 속도 제한을 준수하며, 규제 대상 데이터, 자격 증명, 첨부파일, 보관된 증거는 승인된 회사 관리 시스템으로 옮기세요.

• 임시 이메일함에는 실제 데이터를 넣지 마세요. 실제 고객 기록, 자격 증명, API 키, 규제 대상 데이터를 임시 이메일 주소로 절대 보내지 마세요. 이름이 명백히 가짜인 합성 사용자를 사용하세요.
• 테스트 권한이 있는 것만 테스트하세요. 자신의 제품이나 테스트 권한이 있는 시스템에 대해서만 가입 테스트를 실행하고, 해당 서비스의 속도 제한과 약관을 준수하세요. 임시 이메일을 사용해 제3자 사이트에 계정을 대량으로 만들지 마세요. 볼륨 및 부하 테스트는 SMTP 캐처나 호스팅된 받은편지함 API를 갖춘 자체 스테이징 환경에서 해야 합니다.
• QA 트래픽을 운영 지표에서 제외하세요. 테스트 계정을 명확히 표시하고 분석 및 성장 대시보드에서 제외하세요. 운영 발송 도메인에서 대량의 테스트 메일을 보내는 것은 반송과 불만으로 인해 평판에 해가 될 수 있으므로 피하세요.
• 정책을 문서로 남기세요. 어떤 흐름이 임시 이메일함을 사용할 수 있는지, 어떤 흐름에 회사 메일함이 필요한지, 테스트 데이터를 얼마나 오래 보관하는지, 누가 접근 권한을 갖는지 명시하세요. 경계가 이미 문서화되어 있으면 보안 및 규정 준수 검토가 더 빨리 진행됩니다.

보안이 제공업체가 데이터를 어떻게 처리하는지 묻는다면, 그들이 무엇을 수집하는지, 메시지를 얼마나 오래 보관하는지, 그리고 접근 방식이 어떻게 작동하는지 살펴보세요. 이 임 시 메일과 온라인 프라이버시 에 대한 이 개요는 사용자 입장에서 그러한 질문을 다룹니다. 어떤 흐름이 일회용 이메일함을 사용할 수 있는지에 대한 결정은 여전히 귀사의 법무, 개인정보 보호, 보안 팀의 몫입니다.

미리 고려해야 할 한계

Tmailor 웹 받은편지함은 민감하지 않은 수신 이메일에 대한 짧은 수동 확인에 적합합니다(자동화는 임시 메일 API의 역할입니다). 선택하기 전에 워크플로에 발신 작업, 첨부파일, 장기 보관 증거, 또는 지속적인 주소 복구가 필요한지 판단하세요. 이러한 요구 사항 중 하나라도 있으면 회사 관리 메일함이나 전문 테스트 도구가 필요하며, 아래 체크리스트가 그 이유를 설명합니다.

• Tmailor는 수신 전용입니다. 수신 가입, 인증, OTP 메일은 확인할 수 있지만, 답장 흐름이나 해당 주소에서 발송되는 어떤 것도 확인할 수 없습니다.
• Tmailor는 첨부파일을 받지 않으므로, 송장, 계약서, 문서 전달 이메일은 회사 메일함이나 테스트 도구가 필요합니다.
• 메시지는 도착 후 약 24시간 동안만 보관됩니다. 더 긴 조사에 필요한 링크, 코드, 타임스탬프를 내보내 두세요.
• 액세스 토큰은 만료된 메시지가 아니라 주소를 다시 여는 것이며, 잃어버린 토큰은 복구할 수 없습니다.
• 웹 받은편지함은 사람이 읽습니다. 사람 없이 받은편지함을 읽으려면 SMTP 캐처나 Tmailor 임시 메일 API 같은 호스팅 받은편지함 API가 필요합니다.
• 일부 서비스는 일회용 이메일 도메인을 차단합니다. 테스트하는 흐름이 의도적으로 이런 동작을 한다면, 실제 주소나 회사에서 관리하는 주소로 검증하세요.

적합한 테스트 받은편지함 선택하기

테스트가 무엇을 증명해야 하는지에 따라 받은편지함을 선택하세요. 전달이 필요 없을 때는 예약된 예시 도메인을, 민감하지 않은 수동 점검에는 임시 받은편지함을, 보관이 필요하거나 민감한 흐름에는 회사 메일함을, 발신 설정을 직접 제어할 때는 SMTP 캐처를, 사람 없이 실행되는 종단 간 테스트에는 호스팅 받은편지함 API를 사용하세요.

수동 사례의 경우, 임시 메일함을 열고 다음에 출시할 가입 흐름부터 시작하세요. 임시 이메일은 품질 보증 외에도 실용적인 용도 도 있습니다.