이메일 전달을 설정했고 테스트도 성공했습니다. 그런데 두 주 뒤 고객의 계약 메일이 보이지 않습니다. 스팸에도 없고 배달 실패 알림도 찾을 수 없습니다. 로그에는 550 5.7.1 Unauthenticated email from domain.com이 있습니다.
이 오류에는 여러 인증 원인이 있을 수 있습니다. SRS 누락이나 잘못된 설정도 점검할 항목이지만 코드만으로 원인을 확정할 수는 없습니다. 전달 서버는 다른 도메인의 봉투 발신자를 가진 메시지를 자신의 IP에서 발송할 수 있습니다. Sender Rewriting Scheme, 즉 SRS는 이 SMTP 봉투를 다시 쓰는 방식입니다. 2026년에도 SRS만으로 모든 문제가 해결되지는 않습니다. 기능뿐 아니라 한계도 알아야 합니다.
이 가이드는 SRS의 역할, 문제가 생기는 상황, 전달 시스템에 필요한 요소를 설명합니다. 잘못된 MX, catch-all 설정 오류, DNS 변경으로 인한 경로 장애 등 더 넓은 배달 문제를 조사한다면 먼저 이메일 전달 설정과 문제 해결 가이드를 읽어 보세요.
전달 과정에서 SPF가 실패할 수 있는 이유
전달 서버가 자신의 IP에서 발송하면서 원래 봉투 발신자를 유지하고, 그 도메인이 전달 IP를 허용하지 않으면 SPF가 실패할 수 있습니다. DMARC에 p=reject가 설정되어 있고 유효하며 정렬된 DKIM도 없으면 수신 측이 거부할 수 있습니다. SMTP 거부로 원래 발신자에게 배달 실패 알림이 갈 수도 있지만, 자신의 수신함에는 알림이 없을 수 있습니다.
메일은 하나의 연속된 연결을 통과하지 않습니다. 단계마다 새 TCP 연결을 만드는 SMTP 연결의 연속입니다. 다음은 실패할 수 있는 구성의 예입니다.
alice@client.com이contact@your-agency.com으로 보냅니다- 자신의 서버가 수락합니다. 이 예에서는 Alice의 발송 IP가
client.com의 SPF에서 허용됩니다 - 자신의 서버가 Gmail로 새 SMTP 연결을 열어 전달합니다
- Gmail은 자신의 서버 IP에서 들어오는 연결을 봅니다
- 봉투 발신자는 여전히
alice@client.com입니다 - Gmail이
client.com의 SPF를 확인하지만 전달 IP는 허용되지 않습니다 - SPF가 실패합니다.
client.com이p=reject를 사용하고 유효하며 정렬된 DKIM도 없으면 Gmail이 거부할 수 있습니다
SPF 명세인 RFC 7208도 전달 문제를 다룹니다. 원래 도메인이 중계 서버를 허용한다고 가정하는 것만으로는 충분하지 않습니다. 봉투 재작성은 새 경로의 SPF 검사를 지원하는 방법 중 하나입니다.
두 발신자 정보: 봉투와 헤더
메일에는 두 종류의 발신자 정보가 있습니다. 봉투 발신자(RFC 5321, MAIL FROM, P1)는 SPF와 배달 실패 알림 경로에 쓰입니다. 서버가 사용하는 정보지만 사용자가 전체 헤더의 Return-Path에서도 볼 수 있습니다. 헤더 From(RFC 5322, P2)은 Gmail이나 Outlook에 표시되는 발신자입니다. 전달 시 봉투 발신자의 SPF 허용이 새 발송 서버와 맞지 않을 수 있습니다. SRS는 표시되는 From이 아니라 이 부분을 변경합니다.
| 계층 | 기술 명칭 | RFC | 용도 | 확인 대상 |
|---|---|---|---|---|
| 봉투 발신자 | MAIL FROM / Return-Path | RFC 5321 (P1) | SPF 검사와 배달 실패 알림 경로 | 서버. 사용자도 전체 헤더에서 확인 가능 |
| 헤더 From | From: header | RFC 5322 (P2) | 메일 클라이언트의 발신자 표시 | 최종 사용자 |
전달 후에도 헤더 From은 alice@client.com으로 남을 수 있습니다. 서버는 새 SMTP 트랜잭션을 만들고 SPF는 해당 단계 IP에 대해 봉투 발신자를 평가합니다. 문제는 새 IP에 대한 허용이 없을 수 있다는 점이지, 두 발신자 정보가 다르다는 사실 자체가 아닙니다.
SRS가 실제로 하는 일
SRS는 전달 서버가 새 SMTP 연결을 열기 전에 봉투 발신자(P1)를 다시 씁니다. 표시되는 From은 그대로 둡니다. 봉투에 전달 서버를 허용하는 도메인을 사용하면 보이는 발신자를 유지하면서 SPF를 통과할 수 있습니다. 하지만 원래 From 도메인과의 DMARC 정렬을 보장하지는 않습니다.
우편에 비유하면: SRS가 없을 때 Alice의 편지를 받아 새 자루에 넣어도 반송 주소는 Alice로 남습니다. 운반자와 반송 정보가 다르다는 SPF 문제의 비유이며 위조의 증거는 아닙니다. SRS에서는 자신의 반송 주소를 사용합니다. 자루가 돌아오면 자신이 받아 Alice에게 반송을 이어갈 수 있습니다.
| 항목 | 전달 전 | SRS 재작성 후 (예) |
|---|---|---|
| 헤더 From (P2) | alice@client.com | alice@client.com (변경 없음) |
| 봉투 발신자 (P1) | alice@client.com | SRS0=4fac=PM=client.com=alice@your-agency.com |
| 발송 IP | 자신의 서버 | 자신의 서버 |
| 예시의 SPF 결과 | FAIL | PASS |
SRS 주소 형식 이해하기
SRS는 전달 전에 봉투 발신자를 인코딩된 문자열로 바꿉니다. 변경된 도메인은 실제 경로를 허용해야 합니다. 문자열에는 반송 알림 검증용 인증 코드, 유효 기간을 제한하는 시간 정보, 알림을 돌려보낼 원래 발신자 주소가 들어갑니다. 무의미한 문자가 아니라 구조화된 데이터이며 보호 수준은 구현에 달려 있습니다.
SRS로 다시 쓴 주소의 예입니다.
SRS0=4fac=PM=client.com=alice@your-agency.com- SRS0: 첫 전달 단계입니다. 이후 전달에 사용되는
SRS1은 주소 길이 증가를 제한하지만 무제한 중계를 보장하지는 않습니다 - 4fac: 이 예에서는 HMAC-SHA1 인증 코드입니다. 알고리즘과 길이는 구현마다 다릅니다. 유효하지 않은 코드의 반송 알림을 거부하고 제삼자에게 불필요한 실패 알림을 보내는 백스캐터 악용을 줄이는 데 도움이 됩니다
- PM: 시간 정보입니다. 7-21일은 설정 가능한 예시이며 공통 고정값이 아닙니다. 만료는 오래된 주소 사용을 제한하지만 모든 재전송 공격을 막지는 않습니다
- client.com=alice: 인코딩된 원래 발신자이며 배달 실패 알림을 원래 주소로 돌려보낼 때 사용합니다
SRS를 검토해야 하는 상황
원래 봉투 발신자를 유지한 채 도메인 간에 전달하고 원래 SPF가 중계 서버를 허용하지 않을 때 SRS가 유용합니다. 다중 도메인 전달 구성에서는 모든 발신자의 정책과 항상 호환된다고 가정하지 말고 이 조건과 전체 인증 경로를 확인해야 합니다.
자체 도메인에서 개인 Gmail로. cool-startup.com을 소유하고 founder@gmail.com으로 전달하는 경우입니다. SRS 재작성과 서버의 SPF 허용을 확인하세요. 재작성이 없으면 엄격한 DMARC를 사용하는 발신자 등에서 SPF가 실패할 수 있지만, 유효하며 정렬된 DKIM이 있으면 DMARC를 통과할 수 있습니다.
공유 메일 클러스터를 운영하는 MSP 또는 에이전시. 고객 도메인 200개를 호스팅하고 고객이 Comcast, AT&T, Outlook 등으로 전달하는 경우입니다. 재발송된 스팸은 IP 평판을 해칠 수 있습니다. 수주 안에 Spamhaus에 등록되는 것은 가능한 위험이지 필연적인 결과는 아닙니다. SRS만으로 스팸이나 평판 문제를 해결하지는 못합니다.
발신 커넥터를 사용하는 Microsoft 365. M365의 SRS 동작은 경로와 지원 커넥터 유형에 따라 달라집니다. 사용 중인 버전과 구성에서 SenderRewritingEnabled가 지원되는지 확인하고 적절한 권한과 승인 아래 설정을 변경하세요. 발신 스팸 정책도 확인해야 합니다. 외부 전달의 5.7.520은 정책 제한이며 반드시 SRS 오류를 뜻하지는 않습니다.
SRS만으로 충분하지 않은 이유
SRS는 변경된 도메인의 SPF를 통과시킬 수 있지만 원래 From과의 DMARC 정렬을 자동으로 복원하지는 않습니다. DMARC는 SPF 또는 DKIM 중 적어도 하나가 성공하고 그 인증 도메인이 표시되는 From 도메인과 정렬되도록 요구합니다. SRS가 다른 도메인을 사용하면 SPF가 성공해도 정렬되지 않을 수 있으며, DMARC는 전달 후에도 유효하며 정렬된 DKIM에 의존할 수 있습니다.
전달 시 일부 변경은 DKIM을 무효로 만들 수 있습니다.
- 서명된 제목에
[EXTERNAL]을 추가하면 DKIM이 무효가 될 수 있습니다 - 바이러스 검사 알림이나 구독 해지 링크 등을 끝에 추가하면 서명된 본문이 바뀌어 DKIM이 무효가 될 수 있습니다
- MIME을 8-bit에서 7-bit 인코딩으로 바꾸는 등의 재작성은 서명 부분과 정규화 방식에 따라 DKIM을 무효로 만들 수 있습니다
SPF가 정렬되지 않고 메시지 변경으로 정렬된 DKIM도 무효가 되면 DMARC가 실패합니다. 거부를 포함한 최종 처리는 수신 측 정책에 달려 있습니다.
ARC (Authenticated Received Chain, RFC 8617)는 추가 판단 정보를 제공할 수 있습니다. 서버가 전달 전에 관찰한 결과를 봉인하고 세 가지 헤더를 추가합니다.
ARC-Authentication-Results: 관찰한 SPF, DKIM, DMARC 결과를 기록하며 모두 성공했다고 가정하지 않습니다ARC-Message-Signature: 서명 시점 상태의 메시지 부분에 서명하며 수신 직후 상태와 같다고 보장하지 않습니다ARC-Seal: 봉인을 수행한 서버를 체인에 연결하는 암호학적 서명입니다
Gmail은 SPF와 DKIM으로 DMARC가 통과하지 못할 때 ARC를 고려할 수 있습니다. 봉인 서버와 체인을 신뢰하면 그 정보를 판단에 사용할 수 있습니다. 신뢰를 강제할 수는 없고, 오랫동안 평판을 쌓아도 반드시 얻는다고 보장할 수 없습니다. 수신 측이 결정합니다.
SRS가 작동하는지 확인하는 방법
외부 계정에서 전달 대상 주소로 테스트 메일을 보내고 최종 수신 측의 전체 헤더를 살펴보세요. Return-Path에 SRS 주소 또는 원래 발신자 중 무엇이 표시되는지 확인하고 실제 인증 결과도 점검하세요.
단계 1: 최종 수신 측 Return-Path 확인
# SRS inactive - SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>
# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>단계 2: SRS 도메인 DNS 확인
# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf
# Check MX - bounces need a place to go:
dig MX your-domain.com변경된 도메인은 SPF로 발송을 허용하고 실패 알림을 받을 수 있는 경로를 제공해야 합니다. 적절한 MX가 일반적으로 유용하지만 없다고 항상 도달 불가능한 것은 아닙니다. 경우에 따라 SMTP가 A 또는 AAAA를 암묵적으로 사용할 수 있습니다. 레코드 유무만이 아니라 실제 도달 여부와 서버 응답을 확인하세요.
단계 3: Linux 메일 로그 확인
grep "srs_forward" /var/log/mail.loghash mismatch나 timestamp expired는 공유 비밀값 불일치, 키 교체, 정상적인 지연, 데이터 손상, 악용 시도 등으로 발생할 수 있으며 공격의 증거는 아닙니다. Postfix에는 PostSRSd 같은 SRS 솔루션을 통합해야 합니다. 방법은 버전과 구성에 따라 다릅니다. 지원 구성에서 로컬 도메인용 SRS_EXCLUDE_DOMAINS를 검토하고 경로를 시험하세요. 제외 설정이 없다고 반드시 루프가 생기지는 않습니다.
더 간단한 대안: 전달 중단
SRS는 발송 서버가 바뀔 때 봉투 발신자를 관리합니다. 자신의 도메인에 실제 메일함을 두고 IMAP으로 접근하면 추가 전달 단계와 관련 SPF 문제를 피할 수 있습니다. 하지만 종단 간 인증을 보장하거나 모든 DKIM, DMARC, 접근 문제를 없애지는 않습니다. 올바른 설정은 여전히 필요합니다.
전달이 널리 쓰이는 이유 중 하나는 한 달에 다섯 통만 받는 메일함에 사용자별 요금을 내고 싶지 않기 때문입니다. SRS는 기술 요구뿐 아니라 비용 때문에 선택한 구성을 지원하는 경우도 있습니다.
설명된 TrekMail 모델은 월 $3.50부터 시작하며, 여러 도메인과 공유 저장 공간을 정액으로 제공하고 적용 한도 안에서는 사용자별 요금을 부과하지 않습니다. sales@yourdomain.com을 실제 IMAP 메일함으로 사용하고 Outlook 또는 지원되는 Gmail 연동으로 접근할 수 있습니다. 해당 전달 구성은 피하지만 모든 인증 위험이 사라지지는 않습니다. 현재 가격, 기능, 호환성을 확인하세요.
여러 고객의 구성은 다중 도메인 이메일 호스팅 가이드에서 도메인 수십 개를 정리하고 관리 부담을 줄이는 방법을 다룹니다. 메일함과 기존 전달을 함께 사용한다면 이메일 별칭 전달 가이드에서 전달 경로의 SRS를 확인하세요.
전달을 유지하든 메일함으로 바꾸든 SRS의 역할을 이해하고 작동을 확인하며, 지원된다면 ARC를 검토하세요. 불완전한 전달 설정은 정상 메일의 누락으로 이어질 수 있습니다. 단순한 기술 문제가 아니라 사업 위험입니다.
여기서 소개하는 조건에서 무료 TrekMail 계정은 카드가 필요 없고 체험 만료 기한도 없습니다. 현재 조건을 확인하고 복잡한 전달 구성 없이 여러 도메인의 이메일을 관리하는 방식을 살펴보세요.
