전달을 설정해 contact@yourdomain.com의 메일을 Gmail로 받습니다. 한 주 동안 잘 되다가 일부 고객 메일이 도착하지 않고 반송 알림도 바로 찾지 못할 수 있습니다. 로그에는 550 5.7.1 Unauthenticated email 또는 550 5.7.26 This message does not have authentication information가 나타납니다. 이런 응답에는 여러 원인이 있으며 SRS 이메일 전달은 그중 하나에 대응합니다. 전달 서버는 새 SMTP 연결을 열지만 엔벌로프 발신자에는 원래 도메인이 남습니다. 새 IP가 SPF에서 허용되지 않으면 검증이 실패할 수 있습니다. DMARC가 p=reject이고 정렬된 SPF나 DKIM이 모두 성공하지 못하면 수신 정책에 따라 거부될 수 있습니다. SMTP 거부가 반송 알림으로 이어지기도 하므로 항상 흔적 없이 사라지는 것은 아닙니다.
SRS를 켜도 모든 문제가 해결되지는 않습니다. 올바르게 재작성해도 DMARC 정렬은 실패할 수 있습니다. 전달 실패 원인과 진단 방법은 이메일 전달 설정 및 문제 해결 가이드를 참고하세요.
SRS 이메일 전달이란?
SRS 이메일 전달은 Sender Rewriting Scheme을 이용해 서버가 메일을 전달할 때 엔벌로프 발신자를 바꿉니다. 기술적인 반환 주소에 전달 서비스 도메인을 사용해 그 도메인으로 SPF를 검증하게 합니다. 성공 여부는 DNS와 실제 발송 IP의 허용 여부에 달려 있습니다. 화면에 보이는 From은 원래 발신자 그대로입니다. SRS는 암호화하거나 헤더를 숨기는 기능이 아닙니다. 엔벌로프 정보는 전체 헤더에서 읽을 수 있습니다.
Postfix는 postsrsd 데몬으로 SRS를 연동할 수 있습니다. Microsoft 365와 일부 관리형 이메일 서비스도 하이브리드 구성을 포함한 특정 경로에서 지원합니다. 버전, 커넥터, 설정을 확인하세요. SRS는 SMTP 전달과 SPF의 관계를 보완하지만 모든 DMARC 요구를 해결하지는 않습니다.
전달이 실패할 수 있는 이유: 새로운 SMTP 홉
전달은 SMTP 홉을 추가하므로 새 IP가 허용되지 않으면 SPF가 실패할 수 있습니다. 이메일에는 서로 다른 두 발신자 정보가 있습니다. Header From(RFC 5322)은 사용자가 보는 발신자로, 예를 들면 From: alice@client.com입니다. Envelope Sender(RFC 5321, MAIL FROM)는 SPF 확인과 반송에 사용하는 기술적인 반환 주소입니다. 일반 화면에서는 보이지 않더라도 전체 헤더에서 확인할 수 있습니다.
다음은 가능한 실패 과정이며 모든 전달에서 반드시 발생하는 결과는 아닙니다.
- Alice가
alice@client.com에서 보냅니다. SPF가 발송 서버를 허용하므로 전달 서버에 도착할 때 검증이 성공합니다. - 전달 서버가
you@gmail.com으로 새 SMTP 연결을 엽니다. 이제 연결은 전달 서버 IP에서 옵니다. - 엔벌로프 발신자는
alice@client.com그대로지만, 예시에서는 client.com의 SPF가 전달 서버 IP를 허용하지 않습니다. - Gmail이
client.com의 SPF를 확인하고 연결 IP에 대한 허용이 없어 실패합니다. client.com이p=reject를 게시하고 정렬된 DKIM도 성공하지 못하며 수신자가 거부 정책을 적용하면 메일이 거부될 수 있습니다. 전달 서버는 응답을 받아 반송 알림을 보낼 수도 있습니다.
SRS가 SPF 문제에 대응하는 방식
SRS 이메일 전달은 재발송 전에 엔벌로프 발신자를 전달 서비스 도메인으로 바꿉니다. 수신자는 그 도메인의 SPF를 확인합니다. 현재 레코드가 실제 발송 IP를 허용하면 성공할 수 있습니다. Header From은 변하지 않습니다. 반송은 전달 서비스로 돌아오며, 서비스는 SRS 주소를 검증하고 설정에 따라 원래 발신자에게 전달할 수 있습니다.
SRS 주소 형식 이해하기
SRS는 단순한 반환 주소를 인증 코드가 포함된 구조화된 주소로 바꿉니다. 재작성이지 암호화는 아닙니다.
SRS 적용 전:MAIL FROM: <alice@client.com>
SRS 적용 후:MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>
| 구성 요소 | 예시 | 역할 |
|---|---|---|
SRS0 | 접두사 | 첫 재작성을 나타냅니다. 다음 전달에서는 구현에 따라 SRS1을 사용합니다. |
4fac | 인증 코드 | 예시에서는 로컬 비밀 키를 사용하는 SHA1 기반 축약 HMAC입니다. 위조 반송 위험을 줄이지만 모든 위조를 막는 것은 아닙니다. |
PM | 시간 정보 | 예시에서는 순환하는 Base32 타임스탬프입니다. 만료로 오래된 주소 재사용을 제한하지만 설정에 따라 달라지며 모든 재전송 공격이나 백스캐터를 막지는 못합니다. |
client.com | 원래 도메인 | 반송 경로를 복원할 수 있도록 원래 발신자 도메인을 보존합니다. |
alice | 원래 사용자 | 원래 발신자 주소의 로컬 부분입니다. |
@yourdomain.com | 재작성 도메인 | 전달 서비스 도메인입니다. SPF가 새 발송에 사용하는 IP를 허용해야 합니다. |
두 번째 전달(A → B → C)에서는 서비스가 SRS1을 사용할 수 있습니다. 전체 SRS0 문자열을 반복해서 감싸는 대신 주소가 길어지는 것을 제한합니다. 세부 사항은 해시와 타임스탬프만으로 설명되지 않으며 구현마다 다릅니다. 로컬 부분의 64자 한도는 RFC 5321에 따라 여전히 확인해야 합니다. SRS가 모든 주소의 길이를 보장하지는 않습니다.
SRS만으로 부족한 이유: DMARC 문제
SRS 이메일 전달을 켜도 메일이 스팸으로 분류되거나 거부될 수 있습니다. SRS가 SPF를 성공하게 해도 DMARC 정렬을 유지하는 것은 아닙니다. DMARC는 Header From과 정렬된 도메인에서 SPF 또는 DKIM이 성공해야 합니다. 재작성 후 SPF가 인증하는 도메인은 yourdomain.com이지만 Header From은 client.com 그대로입니다. 예시의 두 도메인은 정렬되지 않습니다. 다만 완화된 정렬 규칙에서는 같은 조직 도메인에 속하는 다른 구성이 정렬될 수 있습니다.
SPF가 정렬되지 않아도 정렬된 DKIM이 성공하면 DMARC는 성공할 수 있습니다. 전달 중 변경이 서명을 손상하는지는 서명한 부분과 정규화 방식에 따라 다릅니다.
- 서명 대상 제목에
[EXTERNAL]을 추가하기 - 서명된 본문에 백신 안내나 법적 고지 추가하기
- 8-bit 인코딩을 7-bit로 변환하기
- MIME 경계 변경하기
이런 변경이 모든 서명을 반드시 무효화하지는 않습니다. 서명 대상과 정규화가 결과를 결정합니다. 정렬된 SPF와 DKIM이 모두 성공하지 못하면 DMARC는 실패합니다. 이때 SRS가 정상 작동해도 수신 정책에 따라 필터링하거나 거부할 수 있습니다.
ARC(Authenticated Received Chain)의 역할
ARC(RFC 8617)는 전달 서비스가 실제 관찰한 인증 결과를 기록하게 합니다. 검증과 봉인 시점은 처리 경로에 따라 다릅니다. 세 가지 헤더를 추가합니다.
- ARC-Authentication-Results: 실패를 포함해 관찰된 SPF, DKIM, DMARC 결과를 기록합니다
- ARC-Message-Signature: 서명 생성 시점의 헤더와 본문에 서명합니다. 이후 서명 대상이 바뀌면 무효화될 수 있습니다
- ARC-Seal: 새 ARC 세트를 기존 체인에 암호학적으로 연결합니다
체인이 유효하고 수신자가 봉인한 서비스를 신뢰하면 DMARC 실패 후에도 수락할지 판단할 때 ARC를 참고할 수 있습니다. ARC는 정렬 자체를 바꾸지 않으며 전달을 보장하지 않습니다. Gmail은 2019년부터 실제 서비스에서 ARC 봉인을 평가해 왔습니다.
2026년의 견고한 구성은 SRS 이메일 전달, DKIM 서명 부분 보존, 필요하고 지원되는 경우 ARC를 조합할 수 있습니다. 세 가지가 항상 모두 필요하거나 충분한 것은 아닙니다. 원래 인증과 수신 정책이 중요합니다.
플랫폼별 SRS 설정
절차는 플랫폼마다 다릅니다. Postfix는 외부 데몬을 사용하는 구성이 있고 Microsoft 365에는 전달 정책과 커넥터가 있으며 Google Workspace는 관리형 기능과 제한을 적용합니다. 현재 설정을 확인하고 기본적으로 모두 꺼져 있거나 켜져 있다고 가정하지 마세요.
직접 관리하는 Linux의 Postfix
Postfix의 SRS 연동 예시는 postsrsd입니다. 다음은 호환되는 배포판용 예시이며 승인된 변경 전에 적합성을 확인해야 합니다.
apt-get install postsrsd다음은 /etc/postfix/main.cf에 postsrsd TCP 맵을 설정하는 이전 방식의 예시입니다. 최신 버전에서는 다른 소켓이나 문법이 필요할 수 있습니다. 기존 설정을 백업하고 현재 맵과 병합하세요. 무조건 덮어쓰면 안 됩니다.
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient확인 사항: 버전에서 지원한다면 SRS_EXCLUDE_DOMAINS를 /etc/default/postsrsd에 설정해 로컬 도메인을 재작성에서 제외할 수 있습니다. 경로, 맵, 소켓 권한, 제외 설정을 확인하고 흐름을 테스트하세요. 잘못된 제외 설정은 자체 메일 재작성이나 라우팅 문제에 영향을 줄 수 있지만 반드시 루프를 만들지는 않습니다.
Microsoft 365
M365는 특정 발신 경로에서 SRS를 처리합니다. 특히 하이브리드 환경이나 외부 게이트웨이 커넥터에서는 현재 동작을 확인하세요. 550 5.7.520 Access denied, Your organization does not allow external forwarding는 전달 정책 제한을 나타내며 SRS 장애를 입증하지 않습니다.
이 제한은 보안 검토가 필요합니다. 권한 있는 관리자가 Security Center → Policies & Rules → Anti-spam → Outbound spam filter policy를 확인하고 승인된 전달만 허용해야 합니다. 다음 명령은 설정 예시입니다. 매개변수는 버전에 따라 다르거나 지원되지 않을 수 있습니다. 테넌트와 버전에 맞는 절차를 확인하고 모든 환경에 적용되는 지침으로 사용하지 마세요.
Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $trueGoogle Workspace
Google은 관리형 전달 기능을 사용합니다. Workspace만의 문제는 아니지만 다음과 같은 상황이 가능합니다.
- 발송량 제한: 캐치올이 스팸을 전달하면 할당량을 소진해 제한될 수 있습니다. 계정 정지 여부는 정책과 상황에 달려 있습니다.
- 루프 감지: 루프를 막기 위해 일부 메시지가 폐기될 수 있습니다. 확인 가능한 정보는 로그, 관리 도구, 경로에 따라 달라지며 항상 기록이 없는 것은 아닙니다.
SRS 전달 실패 진단하기
전체 헤더는 진단에 도움이 됩니다. ProtonMail에서 테스트하고 최종 목적지에 도착한 메시지를 확인하세요. 거부된 경우 헤더를 얻지 못할 수 있으므로 SMTP 로그, 추적 정보, 전체 응답도 사용해야 합니다. 모든 원인을 헤더만으로 파악할 수는 없습니다.
점검 1: Return-Path
SRS 재작성 없는 예시:Return-Path: <original@protonmail.com>
SRS 재작성된 예시:Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>
원래 Return-Path가 남으면 데몬 중단이나 연동 오류일 수 있지만 제외 설정이나 SRS를 통과하지 않는 경로일 수도 있습니다. 경로와 로그를 확인한 뒤 판단하세요.
점검 2: Authentication-Results
재작성 도메인의 spf=pass를 확인합니다. dmarc=fail이면 DKIM이 없거나 유효하지 않거나, 유효해도 정렬되지 않을 수 있습니다. SPF도 원래 From과 정렬되지 않을 수 있습니다. 서명 도메인과 본문·제목 변경을 확인하세요.
점검 3: DNS
dig yourdomain.com TXT +short재작성 도메인의 SPF가 실제 IP를 허용하고 반환 주소에 도달할 수 있는지 확인하세요. MX는 중요하지만 없다는 사실만으로 수신 불가능이라고 단정할 수 없습니다. SMTP가 A나 AAAA를 통한 암시적 MX를 사용할 수 있습니다. 레코드 유무뿐 아니라 라우팅과 실제 응답을 점검하세요.
점검 4: Postfix 로그
grep "srs_forward" /var/log/mail.loghash mismatch 또는 timestamp expired는 노드 간 키 차이, 키 교체, 시계, 만료, 설정 등에서 발생할 수 있습니다. 오래된 주소 재사용이나 재전송 공격도 가능하지만 오류만으로 공격이라고 판단할 수는 없습니다. 백스캐터를 특정 원인에 연결하기 전에 맥락을 확인하세요.
SRS 전달을 중단하는 편이 나은 경우
SRS 이메일 전달은 중간 홉의 구조적인 문제에 대응합니다. SRS, DKIM 보존, ARC에는 추가 구성과 점검이 필요할 수 있습니다. 사용자 라이선스를 아끼는 것처럼 보여도 관리 시간을 포함하면 차이가 줄어들 수 있습니다. 비교 결과는 운영 환경에 따라 다릅니다.
두 방식을 비교해 보세요.
| SRS 이메일 전달 | 호스팅 메일함(TrekMail) | |
|---|---|---|
| SPF 정렬 | SRS 도메인이 원래 From과 다를 수 있음 | 실제 발송 경로에 맞게 설정 및 검증 필요 |
| DKIM | 서명 부분 변경으로 실패할 수 있음 | 지원 SMTP와 설정에 따른 서명 |
| DMARC | 정렬된 DKIM으로 성공 가능, ARC는 수신 판단에 영향을 줄 수 있음 | 인증과 정렬 검증 필요 |
| 설정 복잡성 | postsrsd 연동, 필요한 경우 ARC, 서명 부분 보존 | 지원되는 경우 도메인 설정 안내 |
| 사용자별 비용 | 예시의 라이선스 $0에 진단 및 인프라 비용 추가 | 요금제 가격과 한도 내 공유 용량 |
| 다중 도메인 | 서버 설정 및 도메인별 점검 | 소개된 상품에서 최대 1,000+개 도메인, 요금제에 따라 다름 |
TrekMail은 사용자별 과금 대신 메일함과 도메인 간 공유 저장 공간을 사용하는 정액 요금제를 소개합니다. 저장 공간에만 비용을 내거나 무제한으로 쓴다는 뜻은 아닙니다. 에이전시는 일반적인 Gmail 전달과 비교하거나 별칭 전달의 장단점을 확인하세요. 별칭과 실제 메일함 중에서 선택할 때는 도메인 별칭과 메일함 비교가 도움이 됩니다.
TrekMail 메일함에서 직접 수신하면 해당 메시지의 전달 홉을 없앨 수 있습니다. 그 홉을 위한 SRS나 ARC는 필요 없어지지만 발신 인증은 계속 설정하고 검증해야 합니다. 설정 마법사가 있어도 마찬가지입니다. MX에 지정된 서버가 자동으로 발송 권한을 얻는 것은 아닙니다. SPF, DKIM, DMARC와 외부 SMTP는 경로, 제공업체, 요금제에 달려 있습니다.
TrekMail을 사용해 보세요. 소개된 조건에서는 Nano에 카드가 필요 없으며, 관리형 SMTP가 포함된 Starter는 14일 체험과 월 $3.50부터의 요금을 제공합니다. 현재 제공 여부, 이용 자격, 가격, 조건을 확인하세요.
요약
SRS 이메일 전달은 2025-2026년의 전달 구성에서 유용한 도구이지만 모든 환경의 필수 조건은 아닙니다. 재작성하지 않으면 새 홉에서 SPF가 실패할 수 있습니다. SRS로 SPF가 성공해도 인증 도메인이 From과 정렬되지 않을 수 있습니다. 정렬된 DKIM이 성공하면 DMARC가 성공할 수 있으며 거부는 수신 정책에 달려 있습니다.
Postfix 연동 예시에는 postsrsd, main.cf 맵, 버전별 제외 설정이 있습니다. M365에서는 관리되는 경로와 전달 정책을 확인하고 승인된 경우에만 변경하세요. Google Workspace에서는 정지나 로그 부재를 단정하지 말고 할당량, 루프 감지, 관리 도구를 점검하세요.
SRS, DKIM 서명 부분 보존, ARC는 전달 관리에 도움이 되지만 항상 모두 필요하거나 전달을 보장하지는 않습니다. 대안으로 실제 수신 목적지에 메일함을 두고 인증, 접근, 한도를 계속 확인할 수 있습니다.
