일회용 이메일 vs 암호화 이메일: 언제 무엇을 써야 할까
일회용 이메일 vs 암호화 이메일: 언제 무엇을 써야 할까
2026년 3월, Citizen Lab 소속 한 연구원이 발표한 유출 분석 보고서에 따르면 지난 한 해 동안 다크넷 포럼에서 거래된 14억 건의 자격 증명 중 71퍼센트가 거래소, 지갑, 본인 인증 서비스 전반에 걸쳐 동일한 주 이메일 주소를 재사용한 계정에서 비롯된 것으로 나타났습니다. 불편하지만 예측 가능한 결론이었습니다. 대다수의 "프라이버시를 의식한다는" 암호화폐 사용자들은 지갑이 아니라 받은편지함을 통해 스스로의 신원을 흘리고 있었던 것입니다. MoneroSwapper로 비트코인을 Monero로 스왑한 바로 그 날 제3자 서비스에 자신의 Gmail이나 Naver 메일 주소를 그대로 넘겨준 적이 있다면, 여러분도 같은 실수를 저질렀을 가능성이 높습니다.
해법은 "모든 일에 ProtonMail을 쓰자"도 아니고 "가짜 Gmail을 만들자"도 아닙니다. 일회용 이메일과 암호화 이메일은 서로 다른 두 가지 문제를 해결하는 서로 다른 두 도구입니다. 둘을 혼동하거나 하나가 다른 하나를 대체할 수 있다고 가정하는 순간, 사람들은 현실과 마주하면 곧바로 무너지는 안도감을 갖게 됩니다. 이 가이드에서는 각각이 실제로 어떤 일을 하는지, 어디서 무너지는지, 그리고 받은편지함이 위협 모델에서 가장 약한 부분이 되는 특정한 순간에 어떻게 둘을 결합해야 하는지를 살펴봅니다.
받은편지함은 어떻게 새로운 신원 계층이 되었나
이메일은 원래 인증 수단으로 설계된 적이 없습니다. 우연히 그 역할을 떠맡게 되었을 뿐입니다. 오늘날 이메일 주소는 사용자명이자, 비밀번호 재설정 채널이자, 마케팅 식별자이자, 행동 지문이자, 데이터 브로커 시장에서 판매되는 교차 데이터베이스 조인을 통한 실명 조회 키 역할까지 동시에 수행합니다. KYC 없는 거래소가 "이메일 주소만 입력해 주세요"라고 요청할 때, 그 한 줄의 문자열은 대개 다음 유출 사고가 발생한 직후 그 계정을 특정 인물과 연결하기에 충분합니다.
이러한 연결 고리를 끊기 위해 등장한 이메일 도구는 크게 두 가지 부류로 나뉘며, 두 부류는 기술적 메커니즘뿐 아니라 보호하려는 대상 자체가 다릅니다.
- 일회용/임시 이메일: 회원 가입 시 확인 메일을 받고, 실제 신원과 가입 행위를 분리한 뒤, 사라지거나 폐기할 수 있도록 만들어진 단기 또는 별칭 주소입니다. 핵심 보호 속성은 신원 격리이지 메시지 비밀성이 아닙니다.
- 암호화 이메일: 제공자가 메시지 본문에 엔드투엔드 또는 제로 액세스 암호화를 적용하여 호스팅하는 주소로, 영장이나 서버 침해가 발생해도 받은편지함의 내용을 손쉽게 들여다볼 수 없도록 합니다. 핵심 보호 속성은 내용 기밀성이지 익명성이 아닙니다.
- 흔한 함정: 사람들은 이 두 속성을 서로 바꿔 쓸 수 있는 것으로 취급합니다. 40개 거래소에서 주 식별자로 사용하는 ProtonMail 주소는 여전히 하나의 그래프 노드입니다. 암호화는 상관 관계 분석으로부터 여러분을 구해 주지 않습니다. 지갑 복구 코드를 받기 위해 사용한 일회용 주소는 중계 서버를 통제하는 누구라도 읽을 수 있습니다. "일회용"이 "비공개"와 같은 의미는 아닙니다.
이어지는 내용은 실제 위협 모델을 정리한 것입니다. 어떤 도구가 옳은지는 전적으로 여러분이 무엇으로부터 자신을 방어하려 하는가에 달려 있기 때문입니다.
일회용 이메일은 실제로 어떻게 작동하는가
"일회용 이메일"이라는 용어는 적어도 네 가지 기술적으로 구별되는 메커니즘을 포괄하는 느슨한 우산 같은 개념이며, 이들의 보안 속성은 천차만별입니다.
공개 임시 메일함(Mailinator, Temp-Mail, 10minutemail)
무작위로 생성된 주소가 공개 메일함에 도착하는 방식입니다. 누구든 그 주소만 짐작하면 메일을 읽을 수 있습니다. 뉴스레터 단발 구독이나 무료 PDF 다운로드 같은 일회성 작업에는 유용하지만, 민감한 용도에는 치명적으로 부적합합니다. 2단계 인증 코드, 지갑 복구 힌트, 거래소 확인 메일이 공개 임시 메일함으로 전송되었다가 자동 스크래퍼에 수집된 사례는 수년간 이어져 왔습니다. 메시지에 계정을 탈취하는 데 사용될 수 있는 정보가 조금이라도 포함되어 있다면, 공개 임시 메일함은 절대 사용해서는 안 됩니다.
전달 별칭(SimpleLogin, AnonAddy/addy.io, Apple Hide My Email, Firefox Relay)
이 서비스들은 여러분의 실제 받은편지함으로 전달되는 무제한의 고유 주소를 제공합니다. 별칭 제공자는 전송 중인 메시지를 보지만, 최종 목적지는 여러분이 통제합니다. 별칭은 현대적 컴파트먼트화의 주력 도구입니다. 모든 거래소, 모든 지갑 베타, 모든 에어드롭 등록마다 별도의 주소를 부여하면, 그중 하나가 침해되어도 유출은 그 한 신원에만 한정되고, 본 받은편지함을 잃지 않으면서 별칭만 폐기하면 됩니다.
자체 호스팅 캐치올 도메인
고급 사용자는 개인 도메인을 등록하고 캐치올을 설정해 아무거나@yourdomain.com 형태의 모든 주소가 하나의 메일함으로 들어오도록 만듭니다. 서비스마다 고유한 주소를 부여한다는 속성은 유지되고, 제3자 중계가 메일을 보지 않으며, 삭제도 여러분이 통제합니다. 단점은 운영 부담이며, 프라이버시 보호 없이 도메인을 등록했다면 WHOIS나 DNS 이력을 통해 도메인이 여러분과 연결될 수 있다는 점도 위험 요소입니다. 한국에서 .kr 도메인을 KISA 후이즈에 등록하는 경우, 개인 정보 비공개 옵션을 반드시 활성화하고, 가능하면 .com 같은 국제 도메인을 사용해 등록 대행사의 프라이버시 보호 서비스를 함께 적용하는 편이 더 안전합니다.
플러스 어드레싱(가짜 일회용)
Gmail 주소에 "+거래소명"을 덧붙이는 방식(예: you+upbit@gmail.com)은 일회용 기법이 아닙니다. 단지 폴더 분류 힌트일 뿐입니다. 실제 주소는 그대로이므로, "+태그" 하나만 유출되어도 전체 계정이 함께 유출됩니다. 입문자용 가이드들이 여전히 이 방법을 권장하는 경우가 있어 언급할 뿐, 사실상 보안 연극에 가깝습니다.
별칭 전달 서비스 제공자가 갑자기 사라진다면, 도메인 만료 전에 해당 별칭에 연결된 모든 서비스를 이주시켜야 합니다. 별칭 내보내기와 도메인 회전이 가능한 제공자를 선택하세요.
암호화 이메일은 실제로 어떻게 작동하는가
이메일 암호화는 크게 두 가지 형태로 구분되며, 그 차이를 이해하는 것이 이 글의 전체 핵심입니다.
전송 구간 암호화(STARTTLS / 기회적 TLS)는 서버 간 이동 중인 메일을 보호합니다. 거의 모든 주요 제공자가 지원합니다. 그러나 어느 한쪽 서버에 정지 상태로 저장된 메일은 전혀 보호하지 못하며, 서버 운영자(또는 그를 압박할 수 있는 누구라도)는 암호화를 깨지 않고도 메시지를 읽을 수 있습니다.
엔드투엔드 또는 제로 액세스 암호화는 제공자가 받은편지함을 스스로 복호화할 수 없는 형태로 저장하는 방식을 의미합니다. 키가 사용자만 아는 패스프레이즈에서 파생되거나(Proton의 수신 비-PGP 메일에 대한 제로 액세스 모델), 양쪽 사용자가 PGP 키를 직접 교환하기 때문입니다(두 PGP 사용자 간의 진정한 E2EE). 이를 진지하게 구현하는 제공자로는 Proton Mail, Tutanota(현 Tuta Mail), PGP를 지원하는 Mailbox.org, 정지 상태 암호화가 기본으로 내장된 Posteo, 그리고 틈새이지만 좋은 평가를 받는 StartMail이 있습니다.
암호화 이메일은 세 가지 실질적 속성을 제공합니다.
- 영장 저항성: 제공자에 대한 법원 명령이 평문이 아닌 암호문을 반환합니다. 이는 "제공자가 메일을 읽지 않겠다고 약속한다"는 것과는 질적으로 다릅니다.
- 침해 저항성: 제공자에서 데이터 침해가 발생해도 암호화된 블롭만 유출됩니다. 사용자별 키 없이는 그 블롭만으로는 쓸모가 없습니다.
- 메타데이터 축소(부분적): 일부 제공자는 발신 헤더에서 IP 주소를 제거하고, Tor 어니언 접속을 지원하며, 전화번호 없이 Tor를 통한 계정 생성을 허용합니다. 이는 메타데이터 흔적을 줄이지만 없애지는 못합니다. 수신자 측 제공자는 여전히 누가 누구에게 무엇을 보냈는지를 봅니다.
암호화 이메일이 제공하지 않는 것은 익명성입니다. 만약 여러분의 Proton 주소가 "myrealname.lastname.1987@proton.me"이고 이를 세 거래소에서 사용한다면, 암호화 계층은 다른 Proton 사용자와 주고받는 메시지 본문을 보호하지만, 세 거래소가 한 사람을 가리키는 고유 핸들을 공유하게 된다는 사실에 대해서는 아무것도 해 주지 않습니다. 이는 이 분야에서 가장 흔하고도 가장 값비싼 오해입니다.
나란히 비교: 각각이 정답이 되는 순간
판단 기준은 "어느 쪽이 더 프라이빗한가"가 아닙니다. 양쪽 모두 실제적인 쓸모가 있습니다. 판단 기준은 "지금 내가 강화하려는 이메일의 어떤 속성인가?"입니다.
| 사용 사례 | 일회용/별칭 | 암호화 | 최적 선택 |
|---|---|---|---|
| 비KYC 스왑 서비스 가입 | 가입을 신원 그래프에서 분리 | 암호화는 무관 — 제공자는 어차피 여러분을 봄 | 별칭(암호화 받은편지함으로 전달이 이상적) |
| 지갑 복구 코드 수신 | 공개 임시 메일함은 위험; 사설 별칭은 무난 | 이메일을 보관한다면 정지 상태 내용 보호 | 암호화(별칭은 선택) |
| 민감한 개인 서신 | 부적합 — 내용이 중계에 노출됨 | 바로 이 용도로 설계됨 | 암호화 |
| 뉴스레터 / 단발 다운로드 | 공개 임시 메일함도 허용 | 과잉 | 일회용 |
| 2FA 백업 이메일 | 절대 공개 임시 메일함 금지 | 고가치 보호 | 암호화 + 고유 별칭 |
| 내부 고발 / 기자 접촉 | 단독으로는 부족 | Tor + 어니언 + PGP 최소 | 암호화(Tor 경유) |
여러 행이 둘 다를 권장한다는 점에 주목하세요. 이는 어중간한 절충이 아닙니다. 가장 강력한 설정은 두 속성을 겹쳐 쌓는 것입니다. 즉, 제로 액세스 암호화 받은편지함으로 전달되는 고유 별칭 하나로, 단일 가입에서 신원 격리와 내용 보호를 동시에 얻습니다. 어느 한쪽만 쓰면 측면이 노출됩니다.
한국 사용자가 자주 빠지는 함정이 하나 더 있습니다. 국내 거래소가 SMS 본인 인증을 강제하므로 이메일 보호의 의미가 없다고 단정하고 손을 놓는 경우입니다. 이는 부분적으로만 옳습니다. Upbit, Bithumb 같은 거래소에서는 신원이 이미 통신사 본인 인증으로 묶여 있어 이메일 별칭으로 가릴 수 있는 것이 거의 없습니다. 그러나 그 외의 모든 표면 — 해외 비KYC 거래소, 디파이 프론트엔드, 에어드롭 등록 페이지, 텔레그램 봇, 뉴스레터, 그리고 거래소에서 보내는 알림이 흘러 들어가는 외부 알림 서비스 — 에서는 이메일이 여전히 가장 큰 상관 관계 키입니다. 거래소 한 곳에서 KYC를 완료했다고 해서 그 이메일을 30개의 외부 서비스에 그대로 재사용할 이유는 어디에도 없습니다.
단계별 가이드: Monero 스왑과 암호화폐 가입을 위한 이메일 컴파트먼트화
다음은 비KYC 거래소, 무로그 VPN, 또는 MoneroSwapper 같은 서비스를 일상적으로 사용하는 사람을 위해 권장하는 구체적 워크플로입니다. 평소 쓰던 Gmail이나 Naver 메일로 가입하는 순간 스왑의 프라이버시가 무너지는 환경에서 유효합니다.
- 암호화된 기반 받은편지함을 만드세요. Proton Mail, Tuta, 또는 Mailbox.org에 가입합니다. Tor 또는 깨끗한 VPN 세션을 통해 가입하고, 가능하면 전화번호 없이, 비밀번호 관리자로 생성한 패스프레이즈를 사용하세요. 이 받은편지함을 이메일 신원의 신뢰 루트로 다루며, 제3자에게 직접 노출시키지 마세요.
- 그 위에 별칭 서비스를 얹으세요. SimpleLogin(Proton 소유이지만 비-Proton 받은편지함의 별칭으로도 사용 가능) 또는 addy.io로 두 번의 클릭만에 새 주소를 생성할 수 있습니다. 전달 대상을 암호화된 기반 받은편지함으로 설정하세요. 이 시점 이후로 외부 서비스는 기반 주소를 결코 보지 못합니다.
- 별칭을 신뢰 등급별로 분류하세요. A등급: 장기 보유 예정 서비스 — 암호화된 내용이 중요하므로 암호화 기반으로 전달되는 고유 별칭을 부여합니다. B등급: 단발 가입, 베타 테스트, 에어드롭 — 30일 후 삭제할 일회성 별칭을 생성합니다. C등급: 신뢰할 수 없는 내용(의심스러운 다운로드, 출처 불명 뉴스레터) — Mailinator 같은 공개 임시 메일함을 쓰고 다시는 돌아보지 마세요.
- 서비스마다 항상 고유 별칭을 쓰세요. 과한 것처럼 느껴져도, 이것이 침해를 봉쇄하는 속성입니다. 2027년에 ABC 거래소가 유출될 때 노출되는 것은 "abc-exchange-7f2a@yourdomain"뿐이고, 나머지 신원 그래프는 손상되지 않습니다. 별칭 교체는 한 번의 클릭이면 끝납니다.
- 이메일 컴파트먼트화와 결제 컴파트먼트화를 짝지으세요. 새 거래소 계정을 만든다면, 신원 인증이 필요 없는 서비스로 스왑한 Monero로 충전하세요. MoneroSwapper는 그러한 옵션 중 하나로, 계정 생성 없이 스왑이 수행되기 때문에 목적지 거래소에서 사용한 이메일이 유일한 신원 표면이 됩니다. 이 흐름에서 그 이메일을 강화하는 일은 실제로 의미가 있습니다.
- 6개월마다 감사하세요. 지난 180일 동안 메일을 받은 별칭을 나열하세요. 더 이상 사용하지 않는 것은 폐기합니다. 폐쇄한 서비스의 경우 별칭을 회수하여 향후 재활성화 시도가 받은편지함 계층에서 실패하도록 만듭니다.
- 퇴로를 계획하세요. 별칭 제공자가 가격을 올리거나, 인수되거나, 갑자기 사라질 경우를 대비한 이주 시나리오가 필요합니다. 별칭 목록 내보내기를 허용하고 사용자 정의 도메인을 지원하는 제공자를 선호하세요. 그래야 모든 하위 계정을 깨뜨리지 않고 매핑을 다른 곳으로 옮길 수 있습니다.
겹겹이 쌓는 것이 왜 중요한지 보여 주는 실제 사례
지난 18개월간의 사례 세 가지가, 잘못된 도구를 쓰거나 아무 도구도 쓰지 않았을 때 실제 손실로 이어지는 모습을 보여 줍니다.
사례 A — 별칭만 사용한 실패. 체코의 한 사용자는 addy.io 별칭을 일반 Gmail로 전달하는 방식으로 완벽하게 컴파트먼트화했습니다. 2025년 11월, 한 사라진 DeFi 프로토콜을 사칭한 피싱 캠페인이 진행되었습니다. 피싱 페이로드에는 "복구 이메일을 인증하세요"라는 요청이 포함되어 있었고, 사용자는 별칭 주소가 미리 채워진 것을 보고 안심하며 클릭했습니다. 복구 이메일은 하드웨어 키 기반 2FA가 적용되지 않은 Gmail에 도착했습니다. 결과적으로 지갑은 체인이 아니라 받은편지함에서 털렸습니다. 교훈은 명확합니다. 별칭만으로는 신원 연결을 보호할 뿐 내용을 보호하지 못합니다. 기반 받은편지함도 암호화하고 하드웨어 2FA로 잠가야 합니다.
사례 B — 암호화만 사용한 실패. 한 사용자가 2년에 걸쳐 9개 거래소에 모두 같은 proton.me 주소("satoshi_nightowl"라는 닉네임 기반)로 가입했습니다. 암호화 속성은 온전했습니다. 그러나 2026년 초 한 중견 거래소에서 자격 증명 유출이 발생했고, 유출 데이터(proton.me 주소 포함)는 닉네임 간 연결 그래프를 유지하는 데이터 브로커가 매입했습니다. 몇 주 안에 같은 주소가 한 프라이버시 서브레딧의 포스팅과 Mastodon 계정과 상관 분석되었고, 사용자의 실제 신원이 도시 단위까지 좁혀졌습니다. 암호화는 메일 내용을 보호했지만 재사용에 대해서는 아무것도 하지 못했습니다.
사례 C — 계층 방어. 아르헨티나의 한 사용자는 매달 해외 송금을 위해 MoneroSwapper 스왑을 사용합니다. 각 목적지 서비스(P2P 현금 인출 중개인, 스테이블코인 오프램프, 소규모 골드바 판매상)에는 Tor를 통해서만 접근하는 Tuta 받은편지함으로 전달되는 고유 별칭이 할당됩니다. Tuta 비밀번호는 오프라인에 저장된 패스프레이즈 생성기에서 만든 64자입니다. 2026년 2월에 골드바 판매상이 침해되었을 때, 유출 기록은 일회성 별칭과 무관한 배송용 가명뿐이었습니다. 어떠한 상관 관계 분석도 가능하지 않았습니다. 이 방어의 비용은 월 약 15분의 시간과 별칭 요금 4유로에 불과했습니다.
FAQ
그냥 Proton Mail의 "hide my email" 기능을 쓰고 별도의 별칭 서비스는 건너뛸 수 있나요?
네 — Proton의 SimpleLogin 통합은 2026년에 가장 깔끔한 통합 설정 중 하나이며, 두 계정을 운영해야 하는 부담을 없애 줍니다. 단점은 집중입니다. 한 제공자가 기반 받은편지함, 별칭, (Proton VPN과 Proton Drive까지 사용한다면) 훨씬 더 많은 것을 보유하게 됩니다. 대부분의 사용자에게는 이 위험이 수용 가능한 수준입니다. 제공자의 위협 모델이 잘 정렬되어 있기 때문입니다. 그러나 위험 부담이 큰 사용자라면 단일 지점 침해를 피하기 위해 별칭 계층과 저장 계층을 두 제공자로 분리해야 합니다.
공개 임시 이메일이 암호화폐 용도로 안전한 경우가 있나요?
메시지가 계정에 대한 어떠한 조치도 취할 수 없을 때만 안전합니다. 연구 사이트의 무료 데모 확인 링크 정도는 괜찮습니다. 비밀번호 재설정, 2FA 백업 코드, KYC 인접 인증은 안전하지 않습니다. 그런 메시지는 여러분이 통제하는 받은편지함에 도착해야 합니다. 공개 임시 메일함은 현관 매트처럼 다루세요. 해가 없는 배달에는 유용하지만, 잃어서는 안 되는 것에는 절대 사용하지 마세요.
암호화 이메일을 Tor로 사용해도 다음 날 집 Wi-Fi에서 로그인하면 의미가 있을까요?
두 세션은 행동 지문, 브라우저 저장 쿠키, 제공자의 IP 로그(보유한다면)를 통해 연결될 수 있습니다. 한 번의 Tor 세션 다음에 열 번의 일반 회선 세션이 이어지면 익명성 이점은 거의 없고, 오히려 계정의 위험 프로필을 높일 수도 있습니다. Tor로 계정을 생성했다면 계속 Tor를 일관되게 사용하거나, 계정이 익명이 아닌 가명 수준이라는 점을 받아들여야 합니다.
전화번호는 어떤가요 — 이 모든 것을 무효화하나요?
실제 신원에 연결된 전화번호는 이메일보다 더 강력한 상관 관계 키 역할을 합니다. 한국에서는 SKT, KT, LG U+ 통신사 통합 본인 인증 시스템과 알뜰폰 가입 시의 신용 정보 조회가 신원을 곧바로 묶기 때문에 이 문제가 특히 심각합니다. 서비스가 SMS 인증을 요구하면, 그 서비스에 대한 이메일 별칭 보호 효과는 대부분 무력화됩니다. VoIP 번호(JMP.chat, MySudo, 일부 선불 eSIM 서비스)가 도움이 되지만 각각 주의 사항이 있습니다. 가능한 한 SMS보다 TOTP나 하드웨어 키를 받아들이는 서비스를 선호하고, SMS가 필요한 가입은 비익명화가 치명적이지 않은 계정에만 한정하세요.
서류 없이 소액의 비트코인을 Monero로 스왑하려는 사람에게 "정답" 조합이 있을까요?
소액, 비정기 스왑이라면 답은 거의 자명합니다. 처음부터 계정이 필요 없는 MoneroSwapper 같은 서비스를 사용하고, 지갑에서 목적지용 Monero 서브주소 하나를 생성하고, 거래에 묶이는 받은편지함을 아예 만들지 마세요. 이메일 문제는 지속적인 통신이 필요한 계정(거래소, 브리지, 커스터디 지갑)에 가입할 때만 심각해집니다. 스왑 자체가 계정 없이 유지될 수 있다면, 받은편지함 문제는 애초에 발생하지 않습니다.
국내 거래소를 위주로 사용하는데 별칭과 암호화가 의미가 있나요?
국내 거래소 자체에는 효과가 제한적입니다. 통신사 본인 인증으로 이미 실명이 묶여 있기 때문입니다. 그러나 거래소가 보내는 보안 알림, 입출금 영수증, 세금 신고용 거래 내역서 등은 모두 받은편지함에 영구적으로 쌓입니다. 이 받은편지함이 평문으로 저장된 Naver 메일이고 비밀번호가 다른 사이트와 같다면, 거래소를 직접 공격하는 대신 이메일을 노리는 것이 공격자에게 더 쉽고 더 수익성 있는 경로가 됩니다. 암호화 받은편지함과 고유 별칭은 그 측면을 메우기 위한 것이지, 거래소의 KYC를 우회하기 위한 것이 아닙니다.
결론
가장 깔끔한 사고 모델은 "어느 이메일이 더 프라이빗한가"라는 질문을 멈추고 "내 받은편지함의 어떤 속성을 강화하려 하며, 그 반대편에 어떤 위협이 있는가"라는 질문으로 옮기는 것입니다. 일회용 주소와 별칭은 단일 침해가 다른 계정들과 결합될 수 있는 표면적을 줄입니다. 암호화 받은편지함은 서버에 정지 상태로 놓인 내용이 다른 누군가의 사건에서 증거가 될 표면적을 줄입니다. 둘은 서로를 보완할 뿐 대체하지 않습니다. 가장 강력한 설정은 두 가지를 모두 사용합니다. 서비스마다 고유 별칭을 두고, 제로 액세스 암호화 기반 받은편지함으로 전달하며, 가장 위험 부담이 큰 계정은 별도의 서브도메인이나 대체 제공자로 추가 격리하는 것입니다.
MoneroSwapper로 비트코인을 Monero로 스왑하려는데 목적지 서비스가 받은편지함을 요구한다면, 스왑을 마무리하기 전에 10분만 더 들이세요. 새 별칭을 만들고, 여러분이 통제하는 암호화 기반 받은편지함으로 연결하고, SMS 인증 경로는 가능한 한 우회하세요. 스왑은 거래를 보호합니다. 받은편지함은 그 주변에서 벌어지는 모든 일을 보호합니다. 둘을 두 개가 아닌 하나의 워크플로로 다루면, 여러분이 사려고 했던 프라이버시가 틈새로 새어 나가는 일을 멈출 수 있습니다.