도메인 이메일을 Gmail로 전달하는 설정과 확인 방법

contact@yourdomain.com의 이메일을 Gmail로 전달하도록 설정했습니다. 고객이 계약서를 보내고 은행이 보안 알림을 보내지만, 두 메시지가 모두 보이지 않습니다.

스팸을 확인해도 없습니다. 자신의 계정에는 기록이나 오류, 알림이 없는 상황입니다. 그렇다고 원래 발신자도 알림을 받지 않았다는 뜻은 아닙니다.

이는 Gmail의 사용성보다 인증 문제일 수 있습니다. 도메인 이메일을 Gmail로 전달하면 자사 서버가 다른 도메인에서 온 이메일을 자신의 IP로 다시 보냅니다. 봉투 발신자를 유지하면 Gmail은 자사 IP를 허용하지 않는 원래 도메인의 SPF를 검사할 수 있습니다. SPF가 실패하고 유효하며 정렬된 DKIM도 없다면 엄격한 DMARC(p=reject)로 550-5.7.26 거부가 발생할 수 있습니다. SMTP 거부는 원래 발신자에게 반송 알림을 만들 수 있으며, 자신에게 알림이 없다고 양쪽에 통지 없이 영구 삭제되었다고 볼 수는 없습니다.

위험을 줄이려면 SRS(Sender Rewriting Scheme)로 봉투 발신자를 바꾸고 ARC(Authenticated Received Chain)로 이전 인증 결과를 기록하는 방식을 검토하세요. 두 방식은 상호 보완적이지만 배달을 보장하지 않습니다. 원래 DKIM이 유효하고 정렬되면 그것만으로 DMARC가 성공할 수도 있습니다.

이 글은 SRS, 루프 방지, Gmail 발신 계정 설정을 다룹니다. 전달 중 SPF, DKIM, DMARC와 SRS가 작동하는 원리는 이메일 전달 설정 및 문제 해결 종합 안내서를 참고하세요.

Gmail이 전달 메일을 거부할 수 있는 이유

원래 발신 도메인이 자사 서버 IP를 허용하지 않으면 전달 과정에서 SPF가 실패할 수 있습니다. SRS는 전달 서버 도메인으로 SPF를 검사하도록 하지만 해당 도메인에서 서버를 올바르게 허용해야 합니다. SRS만으로 DMARC 정렬이 복구되지는 않으며 DKIM, ARC와 수신자 정책도 중요합니다.

client@bank.com의 메시지가 you@gmail.com으로 전달될 때 가능한 오류 시나리오입니다.

1. bank.com이 전달 서버에 배달합니다
2. 자사 서버가 Gmail로 다시 보냅니다
3. Gmail이 봉투 발신자 client@bank.com의 SPF를 검사합니다
4. bank.com의 SPF가 자사 IP를 허용하지 않습니다 → 이 예시에서 SPF FAIL
5. DMARC가 p=reject이고 정렬된 인증도 성공하지 못합니다 → Gmail이 550-5.7.26을 반환할 수 있습니다
6. 메시지가 배달되지 않습니다. 자신에게는 알림이 없어도 원래 발신자는 반송 알림을 받을 수 있습니다.

서명에 포함된 본문이나 제목을 수정하지 않으면 전달 후에도 DKIM이 유효할 수 있습니다. 보안 검사 바닥글 추가나 제목 변경은 피하세요. 유효하고 정렬된 DKIM은 SPF가 실패해도 DMARC를 통과시킬 수 있습니다. aspf=s는 SPF 정렬만 규정하며 DKIM 정렬에 영향을 주지 않습니다. 서명된 부분을 변경하면 DKIM이 무효가 될 수 있습니다. SRS는 SPF 완화 방식이지 DMARC나 배달의 보장은 아닙니다.

도메인 이메일을 Gmail로 전달하는 세 가지 구성

모든 구성의 위험이 같지는 않습니다. 용도에 맞는 아키텍처를 선택하세요.

캐치올은 전달 서버의 평판을 악화시킬 수 있습니다. 스팸 발신자는 abc123@yourdomain.com, junk@yourdomain.com 같은 주소를 시험합니다. 서버가 이를 받으면 필터를 통과한 스팸도 전달됩니다. 설명용 시나리오에서 90%가 스팸이라면 IP 평판이 나빠지고 정상 메일도 스팸으로 분류될 수 있습니다. 이는 Gmail의 공식 임계값이나 자동 차단 조건이 아닙니다. 복구에는 몇 주가 걸리기도 하지만 정해진 기간은 없습니다.

별칭과 메일함의 차이는 이메일 별칭 전달의 이점과 위험을 참고하세요. 새 주소를 선택할 때는 도메인 이메일 별칭과 메일함 비교가 도움이 됩니다.

Gmail 전달에서 SRS가 중요한 이유

SRS(Sender Rewriting Scheme)는 봉투 발신자를 원래 도메인에서 전달 서버 도메인으로 바꾸어 SPF 문제를 완화합니다. 이 주소는 Return-Path에 기록되고 반송에 사용됩니다. Gmail은 전달 서버의 도메인으로 SPF를 검사할 수 있지만 올바른 IP 허용이 필요하며 DMARC나 배달은 보장되지 않습니다.

SRS 없음(오류 시나리오):
봉투 발신자: client@bank.com
발송 IP: 203.0.113.10(자사 전달 서버)
SPF: bank.com 레코드 → FAIL(203.0.113.10이 허용되지 않음)
DMARC: 정렬된 DKIM이 없으면 FAIL 가능(p=reject) → 거부 및 발신자 알림 가능

SRS 사용(SPF 완화):
봉투 발신자: SRS0=HASH=TT=bank.com=client@yourdomain.com
발송 IP: 203.0.113.10(자사 전달 서버)
SPF: yourdomain.com 레코드 → 이 예시에서는 PASS(203.0.113.10이 허용됨)
헤더 발신자: client@bank.com(변경 없음, 원래 발신자 표시)

SRS 도메인의 SPF는 전달 서버 IP를 직접 또는 적절한 방식으로 허용해야 합니다. 허용이 없으면 SRS 이후에도 SPF가 실패할 수 있습니다. 호스트 이름만 적는다고 유효한 SPF 설정이 되는 것은 아닙니다.

전달 인프라는 ARC(Authenticated Received Chain) 헤더도 추가할 수 있습니다. ARC는 각 단계에서 관찰한 인증 결과를 서명된 체인으로 기록합니다. 수신자는 전달 서버에 대한 신뢰를 포함해 평가합니다. 올바른 ARC 서명과 공개 키가 필요하지만 일반 DKIM 서명과 동일하지 않으며 DMARC 정렬을 바꾸지도 않습니다. 관리형 서비스에서는 제공업체 지원을 확인하세요.

SPF는 RFC 7208에 정의됩니다. 여러 단계의 인증 결과를 기록하는 ARC는 RFC 8617에 정의됩니다.

루프 방지: 시작 전 네 가지 검사

전달 루프는 5.4.14 Hop count exceeded 같은 오류를 만들고 정상 메일을 막을 수 있습니다. 운영을 시작하기 전에 다음 네 가지를 확인하세요.

1. 순환 경로가 없어야 합니다. you@gmail.com이 you@yourdomain.com으로 되돌려 보내고 다시 Gmail로 오는 필터를 갖고 있는지 확인하세요. 이런 경로가 루프를 만들 수 있습니다.
2. 자동 응답을 관리하세요. 업무 주소(team@domain.com → 여러 Gmail 계정)에서는 자동 응답 중지와 서버 방지 장치를 검토합니다. 일부 시스템은 Precedence: bulk를 고려하지만 보편적인 루프 방지책은 아닙니다.
3. 제삼의 계정에서 시험하세요. Gmail은 중복을 제거할 수 있어 목적지 계정에서 별칭으로 보낸 테스트가 보낸 편지함에만 나타날 수 있습니다. Yahoo나 Outlook 같은 외부 계정으로 독립적인 시험을 하세요.
4. M365 발신 정책을 확인하세요. Microsoft 365가 전달 서버라면 권한 있는 관리자가 발신 스팸 정책을 확인하고 승인된 경우에만 자동 전달을 허용해야 합니다. 테넌트가 차단하면 550 5.7.520이 발생할 수 있습니다. 보안 정책을 우회하지 마세요.

Gmail 전달을 처음 설정할 때 흔한 문제입니다. 오류 메시지만으로 원인이 분명해지는 것은 아닙니다.

TrekMail로 도메인 이메일을 Gmail에 전달하기

원문은 TrekMail이 전달 메시지에 MTA 수준의 SRS 재작성과 ARC 서명을 적용하고 사용자는 목적지를 설정한다고 설명합니다. 현재 지원과 문서를 확인하세요. 자동 처리도 Gmail의 수신을 보장하지 않습니다.

설명된 버전에서는 메일함 전달이 Pro와 Agency 플랜에 제공되고 Free와 Starter는 이를 위해 업그레이드해야 합니다. 현재 이름과 조건을 확인하세요. 원문 절차는 TrekMail 메일함 전달 문서에 있습니다.

1. 대시보드에서 메일함을 엽니다
2. 대상 메일함의 관리를 선택합니다
3. 전달 활성화를 켭니다
4. 전달 대상에 Gmail 주소를 입력합니다
5. 초기 설정에서는 사본 보관을 켭니다
6. 전달 설정 저장을 선택합니다

“사본 보관”은 중요합니다. 설명된 흐름에서는 저장 용량과 로컬 배달이 정상이라면 메일함에 저장하면서 Gmail 전달을 시도합니다. 외부 배달을 보장하거나 백업을 대체하지는 않습니다. 꺼 두면 Gmail이 거부한 메일이 로컬에 남지 않을 수 있으며 큐와 오류 처리 방식에도 영향을 받습니다. 시험 중에는 켜 두고 저장 용량과 보존 정책을 확인하세요.

원문은 여러 메일함을 선택해 일괄 작업으로 공통 목적지를 지정하는 기능도 설명합니다. 백 개 도메인에 적용하는 경우에도 현재 제공 여부, 권한과 한도를 확인하고 목적지를 검증한 뒤 변경하세요.

답장도 완성하기: Gmail 발신 계정 설정

전달은 수신을 처리합니다. 발신자를 별도로 설정하지 않으면 답장이 도메인이 아닌 개인 @gmail.com에서 나갈 수 있습니다. 고객은 ceo@yourdomain.com 대신 Gmail 주소를 보게 됩니다.

허용된 외부 SMTP 인증 정보로 발신 주소를 설정하는 방법을 검토하세요. 발송 경로와 “별칭으로 취급” 옵션을 확인해야 합니다. 이 체크박스만으로 발송 서버가 정해지지는 않습니다. 올바르게 인증되지 않은 경로는 “via gmail.com” 표시나 DMARC 문제를 만들 수 있습니다.

현재 Gmail 인터페이스에 따라 설정 → 계정 및 가져오기 → 다른 주소에서 메일 보내기 → 다른 이메일 주소 추가를 엽니다. “별칭으로 취급”은 구성에 맞게 선택하며 해제가 항상 필수라고 생각하지 마세요.

원문의 TrekMail SMTP 설정(Starter, Pro, Agency):

SMTP Server:  smtp.trekmail.net
Port:         587
Security:     TLS (STARTTLS)
Username:     your-mailbox@yourdomain.com
Password:     Your mailbox password

원문의 Nano: 직접 준비하는 SMTP(SES, SendGrid, Mailgun 등):

SMTP Server:  email-smtp.us-east-1.amazonaws.com  (Amazon SES example)
Port:         587
Security:     TLS
Username:     Your SMTP credentials from your provider

SMTP 코드 블록은 예시입니다. 각 제공업체에서 현재 연결 정보와 인증 정보를 확인하세요. 설명된 절차에서는 주소 추가 후 Gmail이 메일함으로 확인 코드를 보냅니다. 코드로 주소를 확인하고 기본 발신자와 답장 동작을 설정하세요. 실제로 업무 주소가 표시되는지 시험해야 합니다.

결과 확인: Gmail 인증 헤더 읽기

외부 계정에서 테스트 메일을 받은 뒤, 운영 환경에서 신뢰하기 전에 원본 헤더를 확인하세요.

Gmail에서 메시지 열기 → 점 세 개 메뉴 → 원본 보기를 선택하고 Authentication-Results를 찾습니다.

다음은 검증 성공을 보여 주는 설명용 예시지만 DKIM 도메인은 전달 서버의 도메인입니다. 이것만으로 원래 From:과의 정렬, DMARC 성공이나 앞으로의 수신이 입증되지는 않습니다.

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of SRS0=hash=tt=bank.com=client@yourdomain.com
    designates 203.0.113.10 as permitted sender)
    smtp.mailfrom=SRS0=hash=tt=bank.com=client@yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  arc=pass (i=1 spf=pass dkim=pass)

spf=softfail이나 spf=fail이면 바뀐 발신자, IP, SPF와 DNS 응답을 확인하고 캐시와 TTL도 고려하세요. arc=fail은 서명 이후 변경뿐 아니라 잘못된 키, 서명, 체인으로도 발생합니다. 봉투 발신자 처리는 Google의 Gmail 전달 공식 지침을 참고하세요. SRS는 관련 방식 중 하나입니다.

직접 관리와 관리형 서비스: 실제 차이

직접 관리하는 Postfix에서는 postsrsd 설치, srs_secret 보호와 관리, 교체 계획, 올바른 ARC 키를 사용한 OpenARC 통합, 지원되는 Google Postmaster Tools로 평판 확인 등이 필요할 수 있습니다. 업데이트나 잘못된 키 교체, 새로운 발신 정책으로 대응이 필요해져 밤 11 시에 인증 헤더를 조사할 수도 있습니다.

원문의 TrekMail 모델은 목적지 설정 후 MTA가 SRS와 ARC를 처리합니다. 그래도 현재 지원, DNS 인증, 배달 결과를 확인해야 합니다. 관리형 서비스가 모든 운영 검사를 없애지는 않습니다.

시작하기

원문의 Nano는 카드 없이 도메인을 연결하는 선택지이지 전달이 포함된 플랜은 아닙니다. 도메인을 준비하고 DNS 검증을 기다리는 것부터 시작할 수 있습니다. 설명된 전달 기능과 관리형 SRS는 Pro에서 $10/월부터 정액으로, 한도 내 사용자당 요금 없이 제공된다고 안내합니다. 현재 제공 여부와 조건을 확인하세요.

원문은 유료 플랜에 카드가 필요한 14 일 무료 체험을 설명합니다. 카드 없이 시작하는 Nano를 포함한 현재 조건은 trekmail.net/pricing에서 확인하세요.

확인할 네 요소는 SRS 재작성, ARC 결과 기록, 전달 IP의 SPF 허용, 답장용 발신 설정입니다. 이들이 배달을 보장하지는 않습니다. 정렬된 DKIM, 수신자 정책, 로컬 보관과 로그도 확인하세요. 오류로 수신자가 모르는 배달 실패가 생길 수 있지만 항상 양쪽에 알림이 없는 것은 아닙니다.

신중하게 설정하고 헤더를 검증하며 계속 확인하세요.