SRS 전달과 Postfix 실무 설정 가이드

이메일 전달은 목적지를 지정하면 끝날 것처럼 보입니다. 하지만 SRS 전달(Sender Rewriting Scheme)을 사용하지 않는 경로에서는 SPF가 실패할 수 있습니다. bank.com이 전달 주소로 메일을 보내고 서버가 원래 봉투 발신자를 유지해 중계하면 연결 IP는 중계 서버의 것으로 바뀝니다. bank.com이 그 IP를 허용하지 않으면 SPF가 실패합니다. DMARC가 p=reject이고 유효하며 정렬된 DKIM도 없다면 수신자가 거부할 수 있습니다. 다만 SMTP 거부로 배달 오류가 회신되기도 하므로 언제나 알림 없이 삭제되는 것은 아닙니다.

이 글은 SRS의 실제 구성을 다룹니다. 전체 내용은 이메일 전달 설정과 배달 문제 종합 가이드를 참고하세요. 여기서는 구조, 주소 재작성, Postfix 연동, ARC의 보완 역할을 설명합니다. ARC 역시 DMARC 통과를 보장하지는 않습니다.

SRS 전달이 하는 일

SRS는 중계할 때 봉투 발신자의 원래 도메인을 관리하는 도메인으로 바꿉니다. 해당 도메인의 SPF가 중계 서버 IP를 허용하면 목적지에서 검사가 통과할 수 있습니다. 메일 프로그램에 표시되는 From 헤더는 이 재작성으로 변경되지 않습니다.

SRS 없이 원래 봉투 발신자를 유지하면 SPF 문제가 생길 수 있습니다. SRS는 이 특정 문제에 대응하지만 원래 From과의 정렬이나 모든 인증을 자동으로 유지하지는 않습니다. 필요성은 실제 경로와 발송 권한에 따라 달라집니다.

이메일 발신자를 나타내는 두 계층

SRS를 설정하려면 두 주소 필드를 구분해야 합니다. SPF가 검사하는 봉투 발신자는 전달로 연결 IP가 바뀌어도 그대로 남을 수 있습니다.

• 봉투 발신자(RFC 5321 MAIL FROM): 메일 서버가 배달 오류를 회신할 때 사용하는 주소입니다. SPF는 연결 IP가 이 도메인으로 발송할 권한이 있는지 확인합니다.
• From 헤더(RFC 5322 From): 메일 프로그램에 표시되는 주소입니다. DMARC는 SPF 또는 DKIM으로 인증된 도메인과의 정렬을 확인합니다. SRS는 이 필드를 의도적으로 유지합니다.

다음 예시는 중계 서버가 원래 도메인에서는 허용되지 않고 SRS 도메인에서는 허용된다고 가정합니다.

SRS는 관리하는 도메인을 봉투 주소에 넣어 SPF로 서버를 허용할 수 있게 합니다. 검사가 통과해도 다른 인증과 배달 판단은 남습니다. 재작성된 주소는 일반 화면에는 표시되지 않지만 원본 헤더의 Return-Path에서 확인할 수 있습니다.

SRS 주소의 구성 요소 이해하기

재작성된 주소는 복잡해 보여도 각 부분에 역할이 있습니다. 구조를 알면 배달 오류나 여러 중계 단계를 포함하는 경로를 조사하기가 쉬워집니다.

첫 재작성(SRS0)은 다음 형식입니다.

SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomain

각 구성 요소는 다음과 같습니다.

• Hash: 로컬에서 관리하는 공유 비밀값으로 생성한 축약 HMAC입니다. SHA1은 일부 구현에서 사용하는 알고리즘의 예시입니다. 위조된 SRS 오류 회신 주소를 검출하는 데 도움이 됩니다. 검증이 없으면 그럴듯한 SRS0 주소로 오류 알림을 악용할 수 있지만 HMAC도 모든 공격을 막지는 않습니다.
• Timestamp: base32로 표현한 시간 정보이며 이 예시의 유효기간은 7-21일입니다. 형식과 기간은 구현 및 설정에 따라 다릅니다. 만료된 주소를 거부하면 일부 재사용을 제한하지만 재전송 공격을 완전히 방지하지는 않습니다.
• Origin: 배달 오류가 발생했을 때 원래 발신자를 복원할 정보입니다. 서버가 오류 알림을 받고 역변환해 원래 주소로 회신합니다.
• AnchorDomain: 관리하는 도메인입니다. SPF 발송 권한과 도달 가능한 회신 경로가 필요합니다. 보통 MX를 사용하지만 MX가 없으면 적용 가능한 경우 암시적 A/AAAA 대체 경로가 사용될 수 있습니다.

다음 전달 단계에서는 지원되는 구현에 따라 SRS0을 SRS1로 바꿉니다.

SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomain

SRS1은 주소 증가를 제한하지만 로컬 부분이 64자 이내여야 한다는 RFC 5321의 제한은 계속 확인해야 합니다. 여러 중계 단계에서 발생하는 실패에는 길이 외의 원인도 있습니다.

Postfix 연동: PostSRSd 설정

PostSRSd는 Linux와 Postfix에서 사용할 수 있는 SRS 구현 중 하나입니다. Postfix가 canonical map을 통해 재작성된 주소를 요청합니다. 다음은 개념적인 예시입니다. 변경하기 전에 설치한 버전의 문법, 경로, 권한과 문서를 확인하세요.

단계 1: 기준 도메인 준비

설정 파일을 바꾸기 전에 재작성된 봉투에 사용할 도메인을 준비합니다. 확인 항목은 다음과 같습니다.

• MX 레코드: 배달 오류가 도착할 유효한 경로를 확보해야 합니다. RFC 5321에 따라 MX 또는 적용 가능한 암시적 A/AAAA 대체 경로를 확인하세요. 회신 경로에 도달할 수 없으면 오류 알림이 유실될 수 있습니다.
• SPF 레코드: 수신자는 이 도메인에 대해 중계 IP를 검사합니다. 재작성 자체는 IP에 권한을 부여하지 않으므로 레코드와 실제 검사 결과를 확인하세요.
• 평판: 스팸을 전달하면 서버와 기준 도메인의 평판이 나빠질 수 있습니다. 차단 목록 등록이 필연적인 것은 아니지만 전달 트래픽 관리는 필요합니다.

# Verify SPF record exists for your anchor domain
dig relay.yourdomain.com TXT +short
# Expected output - must include your server IP:
"v=spf1 ip4:203.0.113.10 -all"

# Check MX records exist for bounce delivery
dig relay.yourdomain.com MX +short

단계 2: PostSRSd 구성

패키지와 버전에 따라 설정 파일은 /etc/default/postsrsd(Debian/Ubuntu) 또는 /etc/postsrsd/postsrsd.conf에 있을 수 있습니다. 다음 예시가 모든 버전에 공통인 문법은 아닙니다. 제외 목록의 지원 여부와 동작도 확인하세요.

# Domain that appears in SRS-rewritten envelope senders
SRS_DOMAIN=relay.yourdomain.com

# Secret key path
# In a multi-server cluster, this file MUST be identical on all nodes.
# If nodes have different secrets, they can't validate each other's bounces.
SRS_SECRET=/etc/postsrsd.secret

# Exclusion list - critical config, don't skip this
# Without it, Postfix rewrites local-to-external mail too,
# causing routing confusion and potential delivery loops.
SRS_EXCLUDE_DOMAINS=yourdomain.com,client-one.com,client-two.com

새 공유 비밀값은 승인된 관리 계획상 필요한 경우에만 생성하세요. 주의: 아래 출력 리다이렉션은 기존 파일을 덮어씁니다. 현재 비밀값을 안전하게 백업하고 교체 절차와 전달 중인 오류 알림의 검증을 계획해야 합니다. 파일 소유자와 접근 권한도 확인하고, 운영 시스템에서 그대로 실행하지 마세요.

openssl rand -base64 32 > /etc/postsrsd.secret
chmod 600 /etc/postsrsd.secret

단계 3: Postfix 통합

/etc/postfix/main.cf의 설정을 확인하세요. 예시는 PostSRSd 2.x의 소켓 맵과 1.x의 TCP를 구분합니다. 실제 문법, 소켓 위치와 접근 권한을 설치 환경에 맞게 검증해야 합니다.

# PostSRSd 2.x - modern installs (unix socket maps)
sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender
recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient

# PostSRSd 1.x - legacy installs (TCP)
# sender_canonical_maps = tcp:localhost:10001
# sender_canonical_classes = envelope_sender
# recipient_canonical_maps = tcp:localhost:10002
# recipient_canonical_classes = envelope_recipient

구성을 검증한 뒤 운영 절차에 따라 서비스 재시작을 계획하세요.

systemctl restart postsrsd
systemctl restart postfix

SRS만으로 해결되지 않는 문제와 ARC

SRS로 SPF가 통과해도 DMARC 도메인 정렬은 복구되지 않습니다. DMARC는 From 도메인이 SPF 인증 도메인 또는 유효한 DKIM 서명 도메인과 정렬되어야 합니다. 이 예시에서는 SPF가 relay.yourdomain.com을 인증하므로 client.com과 정렬되지 않습니다. 따라서 DMARC가 통과하려면 유효하며 정렬된 DKIM이 필요합니다.

전달 과정에서 서명 대상 부분을 바꾸고 정규화 후에도 차이가 남으면 DKIM이 무효화될 수 있습니다. Subject의 “External Sender” 접두사, 본문에 추가한 수신 거부 안내, MIME 경계 변경 등이 예시입니다. 모든 변경이 반드시 서명을 무효화하는 것은 아닙니다. DKIM이 무효하고 SPF도 정렬되지 않으면 DMARC가 실패하고 수신자가 정책에 따라 거부할 수 있습니다.

RFC 8617의 ARC(Authenticated Received Chain)는 실제로 관찰한 인증 결과를 서명된 체인으로 전달합니다. 서명자를 신뢰하는 수신자는 DMARC 실패가 있어도 이 정보를 수신 판단에 활용할 수 있습니다. ARC가 정렬을 복구하거나 배달을 강제하는 것은 아닙니다.

ARC가 추가하는 헤더는 다음과 같습니다.

• ARC-Authentication-Results: 서버가 관찰하고 기록한 인증 결과
• ARC-Message-Signature: 처리 중 서명 시점의 헤더와 본문에 대한 서명
• ARC-Seal: 중계 단계 사이의 체인 구성 요소를 연결하는 봉인

SRS는 봉투를 처리하고 ARC는 인증 경과를 전달합니다. Google과 Microsoft처럼 엄격한 수신자에게 보완적으로 사용할 수 있지만 항상 둘 다 필요하거나 함께 사용하면 충분한 것은 아닙니다. SPF가 정렬되지 않고 유효하며 정렬된 DKIM도 없다면 SRS만으로 DMARC를 통과할 수 없습니다.

SPF의 공식 명세는 RFC 7208입니다.

도입 전에 알아둘 제공업체별 문제

SRS와 ARC를 올바르게 구성해도 제공업체의 정책으로 경로가 차단될 수 있습니다. 모든 문제가 인증이나 로컬 설정 때문인 것은 아닙니다. 운영에 적용하기 전에 현재 조건을 확인하세요.

M365의 550 5.7.520을 SRS 문제로 조사하면 시간을 낭비할 수 있습니다. 외부 전달 차단을 나타내는 경우 목적지가 아니라 메일이 출발하는 테넌트의 정책입니다. 발신 테넌트의 권한 있는 관리자가 Defender에서 전달 권한을 검토해야 합니다. 보안 제한을 우회하지 마세요.

SRS 동작 검증

운영에 사용하기 전에 경로를 테스트하고 원본 헤더를 확인하세요. SRS Return-Path는 경로 어딘가에서 재작성되었음을 보여주지만 인증과 오류 회신도 검사해야 합니다. 원래 주소가 유지되면 제외 규칙, 다른 경로 또는 연동 오류도 가능하므로 PostSRSd가 중단되었다고 단정할 수 없습니다.

1. Return-Path 확인

ProtonMail 같은 외부 계정에서 전달 주소로 테스트 메일을 보내세요. 목적지에서 메시지 원본을 열고 Return-Path를 찾습니다.

• Return-Path: <SRS0=...@yourdomain.com> → SRS 재작성이 있음. SPF 결과와 역변환도 확인
• Return-Path: <alice@protonmail.com> → 이 경로에서는 재작성이 보이지 않음. 제외 규칙, 연동과 다른 경로 확인

2. 기준 도메인 DNS 확인

# SPF record must cover your server IP
dig relay.yourdomain.com TXT +short

# MX record must exist so bounces can arrive
dig relay.yourdomain.com MX +short

3. Postfix 로그 확인

grep -E "srs_forward|canonical" /var/log/mail.log | tail -50

SRS 요청과 재작성된 주소 응답을 찾으세요. 연결 거부는 서비스 중단뿐 아니라 소켓, 설정 또는 네트워크 제한으로도 발생합니다. 확인 방법 중 하나는 systemctl status postsrsd입니다.

4. 연결 및 TLS 확인

SRS, 네트워크와 TLS 장애는 비슷한 증상을 보일 수 있습니다. SMTP 도달 여부와 TLS 협상을 따로 확인하세요.

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

시간 초과는 네트워크, 포트 제한이나 서버 도달 불가로도 발생합니다. 협상 실패는 SRS와 별개의 TLS 문제를 나타낼 수 있지만 시간 초과만으로 원인을 확정할 수는 없습니다.

전달 대신 직접 호스팅을 선택할 때

SRS, ARC, 기준 도메인, 비밀 키, 제외 목록과 평판에는 관리 작업이 따릅니다. 다른 제공업체의 메일함별 비용을 피하려고 sales@를 개인 받은편지함으로 전달하기도 합니다. 이 예시에서는 사용자당 월 $6를 절약합니다. 한 주소에는 합리적이어도 열 개가 되면 관리 비용이 더 클 수 있습니다.

이메일 별칭 전달의 장단점 가이드는 전달이 유용한 경우와 복잡성이 쌓이는 경우를 비교합니다. 별칭과 메일함 선택 가이드는 주소 구조 결정에 도움이 됩니다.

소개하는 Pro 요금제(월 $10)는 100개 도메인과 50GB 공유 저장 공간을 제공합니다. 현재 가격과 한도를 확인하세요. sales@, support@, info@를 설명된 요금 체계 내에서 사용자당 과금 없이 IMAP 메일함으로 운영하면 해당 외부 전달 경로를 유지할 필요가 없습니다. 용량은 각 메일함의 전용 공간이 아니며 메시지 보존은 설정과 운영에도 달려 있습니다.

여러 도메인을 한 목적지로 모으는 등 전달이 필요하면 소개된 Pro와 Agency 조건에는 서버 측 SRS 재작성과 OpenARC 서명이 포함됩니다. 목적지를 설정하기 전에 현재 지원 여부를 확인하세요. 배달을 보장하는 기능은 아닙니다. 자체 SMTP를 쓰는 Nano에 관리형 전달 권한이 자동으로 생기는 것도 아닙니다. 자체 발신 인프라에 SRS를 구현하려면 위 PostSRSd 예시처럼 호환성과 설정을 검증해야 합니다.

Gmail 경로에 대해서는 도메인 이메일을 Gmail로 전달하는 가이드가 관련 문제와 검증 절차를 설명합니다.

핵심 요약

SRS 전달은 서버를 허용하는 도메인으로 SPF를 검사하도록 봉투 발신자를 바꿉니다. 바꾸지 않으면 SPF가 실패할 수 있지만 모든 메시지가 반드시 실패하지는 않습니다. PostSRSd는 Postfix 연동 방법 중 하나입니다. 유효한 회신 경로, SPF, 비밀 키, 지원되는 제외 규칙과 main.cf의 canonical map을 버전에 맞게 준비하세요. DKIM이 무효화되는 경로에서는 ARC의 추가 정보도 검토할 수 있지만 정렬이나 배달을 보장하지는 않습니다.

변경 후에는 매번 원본 헤더를 확인하세요. 관리 부담이 라이선스 절약보다 크다면 직접 호스팅하는 메일함을 검토하세요. TrekMail 요금제에서 소개된 Nano는 카드가 필요 없지만 활성화와 기능은 현재 조건에 따라 달라집니다. Pro는 지원되는 경로의 SRS와 ARC 관리로 기술 작업의 일부를 대신할 수 있습니다.