# 이메일 주소 심층 분석

> Clean Markdown view of GeekNews topic #29144. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=29144](https://news.hada.io/topic?id=29144)
- GeekNews Markdown: [https://news.hada.io/topic/29144.md](https://news.hada.io/topic/29144.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-05-04T10:41:02+09:00
- Updated: 2026-05-04T10:41:02+09:00
- Original source: [lasans.blog](https://lasans.blog/articles/misc/email-addresses-deep-dive/)
- Points: 6
- Comments: 0

## Topic Body

- 이메일 주소는 단순한 사용자명과 도메인의 조합이 아니라, **RFC 표준에 정의된 복잡한 구조와 규칙, 보안 함정**을 포함하는 체계  
- 로컬 파트(@ 앞)에는 따옴표 형식, 주석, 유니코드 등 일반적으로 알려지지 않은 **다양한 유효 형식**이 존재하며, 대부분의 실무 환경에서는 지원되지 않음  
- 모든 이메일에는 **Envelope Sender와 From 헤더라는 두 개의 발신자 주소**가 존재하며, 이 차이가 스푸핑과 피싱의 근본 원인  
- Gmail의 **점(dot) 무시 정책**, 플러스 주소 지정, 도메인 별칭 등 제공자별 고유 동작이 보안 및 유효성 검사에 직접적 영향  
- 이메일 주소를 수집하거나 검증하는 시스템을 구축할 때, RFC 표준과 실제 동작 간의 **간극을 정확히 이해하는 것이 필수적**  
  
---  
  
### 기본 구조  
- 이메일 주소는 **로컬 파트**(@ 앞), **@ 구분자**, **도메인**(@ 뒤)의 세 부분으로 구성  
- 겉보기에 단순하지만, 각 부분에는 보안·프라이버시·유효성 검사에 영향을 미치는 규칙과 엣지 케이스가 존재  
  
### 로컬 파트 (Local Part)  
- ## 허용 문자  
  - 표준 비따옴표 형식(**dot-atom**)에서 허용되는 문자: 영문자 `a-z`, `A-Z`, 숫자 `0-9`, 특수문자 `. _ - + ! # $ % & ' * / = ? ^ { | } ~`  
  - 최대 길이는 **64 옥텟**(octet)이며, 표준 ASCII에서는 64자와 동일하지만 유니코드 로컬 파트에서는 차이 발생  
    - 옥텟은 정확히 8비트 그룹을 의미하며, 네트워킹(IPv4)에서 0~255 범위를 표현하는 데 사용  
    - 64 옥텟은 512비트 길이의 데이터 블록에 해당  
- ## 대소문자 구분  
  - RFC 5321에 따르면 로컬 파트는 기술적으로 **대소문자를 구분**하며, `User@example.com`과 `user@example.com`은 별도의 메일박스가 될 수 있음  
  - 실제로는 모든 주요 이메일 제공자가 대소문자를 구분하지 않으므로, 저장·비교 전 **소문자로 정규화하는 것이 안전한 기본값**  
  - 도메인 파트는 항상 대소문자를 구분하지 않음  
- ## 점(Dot) 주소 지정  
  - 점은 로컬 파트에 허용되지만 세 가지 제한 존재: 점으로 시작 불가, 점으로 끝 불가, **연속 점 불가**  
  - **Gmail의 점 정규화**: Gmail은 로컬 파트에서 점을 완전히 무시하므로, `johndoe@gmail.com`, `john.doe@gmail.com`, `j.o.h.n.d.o.e@gmail.com`이 모두 동일 수신함으로 전달  
    - RFC 표준이 아닌 Gmail 고유 동작  
    - 공격자가 점 변형 주소로 별도 계정을 생성해 **단일 계정 제한 우회**나 무료 체험 중복 획득에 악용 가능한 실제 공격 벡터  
- ## 서브어드레싱 (플러스 주소 지정)  
  - 구분자를 사용해 로컬 파트에 태그를 추가할 수 있으며, 메일 서버는 기본 주소로 전달하면서 태그를 유지 (**RFC 5233** 표준)  
  - 가장 일반적인 구분자는 `+`이며, Gmail, Outlook, ProtonMail, Fastmail 등에서 지원  
    - Yahoo 일부 구성과 특정 Postfix 설정에서는 `-` 사용  
    - qmail에서는 `=`이 기본 구분자이며, 이것이 **VERP**에서 `@`를 `=`로 인코딩하는 이유  
  - 주요 활용 사례:  
    - **유출 추적**: 서비스별 고유 태그(예: `yourname+servicename@gmail.com`)로 가입해 스팸 수신 시 유출 출처 파악  
    - **수신함 필터링**: 메일 규칙으로 특정 태그 주소의 메일을 자동 분류  
    - **다중 계정**: 플러스를 정규화하지 않는 서비스에서 하나의 이메일로 별도 계정 생성 가능  
  - 많은 웹사이트의 이메일 유효성 검사기가 `+`를 거부하지만, 이는 **검증 코드의 버그**이지 이메일의 제한이 아님  
- ## 따옴표 문자열 형식 (Quoted String Form)  
  - 로컬 파트를 큰따옴표로 감싸면 대부분의 문자 제한이 완화되어, 공백, `@`, 연속 점, 선행·후행 점 등이 허용  
  - 예: `"john doe"@example.com`, `"user@name"@example.com`, `" "@example.com`  
  - 실제로 거의 모든 이메일 제공자가 따옴표 로컬 파트를 수락하지 않으므로, **RFC상 유효하지만 실무에서는 무용**  
- ## 주석 (Comments)  
  - 괄호 안의 주석이 로컬 파트 시작이나 끝에 올 수 있으며, 메일 서버가 제거하고 전달에 영향 없음  
  - RFC 5322에 따라 기술적으로 유효하지만 현대에서는 사용되지 않음  
  - 괄호를 거부하는 유효성 검사기는 **RFC보다 더 엄격한 것**  
- ## 유니코드 로컬 파트 (EAI)  
  - RFC 6530, 6531, 6532에서 정의한 **이메일 주소 국제화**(EAI)로 로컬 파트에 UTF-8 문자 허용  
  - SMTP 세션에서 `SMTPUTF8` 확장을 사용해야 하며, 송·수신 서버 모두 지원 필요  
  - 2026년 기준 채택이 제한적이며, 유니코드 문자는 2~4 옥텟을 사용하므로 **시각적 글자 수보다 적게도 64 옥텟 제한에 도달** 가능  
- ## 역사적 형식  
  - **Bang path (UUCP)**: DNS 이전에 모뎀으로 연결된 Unix 머신 네트워크에서 `!`로 구분된 호스트명 경로(`machine1!machine2!user`)를 사용한 라우팅 방식으로, 허용 문자 목록에 `!`가 포함된 이유. 현재 완전히 사용 중단  
  - **퍼센트 핵(Percent hack)**: `user%otherdomain@relay.com` 형태의 릴레이 라우팅 트릭으로, `%` 문자는 라우팅 메커니즘이 RFC 5321에서 폐기된 후에도 로컬 파트에서 여전히 유효  
  - **소스 라우팅(Source routing)**: SMTP RCPT TO 명령에서 명시적 릴레이 홉 목록(`@relay1,@relay2:user@domain`). RFC 5321에서 폐기  
- ## VERP (Variable Envelope Return Path)  
  - 대량 메일 시스템에서 바운스를 발생시킨 **정확한 수신자를 추적**하기 위한 기술  
  - 수신자 주소를 봉투 발신자(MAIL FROM)에 인코딩하며, 수신자 주소의 `@`를 `=`로 대체  
    - 예: `bounces+alice=gmail.com@newsletter.com`  
  - Mailchimp, SendGrid, Amazon SES 등이 대규모 바운스 처리에 VERP 또는 변형 사용  
- ## SRS (Sender Rewriting Scheme)  
  - 서버가 메일을 전달하면서 **SPF 검사를 통과시키기 위해 봉투 발신자를 재작성**할 때 나타나는 주소 형식  
  - `SRS0=HASH=TT=originaldomain.com=originaluser@forwardingdomain.com` 형태  
  - 다중 홉 전달 시 `SRS1=HASH=encodedSRS0@forwardingdomain.com` 형태  
  - 구조적으로 유효한 이메일 주소이지만 **인프라 산출물**이며 사람이 사용하는 주소가 아님  
  - HASH 구성 요소는 타임스탬프와 원본 주소에 대한 HMAC으로, 위조 방지 및 토큰 유효 기간 제한 역할  
  
### 도메인 파트 (Domain Part)  
- ## 레이블 규칙  
  - 도메인은 점으로 구분된 레이블로 구성되며, 각 레이블에는 영문자 `a-z`, 숫자 `0-9`, 하이픈 `-` 허용  
  - 하이픈으로 시작하거나 끝날 수 없으며, 3~4번째 위치에 연속 하이픈 불가(단, `xn--`로 시작하는 **Punycode 레이블**은 예외)  
  - 레이블 최대 **63자**, 도메인 전체 최대 **253자**, 전체 이메일 주소(addr-spec) 최대 **254자**  
- ## 서브도메인  
  - 도메인은 여러 레벨을 가질 수 있으며, 253자 총 도메인 길이 외에 서브도메인 깊이에 대한 하드 제한 없음  
  - 일반적 사용: 메일 인프라(`mail.`, `smtp.`, `mx.`), 조직 분리(`sales.company.com`), ESP 발송(`email.company.com`)  
- ## IP 주소 리터럴  
  - 도메인명 대신 대괄호 안의 IP 주소 사용 가능: `user@[192.168.1.1]`, `user@[IPv6:2001:db8::1]`  
  - RFC 5321에 따라 유효하지만 공개 메일 서버에서는 거의 수락되지 않으며, **내부 메일 시스템과 SMTP 테스트**에 사용  
- ## 단일 레이블 도메인  
  - 점이 없는 도메인(예: `user@localhost`)은 일부 컨텍스트에서 기술적으로 유효하지만, 공개 메일 서버는 거부  
  - `postmaster@localhost`는 Unix 계열 시스템에서 **로컬 시스템 메일의 관례적 특수 케이스**  
- ## 국제화 도메인명 (IDN)과 Punycode  
  - DNS는 ASCII 전용이므로, 비ASCII 문자는 **Punycode**(RFC 3492)로 인코딩되며 모든 인코딩 레이블은 `xn--` 접두사로 시작  
  - 이메일 클라이언트는 네이티브 스크립트로 표시하고 SMTP는 Punycode 형태로 전송  
  - **호모그래프 공격**: 다른 유니코드 스크립트의 시각적으로 동일한 문자로 잘 알려진 도메인과 유사한 도메인 등록 가능. 브라우저는 의심스러운 IDN에 대해 Punycode를 표시하는 방어 기능이 있지만, **이메일 클라이언트에는 대부분 이런 방어가 없어** 이메일에서 더 효과적인 공격  
- ## 후행 점 (Trailing Dot)  
  - DNS에서 모든 도메인은 기술적으로 루트 존을 나타내는 후행 점으로 끝나지만, 이메일에서는 항상 암시적이며 생략  
  - 대부분의 유효성 검사기가 `user@example.com.` 형태를 거부  
- ## MX 레코드  
  - 이메일 주소의 도메인이 반드시 메일 서버가 있는 곳은 아니며, 발신 서버는 **MX(Mail Exchanger) DNS 레코드**를 조회해 실제 메일 서버 호스트명 확인  
  - 낮은 우선순위 번호가 높은 우선순위를 의미하며, MX 레코드가 전혀 없으면 도메인의 **A 레코드로 폴백**  
  - 도메인이 절대 이메일을 수신해서는 안 되는 경우, **null MX 레코드**(`MX 0 .`)를 게시해 발신 서버에 전달을 시도하지 말 것을 명시적으로 알림 (RFC 7505)  
  
### 최상위 도메인 (TLD)  
- ## 원래의 일반 TLD  
  - 초기 인터넷의 7개 gTLD: `.com`(상업, 현재 비제한, Verisign 운영), `.net`(네트워크, 비제한), `.org`(조직, 비제한), `.edu`(미국 공인 교육기관, 제한), `.gov`(미국 정부, 제한), `.mil`(미군, 제한), `.int`(조약 기반 국제기구, 매우 제한적)  
  - `.arpa`는 IANA가 관리하는 **인프라 TLD**로, 역방향 DNS 조회에서 사용  
- ## 국가 코드 TLD (ccTLD)  
  - ISO 3166-1 alpha-2 국가 코드 기반 2글자 코드로, 약 250개 존재  
  - 일부 ccTLD는 다른 산업에 의해 용도가 전환:  
    - `.io`(영국령 인도양 지역 → 테크 기업), `.tv`(투발루 → 미디어·스트리밍), `.ai`(앵귈라 → AI 기업), `.co`(콜롬비아 → `.com` 대안), `.me`(몬테네그로 → 개인 사이트), `.ly`(리비아 → URL 단축), `.sh`(세인트헬레나 → 소프트웨어 프로젝트)  
  - 용도 전환된 ccTLD를 사용하면 기술적으로 **해당 국가의 레지스트리 관할** 하에 있게 되며, ICANN이 아닌 원래 국가의 레지스트리가 도메인을 통제  
- ## 후원 TLD (sTLD)  
  - 후원 조직과 자격 요건이 있는 TLD: `.aero`(항공운송, SITA 후원), `.coop`(협동조합), `.museum`(박물관), `.jobs`(고용), `.xxx`(성인), `.post`(우편), `.cat`(카탈로니아어·문화)  
- ## 신규 일반 TLD (2012년 이후)  
  - 2012년 ICANN이 신규 gTLD 신청을 개방해 **1,200개 이상**의 새 TLD가 위임  
  - 이메일 유효성 검사에 중요한 영향: TLD 길이를 4~6자로 제한하는 **유효성 검사기는 깨짐** (`.photography`, `.international`, `.construction` 등)  
  - 개발자 관련: `.app`, `.dev`, `.web`, `.code` / 상업: `.shop`, `.store`, `.online` / 콘텐츠: `.blog`, `.news`, `.media` / 비즈니스: `.tech`, `.agency`, `.cloud`  
  - 신규 gTLD는 낮은 등록 비용과 일부 레지스트리의 약한 악용 정책으로 인해 **스팸과 피싱에 과도하게 대표**됨  
- ## 브랜드 TLD  
  - 2012년 ICANN 확장 시 대기업들이 자체 TLD 신청: `.google`, `.youtube`, `.gmail`, `.apple`, `.microsoft`, `.amazon`, `.chase`, `.barclays`, `.bmw`  
  - 대부분 공개 이메일 주소로 사용되지 않으며, 주로 **내부 목적**이거나 아예 미사용  
- ## 지리·도시 TLD  
  - 도시와 지역 자체 TLD: `.nyc`, `.london`, `.paris`, `.berlin`, `.tokyo`, `.sydney`, `.wales`, `.scot`  
  - 등록 시 보통 해당 지역과의 **연관성 입증 필요**  
- ## 국제화 TLD  
  - 비ASCII 스크립트의 TLD가 다수 국가에 존재하며, DNS에서는 Punycode로 인코딩  
    - `.xn--p1ai`(러시아, 키릴 문자), `.xn--fiqz9s`(중국, 간체자), `.xn--mgberp4a5d4ar`(사우디아라비아, 아랍 문자), `.xn--h2brj9c`(인도, 데바나가리 문자)  
- ## 예약·문서화 TLD  
  - RFC 2606, RFC 6761에서 테스트 및 문서화를 위해 예약한 TLD:  
    - `.test`(공개 DNS에 절대 존재하지 않아 소프트웨어 테스트에 안전), `.example`(문서 예시용), `.invalid`(확실히 해석되지 않는 도메인 필요 시), `.localhost`(루프백용)  
  - IANA가 문서와 예시용으로 **`example.com`**, **`example.net`**, **`example.org`** 을 등록해 두어, 실제 메일박스에 도달할 걱정 없이 코드 예시에 자유롭게 사용 가능  
- ## 폐기된 TLD  
  - 국가 소멸로 제거된 ccTLD: `.yu`(유고슬라비아, 2010년 삭제), `.cs`(체코슬로바키아, 1995년 삭제), `.dd`(동독, 1990년 삭제), `.tp`(동티모르, `.tl`로 대체 후 2015년 완전 삭제)  
  - 예외: **`.su`(소련)** 는 1991년 해체에도 불구하고 여전히 활성 도메인이 존재하며, IANA가 수년간 전환 논의 중이지만 활성 상태 유지  
  
### ccTLD의 2차 도메인  
- 많은 ccTLD가 등록 가능한 이름과 TLD 사이에 기능적 2차 레벨 카테고리를 추가  
  - 영국: `.co.uk`, `.org.uk`, `.gov.uk` / 호주: `.com.au`, `.edu.au` / 일본: `.co.jp`, `.ac.jp` / 인도: `.co.in`, `.gov.in` / 브라질: `.com.br`, `.gov.br`  
- 이메일 인증 시스템에서 **조직 도메인을 찾아야 하는 경우** 유효성 검사와 조직 도메인 감지에 영향  
- ## Public Suffix List (PSL)  
  - `publicsuffix.org`에서 커뮤니티가 관리하는 목록으로, 인터넷 사용자가 직접 이름을 등록할 수 있는 모든 **도메인 접미사**를 수록  
  - 공식 위임(`.co.uk`, `.com.au`)과 사설 레지스트리(`github.io`, `wordpress.com`, `herokuapp.com`) 모두 포함  
  - 와일드카드 표기법 사용(예: `*.ck`), 예외는 `!`로 표시(예: `!www.ck`)  
  - 이메일 유효성 검사기와 스팸 필터가 전체 도메인 문자열에서 **조직 도메인을 식별**하는 데 사용  
  - IETF 표준은 아니지만 이 문제에 대한 **사실상의 표준**(de facto standard)  
  
### 이메일 주소 포맷 형식  
- ## 기본 주소 (Bare Address)  
  - `local@domain` 형태의 **addr-spec**으로, SMTP 명령과 단순 컨텍스트에서 사용  
- ## 앵글 브래킷 형식  
  - SMTP에서 MAIL FROM과 RCPT TO 명령에 **꺾쇠괄호로 주소를 감쌈**: `MAIL FROM:<sender@example.com>`  
  - 꺾쇠괄호는 SMTP 명령 구문의 일부이지 주소 자체의 일부가 아님  
- ## 표시 이름 형식 (Display Name Format)  
  - 메시지 헤더(From, To, Cc)에서 사람이 읽을 수 있는 이름이 꺾쇠괄호 주소 앞에 올 수 있음: `"John Doe" <john@example.com>`  
  - 표시 이름에 특수문자가 포함되면 따옴표 필수  
  - **표시 이름 스푸핑**: 발신자가 표시 이름을 원하는 대로 설정할 수 있어, `"PayPal Security <paypal@paypal.com>" <attacker@evil.com>` 형태의 공격이 가능  
    - 많은 이메일 클라이언트가 수신함 목록에서 표시 이름만 보여주므로 **가장 일반적인 피싱 기법** 중 하나  
- ## 그룹 구문 (Group Syntax)  
  - RFC 5322에서 정의한 복수 수신자를 위한 명명된 그룹 형식: `Marketing Team: alice@example.com, "Bob Smith" <bob@example.com>;`  
  - **비공개 수신자 패턴**: `To: undisclosed-recipients:;` — 빈 그룹 구문으로, 실제 수신자는 SMTP 봉투(RCPT TO)에 있고 메시지 헤더에는 보이지 않음  
- ## 인코딩된 표시 이름  
  - 이전 이메일 시스템에서 표시 이름의 비ASCII 문자를 RFC 2047 인코딩 단어로 처리: `=?charset?encoding?encoded_text?=`  
  - 인코딩은 `B`(base64) 또는 `Q`(quoted-printable)  
  - 현대 **SMTPUTF8** 지원 시 이 인코딩 래퍼 없이 헤더에서 직접 UTF-8 사용 가능  
  
### 모든 이메일의 두 발신자  
- ## 봉투 발신자 (Envelope Sender / MAIL FROM)  
  - SMTP `MAIL FROM:` 명령에서 설정되며, 메시지 내용 자체의 일부가 아님  
  - **바운스 라우팅**에 사용되고, SPF 검사 시 검증 대상이며, 최종 수신 서버가 `Return-Path:` 헤더로 저장  
  - 봉투 발신자(envelope from), 역경로(reverse path), RFC5321.MailFrom으로도 불림  
- ## From 헤더  
  - 메시지의 `From:` 헤더에 있는 주소로, 이메일 클라이언트가 **발신자로 표시하는 것**  
  - DMARC이 SPF 또는 DKIM 정렬과 함께 보호하는 대상  
  - 발신자가 자유롭게 설정할 수 있으며 대부분의 메일 서버에서 **고유한 검증 없음**  
  - **이 두 주소는 완전히 다를 수 있으며**, 이는 정상적이고 예상되는 시나리오:  
    - ESP 대량 발송 시 MAIL FROM은 `bounce@esp.com`, From 헤더는 `newsletter@yourbrand.com`  
    - 메일링 리스트에서 MAIL FROM은 목록의 바운스 주소, From 헤더는 원래 게시자  
    - 이메일 전달 시 전달 서버가 SRS로 MAIL FROM을 재작성하되 From 헤더는 원래 발신자 유지  
  - 도메인에 DMARC 적용이 없으면, 누구든 **완전히 관련 없는 MAIL FROM을 사용하면서 해당 도메인을 From 헤더에 넣어** 발송 가능  
- ## Sender 헤더  
  - 메시지의 실제 제출자가 From 주소와 다를 때 실제 발송자를 식별: `Sender: mailer@sendgrid.net`  
- ## Reply-To 헤더  
  - 답장이 가야 할 곳을 지정하며 From 주소와 다를 수 있음  
  - 피싱 벡터로도 악용: 공격자가 From을 합법적으로 보이게 설정하고 **Reply-To를 자신의 주소**로 설정  
- ## Null Sender  
  - `MAIL FROM:<>`는 유효하고 중요한 SMTP 구조로, 빈 봉투 발신자는 바운스 메시지, 자동 응답, 자체적으로 바운스를 생성해서는 안 되는 메시지에 사용  
  - 두 시스템이 실패 알림을 계속 교환하는 **무한 바운스 루프 방지**  
  
### 역할 기반 주소 (Role-Based Addresses)  
- ## RFC 5321 필수  
  - **`postmaster@domain`**: RFC 5321에 따라 메일을 수락하는 모든 도메인에서 이 주소의 메일 수락이 **의무**, 예외 없음  
- ## RFC 2142 권장  
  - `abuse@domain`(스팸·악용 신고), `hostmaster@domain`(DNS 존 관리), `security@domain`(취약점 공개·보안 보고), `webmaster@domain`(웹 서버 문제), `noc@domain`(네트워크 운영)  
- ## 관례적 역할 주소  
  - `info@`, `support@`, `sales@`, `billing@`, `legal@`, `privacy@`, `careers@`, `contact@`, `hello@`, `help@`, `feedback@`, `admin@` 등 공식 표준은 아니지만 널리 사용  
  - 역할 주소는 보통 **여러 사람이 공유**하므로, 민감 정보 전송 시 다수의 팀원이 열람 가능  
  - `abuse@`와 `postmaster@`는 불만 메일을 수신하므로 **소셜 엔지니어링의 대상**  
- # 캐치올 주소 (Catch-All Addresses)  
  - 특정 이메일 주소 형식이 아닌 **메일 서버 구성**으로, 특정 메일박스가 없는 로컬 파트에 대해서도 전달을 수락  
  - 활용 사례: 오타 포착, 개발자 테스트, 정식 별칭 시스템 없이 서비스별 고유 주소 생성  
  - 단점: 어떤 로컬 파트든 전달되므로 **대량 스팸 유입**, SMTP 프로빙을 통한 주소 유효성 검사가 불가능(모든 프로브에 성공 응답 반환)  
  
### 제공자별 고유 동작  
- ## Gmail  
  - **점 정규화**: 로컬 파트의 모든 점 무시  
  - **플러스 주소 지정**: `+` 구분자 지원  
  - **`@googlemail.com`**: 독일·영국에서의 **상표 분쟁**으로 인한 `@gmail.com`의 역사적 별칭으로, 두 도메인 모두 동일 수신함 전달  
  - **문자 제한**: 로컬 파트에 영문자, 숫자, 점만 허용(플러스 주소 지정용 `+` 포함). 전체 RFC 문자 세트 미지원  
  - **로컬 파트 길이 제한**: RFC 최대 64자보다 훨씬 낮은 **30자**  
- ## Microsoft (Outlook, Hotmail, Live)  
  - **점 정규화 없음**: `johndoe@outlook.com`과 `john.doe@outlook.com`은 **별도의 메일박스**  
  - **도메인 별칭**: `@hotmail.com`, `@live.com`, `@outlook.com`이 별칭 구성 시 동일 계정 참조 가능  
  - **플러스 주소 지정** 지원  
- ## Apple (iCloud)  
  - **도메인 별칭**: `@icloud.com`, `@me.com`, `@mac.com`이 동일 수신함 (.mac → .me → .icloud로 **서비스명 변경 이력**)  
  - **플러스 주소 지정** 지원  
  - **Hide My Email**: `randomstring@privaterelay.appleid.com` 형태의 **무작위 별칭 생성**, 각 서비스나 앱별 고유 별칭으로 실제 주소 비공개 유지  
- ## ProtonMail / Proton  
  - **도메인 별칭**: `@proton.me`, `@protonmail.com`, `@pm.me`가 동일 수신함  
  - **플러스 주소 지정** 지원  
- ## 이메일 별칭 서비스  
  - 일회용 이메일과 별개로, 영구적이고 제어 가능한 **전달 주소를 생성하는 서비스**:  
    - **SimpleLogin**(Proton 소속): 커스텀·랜덤 별칭으로 모든 수신함에 전달  
    - **Addy.io**(구 AnonAddy): SimpleLogin과 유사, 셀프 호스팅 가능  
    - **Firefox Relay**(Mozilla): 무료 플랜에서 제한된 랜덤 별칭  
    - **DuckDuckGo Email Protection**: `@duck.com` 별칭  
  - 발신자에게는 실제 수신함과 **구조적으로 구별 불가능한 주소** 생성  
  - 일회용 이메일과의 핵심 차이: 별칭은 영구적이며 제어 가능, 특정 별칭 비활성화·서비스별 발송 확인·원하는 수신함으로 전달 가능  
  
### 일회용·임시 이메일  
- 가입 불필요하고 보통 짧은 기간 후 만료되는 수신함을 제공하며, Mailinator, Guerrilla Mail, 10 Minute Mail, TempMail 등이 대표적  
- 대부분 **캐치올 라우팅**을 사용하므로 해당 도메인의 어떤 로컬 파트든 수신함에 전달  
- 많은 수신함이 **공개적**이어서 주소를 아는 누구든 메시지 열람 가능  
- 알려진 일회용 도메인의 차단 목록(`disposable-email-domains` GitHub 저장소가 가장 많이 참조됨)이 존재하지만 항상 불완전하며, 차단을 회피하기 위해 **지속적으로 새 도메인으로 교체**  
  
### 유효성 검사 (Validation)  
- ## 기술적 유효성 vs 실무적 유효성  
  - RFC상 유효하지만 실제 서버에서 거의 수락되지 않는 것: 따옴표 안의 공백(`" "@example.com`), 따옴표 안의 @(`"user@name"@example.com`), IP 리터럴 도메인(`user@[192.168.1.1]`), 단일 문자/단일 레이블(`a@b`)  
  - RFC상 유효하고 실무에서도 수락되는 것: `user+tag@example.com`, `user_name@example.com`, `user@subdomain.example.co.uk`, `user@example.photography`  
  - 대부분의 애플리케이션에서 **실용적 유효성 검사기가 완전한 RFC 준수 검사기보다 우수**: 기본 구조 확인, 합리적 문자 세트 검증, 선택적으로 도메인의 DNS MX 조회 수행  
- ## 일반적 유효성 검사기 버그  
  - **로컬 파트에서 `+` 거부**: `user+tag@example.com`은 완전히 유효하며, 매우 흔한 버그  
  - **로컬 파트에서 `_` 거부**: 역시 유효  
  - **로컬 파트에서 `%` 거부**: 유효한 문자이며, 폐기된 것은 퍼센트 핵 라우팅 사용뿐  
  - **TLD 길이를 4~6자로 제한**: `.photography`, `.international`, `.construction` 등 수백 개의 **신규 gTLD를 차단**  
  - **하드코딩된 TLD 목록으로 검증**: 목록이 지속적으로 변경되므로 검사기가 노후화  
  - **잘못된 총 길이 제한**: 254 대신 255 또는 256 사용. RFC 3696 정오표 번호 1690에서 널리 인용되던 잘못된 값 320을 **254로 수정**  
  - **로컬 파트에서 대문자 거부**: RFC상 유효  
  - **`user@subdomain.co.uk` 거부**: 유효하며, 2차 ccTLD 패턴의 다중 점 도메인은 정상  
  - **`.dev`, `.app`, `.io`를 TLD로 거부**: 모두 유효한 위임된 TLD  
- ## 길이 제한  
  
  | 파트 | 제한 |  
  |---|---|  
  | 로컬 파트 | 64 옥텟 |  
  | 도메인 레이블 | 63 옥텟 |  
  | 도메인 전체 | 253 옥텟 |  
  | 전체 주소(addr-spec) | 254 옥텟 |  
  
- 로컬 파트 제한은 문자가 아닌 **옥텟 단위**이므로, 멀티바이트 유니코드 문자를 가진 EAI 주소는 시각적으로 64자 미만이면서도 옥텟 제한에 도달 가능  
- ## DNS 기반 유효성 검사  
  - **MX 레코드 확인**: 도메인에 MX 레코드가 있는지 검증하며, 빠르고 저위험. A 레코드 폴백을 사용하는 도메인(MX 미구성)은 이 검사 실패 가능  
  - **Null MX 확인**: 도메인에 `MX 0 .`이 있으면 메일을 **명시적으로 수신하지 않음**  
  - **SMTP RCPT TO 프로빙**: 메일 서버에 연결해 RCPT TO 명령을 발행하여 주소 수락 여부 확인하지만, 많은 서버가 주소 수확을 방지하기 위해 모든 주소에 250 응답을 반환하므로 **신뢰할 수 없음**. 캐치올 도메인은 항상 긍정적 응답. 프로브 IP가 블랙리스트에 추가될 위험도 존재  
  - 이메일 주소를 완전히 신뢰성 있게 검증하는 유일한 방법은 **실제 메시지를 보내 도착 여부를 확인하는 것**이며, 나머지는 모두 휴리스틱  
  
### 보안 함의  
- ## 표시 이름 스푸핑  
  - 누구든 이메일의 표시 이름을 원하는 대로 설정 가능하며, 표시 이름만 보여주는 수신함 뷰에서 사용자는 실제 주소를 명시적으로 확인하지 않으면 합법적 발신자와 **사칭을 구별 불가**  
- ## Punycode를 통한 호모그래프 공격  
  - 다른 유니코드 스크립트의 문자를 사용해 실제 잘 알려진 도메인과 **시각적으로 동일한 도메인** 등록 가능  
  - 이메일 클라이언트는 브라우저와 달리 일반적으로 이에 대한 **경고를 표시하지 않음**  
- ## Gmail 점 트릭을 통한 계정 우회  
  - Gmail이 점을 무시하므로, 공격자가 기존 Gmail 주소의 점 변형으로 서비스에 가입해 **단일 계정 제한 우회**, 무료 체험 중복 획득, 원래 계정 소유자에게 의도된 이메일 수신 가능  
- ## 이메일 주소 재사용  
  - 이메일 제공자가 **버려진 주소를 새 사용자에게 재할당**할 수 있으며, 새 계정 소유자가 이전 소유자가 등록했던 서비스의 계정 복구 이메일을 수신해 비밀번호 재설정을 통한 **계정 탈취 가능**  
  - Gmail은 주소를 재할당하지 않는다고 밝혔지만, 일부 다른 제공자는 역사적으로 재할당한 사례 존재  
- ## 서브어드레스 태그 노출  
  - `user+newsletter@gmail.com`으로 가입하면 수신 서비스가 태그를 포함한 전체 주소를 확인 가능  
  - 플러스 태그를 제거하고 저장하는 서비스는 기본 주소를 노출시키며, 전체 주소를 그대로 저장하는 서비스는 계정 설정이나 데이터 내보내기에서 **추적 전략이 드러남**

## Comments



_No public comments on this page._