이메일 전달

포괄 사서함을 안전하게 설정하는 3가지 패턴

작성자: Alexey Bulygin 2026년 3월 27일

포괄 사서함은 존재하지 않는 수신자를 포함해 도메인으로 오는 모든 메시지를 메일 서버가 받도록 합니다. typo@yourdomain.com을 550 오류로 반송하는 대신 서버가 수신합니다. 편리해 보이지만 열린 통로로 스팸, 피싱, 디렉터리 수집 공격이 몰려들 수 있습니다.

보호 장치 없이 포괄 수신을 켠 도메인은 몇 주 안에 발신 평판을 잃을 수 있습니다. 설정 자체보다 운영 문제가 되지 않도록 관리하는 일이 더 어렵습니다.

이 가이드는 Microsoft 365, Linux 스택, Google Workspace에서 포괄 사서함을 더 안전하게 운영하는 세 가지 격리 패턴을 다룹니다. 필요한지 아직 판단 중이라면 먼저 도메인 포괄 이메일 설명을 읽어보세요.

포괄 사서함이란?

포괄 사서함은 도메인으로 전송됐지만 기존 주소와 일치하지 않는 모든 이메일을 받는 하나의 받은편지함입니다. 누군가 misspelled-name@yourdomain.com으로 보내면 반송하는 대신 지정된 사서함에 넣습니다.

문제는 서버가 이제 모든 것을 받는다는 점입니다. 스팸 봇, 피싱 시도, 자동 디렉터리 검색도 모두 250 OK 응답을 받습니다. 격리 규칙이 없으면 해당 트래픽이 실제 메일과 섞여 도메인 평판을 떨어뜨릴 수 있습니다.

핵심 원칙: 기본 받은편지함으로 보내지 않기

이 원칙은 반드시 지켜야 합니다. 포괄 트래픽은 Directory-Based Edge Blocking(DBEB)을 우회하므로 서버가 수신자를 검증하기 전에 본문을 받습니다. 이 흐름을 ceo@company.com이나 활성 받은편지함으로 보내면 늦게까지 발견하지 못할 보안 사각지대가 생길 수 있습니다.

아래 패턴은 모두 같은 원칙을 따릅니다. 포괄 수신 흐름을 운영 메일과 격리하세요.

패턴 1: 격리 보관함(Microsoft 365 / Exchange)

법률 또는 증거개시 목적으로 포괄 메일을 보관해야 하지만 다섯 분마다 알림을 받고 싶지 않은 조직에서 흔히 쓰는 방식입니다.

작동 방식

수신 - 서버가 알 수 없는 수신자의 메일을 받습니다.
표시 - Transport Rule이 외부에서 왔고 유효한 사용자에게 발송되지 않은 메시지를 식별합니다.
억제 - 규칙이 Spam Confidence Level(SCL)을 9, 즉 신뢰도 높은 스팸으로 설정합니다.
저장 - 메시지를 catchall-sink@yourdomain.com 같은 공유 사서함으로 보냅니다.

PowerShell 설정

먼저 Exchange Admin Center에서 도메인을 "Internal Relay"로 설정해 DBEB를 비활성화합니다. 그런 다음 실행하세요.

# Create the sink (shared mailbox - no license needed)
New-Mailbox -Shared -Name "CatchAll Sink" -PrimarySmtpAddress catchall-sink@yourdomain.com

# Create the transport rule
New-TransportRule -Name "Catch-All Routing & Suppression"
    -FromScope "NotInOrganization"
    -SentTo "catchall-sink@yourdomain.com"
    -RedirectMessageTo "catchall-sink@yourdomain.com"
    -SetSCL 9
    -ExceptIfRecipientBelongsTo "All Valid Users Group"

SCL 9를 쓰는 이유는? 이 설정이 없으면 포괄 사서함이 알림 잡음으로 가득 찹니다. SCL 9는 모든 항목을 정크 폴더로 보냅니다. 매시간이 아니라 매주 검토하는 식으로 운영할 수 있습니다.

패턴 2: 태그가 붙은 흐름(Postfix / Linux)

자체 Postfix/Dovecot 스택을 운영한다면 별도 사서함이 과할 수 있습니다. 대신 헤더를 삽입하고 클라이언트 규칙으로 분류하세요.

작동 방식

수신 - luser_relay가 알 수 없는 로컬 수신자의 메시지를 받습니다.
수정 - MTA가 X-Catch-All: True 헤더를 삽입합니다.
필터링 - Sieve 규칙이 메시지를 전용 폴더로 옮깁니다.

Postfix 구성

# /etc/postfix/main.cf
# Route unknown local users to a specific alias
luser_relay = catchall_alias

# /etc/postfix/virtual
# Map the alias to a real user
catchall_alias    realuser@yourdomain.com

중요: luser_relay는 로컬 도메인에서만 작동합니다. 여러 가상 도메인에는 와일드카드와 함께 virtual_alias_maps를 사용하세요.

# /etc/postfix/virtual
@example.com      realuser@example.com

포괄 규칙과 함께 이메일 전달을 설정한다면 가상 맵이 충돌하지 않는지 확인하세요. 겹치는 규칙은 메일 오배달의 흔한 원인입니다.

Sieve 필터

눈으로 포괄 트래픽을 구분하지 말고 자동화하세요.

if header :contains "X-Original-To" "catchall_alias" {
    fileinto "Junk/CatchAll";
    stop;
}

패턴 3: 부분 와일드카드(정규식 라우팅)

진정한 포괄 사서함이 필요하지 않을 때 더 현명한 방식입니다. *@domain.com 전체를 받는 대신 sales-*@domain.com 같은 특정 패턴만 받고 나머지는 거부합니다.

작동 방식

MTA 또는 이메일 공급자가 정규식과 일치하는 주소, 예를 들어 sales-webinar@와 sales-q1@은 받고 admin@이나 hr@ 같은 고위험 대상은 거부하도록 구성합니다.

Google Workspace 설정

Apps > Google Workspace > Gmail > Default Routing으로 이동합니다.
Specify Envelope Recipients에서 "Pattern Match"를 선택합니다.
정규식을 입력합니다. ^sales-.*@yourdomain\.com$
작업을 설정합니다. 봉투 수신자를 sales-team@yourdomain.com으로 변경합니다.

결과: sales-promo@yourdomain.com은 수락되고 admin@yourdomain.com은 550으로 거부됩니다. 이는 디렉터리 수집 공격의 공격 표면을 크게 줄일 수 있습니다.

주소가 실제 이메일 별칭으로도 작동해야 하나요? 공급자가 지원한다면 부분 와일드카드와 별칭 전달을 결합해 유연성을 높일 수 있습니다.

포괄 사서함 라우팅 루프 방지

포괄 사서함 설정에서 매우 위험한 오류는 라우팅 루프입니다. 다음과 같이 생깁니다.

포괄 수신이 ghost@domain.com의 메일을 받습니다.
규칙이 external@gmail.com으로 자동 전달합니다.
Gmail이 SPF/DMARC 실패로 거부합니다.
Gmail이 NDR을 ghost@domain.com으로 반송합니다.
포괄 수신이 반송 메시지를 받습니다.
규칙이 반송 메시지를 Gmail로 전달합니다.
MaxHopCount를 넘을 때까지 반복합니다.

5.4.14 Hop count exceeded 또는 5.4.6 Routing loop detected 같은 오류가 나타납니다. 트래픽이 많은 도메인에서는 몇 시간 안에 발신 대기열이 급증하고 스팸 차단을 유발할 수 있습니다.

예방 점검 목록

헤더 확인 - MTA가 X-Loop 및 Delivered-To 헤더를 준수하는지 확인합니다.
자동 응답 차단 - Auto-Submitted: auto-generated 헤더가 있는 메시지를 건너뛰도록 포괄 규칙을 구성합니다.
Microsoft 365 주의점 - 기본적으로 발신 스팸 정책은 오류 5.7.520 Access denied와 함께 외부 전달을 차단합니다. Outbound Spam Filter Policy에서 활성화해야 하지만 백스캐터 위험이 커지므로 신중히 판단하세요.

공급자별 전달의 함정은 이메일 별칭 전달 가이드에서 자세히 다룹니다.

대부분의 포괄 사서함이 존재하는 이유와 더 나은 선택

근본 원인은 흔히 사용자별 라이선스 비용을 피하려는 것입니다. support@, billing@, jobs@이 필요하지만 Google이나 Microsoft에 사용자당 매월 $18를 지불하고 싶지 않다면 포괄 수신이 영리한 우회책처럼 보입니다.

대체로 그렇지 않습니다. 평판 비용을 낳는 기술 부채가 될 수 있습니다.

사용자별로 과금하지 않는 공급자가 더 적합할 수 있습니다. TrekMail은 설명된 상품에서 사용자별 가격 대신 통합 저장공간을 사용합니다.

Nano 요금제 - $0, 카드가 필요 없습니다.
Starter - 월 $3.50, 14일 체험.
Pro - 월 $10, 14일 체험.
Agency - 월 $23.25, 14일 체험.

현재 요금제 한도 안에서 support@, billing@, jobs@을 실제 사서함이나 사용자 지정 도메인의 별칭으로 만들 수 있습니다. 디렉터리에 존재하므로 서버는 잘못된 수신자를 경계에서 적절한 550 응답으로 거부할 수 있습니다. 이는 도메인 평판 보호에 도움이 되며 Transport Rule, Sieve 필터, 정규식 라우팅의 필요성을 줄일 수 있습니다.

MSP 또는 성장 중인 기업으로서 여러 도메인을 관리한다면 포괄 우회책과 내장 대안을 비교하세요. TrekMail의 포괄 받은편지함 기능은 DNS, 인증, 라우팅이 올바르게 구성됐을 때 안전망을 제공하고 일부 구조적 위험을 줄이도록 설계됐습니다.

마무리

포괄 사서함 자체가 나쁜 것은 아닙니다. 특히 보호되지 않은 포괄 수신이 도메인을 해칠 수 있습니다. Exchange에는 격리 보관함, Postfix에는 태그 흐름, Workspace에는 부분 와일드카드처럼 스택에 맞는 격리 패턴을 고르고 핵심 원칙을 지키세요. 포괄 트래픽을 운영 메일과 섞지 마세요.

상황에 따라 복잡성을 피할 수도 있습니다. 실제 주소를 충분히 저렴하게 제공해 포괄 수신이 필요 없는 공급자를 선택하세요.

이 글 공유하기

게시 공유 공유