모든 업무에는 공식 주소가 필요합니다. sales@, billing@, abuse@, legal@ 등 필요한 주소는 빠르게 늘어납니다. Google Workspace나 Microsoft 365에서는 주소마다 사용자 요금이 붙습니다. 역할 하나당 매월 $6-$12입니다. 조직을 제대로 정리하기 위해 내는 사용자별 세금인 셈입니다.
더 심각한 문제도 있습니다. 팀원이 AWS 루트 계정을 개인 업무 주소로 등록한 뒤 퇴사합니다. IT팀이 메일함을 중지하면 자체 인프라의 비밀번호 재설정 메일을 받을 수 없습니다. 사정을 고려하지 않는 지원팀에 소유권을 증명하느라 오후를 전부 쓰게 됩니다.
이메일 별칭은 두 문제를 모두 해결합니다. 외부에 공개되어 메일을 받은 뒤 기존 메일함으로 전달하는 주소입니다. 별도 계정, 인증 정보, 추가 사용자 요금이 필요 없습니다. 이 안내서에서는 별칭이 제 역할을 하는 네 가지 전달 방식과 오히려 업무를 망치는 한 가지 상황을 설명합니다.
DNS, MX 레코드, 전달 설정은 이메일 별칭 전달 안내서를 참고하세요.
이메일 별칭이란?
이메일 별칭은 실제 메일함으로 전달되는 대체 수신 주소입니다. 자체 받은편지함, 비밀번호, 스토리지가 없습니다. 별칭 앞으로 메일이 오면 서버가 봉투 수신자를 바꿉니다. RCPT TO: sales@domain.com이 RCPT TO: alice@domain.com으로 바뀐 뒤 배송됩니다. 발신자는 sales@를 보고 Alice가 메일을 받습니다. 변경 과정은 보이지 않으며, 바로 그것이 목적입니다.
활용 사례 1: 역할별 전달
이메일 별칭의 주요 용도는 공개된 역할을 현재 담당자와 연결해 기능의 책임자를 정하는 것입니다. 별칭 하나에 전달 대상 하나를 지정합니다. 이 일대일 방식은 RFC 2142에도 명시되어 있습니다. 담당자가 누구든 모든 도메인은 표준 역할 주소를 유지해야 합니다.
| 별칭 | 업무 | 전달 대상 |
|---|---|---|
sales@ | 잠재 고객 문의 | 창업자 또는 영업 책임자 |
billing@ | 청구서, 영수증 | 재무 책임자 또는 사무 관리자 |
abuse@ | 규정 준수 (RFC 2142) | 기술 책임자 또는 시스템 관리자 |
legal@ | 계약서, 비밀유지계약 | 창업자 또는 외부 변호사 |
no-reply@ | 자동 알림 | 보관용 메일함 또는 /dev/null |
어느 주소도 별도 계정이 필요하지 않습니다. 기존 메일함을 가리키는 이메일 별칭으로 만들면 됩니다. Postfix에서는 /etc/postfix/virtual에 몇 줄만 설정합니다.
sales@company.com alice@company.com
billing@company.com bob@company.com
abuse@company.com cto@company.com
legal@company.com alice@company.comPostfix는 수신할 때마다 별칭 맵을 조회하고 배송 전에 봉투 주소를 바꿉니다. Alice가 다른 역할로 이동하면 한 줄을 수정한 뒤 다시 불러옵니다.
postmap /etc/postfix/virtual
systemctl reload postfix업체에 요청하거나 계정을 이전하거나 세 개 메일 프로그램에 흩어진 전달 규칙을 관리할 필요가 없습니다.
활용 사례 2: 인프라 담당자 인수인계
이메일 별칭의 가장 저평가된 용도이자, 문제가 발생한 뒤 복구하기 가장 어려운 상황입니다. 중요한 SaaS를 개인 업무 주소로 등록하면 그 사람이 떠나는 날부터 위험 요소가 됩니다.
상황은 늘 같습니다. Steve가 도메인 등록 업체, AWS 루트 계정, Stripe 관리 화면을 steve@company.com으로 등록합니다. Steve가 이직하고 90일 뒤 IT팀이 메일함을 중지합니다. 청구 메일은 반송되고 비밀번호 재설정은 사라지며 AWS 루트 계정의 2FA 코드도 받을 수 없습니다. 응답 기한도 없는 지원팀에 오 년 전 직접 만든 계정의 소유권을 증명해야 합니다.
해결책은 모든 인프라 등록에 영구적인 이메일 별칭을 사용하는 것입니다.
ops@company.com을 만들어 기술 책임자나 시스템 관리자 등 현재 담당자에게 전달합니다.- DNS 등록 업체, AWS, Stripe, GitHub, Cloudflare 등 중요한 서비스는 모두
ops@으로 등록합니다. - 담당자가 바뀌면 별칭 대상을 새 담당자로 변경합니다. 변경은 한 번이며 일 분도 걸리지 않습니다.
업체에 등록된 주소는 바뀌지 않습니다. 중단 시간, 비밀번호 찾기의 반복, 소유권 증명 지원 요청도 없습니다.
이 방식이 작동하는 이유는 주소 자체가 영구 자산이기 때문입니다. 뒤에 연결된 전달 대상은 업체가 알 필요 없이 언제든 바꿀 수 있습니다.
활용 사례 3: 수신 추적 및 분류
별칭을 사용하면 계정이나 복잡한 받은편지함 규칙을 만들지 않고, 메일 구성을 여러 번 수정하지 않으면서 수신 메일에 표식을 붙여 분류할 수 있습니다. 대부분의 상황은 전용 추적 별칭과 플러스 주소라는 두 가지 방식으로 해결됩니다.
전용 추적 별칭
박람회 참가, 업체 체험판 가입, 완전히 신뢰하지 않는 뉴스레터 구독에는 출처별 이메일 별칭을 사용합니다. 예를 들어 conf2026@company.com이나 acme-vendor@company.com입니다. 주소가 스팸 목록에 나타나거나 불필요한 메일이 늘면 별칭을 삭제하세요. 즉시 멈춥니다. 기본 주소는 이렇게 선택적으로 해지할 수 없습니다.
이 방식은 전체 수신 메일함과 잘 맞습니다. 도메인의 모든 주소를 한 메일함으로 받은 뒤 어떤 태그가 도착하는지 확인하고 추적 별칭을 나중에 만들 수 있습니다.
플러스 주소 (하위 주소, RFC 5233)
현대적인 메일 서버 대부분은 RFC 5233에 따라 + 구분자를 쓰는 하위 주소를 지원합니다. 따로 만들 필요 없이 호환 서버에서 자동으로 작동합니다.
alice+jira@company.com → delivers to alice@company.com
alice+shopify@company.com → delivers to alice@company.com
alice+newsletters@company.com → delivers to alice@company.com태그와 일치하는 받은편지함 규칙 하나만 설정하면 모든 메일이 알맞은 폴더로 이동합니다. 관리 부담은 없습니다. 기존 이메일 별칭에 분류 정보를 덧붙이는 방식입니다.
활용 사례 4: 별칭으로 보내기와 실패하는 상황
이메일 별칭으로 받는 과정은 자동이지만, 별칭으로 보내려면 단계가 하나 더 필요합니다. 생략하면 답장을 받은 모든 고객에게 개인 주소가 공개됩니다.
고객이 sales@company.com으로 보내고 메일은 alice@company.com으로 전달됩니다. Alice가 그대로 답장하면 고객에게 발신자가 alice@company.com으로 표시됩니다. 전문적인 대표 주소가 사라지고 Alice의 직접 주소가 고객 연락처에 영구적으로 남습니다.
별칭에는 인증 정보가 없습니다. 별칭으로 보내려면 메일 프로그램에 발신 ID를 설정하세요.
- 일반 메일 프로그램 (Outlook, Thunderbird, Apple Mail): 별칭을 보낸 사람 주소로 쓰는 새 ID를 추가하고 기본 메일함의 SMTP 정보로 인증합니다. 계정으로 보내되 From 헤더에는 별칭이 표시됩니다.
- 자체 SMTP (TrekMail Free 또는 Amazon SES나 SendGrid를 쓰는 Starter): 보내기 전에 SMTP 업체 관리 화면에서 별칭이나 발신 도메인 전체를 인증해야 합니다. 생략하면
554 Message rejected: Email address is not verified로 거부됩니다. 전체 과정은 TrekMail의 자체 SMTP 설정 안내서를 참고하세요.
이메일 별칭이 적합하지 않은 상황
이메일 별칭은 일대일 도구입니다. 별칭 하나를 메일함 하나로 전달하면 앞의 활용법이 모두 올바르게 작동합니다. 같은 별칭을 Alice, Bob, Charlie에게 동시에 전달해 모두 support@을 받게 하면 상태가 나뉜 받은편지함이 만들어지고 결국 고객을 잃게 됩니다.
Alice가 고객에게 답장해 문제를 해결해도 답장은 Alice의 보낸편지함에만 저장됩니다. 서버 공유 폴더나 Bob의 프로그램에는 없습니다. Bob은 이를 모르고 세 시간 뒤 상충하는 내용으로 답장합니다. 고객은 혼란스럽고 불쾌한 경험으로 기억합니다.
설정으로 해결할 수 없는 별칭 구조의 한계입니다. 별칭이 맞는 상황과 그렇지 않은 상황은 도메인 이메일 별칭과 메일함 비교를 참고하세요.
공유 받은편지함의 올바른 해결책: support@company.com 전용 메일함을 만들고 비밀번호 관리 도구로 인증 정보를 공유합니다. Alice와 Bob이 IMAP 프로그램에 계정을 추가하면 누가 답장해도 서버의 보낸편지함에 저장되어 양쪽에 동기화됩니다. 상태를 공유하고 답장이 겹치지 않으며 정보도 새지 않습니다.
| 상황 | 알맞은 도구 | 이유 |
|---|---|---|
| 한 사람이 역할 주소를 담당 | 별칭 | 추가 계정이나 사용자 요금 불필요 |
| 인프라 및 서비스 계정 | 별칭 | 담당자가 바뀌어도 그대로 유지 |
| 출처별 수신 추적 | 이메일 별칭 | 필요할 때 삭제할 수 있고 용량 불필요 |
| 신뢰도가 낮은 가입용 임시 주소 | 이메일 별칭 | 스팸 목록에 팔리면 즉시 해지 |
| 두 명 이상이 읽고 답장 | 메일함 | IMAP 상태 공유, 답장 충돌 방지 |
| 팀의 장기 소유 | 메일함 | 감사 기록, 위임 접근 |
사용자별 요금제가 잘못된 구조를 선택하게 한다
Google Workspace와 Microsoft 365에서는 메일함을 만들 때마다 비용이 듭니다. 이 가격 때문에 팀은 월 $6를 아끼려고 별칭을 공유 받은편지함으로 사용하고 앞서 설명한 문제를 겪습니다. 잘못된 구조는 게으름이 아니라 사용자별 과금에 대한 합리적인 반응입니다.
TrekMail은 정액제이며 계정의 모든 메일함이 스토리지를 공유합니다. 메일함이나 별칭마다 과금하지 않습니다. Starter는 월 $3.50에 도메인 50개와 공용 스토리지 15GB를 제공합니다. 메일함 3개와 별칭 10개를 쓰든, 메일함 20개와 별칭 200개를 쓰든 가격은 같습니다.
이제 비용 때문에 잘못된 도구를 선택할 필요가 없습니다. support@ 전용 메일함, 영구적인 인수인계용 ops@ 별칭, 박람회별 이메일 별칭을 만들고 실제 업무에 맞는 구조를 구축하세요.
처음부터 시작한다면 내 도메인으로 이메일 만드는 방법에서 도메인 준비, DNS 레코드, 첫 메일함 설정을 확인하세요.
이메일 별칭 요약
이메일 별칭은 일대일 전달 도구입니다. 역할 주소, 인프라 인수인계, 수신 추적에 사용하세요. 관리 부담 없는 태그에는 플러스 주소를 사용합니다. 여러 사람이 읽고 답장해야 하는 순간 전용 메일함으로 바꾸세요. 처음 세 가지 상황에는 별칭이 적합하지만 네 번째에는 별칭이 제공하지 못하는 공유 IMAP 상태가 필요합니다.
사용자별 비용을 그만 내세요
기존 업체는 ID를 만들 때마다 비용을 청구합니다. TrekMail에서는 이메일 별칭이 무료이며 무제한입니다. 두 번째 메일함, 다섯 번째 도메인, 스무 번째 별칭도 마찬가지입니다.
Starter 요금제, 월 $3.50:
- 계정 하나에 맞춤 도메인 50개
- 모든 메일함이 공유하는 15GB 스토리지
- 도메인별 무제한 별칭
- 전체 수신 메일함 전달
- 관리형 SMTP 포함, 외부 업체 불필요
- SPF, DKIM, DMARC 설정 마법사
월 $3.50이면 Google Workspace 사용자 한 명보다 저렴한 가격으로 도메인 50개와 필요한 모든 별칭을 이용할 수 있습니다.
14일 체험은 trekmail.net에서 시작할 수 있으며 카드가 필요합니다. 약정 전에 시험하려면 Nano 요금제를 이용하세요. 도메인 10개, 공용 스토리지 5GB, 자체 SMTP를 제공하며 카드와 만료 기간 없이 영구 무료입니다. Nano로 시작한 뒤 준비되면 업그레이드하세요.
