도메인 이메일 전달의 SRS, ARC와 진단 방법

도메인 이메일 전달은 서버가 새 SMTP 연결로 메시지를 다시 보내는 과정입니다. 발신 주소를 재작성하지 않으면 SMTP 봉투에 원래 발신자의 도메인이 남을 수 있습니다. 이 차이는 인증과 수신에 문제를 일으킬 수 있으며, 반송 메일이 보이는지는 경로와 처리 방식에 달려 있습니다.

인증을 제대로 구성하지 않으면 Gmail에서 스팸으로 분류되거나 거부될 수 있고, Yahoo에서 550 거부가 발생하거나 Microsoft 365 정책에 의해 차단될 수 있습니다. 모든 문제가 전달 서버 운영자에게 바로 보이는 것은 아닙니다.

이 가이드는 2026년에 활용할 수 있는 세 가지 전달 방식, 주요 제공업체에서 나타날 수 있는 오류 코드, 십 분 안에 시작할 수 있는 진단 절차를 설명합니다. 전체 설정은 이메일 전달 설정 및 문제 해결 종합 가이드를 참고하세요.

도메인 이메일 전달이 SPF 실패를 일으킬 수 있는 이유

전달 서버가 새 SMTP 발신 서버가 되어도 Return-Path는 원래 도메인을 가리킬 수 있습니다. 해당 도메인의 SPF 레코드가 전달 서버 IP를 허용하지 않으면 SPF가 실패합니다. DMARC가 p=reject인 경우에도 원래 From 도메인과 정렬된 유효한 DKIM이 남아 있으면 DMARC는 통과할 수 있습니다. SPF 실패만으로 메시지가 자동 삭제되는 것은 아닙니다.

다음은 발생 가능한 실패 과정입니다.

alice@bank.com이 info@yourdomain.com으로 보냅니다. 은행의 SPF 레코드는 은행 메일 서버를 허용합니다.
전달 서버가 you@gmail.com으로 다시 보냅니다. Gmail에는 전달 서버 IP가 보이지만 Return-Path는 여전히 bank.com을 가리킵니다.
전달 서버 IP가 bank.com의 SPF 레코드에 없으므로 이 예에서는 SPF가 실패합니다.
서명된 본문에 꼬리말을 넣거나 서명된 제목을 변경하면 DKIM도 실패할 수 있습니다. 정렬된 인증이 모두 실패하면 DMARC가 실패하고 수신 서버가 거부 정책을 적용할 수 있습니다.

반송 메일은 원래 발신자에게 가거나 지연될 수 있으며, 오류와 설정에 따라 발생하지 않을 수도 있습니다. 로그와 반송 경로를 확인해야 합니다.

캐치올 전달은 수집된 스팸까지 전달 서버 IP로 보내므로 위험을 키울 수 있습니다. Gmail에서 IP 평판과 수신률이 나빠져 정상 메일이 스팸으로 분류되거나 거부될 수 있습니다. 모든 경로에서 같은 순서로 문제가 생기는 것은 아닙니다.

전달 방식이 적합한지 고민 중이라면 구성 전에 이메일 별칭 전달의 장단점을 살펴보세요.

더 안정적인 도메인 이메일 전달을 위한 3가지 방식

세 가지 방식은 서로 다른 위험을 다루며 함께 사용할 수 있습니다. 모든 구성에 세 가지가 전부 필수인 것은 아니고, 함께 사용해도 모든 수신 서버의 수락이 보장되지는 않습니다. 인증 경로와 수신 정책에 맞게 선택하세요.

1. Sender Rewriting Scheme (SRS)

SRS는 SMTP 봉투 발신자를 전달 서비스의 도메인으로 재작성합니다. 해당 도메인이 전달 서버를 허용하면 SPF가 통과할 수 있습니다. 재작성 주소에 인코딩된 정보는 SRS 반송 처리가 올바르게 구성된 경우 원래 발신자에게 반송을 돌려보내는 데 사용됩니다.

SRS 적용 전:

MAIL FROM: <alice@bank.com>

SRS 적용 후:

MAIL FROM: <SRS0=hash=TT=bank.com=alice@forwarder.com>

한계가 있습니다. 전달 서비스 도메인의 SPF 통과는 보통 원래 From 도메인과 정렬되지 않습니다. 따라서 SRS만으로 DMARC를 통과시키지는 못합니다. 보존된 정렬 DKIM이 통과하면 DMARC도 통과할 수 있고, 그렇지 않으면 수신 서버가 신뢰하는 ARC 이력을 정책 판단에 참고할 수 있습니다.

2. Authenticated Received Chain (ARC)

ARC (RFC 8617)는 중간 서버가 기록한 인증 결과의 이력을 보호합니다. 전달 서버는 암호학적으로 연결된 세 개의 헤더를 추가합니다. 이 헤더는 이력의 무결성을 보호하지만 기록된 결과가 신뢰할 만하다는 사실을 그 자체로 보증하지는 않습니다.

ARC-Authentication-Results: i=1; forwarder.com; spf=pass; dkim=pass; dmarc=pass
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; ...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=forwarder.com; ...

Google과 Microsoft는 수신 결정에 ARC를 참고할 수 있습니다. 최종 구간에서 인증이 실패해도 신뢰하는 ARC 체인을 근거로 수락할 수 있지만, 유효한 체인이 수락을 보장하거나 실패한 DMARC 결과를 자동으로 통과로 바꾸지는 않습니다.

신뢰 여부는 수신 서버의 정책과 중간 운영자의 평판에 달려 있습니다. 새 서명 도메인이나 새 IP가 자동으로 ARC 신뢰를 얻는 것은 아닙니다.

3. 메시지 그대로 전달하기 (DKIM 보존)

원래 DKIM을 보존하려면 서명된 내용의 변경을 최소화하세요. 꼬리말 추가, 제목 재작성, 검사 도구의 본문 변경을 피하는 것이 좋습니다. DKIM은 정규화 규칙에 따라 본문과 선택된 헤더를 검증합니다. 모든 바이트 변경이 서명을 깨뜨리지는 않지만 서명 대상 변경은 실패를 일으킬 수 있습니다.

어려운 전달 문제는 메시지 변경 때문에 생기기도 합니다. 스팸 검사기가 본문에 "MailGuard가 검사한 메시지입니다"를 추가해도 발송 로그에 명확한 표시가 없을 수 있습니다. 수신 헤더나 진단용 메시지를 확보했다면 Authentication-Results의 dkim=fail (body hash did not verify)가 단서가 됩니다.

DKIM 보존이 도움이 되려면 유효한 서명이 전체 경로를 통과하고 원래 From 도메인과 정렬되어야 합니다. SPF 정렬도 없고 해당 DKIM도 실패하면 DMARC는 실패합니다. 실제 처리는 수신 정책과 ARC 신뢰 여부에 따라 달라집니다.

주요 제공업체의 전달 오류 처리

Microsoft, Google, Yahoo는 정책, 인증, 평판을 바탕으로 메일을 차단하거나 분류할 수 있습니다. Yahoo의 550 거부도 가능한 사례지만 업체마다 하나의 고정된 실패 방식이 있는 것은 아닙니다. 전체 SMTP 응답과 로그를 읽어 발신 측 정책, 중간 경로, 수신 측 중 어디에서 문제가 발생했는지 확인하세요.

Microsoft 365 (Exchange Online)

Microsoft의 Defender 아웃바운드 스팸 정책은 자동 외부 전달을 차단할 수 있습니다. 해당 정책이 적용되면 메일이 전달 서비스에 도달하기 전에 차단될 수 있으므로 현재 테넌트 설정을 확인하세요.

오류 코드	원인	해결
`550 5.7.520`	자동 전달 차단일 수 있으므로 전체 오류 메시지 확인	승인된 범위에 한해 Microsoft Defender → 스팸 방지 → 아웃바운드 정책에서 외부 전달 허용
`5.4.14`	홉 수 초과, 라우팅 루프 가능성	전체 경로 확인; A→B→A는 가능한 구성 오류

5.7.520 반송은 원래 봉투 발신자에게 갈 수 있어 수신 사서함 관리자가 보지 못할 수 있습니다. 메시지 추적과 발송 로그로 실제 반송 경로를 확인하세요.

Google Workspace / Gmail

명시적 거부의 예는 550-5.7.1 Unauthenticated email from domain.com is not accepted due to domain's DMARC policy입니다. p=reject가 설정되어 있고 정렬된 인증이 통과하지 않으며 수신 정책 예외도 없는 경우 발생할 수 있습니다. SRS나 ARC가 없다는 사실만으로 거부가 결정되는 것은 아닙니다.

평판 저하도 살펴보세요. 캐치올의 스팸을 전달하면 수일 또는 수주에 걸쳐 전달 IP 평판이 나빠질 수 있으며 정상 메일이 스팸으로 분류되거나 거부될 수 있습니다. 오류 코드와 반송 발생 여부는 실제 처리에 따라 달라집니다.

Yahoo / AOL

Yahoo에서도 인증 부족으로 550 거부가 발생할 수 있지만 모든 전달 메일을 첫 시도에 거부하는 것은 아닙니다. 제목이 서명 대상이면 [FWD] 또는 [External] 추가가 DKIM 실패를 일으킬 수 있습니다. SPF와 DKIM 실패는 DMARC 실패 위험을 높이지만, 구체적인 정책과 메시지 근거 없이 100% 거부를 단정할 수 없습니다. 오래된 구성도 경로별로 진단해야 합니다.

전달 진단 체크리스트

전달이 실패하면 설정을 바꾸기 전에 다음 순서로 확인하세요.

수신 측 Authentication-Results 헤더 확인 (Gmail의 "원본 보기", Outlook의 메시지 원본).
```
Authentication-Results: mx.google.com;
  spf=fail (domain of bank.com does not designate 198.51.100.1 as permitted)
  dkim=fail (body hash did not verify)
  dmarc=fail (p=REJECT)
```
spf=fail → 봉투 도메인, 발송 IP, SPF를 확인하세요. SRS 누락이나 구성 오류는 가능한 원인입니다.
dkim=fail (body hash) → 서명된 본문 변경이나 전송 손상을 조사하세요.
정렬된 SPF와 DKIM이 모두 통과하지 않으면 DMARC는 실패합니다. 거부와 ARC 예외 적용은 수신 서버의 정책에 달려 있습니다.
라우팅 루프 확인. 5.4.14 Hop count exceeded는 홉 제한 초과를 나타내므로 전체 문맥을 확인하세요. A→B→C→A 같은 순환 경로가 있는지 그려보세요.
Reply-To 동작 테스트. 답장은 보통 Reply-To가 있으면 그 주소를, 없으면 From을 사용합니다. 예상과 달리 전달 서비스로 답장이 가면 두 헤더를 모두 확인하세요. 그 현상만으로 From 재작성을 단정할 수 없습니다.
메시지를 처리하는 모든 구성 요소 점검. 스팸 필터, 바이러스 검사기, 메일링 리스트, 피싱 방지 도구가 서명된 내용을 바꿀 수 있습니다. 모든 변경이 DKIM을 깨뜨리지는 않으므로 서명 대상과 정규화 규칙을 확인하세요.
캐치올 전달량 확인. 개별 메시지가 인증을 통과해도 많은 스팸을 전달하면 Gmail 수신에 악영향을 줄 수 있습니다.

전달과 주소별 라우팅 중 어떤 방식이 적합한지 고민된다면 도메인 이메일 별칭과 사서함 비교를 참고하세요. 해결하는 문제와 실패 위험이 다릅니다.

TrekMail 전달 인프라

직접 운영하는 Postfix에서는 SRS용 postsrsd, ARC용 OpenARC, 키 교체, 서명된 내용 보존이 중요할 수 있습니다. 네 가지는 별도 관리 항목이며 실제로 필요한 구성은 설계에 달려 있습니다. 비슷한 수신 증상도 원인은 다를 수 있습니다.

전달 서비스의 DKIM 재서명은 별도의 설계 선택이지 ARC의 보편적 필수 조건이 아닙니다. 새 서명은 전달 서비스를 인증할 수 있지만 원래 From과의 DMARC 정렬을 자동으로 복구하지 않습니다. 원래의 유효한 DKIM을 보존하고 수신 측 ARC 판단을 확인하세요. 재서명 누락만으로 모든 실패를 설명할 수는 없습니다.

현재 TrekMail 문서에서 사용 중인 경로에 OpenARC, DKIM 재서명, 자동 SRS가 적용되는지 확인하세요. 각 기능의 목적은 다르며 수신을 보장하지 않습니다. 사서함 전달 설정에서 목적지 주소를 지정하고 테스트 메시지로 서명된 내용이 유지되는지 확인하세요.

	직접 운영하는 Postfix	TrekMail
SRS 재작성	postsrsd 수동 설정과 검증 필요	현재 경로의 자동 적용 여부 확인
ARC 서명 + DKIM 재서명	OpenARC 구성과 설계에 따른 별도 DKIM 단계	현재 인프라와 구성 확인
메시지 변경 위험	플러그인이 서명된 내용 변경 가능	전달 경로의 내용 보존 확인
캐치올 전달량 관리	자체 필터링과 모니터링 필요	현재 도메인별 설정 확인

안내된 요금은 사서함 전달을 포함한 Pro ($10/월), Agency ($23.25/월)이며, 카드 등록이 필요한 14일 무료 체험이 제시되어 있습니다. Nano ($0, 도메인 10개, 자체 SMTP)와 Starter ($3.50/월, 도메인 50개)는 전달 미포함으로 안내됩니다. 구매 전에 trekmail.net/pricing의 전체 요금제 비교에서 현재 가격, 기능, 한도를 확인하세요.

결론

2026년에 안정적으로 도메인 이메일 전달을 운영하려면 봉투 발신자, 정렬된 DKIM 보존, 수신 정책 확인이 중요합니다. SRS와 ARC는 도움이 될 수 있지만 모든 구성의 필수 조건이나 수신 보장은 아닙니다. 전달 서비스의 새 DKIM 서명은 원래 발신자와의 정렬을 대신하지 않습니다.

문제 해결은 신뢰할 수 있는 수신 서버의 Authentication-Results부터 시작하세요. 해당 서버의 검사 결과를 보여주므로 이전 헤더와 로그를 함께 살펴 전체 경로를 확인해야 합니다.

Postfix를 직접 관리하고 싶지 않다면 TrekMail로 도메인에 업무용 이메일 설정하기를 참고하세요. 간단한 설정은 약 15분 걸릴 수 있습니다. 현재 SRS, ARC, DKIM 지원을 확인하고 실제 경로를 테스트하세요.