엔터프라이즈 체크리스트: QA/UAT에서 임시 이메일 사용 시 OTP 위험 줄이기
OTP 검증은 임시 이메일을 사용하는 모든 QA 파이프라인에서 가장 취약한 연결고리입니다. 차단된 도메인 하나, 재전송 폭주 한 번, 혹은 만료된 받은 편지함 하나가 수백 건의 허위 테스트 실패로 이어질 수 있으며, 정리 작업의 책임자는 아무도 없습니다. 이 엔터프라이즈용 체크리스트는 QA 리드와 DevOps 팀에게 UAT 환경에서 OTP 위험을 줄이기 위한 체계적인 접근 방식을 제공합니다. 도메인 순환 일정, 재전송 스로틀 규칙, TTFOM(최초 OTP 메시지 수신까지 걸리는 시간) p50/p90 벤치마크, 받은 편지함 소유권 할당, 그리고 스프린트 도중 이메일 전달이 중단될 때의 에스컬레이션 경로를 다룹니다.
빠른 접근
핵심 요약
- OTP 신뢰성을 성공률과 TTFOM(p50/p90, p95)을 포함한 측정 가능한 SLO로 다루세요.
- QA/UAT 트래픽과 도메인을 프로덕션과 분리하여 평판과 분석이 훼손되지 않도록 하세요.
- 재전송 대기 시간을 표준화하고 로테이션 횟수를 제한하며, 규칙적인 재시도를 거친 뒤에만 로테이션하세요.
- 테스트 유형에 따라 받은편지함 전략을 선택하세요. 회귀 테스트에는 재사용 가능한 주소를, 대량 테스트에는 수명이 짧은 주소를 사용하세요.
- 발신자×도메인 지표를 실패 코드와 함께 계측하고 분기별 통제 검토를 시행하세요.
QA/UAT에서 임시 이메일을 사용하는 기업의 OTP 위험을 줄이기 위한 체크리스트
여기서 반전이 있습니다: 테스트 환경에서 OTP 신뢰성은 단지 '메일'만의 문제가 아닙니다. 타이밍 습관, 발신자 평판, 그레이리스트, 도메인 선택, 그리고 팀이 스트레스 상황에서 어떻게 행동하는지 간의 상호작용입니다. 이 체크리스트는 그 복잡한 문제를 공유된 정의, 보호막, 증거로 전환합니다. 임시 메일함에 처음 사용하신다면, 먼저 임 시 메일 의 핵심 내용을 훑어보며 용어와 기본 동작을 익히세요.
1) QA/UAT에서 OTP 위험 정의하기
QA, 보안, 제품이 OTP 신뢰성에 대해 같은 언어로 말할 수 있도록 용어를 통일하세요.
"OTP 성공률"의 의미
OTP 성공률은 정책 창(예: 테스트 플로우의 경우 10분) 내에 유효한 코드를 수신하고 사용한 OTP 요청의 비율입니다. 발신자(코드를 발급하는 앱/사이트)와 수신 도메인 풀별로 추적하세요. 사용자 이탈 사례는 별도로 제외하여 사고 분석이 희석되지 않도록 하세요.
팀을 위한 TTFOM p50/p90
첫 OTP 메시지 도달 시간(TTFOM)—"코드 전송"부터 첫 메시지가 받은편지함에 도착할 때까지의 초입니다. p50과 p90(스트레스 테스트의 경우 p95)을 차트로 그리세요. 이러한 분포는 일화에 의존하지 않고도 큐잉, 스로틀링, 그레이리스트를 드러냅니다.
거짓 음성과 실제 실패
"거짓 음성"은 코드는 수신했지만 테스터의 플로우가 이를 거부하는 경우로, 흔히 앱 상태 , 탭 전환 , 또는 만료된 타이머 때문에 발생합니다. "실제 실패"는 정책 창 내에 도착하지 않는 경우입니다. 분류 체계에서 이 둘을 구분하세요. 실제 실패만이 로테이션을 정당화합니다.
스테이징이 전달성을 왜곡할 때
스테이징 엔드포인트와 합성 트래픽 패턴은 흔히 그레이리스트나 우선순위 하락을 유발합니다. 기준선이 프로덕션보다 나쁘게 느껴진다면 이는 예상된 일입니다. 비인간 트래픽은 분포가 다르기 때문입니다. 간단한 안내는 2025년 임시 메일 개요를 참고하세요.
2) 흔한 실패 유형 모델링
영향이 가장 큰 전달 함정을 정리해 두면 정책과 도구로 미리 대비할 수 있습니다.
그레이리스트와 발신자 평판
그레이리스트는 발신자에게 나중에 다시 시도하라고 요구하므로 첫 시도는 지연될 수 있습니다. 신규 또는 '콜드' 발신자 풀도 평판이 쌓일 때까지 같은 문제를 겪습니다. 새 빌드의 알림 서비스 첫 몇 시간 동안에는 p90 급증을 예상하세요.
ISP 스팸 필터와 콜드 풀
일부 제공업체는 콜드 IP나 도메인을 더 엄격하게 검사합니다. 새 풀에서 OTP를 대량으로 발송하는 QA 실행은 캠페인처럼 보여 비중요 메시지가 느려질 수 있습니다. 워밍업 절차(낮고 규칙적인 발송량)가 이를 완화합니다.
속도 제한과 피크 혼잡
재전송 요청을 몰아서 보내면 속도 제한에 걸릴 수 있습니다. 부하가 큰 시기(예: 세일 이벤트, 게임 출시)에는 발신자 대기열이 길어져 TTFOM p90이 커집니다. 체크리스트에는 재전송 대기 시간 과 재시도 상한 을 명확히 정의해 스스로 만든 지연을 피해야 합니다.
흐름을 깨뜨리는 사용자 행동
탭 전환, 모바일 앱 백그라운드 전환, 잘못된 별칭 복사는 메시지가 전달되더라도 거부나 만료를 일으킬 수 있습니다. 테스트용 UI 마이크로텍스트에 "페이지에 머무르고, 기다리고, 한 번만 재전송"이라는 안내 문구를 넣으세요.
3) 환경을 분리하고 신호도 분리
QA/UAT를 프로덕션과 분리해 발신자 평판과 분석이 오염되지 않도록 하세요.
스테이징 도메인과 프로덕션 도메인
스테이징용으로 별도의 발신자 도메인과 회신(reply-to) 아이덴티티를 유지하세요. 테스트 OTP가 프로덕션 풀로 유출되면 잘못된 교훈을 얻고, 프로덕션 배포에 평판이 필요한 바로 그 시점에 평판을 떨어뜨릴 수 있습니다.
테스트 계정과 할당량
이름이 지정된 테스트 계정을 만들고 할당량을 부여하세요. 관리된 테스트 아이덴티티 몇 개가 빈도 휴리스틱에 걸리는 수백 개의 임시 계정보다 낫습니다.
합성 트래픽 시간대
한산한 시간대에 합성 OTP 트래픽을 발생시키세요. 남용처럼 보이는 끝없는 폭주가 아니라 짧은 버스트로 지연 시간을 측정하세요.
메일 흔적 점검
테스트가 접촉하는 도메인, IP, 제공업체를 목록화하세요. 스테이징 아이덴티티의 SPF/DKIM/DMARC가 일관되게 설정되어 있는지 확인해 인증 실패와 전달 문제를 혼동하지 않도록 하세요.
4) 알맞은 받은편지함 전략 선택
테스트 신호를 안정시키기 위해 언제 주소를 재사용하고 언제 수명이 짧은 받은편지함을 쓸지 정할 수 있나요?
회귀 테스트를 위한 재사용 주소
장기 테스트(회귀 스위트, 비밀번호 재설정 루프)에서는 재사용 가능한 주소 가 연속성과 안정성을 유지합니다. 토큰 기반 재개방은 날짜와 기기 간 잡음을 줄여 여러 빌드에서 동일 조건의 결과를 비교하기에 이상적입니다. 운영 세부사항은 '임시 우편함 재사용' 에서 해당 수신함을 안전하게 다시 여는 방법에 대한 안내를 참고하세요. 스위트가 코드나 CI에서 실행된다면, Tmailor 임시 메일 API 는 수신 전용 주소를 생성해 삭제할 때까지 계정에 유지하며, 각 메시지에서 일회성 코드와 링크를 추출합니다(최선 노력).
버스트 테스트를 위한 단기 수명
일회성 급증과 탐색적 QA의 경우, 단기 수명 수신함은 잔여물을 최소화하고 목록 오염을 줄여줍니다. 또한 시나리오 사이에 깔끔한 초기화를 유도합니다. 테스트에 단일 OTP만 필요하다면, 10 Minute Mail 같은 단기 수명 모델이 적합합니다.
토큰 기반 복구 규율
재사용 가능한 테스트 수신함이 중요하다면, 액세스 토큰을 자격 증명처럼 취급하세요. 테스트 스위트의 라벨 아래 비밀번호 관리자에 저장할 수 있으며, 역할 기반 접근 권한을 부여할 수 있습니다.
주소 충돌 방지
별칭 무작위화, 기본 ASCII, 그리고 빠른 고유성 검사가 오래된 테스트 주소와의 충돌을 방지합니다. 별칭 이름 지정이나 저장 방식을 스위트별로 표준화하세요.
5) 효과적인 재전송 대기 시간 설정
"분노 재전송"과 잘못된 스로틀링을 줄이기 위해 타이밍 동작을 표준화하세요.
재전송 전 최소 대기 시간
첫 번째 요청 후에는 60~90초 기다린 뒤 단일 구조화된 재시도를 하세요. 이렇게 하면 그레이리스트의 첫 번째 단계에서 실패하는 것을 피하고 발신자 대기열을 깨끗하게 유지할 수 있습니다.
단일 구조화 재시도
테스트 스크립트에서 한 번의 공식 재시도만 허용한 후 일시정지하세요. 특정 날짜에 p90이 늘어난 것처럼 보인다면, 모두의 결과를 떨어뜨리는 재시도를 무작정 반복하지 말고 기대치를 조정하세요.
앱 탭 전환 처리
사용자가 앱을 백그라운드로 보내거나 다른 곳으로 이동하면 코드가 무효화되는 경우가 많습니다. QA 스크립트에서는 "화면에 머무르기"를 명시적인 단계로 추가하고, 운영체제/백그라운드 동작을 로그에 기록하세요.
타이머 텔레메트리 수집
정확한 타임스탬프를 기록하세요: 요청, 재전송, 수신함 도착, 코드 입력, 수락/거부 상태. 발신자와 도메인 별로 이벤트를 태그하여 나중에 포렌식 분석이 가능하도록 하세요.
6) 도메인 순환 정책 최적화
테스트 관찰성을 단편화하지 않으면서 그레이리스트를 우회하도록 스마트하게 순환하세요.
발신자별 로테이션 상한
자동 회전은 첫 빗나갔을 때 작동해서는 안 됩니다. 발신자별로 임계값을 정의하세요: 예를 들어 동일한 발신자×도메인 조합에서 두 개의 윈도가 실패한 뒤에만 로테이션하고, 평판을 보호하기 위해 세션당 로테이션을 ≤2회 로 제한하세요.
도메인 풀 관리와 TTL
오래된 도메인과 신규 도메인을 섞어 도메인 풀을 관리하세요. p90이 흔들리거나 성공률이 떨어지면 '지친' 도메인을 잠시 쉬게 하고, 회복된 후 다시 편입하세요. TTL을 테스트 주기와 맞춰 받은편지함 가시성이 검토 윈도와 일치하도록 하세요.
A/B 테스트를 위한 고정 라우팅
빌드를 비교할 때는 고정 라우팅을 유지하세요. 동일한 발신자가 모든 변형에서 동일한 도메인 계열로 라우팅되도록 합니다. 이렇게 하면 지표가 서로 오염되는 것을 막을 수 있습니다.
로테이션 효과 측정
로테이션은 감이 아니라 측정의 대상입니다. 동일한 재전송 윈도 조건에서 로테이션을 적용한 변형과 적용하지 않은 변형을 비교하세요. 더 자세한 근거와 보호 장치는 이 설명글의 OTP를 위한 도메인 로테이션 을 참조하세요: OTP를 위한 도메인 회전.
7) 올바른 지표를 계측하세요
지연 분포를 분석하고 근본 원인 라벨을 부여하여 OTP 성공을 측정 가능하게 만드세요.
발신자 × 도메인별 OTP 성공률 : 최상위 SLO는 발신자 × 도메인 매트릭스로 분해되어야 하며, 이 매트릭스를 통해 문제가 사이트/앱에 있는지 아니면 사용된 도메인에 있는지 드러납니다.
TTFOM p50/p90, p95
중앙값과 꼬리 지연 시간은 서로 다른 이야기를 합니다. p50은 일상적인 상태를 나타내고, p90/p95는 부하, 스로틀링, 대기열을 보여줍니다.
재전송 규율 준수율 %
공식 재전송 계획을 준수한 세션의 비율을 추적하세요. 너무 일찍 재전송한 경우에는 해당 시도를 전달 가능성 결론에서 제외하세요.
실패 분류 코드
GL(그레이리스트), RT(속도 제한), BL(차단된 도메인, 사용자 상호작용/탭 전환), OT(기타)와 같은 코드를 채택하세요. 사고 기록에는 코드를 필수로 남기세요.
8) 피크 대비 QA 플레이북 구축
게임 출시나 핀테크 전환 시의 트래픽 폭주를 코드 손실 없이 처리하세요.
이벤트 전 워밍업 실행
피크 24–72시간 전에 알려진 발신자로부터 저속으로 정기적인 OTP를 전송해 평판을 워밍업하세요. 워밍업 기간 전반에 걸쳐 p90 추세선을 측정하세요.
위험도별 백오프 프로필
위험 범주별로 백오프 곡선을 적용하세요. 일반 사이트는 몇 분에 걸쳐 두 번 재시도합니다. 고위험 핀테크는 대기 시간을 길게 하고 재시도 횟수를 줄이면 경고가 덜 발생합니다.
카나리아 순환 및 경보
이벤트 중에는 OTP의 5–10%가 카나리아 도메인 하위 집합을 통해 라우팅되도록 하세요. 카나리아의 p90이 상승하거나 성공률이 떨어지면 초기에 1차 풀을 순환시키세요.
페이저 및 롤백 트리거
숫자 트리거를 정의하세요. 예를 들어 OTP 성공률이 10분 동안 92% 아래로 떨어지거나 TTFOM p90이 180초를 초과하면 대기 중인 담당자를 호출하거나, 대기 시간을 늘리거나, 휴식 상태인 풀로 전환합니다.
9) 안전한 취급 및 개인정보 보호 통제
규제 산업에서 테스트 신뢰성을 보장하면서 사용자 개인정보를 보호하세요.
수신 전용 테스트 메일박스
악용 경로를 억제하고 아웃바운드 위험을 제한하려면 수신 전용 임시 이메일 주소를 사용하세요. 첨부파일은 단순히 범위 밖인 것이 아니라, Tmailor 받은편지함은 모든 인바운드 첨부파일이 도착 즉시 제거되기 때문에 파일을 전혀 받을 수 없습니다. 테스트 중인 흐름이 파일 형태로 무언가를 전달한다면 여기서는 검증할 수 없습니다.
24시간 표시 기간
테스트 메시지는 도착 후 ~24시간 이내에 표시되어야 하며, 그 후 자동으로 삭제됩니다. 그 기간은 검토하기에 충분히 길고, 사생활을 보호하기에는 충분히 짧다. 정책 개요와 사용 팁을 위해 임 시 우편 가이드 에서 팀을 위한 기본 자료를 모아 제공합니다.
GDPR/CCPA 고려사항
흐름상 가능한 한 테스트 이메일에 실제 개인정보를 넣지 마세요. 테스트에서 정말 피할 수 없다면 해당 테스트에 필요한 범위로 데이터를 제한하고, 보존 기간을 짧게 유지하며, 로그와 스크린샷, 복사한 코드를 즉시 삭제하세요. 짧은 보존 기간, 정제된 HTML, 이미지 프록시는 노출을 줄여 주지만, 공유되고 인증되지 않은 받은편지함을 개인정보를 안전하게 보관하는 장소로 만들어 주지는 않습니다. 임시 이메일 주소는 통제된 데이터 저장소가 아닙니다. 주소를 가진 사람은 누구나 그 안에 도착한 내용을 읽을 수 있고, 받은편지함에는 스팸 폴더나 필터가 없어 모든 수신 메시지가 그대로 표시됩니다.
로그 마스킹 및 접근 관리
로그에서 access token과 코드를 마스킹하고, 받은편지함의 access token에는 역할 기반 접근을 적용하세요. 누가 언제 어떤 테스트 메일박스를 다시 열었는지 감사 기록을 유지하세요. access token은 실제로 단일 실패 지점이므로 그렇게 취급하세요. 비밀번호가 아니라 복구 키이며, 다른 사람이 주소에 접근하는 것을 막지 못하고, 게스트 주소의 경우 분실한 토큰은 Tmailor를 포함해 누구도 재생성할 수 없습니다. 무료 Tmailor 계정에 저장된 테스트 받은 편지함은, 생성 이메일에서 열어 Access Token을 변경하여 새 토큰을 발급할 수 있는데, 이 경우에도 이전 복사본은 모두 작동하지 않습니다.
10) 거버넌스: 체크리스트의 소유자는 누구인가
이 문서의 모든 통제 항목에 대해 담당자, 주기, 증거를 지정하세요.
OTP 신뢰성을 위한 RACI
책임 담당자(주로 QA), 책임자 스폰서(보안 또는 제품), 자문(인프라/이메일), 정보 드(지원)를 명명하세요. 이 RACI를 저장소에 게시하세요.
분기별 통제 검토
분기마다 체크리스트에 따라 샘플 실행을 실시하여 재전송 대기 시간, 교체 임계값, 지표 라벨이 여전히 준수되고 있는지 확인합니다.
증거 및 테스트 산출물
각 통제 항목에 스크린샷, TTFOM 분포, 발신자×도메인 표를 첨부하고, Access Token은 해당 테스트 스위트를 참조하여 안전하게 보관하세요.
지속적 개선 루프
사고가 발생하면 런북에 대응 절차나 안티패턴을 추가하세요. 임계값을 조정하고, 도메인 풀을 갱신하며, 테스터가 보는 문구를 업데이트하세요.
비교 표 — 교체 vs 미교체 (QA/UAT)
이 표는 벤치마크 데이터가 아닌 엔지니어링 지침 입니다. 지연이나 성공률 수치는 의도적으로 넣지 않았습니다. 이는 발신 플랫폼, 수신 도메인, 빌드, 시간대에 따라 달라지므로 여기에 적힌 숫자는 재현할 수 없는 숫자가 되기 때문입니다. 위에서 정의한 지표를 계측하여 자체 기준선을 측정한 뒤, 아래 행을 참고해 어떻게 대응할지 결정하세요.
| 시나리오 | 교체 적용 시 | 교체 미적용 시 | 확인할 사항 |
|---|---|---|---|
| 그레이리스트 의심 | 재전송 대기 시간을 한 번 온전히 기다린 뒤 재시도를 기록하고, 대체 도메인 하나와 비교하세요 | 한 번의 연장된 관찰 기간 동안 같은 주소를 유지하세요 | 너무 일찍 교체하면 비교가 무너집니다. 대기 때문인지 교체 때문인지 더 이상 구분할 수 없습니다 |
| 피크 시간대 발신자 대기열 | 동일한 발신자 부하에서 특정 수신 도메인의 동작이 더 나쁠 때만 교체하세요 | 대기 시간을 늘리고 도메인은 안정적으로 유지하세요 | 큐 혼잡은 보통 발신자 측에서 발생하므로, 도메인을 바꾸면 원인은 건드리지 못한 채 잡음만 더해집니다 |
| 콜드 발신자 풀 | 발신자를 워밍하고 소규모 카나리아 하위 집합으로 라우팅하세요 | 안정적인 도메인에서 워밍만 수행 | 워밍업 규율이 전환보다 더 중요합니다. 빌드를 비교하기 전에 워밍업 기간을 기록하세요 |
| 안정적인 발신자 | 세션당 회전 0~1회로 제한 | 회전하지 않는 것을 선호 | 불필요한 교체는 증거를 조각내고 정상적인 통제 경로를 흐립니다 |
| 수신 도메인 하나가 플래그 처리됨 | 대체 도메인 하나를 시도해 보세요 — 이는 전달 결함에 대한 일반적인 문제 해결입니다 | 같은 도메인으로 계속 재시도하고 실패를 기록하세요 | 어떤 발신자×도메인 쌍이 실패했는지 기록하여 결과가 일화가 아닌 재현 가능한 것이 되도록 하세요 |
| 사이트 정책상 일회용 이메일을 금지합니다 | 회전할 것이 없습니다. 중단하세요. | 여기서 임시 이메일 테스트 경로를 중단하세요 | 이것은 전달 문제가 아니라 정책 경계입니다. 해당 흐름을 실제 또는 회사가 관리하는 메일함으로 옮기세요. 일회용 주소를 계속 바꿔가며 수용을 강제하는 것은 회피 행위이며, QA는 이를 해서는 안 됩니다 |
사용 방법
OTP 테스트, 발신자 규율, 환경 분리를 위한 체계적인 프로세스로, QA, UAT, 운영 격리에 유용합니다.
1단계: 환경 격리
QA/UAT용 발신자 식별과 도메인 풀을 별도로 만들고, 운영 환경과는 절대 공유하지 마세요.
2단계: 재전송 타이밍 표준화
재시도 한 번을 시도하기 전에 60~90초를 기다리고, 세션당 총 재전송 횟수를 제한하세요.
3단계: 회전 상한 설정
동일한 발신자×도메인에서 임계값을 위반한 경우에만 회전하고, 세션당 2회 이하로 제한하세요.
4단계: 토큰 기반 재사용 도입
접근 토큰을 사용해 같은 주소를 회귀 및 재설정 시 다시 열고; 접근 토큰을 비밀번호 관리자에 저장하세요.
5단계: 지표 계측
OTP 성공, TTFOM p50/p90(및 p95), 재전송 규율 준수율, 실패 코드를 기록하세요.
6단계: 피크 리허설 실시
발신자를 워밍업하고, 알림이 포함된 카나리 로테이션을 사용해 이탈을 조기에 포착하세요.
7단계: 검토 및 인증
첨부된 증거와 함께 각 통제 항목을 검토하고 승인하세요.
자주 묻는 질문
왜 OTP 코드가 QA에서는 늦게 도착하는데 운영 환경에서는 그렇지 않나요?
스테이징 트래픽은 수신자에게 더 시끄럽고 차갑게 보입니다. 그레이리스트와 스로틀링은 풀이 데워질 때까지 p90을 넓힙니다.
"코드 재전송"을 누르기 전에 얼마나 기다려야 하나요?
약 60~90초입니다. 그다음 구조화된 재시도를 한 번 하세요. 추가 재전송은 대기열을 더 악화시키는 경우가 많습니다.
도메인 로테이션이 항상 단일 도메인보다 나은가요?
아니요. 임계값에 도달했을 때만 로테이션하세요. 과도한 로테이션은 평판을 해치고 지표를 흐리게 만듭니다.
TTFOM과 전달 시간의 차이는 무엇인가요?
TTFOM은 첫 메시지가 받은편지함 화면에 나타날 때까지를 측정하고, 전달 시간은 테스트 기간을 넘어선 재시도까지 포함할 수 있습니다.
재사용 주소가 테스트에서 전달 가능성에 해가 되나요?
본질적으로는 아닙니다. 비교를 안정화하고, access token을 안전하게 저장하며, 조급한 재시도를 피하게 해줍니다.
서로 다른 발신자 간 OTP 성공률은 어떻게 추적하나요?
지표를 발신자 × 도메인별로 매트릭스화하여 문제가 사이트/앱에 있는지 도메인 계열에 있는지 드러내세요.
임시 이메일 주소가 QA 과정에서 GDPR/CCPA를 준수할 수 있나요?
네. 수신 전용, 짧은 노출 기간, 정제된 HTML, 이미지 프록시는 개인정보 우선 테스트를 지원합니다.
그레이리스트와 워밍업이 OTP 신뢰성에 어떤 영향을 미치나요?
그레이리스트는 초기 시도를 지연시키고, 콜드 풀은 꾸준한 워밍업이 필요합니다. 둘 다 대부분 p50이 아니라 p90에 영향을 줍니다.
QA와 UAT 메일박스를 운영 환경과 분리해야 하나요?
네. 풀을 분리하면 스테이징 노이즈가 운영 평판과 분석을 저하시키는 것을 막을 수 있습니다.
OTP 성공 감사에서 가장 중요한 텔레메트리는 무엇인가요?
OTP 성공률, TTFOM p50/p90(스트레스 시 p95), 재전송 준수율, 그리고 타임스탬프가 포함된 실패 코드입니다. 빠른 참고는 임시 메일 FAQ 를 참고하세요.
Priya Nair focuses on email deliverability and one-time-password (OTP) flows. She tests how verification codes from Google, Apple, social and crypto platforms land in disposable inboxes, and documents what improves OTP reliability on temp mail.
