SRS의 원리와 이메일 전달 인증의 한계

contact@your-agency.com → you@gmail.com으로 전달하도록 설정했습니다. 테스트에서는 정상적으로 도착합니다. 그런데 두 주 뒤 기업 고객이 보낸 계약서가 스팸함에서도 보이지 않습니다. 로그에는 550 5.7.1 Unauthenticated email 또는 550 5.7.520 Access denied가 나타납니다. 후자는 Microsoft 365에서 조직 정책이 외부 전달을 차단하는 경우 등에 발생합니다. 첫 번째 오류만으로 원인을 단정할 수는 없습니다. SMTP 거부가 전달 서버에 통보되어도 사용자가 알림을 보지 못할 수 있습니다.

전달 과정의 SPF 문제에 대응하는 방법 중 하나가 적절히 구성한 발신자 재작성 방식 SRS입니다. 원래 봉투 발신자 도메인이 중계 서버의 발송을 허용하지 않으면 전달 과정에서 SPF가 실패할 수 있습니다. 2026년 Google과 Yahoo의 발신자 요구사항은 인증을 중요하게 다루지만 모든 발신자에게 DMARC p=reject를 요구하는 것은 아닙니다(Google 이메일 발신자 가이드라인). SPF 실패만으로 DMARC 실패나 알림 없는 삭제가 결정되는 것도 아닙니다. 이 글에서는 SRS의 동작, 한계, 함께 검토할 대책을 설명합니다.

전달 구성 전반은 이메일 전달 설정과 일반적인 문제 해결 가이드에서 확인하세요.

발신자 재작성 방식(SRS)이란?

SRS는 SMTP 봉투의 발신자 주소를 바꿔 전달 과정에서 발생하는 일부 SPF 문제에 대응하는 방식입니다. 전달 서버는 원래 봉투 주소(MAIL FROM)를 전달용 도메인의 주소로 재작성합니다. 수신 서버는 이 도메인에 대해 SPF를 검사합니다. DNS 레코드와 발송 권한이 올바르면 검사가 통과할 수 있습니다. 봉투 주소는 일반적인 메일 화면에는 보이지 않지만 원본 헤더의 Return-Path에서 확인할 수 있습니다. 재작성하지 않으면 중계 서버가 발송 권한이 없는 원래 도메인의 주소를 유지해 SPF가 실패할 수 있습니다. 다만 SPF 실패만으로 사칭이나 DMARC 실패를 확정할 수는 없습니다.

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

전달 인증 문제를 이해하려면 봉투와 메시지 헤더의 발신자를 구분해야 합니다. SPF는 봉투 발신자 도메인을 검사합니다. DMARC는 사용자에게 표시되는 발신자 도메인이 SPF 또는 DKIM으로 인증된 도메인과 정렬되는지 확인합니다. 전달은 이 관계를 바꿀 수 있습니다.

봉투는 메시지 전송과 배달 오류 회신에 사용되며 SPF는 이 계층의 도메인을 검사합니다. 메일 프로그램에 표시되는 발신자는 헤더에 있고 DMARC 정렬의 기준이 됩니다. 전달로 새로운 SMTP 연결이 생기면 SPF 문제가 발생할 수 있지만 모든 인증 검사가 반드시 실패하지는 않습니다. 유효하고 정렬된 DKIM이 유지되면 DMARC가 통과할 수 있습니다.

새로운 SMTP 연결이 SPF에 영향을 주는 이유

전달 서버는 목적지로 새로운 SMTP 연결을 엽니다. 봉투 발신자는 alice@bank.com으로 유지되지만 연결 IP는 전달 서버의 IP가 됩니다. SPF는 이 IP를 bank.com의 SPF 레코드와 비교합니다. 허용되지 않은 IP라면 검사가 실패합니다. bank.com이 DMARC p=reject를 게시하고 유효하며 정렬된 DKIM도 없다면 수신 서버가 거부할 수 있습니다. 거부 응답이 중계 서버에 전달되고 배달 오류가 회신될 수도 있으므로 언제나 알림 없이 사라지는 것은 아닙니다.

이 상황이 반드시 단순한 설정 오류를 뜻하지는 않습니다. 원래 봉투 발신자를 유지하면서 전송 경로를 추가하면 발생할 수 있는 문제입니다. 실제 결과는 경로와 SPF 권한에 따라 달라지며 모든 전달에 동일하게 발생하지는 않습니다.

SRS가 봉투 주소를 재작성하는 방법

SRS는 새 SMTP 연결을 시작하기 전에 봉투 주소 MAIL FROM을 전달용 도메인의 주소로 바꿉니다. 수신자에게 표시되는 From: 헤더는 이 작업을 위해 변경할 필요가 없습니다.

# WITHOUT SRS - SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)

# WITH SRS - SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)

이 예시에서 수신 서버는 your-domain.com의 SPF를 검사합니다. 해당 도메인이 실제 발송 IP를 허용하므로 검사가 통과합니다. 수신자는 여전히 From: alice@bank.com을 봅니다. SRS는 개별 SPF 검사에 대응하지만 원래 표시 발신자 도메인과의 정렬까지 복구하지는 않습니다.

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

Return-Path의 SRS 주소는 임의의 문자열처럼 보여도 각 부분에 역할이 있습니다. 구조를 알면 재작성이 수행되는지 확인하고 문제를 조사하기가 쉬워집니다. 세부 형식은 구현에 따라 다릅니다.

예시: SRS0=4fac=PM=bank.com=alice@your-domain.com

SRS는 SPF 도메인 정렬을 복구하지 않는다

SRS를 적용해 SPF 검사가 통과해도 원래 표시 발신자와의 SPF 정렬은 복구되지 않습니다. DMARC에는 정렬된 SPF 또는 유효하고 정렬된 DKIM이 필요합니다. 따라서 SRS를 올바르게 설정한 뒤에도 인증 문제가 남을 수 있습니다.

DMARC에서는 SPF나 DKIM으로 인증된 도메인이 적용되는 정렬 규칙에 따라 표시된 From: 도메인과 일치해야 합니다. 이 SRS 예시에서는 다음과 같습니다.

• SPF 검사: PASS - IP가 봉투 도메인 your-domain.com의 발송 권한을 가짐
• SPF 정렬: FAIL - 봉투 your-domain.com ≠ 헤더 bank.com

이 경우 DMARC가 통과하려면 유효하고 정렬된 DKIM이 필요합니다. 서명 유효성은 본문뿐 아니라 서명 대상 헤더와 정규화 방식에도 영향을 받습니다. “External Email” 경고 배너, 끝에 추가한 바이러스 검사 안내, 8-bit에서 7-bit로 바꾸는 MIME 변환 등이 서명 대상 부분을 수정하면 DKIM이 무효화될 수 있습니다.

SPF 정렬이 실패하고 필요한 DKIM도 무효화되면 DMARC가 실패합니다. SRS 재작성 자체는 정상이어도 발신자와 수신 서버의 정책에 따라 메시지가 거부될 수 있습니다.

SRS를 보완하는 ARC

ARC(Authenticated Received Chain, RFC 8617)는 SRS를 보완할 수 있습니다. SRS가 봉투 주소를 바꾸는 반면 ARC는 중계 서버가 실제로 관찰한 인증 결과를 서명된 체인으로 기록합니다. 다음 수신 서버는 이를 판단에 활용할 수 있습니다. ARC 자체가 메시지의 안전성을 인증하는 것은 아닙니다.

ARC는 ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal 헤더를 추가합니다. 이를 통해 이전 인증 결과를 중계 후에도 참고할 수 있습니다. 다만 메시지 서명은 본문에도 의존하므로 서명 이후의 모든 변경을 견디는 것은 아닙니다. ARC가 DMARC 도메인 정렬을 복구하는 것도 아닙니다.

주의할 점: ARC 서명자를 신뢰할지, 결과를 어떻게 활용할지는 수신자가 결정합니다. Microsoft 365에서는 필요한 경우 현재 테넌트가 지원하는 방식에 따라 권한 있는 관리자가 PowerShell(Set-ArcConfig)로 신뢰할 서명자를 구성할 수 있습니다. 모든 환경에서 수동 등록이 필요한 것은 아닙니다. Gmail의 신뢰 판단을 수동으로 강제할 수도 없습니다.

운영 환경에서는 SRS로 전달 후 SPF를 처리하고 ARC로 이전 인증 결과를 전달하는 구성을 검토할 수 있습니다. 하지만 두 방식이 항상 함께 필요한 것은 아니며, 함께 사용해도 모든 주요 제공업체의 수신을 보장하지는 않습니다.

SRS 문제 조사 체크리스트

전달된 메일이 도착하지 않으면 다음 절차로 SRS 문제와 그 앞 단계의 인증 오류 또는 정책 차단을 구분하세요.

1. Return-Path 헤더 확인

외부 계정에서 전달 경로를 거쳐 테스트 메일을 보내고 최종 목적지에서 원본 헤더를 확인하세요. 다음은 가능한 결과의 예시이며 모든 환경에서 같은 결과가 나오는 것은 아닙니다.

# SRS inactive - SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)

# SRS active - SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)

2. Microsoft 365의 발신 차단 확인

Microsoft 365에서 나가는 외부 전달을 테넌트 정책이 차단하면 메시지가 테넌트를 떠나기 전에 막힙니다. 수신 서버의 SRS로는 해결할 수 없습니다.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

권한 있는 관리자가 Defender 포털의 아웃바운드 스팸 필터 정책을 확인해야 합니다. 변경은 조직의 승인과 보안 방침에 따라 수행하고 다른 경로로 제한을 우회하지 마세요. 수신 측 SRS는 이 발신 정책을 바꾸지 않습니다.

3. 라우팅 루프 확인

A가 B로 전달하고 B가 다시 A로 전달하면 규칙과 보호 장치에 따라 루프가 생길 수 있습니다. 로그에서 다음과 같은 항목을 찾으세요.

554 5.4.14 Hop count exceeded
5.4.6 Routing loop detected

전달 대신 독립된 메일함 사용하기

postsrsd 설정, HMAC 키 관리, DMARC 정렬 오류 조사는 메일함별 비용을 줄이려고 업무 메일을 개인 받은편지함으로 전달할 때 따르는 관리 작업입니다. SRS는 이 구조의 특정 문제에 대응합니다. 직접 호스팅한 메일함은 추가 전달 단계를 없앨 수 있지만 올바른 인증 구성과 운영은 여전히 필요합니다.

contact@client-domain.com을 Gmail로 전달하면서 SRS를 관리하는 대신 contact@client-domain.com을 TrekMail의 IMAP 메일함으로 운영할 수 있습니다. 지원되는 IMAP 클라이언트로 접근할 수 있으며, 해당 연동을 지원하는 Gmail 앱도 선택지가 될 수 있습니다. 배달은 호스팅된 메일함으로 직접 이루어져 추가 전달이나 그에 따른 봉투 재작성이 필요하지 않습니다. 그렇다고 모든 인증 및 배달 위험이 없어지는 것은 아닙니다. 도메인 이메일을 Gmail로 전달하는 가이드와 별칭과 메일함 비교에서 차이를 확인하세요.

여러 고객 도메인을 관리한다면 TrekMail에서 별도 메일함을 구성해 각 고객 서버의 SRS를 유지하는 대신 관리를 모을 수 있습니다. 제공되는 분리 기능과 설정 시간은 요금제와 구성에 따라 달라지며 절대적인 보안을 보장하지 않습니다. 다중 도메인 이메일 호스팅 가이드에서는 규모가 커질 때 관리하는 방법을 설명합니다.

소개된 TrekMail 조건은 월 $3.50부터 시작하며 무료 체험은 14일입니다. 현재 가격, 조건, 기능을 확인하세요. 독립된 메일함을 설정하고 직접 호스팅이 업무에 적합한지 검토해 보세요.