도메인 이메일 별칭: 다섯 가지 설정 문제와 진단 방법

도메인 이메일 별칭을 설정했습니다 - sales@yourcompany.com은 내 받은편지함으로, support@는 고객지원팀으로 연결했습니다. 관리 화면에서는 정상이지만 문의를 놓치거나 고객이 반송을 받을 수도 있습니다. 지난 세 주 동안 답장을 개인 주소로 보냈다는 사실을 뒤늦게 발견하는 상황은 예시이지 별칭의 필연적인 결과는 아닙니다.

도메인 별칭 문제가 단순한 오타 때문인 경우만 있는 것은 아닙니다. 기존 라우팅 방식과 현대적인 인증 체계 - SPF, DKIM, DMARC - 가 충돌할 수 있습니다. 별칭을 만들 때는 이런 제약을 놓치기 쉽습니다.

550 5.7.520이나 554 5.4.14가 표시되거나, 서버가 250 OK라고 응답했는데도 메일이 보이지 않는다면 원인을 구분해서 살펴보세요. 이 글에서는 대표적인 설정 오류 다섯 가지와 관련 오류 코드, 해결 방향을 설명합니다. 서버의 수락 응답이 최종 배달을 보장하는 것은 아닙니다.

별칭과 사서함의 차이부터 알아야 한다면 도메인 이메일 별칭과 사서함 비교를 먼저 읽어보세요.

도메인 별칭에 문제가 있나요? 여기서 시작하세요

도메인 별칭 장애는 대체로 다음 다섯 유형으로 나눠 살펴볼 수 있습니다. DNS, 라우팅 규칙이나 관리자 정책을 바꾸기 전에 증상에 맞는 항목을 찾으세요. 오류 코드는 조사 방향을 알려주는 단서이지, 원인을 단독으로 확정하는 증거는 아닙니다.

도메인 별칭이 실패하는 이유: 두 가지 발신 주소

이 문제에서는 두 발신자 식별자가 중요합니다. 봉투 발신자(RFC 5321 MAIL FROM)는 서버가 반송 경로에 사용하는 주소이며, SPF는 이 주소의 도메인을 검사합니다. 헤더 발신자(RFC 5322 From:)는 수신자가 Gmail이나 Outlook에서 보는 주소입니다. DMARC는 이 도메인이 SPF 또는 DKIM으로 인증된 식별자와 정렬되는지 확인합니다.

같은 서버에서 sales@를 bob@으로 내부 라우팅하면 일반적으로 새로운 외부 SPF 검사가 발생하지 않지만, 그것만으로 인증 성공이 보장되지는 않습니다. 외부로 전달하면 수신 서버는 전달 서버의 IP를 보게 됩니다. 원래 봉투 발신자가 유지되고 그 IP가 해당 도메인의 SPF에서 허용되지 않으면 SPF가 실패할 수 있습니다. 원 발신자의 정책이 p=reject이고 DMARC도 실패하면 수신자가 거부할 수 있습니다. 다만 유효하고 정렬된 원본 DKIM 서명이 보존되면 DMARC는 통과할 수 있으며, 거부·격리·반송 여부는 정책과 처리 단계에 따라 달라집니다.

설정 오류 1: SRS 없는 외부 전달

도메인 별칭 메일을 Gmail, Yahoo, 개인 Outlook.com 주소로 전달하면서 원래 봉투 발신자를 유지하면 SPF가 실패할 수 있습니다. 엄격한 DMARC 정책에서는 특히 주의해야 합니다. 이 글에서 다루는 2025-2026 시점의 문제 유형이지만 모든 전달 메일이 실패한다는 뜻은 아닙니다. p=reject 환경에서도 보존된 DKIM과 수신자 정책이 결과에 영향을 줍니다.

예를 들어 고객 alice@bank.com이 contact@yourdomain.com으로 메일을 보냅니다. 내 서버가 이를 you@gmail.com으로 전달하면 Gmail은 bank.com의 SPF를 검사합니다. 전달 서버 IP가 bank.com에서 허용되지 않았다면 SPF가 실패합니다. 은행 정책은 p=reject입니다. 정렬된 DKIM도 통과하지 못하면 DMARC가 실패하여 거부되거나 다른 정책 조치가 적용될 수 있습니다. 내 서버가 앞서 보낸 250 OK는 그 시점의 수락만 뜻하며, 이후 반송 알림이 반드시 오는 것은 아닙니다.

봉투 SPF를 위한 해결책: Sender Rewriting Scheme(SRS). SRS는 전달 전에 봉투 발신자를 내 도메인으로 다시 작성합니다.

원래 봉투 주소: alice@bank.com
SRS 적용 후: SRS0=hash=TT=bank.com=alice@yourdomain.com

이제 Gmail은 yourdomain.com의 SPF를 검사합니다. 내 서버가 그 도메인에서 허용되면 SPF가 통과할 수 있습니다. SRS는 서버 수준에서 호스팅 업체나 메일 관리자가 활성화합니다. Postfix와 Exim에서 사용할 수 있는 SRS 통합 방식이 있으므로 실제 환경의 지원 여부를 확인하세요.

중요한 한계가 있습니다. SRS는 새 봉투 주소에 대한 SPF를 통과시킬 수 있지만 원래 From 도메인과의 정렬을 복원하지는 않습니다. 전달 메일의 DMARC 정렬에는 원래 From 도메인과 정렬되는 유효한 DKIM 서명이 보존되면 충분할 수 있습니다. ARC(Authenticated Received Chain)는 이전 인증 결과를 전달하지만, 수신자가 체인을 검증하고 봉인 서비스의 신뢰성을 확인한 뒤 재량으로 활용해야 합니다. 정렬이나 배달을 보장하지 않습니다. 내 도메인이 원래 From과 다르다면 그 도메인으로 다시 DKIM 서명해도 정렬이 복원되지 않습니다.

더 단순한 대안: 가능하다면 불필요한 외부 전달을 없애고 자체 도메인의 실제 IMAP 사서함을 모바일 클라이언트로 사용하세요. 전달은 때때로 2012년식 방식으로 묘사되지만 지금도 유용할 수 있습니다. 다만 인증과 보안 정책을 고려해 설계해야 합니다.

설정 오류 2: Microsoft 365의 외부 전달 차단

외부 전달을 사용하는 도메인 별칭에서 발신자가 550 5.7.520 Access denied를 받는다면 Microsoft 정책을 확인하세요. Exchange Online의 아웃바운드 스팸 필터에서 "Automatic - System-controlled"는 설명된 기본 동작상 자동 외부 전달을 차단합니다. 데이터 유출을 줄이기 위한 조치입니다. 변경하기 전에 현재 테넌트의 정책과 보안 요구사항을 확인하세요.

관리 포털에서 변경하는 방법:

1. Microsoft 365 Defender 포털을 엽니다
2. Email & collaboration → Policies & rules → Threat policies → Anti-spam으로 이동합니다
3. Anti-spam outbound policy (Default)를 편집합니다
4. 보안 정책이 허용하는 경우 "Automatic forwarding rules"를 On - Forwarding is enabled로 설정합니다

특정 사용자에게만 전달을 허용하려면 조직 전체의 기본 정책 대신 해당 계정에만 적용되는 사용자 지정 아웃바운드 정책을 만드세요. 허용 범위를 제한하는 편이 관리하기 좋습니다.

PowerShell 대안: 다음 예시는 조직 전체의 기본 정책에서 전달을 허용합니다. 해당 변경 권한이 있고 조직 차원의 허용이 승인된 경우에만 실행하세요. 일부 계정에만 허용하려면 해당 계정에 적용되는 별도 정책을 사용하세요.

Connect-ExchangeOnline
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode On

설정 오류 3: 라우팅 루프

도메인 별칭의 라우팅 루프에서는 554 5.4.14 Hop Count Exceeded가 발생할 수 있습니다. 메시지가 주소 사이를 오가다가 서버에 설정된 홉 한도에 도달합니다 - 특정 환경에서 15-20홉을 예로 들 수 있지만 보편적인 한도는 아닙니다. 이후 원 발신자에게 반송될 수 있으며 대상 받은편지함에는 도착하지 않습니다.

대상 사서함에 남아 있는 전달 규칙이 흔한 원인입니다.

서버 별칭: info@ → admin@
admin@의 사서함 규칙: 보관을 위해 모든 메일을 info@로 전달
결과: 홉 한도를 넘을 때까지 반복

예를 들어 두 해 전의 부재중 응답이나 모든 메일을 info@로 보관하는 잊힌 전달 규칙도 확인하세요. 두 해라는 기간은 예시이지 정해진 원인은 아닙니다. 서버 측 별칭 규칙과 사서함 규칙을 모두 점검해야 합니다. Exchange에서는 관리 센터의 전송 규칙을, Google Workspace에서는 관련 계정의 "Filters and Blocked Addresses"를 확인하세요.

구조적으로는 서버의 별칭 확장 시점과 사용자 규칙 적용 시점을 확인하세요. 원래 수신 주소를 유지하는 "redirect"가 구성에 따라 같은 별칭을 다시 실행할 수 있습니다. 최종 사서함으로 직접 배달하는 경로를 만들고 되돌아가는 규칙을 제거하세요. 올바른 처리 순서는 메일 시스템마다 다릅니다.

설정 오류 4: "Send As"의 발신자 노출

별칭으로 답장하려는 경우 수신 설정만으로는 충분하지 않습니다. sales@yourcompany.com으로 받은 메일에 답했는데 From에 bob.smith@yourcompany.com이 보이면 의도한 발신자 설정이 작동하지 않은 것입니다. 내 화면에서는 눈치채지 못한 채 기본 주소가 노출될 수 있습니다.

Google Workspace에서 확인할 사항:

1. User Settings → Accounts → "Send mail as"를 엽니다
2. 별칭 주소를 추가합니다
3. 사용하려는 발신자 관계에 맞춰 "Treat as an alias" 선택 해제 여부를 결정하세요. 선택 해제가 항상 개인정보 노출을 막는 것은 아닙니다. 테스트 메일의 From, Reply-To와 다른 헤더도 확인하세요.

Microsoft 365에서 확인할 사항:

M365에서 "Bob on behalf of Sales" 표시는 위임 발송 권한과 관련될 수 있으며, 모든 별칭의 기본 동작은 아닙니다. 사서함 별칭으로 발송하는 기능에는 별도의 조직 설정이 있습니다.

Connect-ExchangeOnline
Set-OrganizationConfig -SendFromAliasEnabled $true

이 설정은 Exchange Online에만 적용되며 온프레미스 Exchange에는 적용되지 않습니다. SendFromAlias는 Send As 및 Send on Behalf 권한과 별개이고 클라이언트 지원도 확인해야 합니다. 따라서 모든 "on behalf of" 표시를 이 명령 하나로 없앨 수 있는 것은 아닙니다.

설정 오류 5: 캐치올과 별칭의 충돌

캐치올(*@domain.com)은 개별 대상이 지정되지 않은 주소를 받아 처리합니다. 라우팅 로직이 구체적인 별칭보다 포괄적인 규칙을 먼저 적용하면 메일이 오류 없이 엉뚱한 받은편지함으로 갈 수 있습니다.

Postfix의 인덱스 맵에서 virtual_alias_maps는 정확한 주소를 먼저 조회한 뒤 도메인 캐치올을 조회합니다. 소스 파일의 단순한 위아래 순서가 조회 우선순위를 결정하지는 않습니다. 아래 예시는 읽기 편하도록 개별 별칭을 위에 배치한 것입니다.

# /etc/postfix/virtual
billing@yourdomain.com    finance@yourdomain.com
support@yourdomain.com   helpdesk@yourdomain.com
@yourdomain.com          catchall@yourdomain.com

postmap /etc/postfix/virtual && postfix reload

이 예시에서 캐치올이 마지막에 있는 것은 설명을 위한 배치이지 인덱스 맵의 필수 조건이 아닙니다. 순서대로 평가하는 PCRE 규칙에서는 규칙 순서가 중요할 수 있습니다. MySQL 기반 맵은 실제 쿼리와 맵 유형이 일치 우선순위를 결정합니다. 설정과 기존 맵을 백업하고 필요한 규칙을 보존하세요. 승인된 변경 전에 수신자 검증과 목적지를 확인하고 검증 후 다시 로드하세요. 행 순서를 바꾸는 것만으로 해결된다고 가정하지 마세요.

심화 진단: 원본 헤더 읽기

반송 없이 메일이 사라진 것처럼 보인다면 스팸함이나 격리함에 도착한 메시지의 원본 헤더를 확인하세요. Authentication-Results에는 수신 서버가 수행한 인증 결과가 표시됩니다. 로그와 메시지 추적을 함께 봐야 하며, 이 헤더 하나가 모든 배달 실패를 설명하는 것은 아닙니다.

Gmail에서는 메시지 열기 → 점 세 개 메뉴 → "Show original"로 이동해 인증 부분을 찾으세요.

인증 실패 - SRS 미적용 가능성:

Authentication-Results: mx.google.com;
  spf=softfail (domain of transition does not designate
    192.0.2.1 as permitted sender) smtp.mailfrom=alice@bank.com;
  dmarc=fail action=quarantine header.from=bank.com;

smtp.mailfrom이 여전히 alice@bank.com입니다. 해당 IP가 전달 서버라면 이 예시는 봉투 발신자가 SRS로 바뀌지 않았음을 보여줍니다.

인증 통과 - 봉투 주소 재작성:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=SRS0=HHH=TT=bank.com=alice@yourdomain.com;
  dmarc=pass header.from=bank.com;

봉투 주소가 바뀌었고 yourdomain.com의 SPF가 통과했습니다. 여기서 DMARC 통과는 SRS 덕분이 아닙니다. 예를 들어 bank.com과 정렬된 유효한 원본 DKIM 서명이 보존되어 있어야 합니다. 그 DKIM 검사 결과는 이 축약된 예시에는 나오지 않습니다.

별칭에 대한 SMTP 수락 동작을 확인하려면 swaks를 사용할 수 있습니다. 이 명령은 테스트 메시지를 보낼 수 있으므로 사용 권한이 있는 서버, 도메인, 발신 주소에서만 실행하세요. 예시 값은 관리하는 테스트 정보로 바꾸고, 허가 없이 타인의 주소를 사용하지 마세요.

swaks --to sales@yourdomain.com --from test@external.com --server mx.yourdomain.com

250 OK는 해당 SMTP 단계에서 수락했다는 뜻이지, 독립된 사서함이 존재하거나 최종 배달이 완료됐다는 증거는 아닙니다. 550 User Unknown은 수신자 거부를 나타내므로 별칭 맵, 대상 사서함, 수신자 정책을 확인하세요.

예방: 라우팅을 단순화하고 홉 줄이기

문제를 만드는 라우팅 구조부터 단순화하면 많은 설정 오류를 예방할 수 있습니다. 다음 두 원칙이 위의 주요 실패 유형에 도움이 됩니다.

원칙 1: 불필요한 외부 전달을 피하세요. 업무 메일은 업무 도메인에 두고 휴대전화의 IMAP 클라이언트로 접근할 수 있습니다. 외부 전달은 SPF 검사를 복잡하게 만들고 외부 사업자의 인프라를 거치게 하며 발신자 설정도 추가로 요구할 수 있습니다. 편의상 이점이 있다면 이러한 위험과 함께 비교하세요.

원칙 2: 별칭 연결을 가능하면 한 홉으로 줄이세요.

홉이 늘면 루프, 헤더 변경, 인증 실패 가능성도 늘어납니다. 한 홉 직접 전달은 설계 목표이며 보편적인 프로토콜 한도는 아닙니다.

임시 주소나 캠페인용 주소에는 매번 별칭을 만드는 대신 플러스 주소 - bob+newsletter@domain.com - 를 고려하세요. 지원 여부와 필요한 설정은 공급자와 환경에 따라 다르므로 TrekMail, Gmail, Exchange에서 각각 확인해야 합니다. 일부 웹 양식은 + 문자를 거부하므로 어디서나 사용할 수 있는 것은 아닙니다.

별칭과 전달의 장단점은 이메일 별칭 전달에서 더 자세히 설명합니다.

가격 구조가 문제인 경우

사용자당 요금제에서는 용도별 사서함 추가 비용이 부담될 수 있지만, 별칭이나 공유 사서함이 항상 별도의 유료 라이선스를 요구하는 것은 아닙니다. 추가 라우팅 때문에 SRS 헤더나 PowerShell 전달 정책을 조사하는 데 몇 시간이 걸릴 수는 있으나 정해진 소요 시간은 아닙니다.

TrekMail은 계정 단위 요금제를 사용하며 모든 도메인에 적용되는 개별 정액 요금은 아닙니다. 과거 Starter($3.50/월) 예시에서는 sales@, support@, billing@를 별도의 IMAP 사서함으로 만들어 각자의 로그인과 발신 주소를 사용하는 구성을 설명합니다. 별칭 라우팅을 줄일 수 있지만 현재 가격, 권한, 사서함 한도와 공유 저장 공간을 확인해야 합니다. 별도 로그인이 독립된 저장 용량을 보장하지는 않습니다. 설명된 Nano 모델에서만 답장을 포함한 모든 발신에 자체 외부 SMTP가 필요하며, 유료 관리형 발신은 실제 권한과 클라이언트 구성에 따릅니다.

과거 대행사 예시에는 Pro($10/월)와 100개 도메인이 나옵니다. 고객을 추가하기 전에 현재 요금, 한도와 권한을 확인하세요. Gmail이나 cPanel에서의 IMAP 마이그레이션에는 승인된 원본 접근, 호환성 확인, 폴더와 메시지 수 검증, 최종 동기화가 필요합니다. 연락처와 일정은 별도로 확인해야 합니다. DNS 전환과 이전을 계획하고 테스트하세요. 운영 환경에 영향이 없다는 보장이나 백업 대체 기능은 아닙니다.

처음 도메인 이메일을 설정한다면 내 도메인으로 이메일 만들기에서 전체 과정을 살펴보세요. 최신 요금 구조와 체험 조건은 TrekMail 가격 안내에서 확인하세요. 원문의 예시에는 신용카드가 필요한 유료 요금제 14일 체험이 나오지만, 가입 시 적용되는 조건은 별도로 확인해야 합니다.

결론

도메인 별칭에서는 외부 전달의 인증 문제, Microsoft 365 정책 차단, 잊힌 규칙의 루프, 잘못된 발신자 설정, 캐치올 충돌 등 다섯 유형을 점검하면 좋습니다. 오류 코드와 헤더로 원인을 좁힐 수 있지만 모든 장애에 고유 코드나 단일 해결책이 있는 것은 아닙니다. SRS는 전달 봉투의 SPF에 도움이 될 뿐 원래 DMARC 정렬을 복원하지 않습니다.

이런 문제가 반복된다면 설정만 볼 것이 아니라 사용자당 요금 구조를 피하기 위해 너무 복잡한 우회 경로를 만들고 있는지도 살펴보세요. 사서함 구조나 가격 모델을 바꾸는 편이 나을 수 있습니다.

전달 아키텍처와 문제 해결의 전반적인 내용은 이메일 전달 설정 및 문제 해결에서 시작하세요.