도메인 catch-all 설정과 배달 위험

누군가 saels@로 잘못 입력했지만 의도한 주소는 sales@였을 때 문의를 놓치지 않으려고 도메인 catch-all을 활성화할 수 있습니다. 하지만 알 수 없는 수신자도 허용하면 스팸 발송자의 자동 탐색 메시지도 들어올 수 있습니다. 위조 발신자에게 보내는 오류 알림, 자동 회신 루프와 외부 전달 문제는 관리할 위험입니다. 필연적인 결과는 아니지만 적절한 구조와 통제가 필요합니다.

“catch-all을 켜고 받은편지함으로 보내기”만으로는 운영을 설명하기 어렵습니다. 이 글은 격리용 메일함, Postfix 패턴 라우팅, 루프 방지와 외부 전달의 인증 문제를 다룹니다. 기초는 이메일 전달 설정 가이드를 참고하세요. 여기서는 도메인 catch-all을 자세히 설명합니다.

도메인 catch-all이란?

catch-all은 메일함, 별칭, 그룹 등 유효하게 구성된 목적지와 일치하지 않는 도메인 주소를 처리하는 메일 서버 규칙입니다. 알 수 없는 수신자에게 550 User Unknown을 반환하는 대신 수신자 명령에 250 OK로 응답하고 대체 목적지로 라우팅할 수 있습니다. 수신자 허용과 메시지 데이터의 최종 수락은 별개입니다. catch-all은 SMTP 봉투의 수신자를 처리하며 그 자체로 발신자 인증을 깨지는 않습니다.

봉투와 헤더를 구분해야 하는 이유

두 계층을 구분하면 라우팅과 인증을 이해하기 쉽습니다. 다만 모든 catch-all 문제가 이 차이에서 비롯되지는 않습니다. 며칠의 조사와 두 분의 수정이라는 대비는 예시이지 예측이 아니며 실제 해결 시간은 원인에 따라 달라집니다.

RFC 5321은 SMTP 봉투와 세션에서 교환하는 RCPT TO, MAIL FROM 명령을 정의합니다. RFC 5322는 메일 프로그램에 표시되는 To:, From: 등의 메시지 헤더를 정의합니다.

catch-all은 알 수 없는 봉투 수신자를 다른 목적지에 매핑하면서 헤더를 유지할 수 있습니다. SPF는 MAIL FROM, 또는 해당되는 경우 HELO 식별자에 대해 연결 IP를 평가합니다. DKIM은 서명된 메시지 부분의 암호학적 서명을 검증합니다. DMARC는 적어도 하나의 SPF 또는 DKIM 검사가 통과하고 해당 도메인이 표시된 From과 정렬되어야 합니다. 수신자 변경만으로 이 검사들이 실패하지는 않습니다. 반면 외부 전달이 연결 IP를 바꾸면 SPF 문제가 생길 수 있습니다.

외부 전달에서 발생할 수 있는 문제

catch-all을 Gmail이나 Outlook.com으로 전달하면 SMTP 단계가 추가됩니다. 다음은 가능한 실패 사례이며 모든 전달의 결과는 아닙니다.

원래 발신자: client@bank.com(IP: 1.2.3.4)
서버가 typo@yourdomain.com을 허용하고 you@gmail.com으로 전달
Gmail은 중계 서버 IP에서 연결을 받지만 봉투 발신자는 bank.com으로 유지됨
bank.com의 SPF가 중계 IP를 허용하지 않으면 SPF 실패
DMARC p=reject이고 유효하며 정렬된 DKIM도 없으면 수신자가 거부할 수 있음. 다만 배달 오류가 발신자에게 회신될 수도 있음

catch-all이 잘못 입력한 수신자를 받아도 전달 과정이 다른 문제를 추가할 수 있습니다. 전달이 필요하면 SRS(Sender Rewriting Scheme)나 재작성을 관리하는 서비스를 검토하세요. SRS는 원래 From과의 정렬을 복구하지 않고 배달도 보장하지 않습니다. 소개된 TrekMail의 이메일 별칭 전달은 지원되는 요금제와 경로에서 서버 측 처리를 제공합니다. 현재 조건을 확인하세요.

catch-all의 세 가지 위험

백스캐터, 자동 회신 루프와 전달 시 SPF/DMARC 문제는 세 가지 주요 확인 사항입니다. 설정 변경 전에 함께 검토하세요. 하나만 해결하면 다른 문제가 생길 수 있습니다. 다섯 분의 작업이 일주일의 복구로 이어진다는 대비는 주의용 예시이지 정해진 소요 시간이 아닙니다.

1. 백스캐터와 평판 위험

메시지 데이터 뒤에 250 OK로 최종 수락한 메일을 나중에 배달하지 않고 MAIL FROM으로 오류 알림을 보내면 백스캐터가 될 수 있습니다. 발신자가 위조되었다면 무관한 사람이 알림을 받습니다. 이런 원치 않는 트래픽은 평판을 해치고 차단 목록 등록에 영향을 줄 수 있지만 며칠 안에 반드시 등록되는 것은 아닙니다.

허용하지 않는 수신자는 SMTP 세션의 해당 250 OK 전에 거부하거나 수락한 메일을 관리되는 격리 공간에서 처리하세요. 위조되었거나 검증할 수 없는 발신자에게 원치 않는 알림을 보내지 마세요. 정당한 배달 오류 알림을 일괄 금지하거나 유효한 메일을 기본적으로 알림 없이 삭제하라는 뜻은 아닙니다.

2. 자동 회신 루프(Exchange 오류 5.4.14)

catch-all 수신 메일함에 부재중 회신이 켜져 있으면 random@yourdomain.com으로 온 스팸에 위조 발신자 대상 회신이 나갈 수 있습니다. 경로에 따라 오류 알림과 회신이 random@yourdomain.com으로 돌아와 루프를 만들 수 있습니다. Exchange가 550 5.4.14 Hop count exceeded - possible mail loop를 기록하기도 하지만 모든 자동 회신이 이 경로를 만드는 것은 아닙니다.

지원되는 Exchange 환경에서는 catch-all 트래픽에 X-Auto-Response-Suppress: All을 적용하는 방법을 검토하세요. 회신, 배달 알림과 읽음 확인 중 실제로 무엇이 억제되는지 검사해야 합니다. 동작은 모든 시스템에 공통되지 않으며 이 헤더가 별도의 루프 방지를 대체하지는 않습니다.

3. 주소 수집 공격(DHA)

모든 수신자에게 250 OK를 반환하면 스팸 발송자가 admin@, hr@, ceo@, invoice@ 등의 수천 가지 조합을 시도할 수 있습니다. catch-all은 서버가 주소를 허용한다는 사실만 보여주며 실제 메일함 목록을 알려주지는 않습니다. 스팸이 늘고 몇 년씩 이어질 가능성은 있지만 실제 주소가 검증되었다거나 그 기간 동안 반드시 공격받는다고 단정할 수는 없습니다.

대응 방법 중 하나는 아래 전략 2처럼 특정 패턴만 허용하는 것입니다.

전략 1: 전용 격리 메일함

알 수 없는 수신자의 메일을 신중하게 처리하고 별도 목적지를 고려하세요. 격리 메일함은 보안 샌드박스가 아닙니다. 접근을 제한하고 필터를 적용하며 전달과 자동 회신이 꺼져 있는지 확인해야 합니다. 유용한 메일을 일상 업무와 분리해 검토할 수 있지만 메일함만으로 발신 평판이 보호되지는 않습니다.

처리 예시:

수락: 정한 규칙에 따라 *@domain.com 처리
식별: 알 수 없는 수신자를 메일함, 별칭, 그룹 등 유효한 목적지와 구분
분리: catchall_sink@domain.com 같은 전용 메일함으로 라우팅
억제: 지원 환경에서 스팸 신뢰도 9와 X-Auto-Response-Suppress: All 검토

주간 검토를 계획하고 양과 긴급도에 맞춰 빈도를 조정할 수 있습니다. 정상 메일을 적절한 받은편지함으로 옮기고 나머지는 정책에 따라 처리하세요. 용량, 보존 기간과 접근 권한도 확인해야 합니다. 방치된 격리 메일함은 복구하려던 문의를 잃을 수 있습니다.

Microsoft 365 / Exchange Online 전송 규칙

M365 설정을 무작정 변경하지 마세요. Internal Relay는 Directory Based Edge Blocking(DBEB)을 비활성화하지만 그 자체로 catch-all을 구현하지는 않습니다. 다른 수신자를 처리할 승인된 자체 메일 서버와 커넥터가 있는 해당 토폴로지에서만 이 도메인 유형을 사용하고, 모든 수신자를 여기서만 호스팅할 때의 대안으로 쓰지 마세요. 관리자는 모든 유효한 수신자를 검토해야 하며 그룹 구성원 여부만으로 미등록 수신자를 판별할 수는 없습니다. 다음은 조정하고 시험할 개념적인 규칙이며 보편적인 절차가 아닙니다.

조건	값	목적
발신자 위치	조직 외부	예시를 외부 트래픽으로 한정
수신자가 다음의 구성원이 아님	All Valid Users	구성된 메일함, 별칭, 그룹과 경로 유지
메시지 리디렉션 목적지	catchall_sink@domain.com	선택된 트래픽을 전용 메일함으로 전송
SCL 설정	9	높은 확신도의 스팸 분류 요청. 스팸함, 격리와 알림은 실제 분류 결과와 정책에 따라 달라짐
헤더 설정	X-Auto-Response-Suppress: All	지원되는 자동 회신을 억제하고 별도 루프 방지도 적용

도메인 유형을 바꾸기 전에 규칙과 경로를 계획하고 시험하세요. 순서와 실행 방법은 기존 구성에 따라 다릅니다. Internal Relay 전환 중 필요한 통제가 없는 구간을 만들지 마세요.

전략 2: Postfix PCRE로 패턴 제한

제한된 패턴은 모든 사전 공격 후보를 받지 않고 특정 주소군을 처리할 수 있습니다. 예상 패턴을 정의한 다음 다른 수신자가 SMTP 수신자 검증에서 거부되는지 확인하세요. 맵에 와일드카드가 없다는 사실만으로 거부가 보장되지는 않습니다. 허용 범위를 줄일 수 있지만 대부분의 공격을 차단한다는 보장은 아닙니다.

Postfix virtual alias map에서 PCRE(Perl Compatible Regular Expression)를 사용하는 예시입니다. PCRE 맵 지원이 설치되어 있는지 확인하고, 기존 수신자 클래스와 받아내려는 오타까지 포함해 패턴을 시험하세요.

# /etc/postfix/virtual_pcre

# Catch any address starting with "sales-" (sales-q1, sales-webinar, etc.)
/^sales-.*@yourdomain\.com$/    sales-team@yourdomain.com

# Catch common "support" typos (suport, supprt)
/^supp?o?rt@yourdomain\.com$/   support@yourdomain.com

# No wildcard below = hard 550 reject for everything else

/etc/postfix/main.cf 연동을 확인하세요. 다음 줄은 기존 값을 대체하므로 설정을 백업하고 기존 맵과 적절하게 병합해야 합니다. 확인 없이 덮어쓰지 마세요.

virtual_alias_maps = pcre:/etc/postfix/virtual_pcre

테스트와 승인 후 설정을 다시 로드하세요: postfix reload

범위를 넓히려면 전역 catch-all 대신 알려진 주소를 보수적으로 지정하는 패턴을 고려하세요.

/^(info|contact|hello|team)@yourdomain\.com$/    info@yourdomain.com

예상 주소를 처리하면서 모든 조합이 유효하다고 표시하지 않는 구성이 가능합니다. 다만 결과는 수신자 클래스, 다른 맵과 검증 규칙에도 달려 있습니다.

catch-all이 적합한 경우

catch-all은 범위를 정한 용도에 적합할 수 있습니다. 이유와 통제가 명확하면 지속 사용도 선택지입니다. 세 가지 사례와 별도로 검토할 이유를 소개합니다.

합리적인 용도:

단기 캠페인 주소: promo-jan@, promo-feb@, promo-mar@를 하나씩 만들지 않고 처리
고객 초기 설정: 정식 주소 구성이 끝나기 전에 메일 수신
기존 시스템 마이그레이션: 전환 중 아직 모두 파악하지 못한 활성 주소의 메일 수신

이 세 경우에는 사용 기간을 제한해 계획하세요. 필요한 주소를 파악하면 메일함이나 별칭을 만들고 catch-all을 종료할지 검토합니다. 주소 구조는 도메인 별칭과 메일함 비교를 참고하세요.

다시 검토할 이유: 별칭 세 개 때문에 사용자당 월 $6를 내기 싫다는 경우입니다. 별칭에 반드시 유료 라이선스가 필요한 것은 아닙니다. 제공업체 조건을 확인하고 가격 문제를 직접 해결하세요. 여섯 달 뒤에도 남을 수 있는 운영 복잡성으로 덮지 않는 편이 좋습니다.

TrekMail로 주소 관리 설계하기

사용자당 비용 때문에 명시적인 주소 대신 catch-all을 선택하기도 합니다. TrekMail은 공유 용량과 도메인 및 메일함 한도가 있는 계정 요금제를 제공합니다. 일반적인 도메인별 개별 요금이나 무제한 주소를 뜻하지는 않습니다. 현재 조건으로 메일함과 별칭 비용을 비교하세요.

	사용자당 가격 예시	TrekMail 요금제에 따른 구성
sales@, support@, info@ 메일함	각 메일함에 별도 라이선스가 필요하면 월 비용의 3×	선택한 요금제 한도 내 이용
별칭 대신 catch-all 사용	절약액은 실제 별칭 가격에 따라 다름	비용과 별도로 평가할 라우팅 선택
Gmail이나 Outlook으로 전달	SPF/DMARC 문제를 추가할 수 있음	지원 요금제와 경로에서 SRS 관리. 배달 보장은 아님
기존 호스트에서 이전	수동 IMAP 동기화가 필요할 수 있음	현재 제공 여부와 요금제에 따른 서버 측 이전 도구

과거 Starter 예시(월 $3.50)는 요금제 한도 내 주소 관리를 설명하며 현재 가격과 기능은 따로 확인해야 합니다. catch-all은 일상적으로 쓰는 명시적 주소를 대체하지 않습니다. 설명된 Nano 모델에서는 답장을 포함한 모든 발신에 자체 외부 SMTP가 필요하고 유료 관리형 발신은 실제 권한에 따릅니다. 이전 시에는 승인된 원본 접근, 호환성, 복사 검증과 최종 동기화가 필요하며 연락처와 일정은 별도로 확인해야 합니다. 도메인 이메일 설정 가이드는 DNS, SPF/DKIM/DMARC와 메일함을 다룹니다.

catch-all 활성화 전 체크리스트

활성화하기 전에 다음을 확인하세요. 통제가 부족하면 배달 문제와 추가 작업이 생길 수 있습니다.

SMTP 수신자 검증: 허용 패턴 밖의 수신자는 세션 중 거부합니다. 수락한 메일로 위조 발신자에게 원치 않는 알림을 보내지 않습니다.
자동 회신 통제: 지원 환경에서 X-Auto-Response-Suppress: All을 검토하고 실제 동작을 확인합니다. 헤더에 의존하지 않는 루프 방지도 준비합니다.
격리 공간 준비: 알 수 없는 수신자용 전용 메일함을 업무 받은편지함과 분리하고 용량과 접근 권한을 갖춥니다.
분류와 검토 방법: 신중한 정책을 적용하고 정상 메일을 찾아 처리할 수 있도록 정기적으로 검토합니다.
SPF/DMARC 검증: SRS를 사용한다면 실제 재작성된 봉투 발신자 도메인의 SPF가 연결 IP를 허용하는지 확인합니다. DMARC에는 SPF나 DKIM 중 하나 이상의 검사가 성공하고 정렬되어야 합니다. 온전히 유지된 정렬된 DKIM은 SRS 없이도 통과할 수 있으며, SRS만으로 원래 From과의 정렬을 복구하지는 않습니다.
전체 지정보다 제한된 패턴: 지원되는 환경에서는 특정 패턴을 검토하고 수신자 검증을 시험합니다.
백스캐터 방지: 위조 발신자에게 원치 않는 알림을 보내지 않습니다. 정상일 가능성이 있는 메일은 정책에 따라 보관하고 검토하며 기본적으로 알림 없이 삭제하지 않습니다.