이메일 별칭의 개념과 설정 방법 및 실무 권장 사항

비즈니스를 운영하다 보면 직원 수보다 더 많은 이메일 주소가 필요합니다. 잠재 고객 문의에는 sales@, 지원 요청에는 support@, 청구서에는 billing@가 필요합니다. 기존 방식은 주소마다 별도의 사서함을 유료로 만드는 것입니다. 그러면 좌석도 세 개, 월 요금도 세 건, 관리할 로그인도 세 개가 됩니다.

더 효율적인 방법은 이메일 별칭입니다. 이메일 별칭을 사용하면 추가 좌석 비용이나 별도 로그인 관리 없이도 전문적인 역할 기반 이메일 주소를 만들 수 있습니다. 하지만 잘못 설정하면 기본 주소가 노출되고 SPF 및 DMARC 인증에 실패할 위험이 생기거나, 메일이 별도 알림 없이 전달되지 않을 수 있는 라우팅 루프가 발생할 수 있습니다.

이 가이드에서는 이메일 별칭이 기술적으로 무엇인지부터 실제로 유용한 활용 사례, 라우팅을 처리하는 SMTP 메커니즘, 많은 설정에서 문제가 되는 "다른 주소로 보내기" 기능, 일반적인 설정 오류, TrekMail에서 이메일 별칭을 단계별로 설정하는 방법까지 모두 다룹니다.

이메일 별칭이란?

이메일 별칭은 기존 사서함을 가리키는 가상 라우팅 주소입니다. 전용 저장 공간과 로그인 자격 증명이 없으며, 독립된 사용자 계정도 아닙니다. 이메일 별칭 주소로 메일이 도착하면 서버는 라우팅 테이블을 확인하고 설정된 대상 사서함을 찾아 메시지를 전달합니다. 이 과정은 발신 서버가 메시지 본문 전송을 완전히 마치기 전부터 진행됩니다.

이메일 별칭으로 로그인하는 것이 아니라, 별칭이 연결된 사서함으로 로그인합니다. 별칭은 서버 수준의 지시 사항일 뿐입니다. 즉, 이 주소로 온 메일은 저 사서함에 넣으라는 뜻입니다.

이메일 별칭이 아닌 세 가지는 다음과 같습니다.

• 사서함이 아닙니다. 별칭 자체에는 저장 공간이 없습니다. 이메일 별칭을 삭제해도 메일 기록은 사라지지 않습니다. 메일은 처음부터 대상 사서함에 전달되었기 때문입니다.
• 전달 규칙이 아닙니다. 전달은 메일을 외부 서버로 보냅니다. 이메일 별칭은 도메인의 메일 시스템 안에서 내부적으로 라우팅하므로, 그 자체로는 SPF 또는 DMARC 위험을 추가하지 않습니다.
• 공유 받은편지함이 아닙니다. 여러 이메일 별칭이 하나의 사서함을 가리킬 수 있지만, 여러 사용자가 하나의 공통 대기열에서 함께 작업하는 공유 받은편지함과는 다릅니다.

접수 담당자에 비유하면: 기본 사서함은 사무실이고 이메일 별칭은 문에 붙인 또 하나의 명패입니다. 누군가 "창업자", "영업 관리자", "Bob" 가운데 어떤 이름으로 편지를 보내든 모두 같은 방에 도착합니다. 별칭을 이용하면 더 큰 사무실이나 더 큰 예산 없이도 수신 메일을 전문적으로 관리할 수 있습니다.

기술적으로 이메일 별칭은 메일 서버의 별칭 맵 항목으로 구현됩니다(Postfix에서는 virtual_alias_maps, Exim에서는 라우터 항목, 호스팅 플랫폼에서는 라우팅 규칙). 서버의 SMTP 데몬은 수신 연결을 처리할 때 RCPT TO 단계에서 이 맵을 확인합니다. 수신 주소가 별칭 테이블에 있으면 내부 전달 경로를 자동으로 다시 씁니다. 발신자는 이 과정을 알 수 없습니다.

이메일 별칭, 이메일 전달, 사서함 비교

이메일 별칭과 이메일 전달의 핵심 차이는 메시지가 머무는 위치입니다. 별칭은 메시지를 도메인의 메일 시스템 안에 유지하지만, 전달은 외부 서버로 보냅니다. 이 과정에서 SPF와 DMARC 인증 문제가 발생해 정상 메일이 별도 알림 없이 전달되지 않을 위험이 있습니다. 사서함은 둘과 다르게 전용 저장 공간과 자체 로그인 자격 증명, 완전히 독립된 사용자 계정을 갖습니다. 이 세 가지를 혼동하면 불필요한 비용을 내거나 이메일을 놓칠 수 있습니다.

판단 기준은 간단합니다. 메일이 도메인 안에 머무르면 이메일 별칭을 사용합니다. 메일이 다른 메일 서버에 도달해야 한다면 전달을 사용하되, 먼저 제공업체가 SRS와 ARC를 지원하는지 확인해야 합니다. 지원하지 않으면 엄격한 DMARC 정책을 사용하는 발신자의 메일이 전달되지 않을 위험이 있습니다. 사용자가 직접 로그인하거나 자신의 받은편지함을 독립적으로 관리해야 하거나, 명확한 감사 추적이 필요하다면 실제 사서함을 만드세요.

전체 판단 기준은 도메인 이메일 별칭과 사서함: 선택 방법을 참조하세요.

실제로 유용한 활용 사례

좋은 이메일 별칭 설정은 단순히 외관을 꾸미는 것이 아니라 실제 운영 문제를 해결합니다. 다음은 구축할 가치가 있는 활용 방식입니다.

1. 역할 기반 라우팅(전문적인 대외 창구)

혼자 창업했다고 해서 외부에 반드시 혼자 일하는 것처럼 보일 필요는 없습니다. info@, press@, accounts@, sales@를 이메일 별칭으로 만들고 모두 기본 사서함으로 라우팅하세요. 작은 팀처럼 전문적인 인상을 즉시 줄 수 있습니다. 실제 영업 직원을 채용하면 sales@ 이메일 별칭을 삭제하고 그 직원을 위한 실제 사서함을 만들면 됩니다. 별도 재설정이나 추가 비용 없이 깔끔하게 인계할 수 있습니다.

2. 공급업체 추적 전략

완전히 신뢰하지 않는 공급업체에는 기본 업무용 이메일을 제공하지 마세요. 대신 공급업체별 이메일 별칭을 만드세요. 예를 들면 hubspot@yourdomain.com, linkedin@yourdomain.com, surveygizmo@yourdomain.com입니다. linkedin@로 스팸이 들어오기 시작하면 누가 데이터를 판매했거나 침해 사고를 겪었는지 바로 파악할 수 있습니다. 해당 이메일 별칭을 삭제해 불필요한 메일을 차단해도 나머지 설정에는 영향이 없습니다.

이는 카나리아 토큰과 같은 역할을 하는 이메일 별칭 활용법입니다. 설정 비용이 들지 않으며 공급업체 데이터베이스가 침해되었을 때 원인을 찾는 시간을 크게 줄여 줍니다. 이런 사고는 많은 운영자가 예상하는 것보다 자주 발생할 수 있습니다.

3. 오타 변형 및 이전 주소

이름이 Michael이라면 누군가는 micheal@yourdomain.com으로 메일을 보낼 수 있습니다. 회사가 작년에 브랜드를 변경했어도 이전 도메인으로 메일이 계속 올 수 있습니다. 이메일 별칭은 두 문제를 모두 해결합니다. 흔한 철자 오류와 이전 주소를 현재 받은편지함에 연결하세요. 누락되는 메일 없이 두 시스템을 따로 확인할 필요도 없습니다.

4. 플러스 주소 지정(설정이 필요 없는 별칭)

TrekMail, Gmail, Microsoft 365를 포함한 대부분의 최신 이메일 시스템은 RFC 5233에 정의된 플러스 주소 지정을 지원합니다. 주소가 bob@company.com이라면 관리자 설정 없이 bob+newsletter@company.com 또는 bob+support-ticket@company.com을 사용할 수 있습니다. 메일은 여전히 Bob의 받은편지함에 도착하지만, 하위 주소 태그를 이용해 자동으로 필터링할 수 있습니다.

단점도 있습니다. 일부 웹 양식은 + 문자를 허용하지 않습니다. 플러스 주소 지정은 필터링과 추적에 안정적으로 쓸 수 있지만 모든 곳에서 허용되는 것은 아닙니다. 공식적인 역할 기반 주소에는 정식 이메일 별칭을 만드세요.

5. 에이전시 및 다중 도메인 관리

여러 고객의 이메일을 관리하거나 고객마다 자체 도메인을 사용하는 에이전시를 운영한다면 도메인별 이메일 별칭 문제의 영향이 달라집니다. 사용자별 과금 모델에서는 모든 역할 주소(support@clientdomain.com, billing@clientdomain.com)가 좌석 비용을 하나 더 만들어 고객 청구서에 추가되거나 에이전시의 수익을 줄일 수 있습니다. TrekMail의 정액제 플랜에서는 사서함별 추가 요금 없이 모든 고객 도메인에 이메일 별칭을 만들 수 있습니다. 대시보드 하나, 정액 요금 하나로 도메인별 사서함 비용을 피할 수 있습니다. 수십 개 고객 도메인을 관리하는 팀이라면 대규모 다중 도메인 이메일 호스팅을 참조하세요.

6. 팀 성장에 따른 부서 라우팅

팀이 성장하면 부서 단위 주소가 라우팅과 책임 소재 관리에 중요해집니다. hr@, legal@, finance@는 현재 담당 직원의 사서함을 가리키는 별칭으로 만들 수 있고, 팀 규모가 커지면 공유 사서함으로 전환할 수도 있습니다. 이메일 별칭은 간단히 만들 수 있으며 담당자의 역할이 바뀌어도 몇 초 만에 대상을 변경할 수 있습니다. DNS 변경이나 재온보딩도 필요하지 않습니다.

이메일 별칭의 메일 라우팅 방식(SMTP 메커니즘)

이메일 별칭은 메시지 본문이 전송되기 전인 SMTP 연결의 RCPT TO 단계에서 작동합니다. 발신 서버가 RCPT TO: <sales@yourdomain.com>을 보내면 수신 메일 서버는 별칭 테이블을 확인하고 sales에 해당하는 라우팅 항목을 찾은 뒤, 내부 전달 경로를 대상 사서함으로 다시 쓰고 250 OK로 연결을 수락합니다. 메시지의 원래 To: 헤더는 유지되며 내부 전달 경로만 바뀝니다.

단계별 과정은 다음과 같습니다.

1. 외부 서버가 MX 서버에 연결해 SMTP 세션을 엽니다.
2. 발신 서버가 다음 명령을 보냅니다. RCPT TO: <sales@yourdomain.com>
3. 수신 서버가 별칭 맵을 확인합니다. sales라는 사서함은 없지만 bob@yourdomain.com으로 라우팅하라는 별칭 규칙이 있습니다.
4. 수신 서버가 연결을 수락하고(250 OK) 메시지를 Bob의 사서함에 전달합니다.
5. Bob의 이메일 클라이언트에는 To: sales@yourdomain.com이 표시됩니다. 원래 헤더는 변경되지 않습니다.
6. 발신 서버는 이메일 별칭의 존재를 알 수 없습니다. 추가 SMTP 세션이나 별도로 드러나는 반송도 없습니다.

가장 널리 쓰이는 오픈 소스 MTA 중 하나인 Postfix에서는 virtual_alias_maps를 통해 이를 구현합니다. 이는 별칭 주소를 실제 사서함에 매핑하는 조회 테이블입니다. 다른 MTA는 처리 방식이 다르지만(Exim은 라우터 설정, Haraka는 플러그인 기반 라우팅 사용), 개념은 같습니다. 이메일 별칭은 메일이 저장되기 전에 해석되는 서버 측 재작성 규칙입니다.

알아 둘 점이 하나 있습니다. 별칭 해석은 SMTP RCPT TO 명령에 사용된 봉투 주소를 기준으로 하며, 메시지의 To: 헤더를 기준으로 하는 것은 아닙니다. 메일링 리스트로 보낸 메일에는 To: list@example.com이 들어 있어도 RCPT TO: member@yourdomain.com이 사용될 수 있습니다. 별칭은 헤더가 아니라 RCPT TO 주소에 반응합니다.

"다른 주소로 보내기" 문제: 별칭 주소로 답장하기

이메일 별칭을 통한 메일 수신은 간단합니다. 대부분의 설정이 실패하는 지점은 이메일 별칭 주소를 보내는 사람으로 사용해 답장할 때입니다. Bob이 sales@yourdomain.com으로 온 메시지를 받고 답장을 누르면 기본 보낸 사람 주소는 bob@yourdomain.com입니다. 이메일 별칭으로 유지하려던 전문적인 대외 창구가 즉시 깨집니다. 수신자에게 역할 주소가 아니라 Bob의 개인 주소가 표시됩니다.

주요 플랫폼마다 "다른 주소로 보내기" 설정 방법이 다릅니다.

Google Workspace

Gmail 설정 → 계정 → "다른 주소에서 메일 보내기" → 다른 이메일 주소 추가로 이동합니다. 별칭을 입력하세요. 설정 대화 상자가 나타나면 "별칭으로 처리"의 선택을 해제합니다. 이렇게 해야 Google이 이메일 별칭 주소를 표시 이름처럼 사용하는 것이 아니라 실제 보낸 사람 주소로 사용합니다. 이 항목을 선택한 상태로 두면 답장의 From 필드에 기본 주소가 계속 표시될 수 있습니다. 흔한 실수이므로 다시 확인하세요.

Microsoft 365

과거에는 테넌트 관리자가 PowerShell 명령 Set-OrganizationConfig -SendFromAliasEnabled $true를 실행해야 했습니다. 이를 설정하지 않으면 답장에 "Bob on behalf of Sales"가 표시될 수 있습니다. 기술적으로는 정확하지만 기본 주소가 노출되고 외부 커뮤니케이션에서 전문성이 떨어져 보일 수 있습니다. Microsoft는 2024년에 기본 관리 센터 토글을 추가했지만, 그 이전에 프로비저닝된 테넌트라면 해당 플래그가 설정되어 있는지 확인하세요.

TrekMail

TrekMail은 이 기능을 기본적으로 처리하는 것으로 안내합니다. 서버 측 추가 설정 없이 모든 사서함에 여러 발신 주소를 구성하고 Outlook, Thunderbird, Apple Mail 또는 웹메일에서 사용할 From 주소를 직접 선택할 수 있습니다. 이메일 별칭은 별도 절차 없이 선택 가능한 From 주소로 표시됩니다. 전체 클라이언트 설정은 IMAP/SMTP 설정에서 확인하세요.

이메일을 망가뜨리는 설정 오류

이메일 별칭의 개념은 간단하지만 실제 설정은 의외로 작은 오류에 취약합니다. 다음 세 가지 설정 오류가 대부분의 문제를 일으킵니다.

1. 전체 수신의 함정

전체 수신 이메일 별칭(*@yourdomain.com)은 존재하지 않는 주소로 보낸 메시지를 포함해 도메인으로 전송된 모든 메시지를 받습니다. 안전망처럼 들리지만 실제로는 그렇지 않습니다.

스패머는 디렉터리 수집 공격(DHA)을 사용합니다. 무작위로 생성한 수천 개의 로컬 파트로 도메인에 메일을 보냅니다. 전체 수신이 없으면 서버는 SMTP 단계에서 알 수 없는 주소를 550 5.1.1 User unknown 응답으로 거부해 발신 서버가 더 이상 시도하지 않도록 합니다. 전체 수신 이메일 별칭이 있으면 서버가 모든 메일을 수락하므로 스패머에게 해당 도메인을 계속 탐색할 가치가 있다는 신호를 줄 수 있습니다. 스팸 양이 급증하고 필터가 과부하되면 정상 메일이 그 속에 묻힐 수 있습니다.

실제로 잘못 전달된 메일을 위한 안전망이 필요하다면 전체 수신 메일을 전용 격리 사서함으로 라우팅하세요. 실제 사용자의 받은편지함으로 보내서는 안 됩니다. TrekMail 문서에는 장단점이 자세히 설명되어 있습니다. 전체 수신 받은편지함 설정과 위험을 참조하세요.

2. 라우팅 루프

이 문제는 알아차리기 어렵습니다. support@를 bob@yourdomain.com으로 라우팅하는 이메일 별칭으로 설정했습니다. Bob은 휴가를 가면서 자리를 비운 동안 팀에서 처리해 줄 것이라 생각하고 자신의 사서함에 들어오는 모든 메일을 support@로 자동 전달하도록 설정합니다.

이제 루프가 생깁니다.

support@ delivers to bob@ → bob@ forwards to support@ → delivers to bob@ → forwards to support@ → …

메일 서버는 결국 이를 감지합니다. Postfix는 홉 수를 추적하며 메시지가 한도를 넘으면 5.4.14 Hop count exceeded 반송 메시지가 표시됩니다. 하지만 그때는 원본 메시지를 복구하지 못할 수 있습니다. 해결 방법은 휴가 규칙이나 자동 전달 규칙을 설정하기 전에 기존 별칭과 전달 관계를 모두 도식화하는 것입니다. 어떤 사서함을 그 사서함 자체로 다시 라우팅되는 이메일 별칭으로 전달해서는 안 됩니다.

3. "전체 답장"으로 인한 주소 노출

marketing@yourdomain.com으로 메시지를 보내는 메일링 리스트에 참여 중이라고 가정해 보겠습니다. 이메일 별칭은 기본 bob@yourdomain.com 받은편지함으로 라우팅됩니다. From 주소를 별칭으로 바꾸지 않고 "전체 답장"을 누르면 대화의 모든 수신자에게 bob@yourdomain.com이 표시됩니다. 의도한 marketing@ 주소가 아닙니다. 법률, 의료, 금융처럼 민감한 업종에서는 사소한 불편이 아니라 실제 개인정보 노출이 될 수 있습니다.

해결 방법은 위에서 설명한 "다른 주소로 보내기" 설정입니다. 민감한 역할 기반 커뮤니케이션을 처리한다면 이메일 별칭 대신 전용 사서함을 만드는 것도 고려하세요. 로그인과 사용자 계정이 분리되므로 실수로 주소가 노출될 가능성을 줄일 수 있습니다.

별칭과 전달의 조합: SPF, DMARC, SRS

이메일 별칭과 외부 전달을 결합하면, 예를 들어 contact@yourdomain.com을 개인 Gmail로 연결하면 인증 충돌이 발생해 정상 메일이 별도 알림 없이 전달되지 않을 위험이 생깁니다. 흔한 설정이지만 문제 원인을 진단하기 어려울 수 있습니다.

어떤 문제가 왜 발생하는지 살펴보겠습니다.

SPF 실패: 전달 서버는 자체 서버 IP를 사용해 메시지를 Gmail로 중계합니다. 원래 발신자의 도메인(예: bank.com)이 게시한 SPF 레코드에는 전달 서버의 IP가 허용되어 있지 않습니다. 따라서 원본 메시지가 정상이어도 Gmail에서는 SPF가 실패할 수 있습니다. 메시지는 원래 허용된 출처에서 왔지만 전달 서버가 bank.com의 SPF 목록에 없기 때문입니다.

DMARC 거부 위험: bank.com이 엄격한 DMARC 정책(p=reject)을 게시한 경우, 전달된 메시지에서 정렬된 SPF와 정렬된 DKIM이 모두 실패하면 Gmail이 메시지를 거부할 수 있습니다. 전달 서버가 바닥글을 추가하거나 인코딩을 바꾸거나 본문 줄바꿈을 변경하면 DKIM 서명이 깨질 수 있습니다. 이때 SPF도 정렬에 실패하고 DKIM도 유효하지 않다면 DMARC를 통과할 수 없으며, p=reject 정책에 따라 강하게 거부될 수 있습니다. 반대로 DMARC는 정렬된 SPF 또는 정렬된 DKIM 중 하나가 통과하면 인증을 통과합니다.

다음 두 메커니즘으로 문제를 완화할 수 있지만, 둘 다 호스팅 제공업체의 지원이 필요합니다.

• SRS(Sender Rewriting Scheme): 전달 서버가 봉투 발신자(MAIL FROM)를 사용자의 도메인으로 다시 씁니다. 그러면 메시지가 원래 발신자 도메인이 아니라 사용자의 도메인에서 온 것으로 표시되므로 목적지에서 SPF를 통과할 수 있습니다. 반송 주소도 다시 인코딩되어 원래 발신자에게 도달할 수 있습니다.
• ARC(Authenticated Received Chain): 전달 서버가 메시지에 암호화된 인증 연속 서명을 추가해 전달 전에 SPF 및 DKIM 검사를 통과했음을 증명합니다. ARC를 지원하는 목적지 서버는 신뢰할 수 있는 중간 서버에 대해 이 정보를 고려하여 전달 과정의 SPF 실패를 평가할 수 있습니다. ARC는 RFC 8617에 정의되어 있습니다.

저가형 도메인 등록기관과 기존 공유 호스트 가운데 ARC를 지원하지 않는 곳이 많고 SRS를 지원하지 않는 곳도 많습니다. 이런 플랫폼에서 별칭을 외부로 전달하면 엄격한 DMARC 정책을 사용하는 발신자의 정상 메일이 별도 반송 없이 전달되지 않을 위험이 있습니다. TrekMail은 전달 메일에 SRS와 ARC를 지원한다고 안내합니다.

이 시나리오의 전체 메커니즘은 이메일 별칭 전달: 장단점과 해결 방법 및 더 포괄적인 이메일 전달 설정 및 문제 해결 가이드를 참조하세요.

TrekMail에서 이메일 별칭 설정하기

TrekMail 이메일 별칭은 도메인 수준에서 관리됩니다. 도메인별로 만들며 같은 도메인의 모든 사서함으로 라우팅할 수 있습니다. 전체 설정 순서는 다음과 같습니다.

1단계: 도메인 추가 및 DNS 설정

도메인이 아직 TrekMail에 없다면 대시보드의 Domains → Add Domain에서 추가합니다. TrekMail은 필요한 DNS 레코드인 MX, SPF, DKIM, DMARC 값을 생성해 제공하는 것으로 안내합니다. 이를 DNS 제공업체의 제어판에 복사하세요. 전체 레코드 값은 필수 DNS 레코드에서 확인할 수 있습니다. DNS 전파는 일반적으로 한 시간 이내에 완료될 수 있으며, TrekMail이 레코드를 감지하면 녹색 상태 표시가 나타납니다.

2단계: 대상 사서함 만들기

이메일 별칭에는 전달 대상이 필요합니다. 먼저 Mailboxes → Add Mailbox로 이동해 주소와 비밀번호를 설정하고 대상 사서함을 만드세요. 이메일 별칭을 통해 라우팅된 메일이 도착할 받은편지함입니다. TrekMail에서는 사서함을 만들 때 사용자별 요금이 새로 부과되지 않고 플랜의 통합 저장 공간을 사용하는 것으로 안내합니다.

3단계: 이메일 별칭 만들기

도메인 대시보드에서 Aliases → Add Alias로 이동합니다. 이메일 별칭의 로컬 파트(예: sales)를 입력하고 드롭다운에서 대상 사서함을 선택한 다음 저장합니다. 이메일 별칭은 즉시 활성화되는 것으로 안내되며 DNS 변경이나 전파 대기가 필요하지 않습니다.

플랜에서 허용하는 수만큼 별칭을 만들 수 있습니다. 현재 안내 기준으로 Starter는 도메인별 별칭 수에 제한이 없으며 별칭별 요금도 없습니다.

4단계: 이메일 클라이언트에서 "다른 주소로 보내기" 설정

이메일 별칭으로 수신만 하는 것이 아니라 해당 주소로 답장하려면 클라이언트에 별칭을 발신자 계정으로 추가합니다.

• Thunderbird: Account Settings → Manage Identities → Add로 이동합니다. 이메일 별칭 주소를 입력하고 기본 사서함과 동일한 SMTP 서버와 자격 증명을 사용합니다.
• Outlook(데스크톱): 서버 측에서 설정한 뒤 별칭이 선택 가능한 From 주소로 자동 표시될 수 있습니다. 표시되지 않으면 File → Account Settings → Email → More Settings로 이동해 "Include a From header" 옵션을 확인합니다.
• Apple Mail: Mail → Preferences → Accounts로 이동해 계정을 선택한 다음 Account Information을 엽니다. "Email Address" 필드에 이메일 별칭 주소를 쉼표로 구분된 값으로 추가합니다. 그러면 Apple Mail에서 From 옵션으로 선택할 수 있습니다.
• 웹메일: TrekMail 웹메일 인터페이스에서는 드롭다운에서 From 주소를 선택할 수 있으며, 대시보드에서 설정한 이메일 별칭이 여기에 표시되는 것으로 안내합니다.

TrekMail의 IMAP/SMTP 설정은 클라이언트 간에 동일하게 안내됩니다. IMAP은 포트 993(SSL/TLS), SMTP는 포트 587(STARTTLS)을 사용합니다. 자세한 내용은 IMAP/SMTP 설정 문서에서 확인하세요.

5단계: 종단 간 테스트

외부 계정에서 새 이메일 별칭으로 테스트 메시지를 보내고 대상 사서함에 도착하는지 확인합니다. 그런 다음 From 주소로 이메일 별칭을 사용해 답장하고, 수신자에게 기본 사서함 주소가 아니라 별칭 주소가 표시되는지 확인합니다. From에 잘못된 주소가 표시되면 클라이언트의 "다른 주소로 보내기" 설정을 확인하세요.

DNS가 설정된 도메인에서 작동하는 이메일 별칭까지 구성하는 데 걸리는 시간은 약 세 분으로 안내됩니다.

기존 방식과 TrekMail 방식 비교

이메일 별칭 관리는 간단해 보이지만 규모가 커지거나 사용자별 과금 모델에서 역할 주소 하나하나가 비용 협의 항목이 되면 이야기가 달라집니다.

기존 방식(Google Workspace / Microsoft 365)

사용자별로 요금을 냅니다. 원문 작성 시점에 Google Workspace Business Starter는 $6/user/month였고 Microsoft 365 Business Basic도 비슷한 수준이었습니다. 도메인별이나 별칭별이 아닌 사용자별 과금입니다. 이메일 별칭 자체는 무료이지만 대상 사서함에는 유료 좌석이 필요합니다.

많은 소규모 팀이 사용하는 우회 방법은 모든 이메일 별칭을 한 사용자의 계정에 몰아넣는 것입니다. info@, sales@, billing@, support@를 모두 창업자의 사서함에 연결합니다. 추가 좌석 비용은 피할 수 있지만 받은편지함이 혼란스러워집니다. 모든 메시지가 한곳에 도착하고, 중요한 잠재 고객 문의가 청구 알림에 묻히며, 담당자도 명확하지 않습니다.

에이전시는 더 어렵습니다. 수백 개 고객 테넌트의 이메일 별칭을 관리하려면 고객마다 별도 관리 콘솔을 사용하고 "다른 주소로 보내기" 권한을 위한 PowerShell 스크립트를 다루며, 각 청구서에 사용자별 라이선스 비용을 반영해야 할 수 있습니다. 고객의 역할 주소를 새로 추가하려면 라이선스를 추가하거나 해당 역할에 전용 저장 공간을 제공할 수 없는 이유를 설명해야 합니다.

TrekMail 방식

TrekMail은 정액제 도메인 호스팅을 사용한다고 안내합니다. 사용자별이 아니라 서비스에 대해 요금을 냅니다. 원문 작성 시점에 Starter 플랜은 $3.50/month였으며 통합 저장 공간으로 최대 50 domains를 지원했습니다. 이메일 별칭이나 사서함을 추가해도 새 비용 항목이 생기지 않는 것으로 안내됩니다.

TrekMail에서는 사서함 추가에 별도 비용이 들지 않는 것으로 안내하므로, support@를 이미 복잡한 창업자의 받은편지함에 별칭으로 연결하는 대신 전용 사서함을 제공할 수 있습니다. 감사 추적이 개선되고 받은편지함이 깔끔해지며, 지원 담당자를 채용하면 로그인 자격 증명만 전달하면 됩니다. 이메일 별칭 재설정, 좌석 업그레이드, 청구서 변경이 필요하지 않은 것으로 안내됩니다.

고객 이메일을 대규모로 관리하는 에이전시의 경우, 원문 작성 시점에 Agency 플랜은 $23.25/month였으며 일괄 가져오기와 API 액세스를 포함해 1,000+ domains를 지원했습니다. 도메인당 비용은 센트의 일부 수준으로 계산될 수 있습니다. 사용자별 라이선스와 근본적으로 다른 모델이며 그 차이는 수익성에 반영됩니다.

플랜 세부 정보는 trekmail.net/pricing에서 확인하세요.

빠른 참조

빠르게 결정해야 할 때 이 표를 사용하세요.

기억해야 할 세 가지 원칙:

1. 내부 라우팅 = 이메일 별칭. 외부 라우팅 = 전달. 이메일 별칭으로 충분한 곳에서 전달을 사용하지 마세요. 불필요한 SPF/DMARC 위험을 추가할 수 있습니다.
2. 별칭을 대외 커뮤니케이션 창구로 사용하기 전에 "다른 주소로 보내기"를 설정하세요. 답장으로 기본 주소가 노출되면 구축한 전문적인 대외 창구의 의미가 사라집니다.
3. 전체 수신 메일을 실제 사용자의 받은편지함으로 라우팅하지 마세요. 격리 사서함을 사용하거나 전체 수신 기능을 사용하지 않는 편이 좋습니다.

결론

이메일 별칭은 비즈니스 이메일 설정에서 매우 유용하면서도 흔히 잘못 설정되는 도구입니다. 올바르게 설정하면 추가 비용이나 추가 로그인 없이 전문적인 다중 주소 이메일 체계를 구축할 수 있으며, 별칭의 내부 라우팅 자체는 전달 가능성 위험을 추가하지 않습니다. 잘못 설정하면 라우팅 루프나 주소 노출이 발생할 수 있고, 외부 전달에서는 수신 측 DMARC 정책에 따라 메일이 별도 알림 없이 전달되지 않을 위험도 있습니다.

간단히 요약하면 다음과 같습니다.

• 역할 기반 주소, 공급업체 추적, 오타 변형에는 이메일 별칭을 사용합니다.
• 별도 로그인, 전용 저장 공간, 명확한 감사 추적이 필요하면 실제 사서함을 사용합니다.
• 통제된 격리 전략이 없다면 전체 수신 기능을 피합니다.
• 이메일 별칭을 외부로 전달한다면 제공업체가 SRS와 ARC를 지원하는지 확인합니다. 기존 호스트 중에는 지원하지 않는 곳이 많습니다.
• 외부 커뮤니케이션에서 별칭을 사용하기 전에 반드시 "다른 주소로 보내기"를 설정합니다.

역할 기반 주소 몇 개를 유지하기 위해 사용자별 비용을 내고 있다면 비용 구조가 비효율적일 수 있습니다. TrekMail의 정액제 모델은 사서함이나 이메일 별칭별이 아니라 도메인 기준으로 과금한다고 안내합니다. 원문 작성 시점에 Starter 플랜은 $3.50/month에 최대 50 domains를 지원했습니다. Nano 플랜은 신용카드가 필요 없고 체험 기간도 없는 무료 플랜으로 안내되었으며, 10 domains와 5GB 통합 저장 공간을 제공했습니다.

여러 도메인에서 관리형 SMTP, 통합 저장 공간, 전체 이메일 별칭 관리가 필요하다면 유료 플랜은 원문 작성 시점에 14-day 무료 체험을 제공했으며 시작 시 신용카드가 필요했습니다. 전체 플랫폼은 trekmail.net에서 사용해 보고, 모든 플랜은 trekmail.net/pricing에서 비교하세요.