이메일 별칭 전달의 SPF·DMARC 오류와 대응 방법

이메일 별칭 전달을 설정해 contact@yourdomain.com의 메일을 Gmail에서 받습니다. 몇 달 동안 잘 작동했습니다. 그런데 고객이 서명된 계약서에 관해 보낸 이메일을 보지 못합니다. 세 주 뒤 알게 되었을 때는 이미 계약 기회를 놓쳤습니다.

자신에게는 반송 알림이 없고 스팸 폴더에도 없습니다. 빠진 이메일과 놓친 기회만 남습니다.

별칭과 전달을 함께 사용할 때 엄격한 DMARC 정책으로 이런 문제가 생길 수 있습니다. 수신자는 실패를 알아차리지 못하기도 합니다. 프로토콜을 이해하면 원인을 찾고 위험을 줄이는 데 도움이 됩니다. 이 안내서는 문제 지점, 로그에서 확인할 오류 코드, 전달 메일의 인증을 개선하는 두 가지 방식을 설명합니다. 배달을 보장하는 방법은 아닙니다.

기본 설정부터 필요하다면 이메일 전달 설정 및 문제 해결 안내서를 먼저 읽으세요. 이 글은 오류가 발생하는 방식을 다룹니다.

이메일 별칭 전달이 실제로 하는 일

이메일 별칭은 라우팅 규칙으로, 자체 수신함이나 로그인, 저장 용량이 없습니다. 누군가 sales@yourdomain.com으로 보내면 서버가 메시지를 받아 다른 곳, 흔히 개인 Gmail 또는 Outlook 계정으로 전달합니다. 소규모 기업의 업무 주소에 자주 사용되지만, 알아차리기 어려운 배달 문제를 일으킬 수 있습니다.

별칭에서 외부로 전달할 때는 새 SMTP 연결을 열어 목적지로 보냅니다. 이 단계에서 인증 문제가 생길 수 있습니다. 자사 서버가 다른 곳에서 만들어진 이메일을 원래 발신자와 관련된 인증 정보를 그대로 둔 채 다시 보내기 때문입니다.

이메일의 두 계층

모든 이메일에는 평소 잘 생각하지 않는 두 가지 계층이 있습니다. 이를 구분하면 전달이 인증을 방해하는 이유를 이해할 수 있습니다.

client@bank.com이 별칭 sales@yourdomain.com으로 이메일을 보내면 bank.com 서버가 발송합니다. 이 예시에서는 bank.com이 자체 발송 IP를 허용하므로 SPF가 성공합니다.

자사 서버가 founder@gmail.com으로 전달하면 새 SMTP 연결이 열립니다. 연결 IP는 자사 서버 것이지만 봉투 발신자는 원래 주소로 남을 수 있습니다. 헤더에는 여전히 client@bank.com이 표시됩니다.

Gmail이 bank.com의 SPF를 검사하면 허용되지 않은 자사 서버 IP가 보여 SPF가 실패할 수 있습니다. bank.com에 p=reject가 있고 정렬된 DKIM 검증도 성공하지 못한다면 Gmail은 수신 정책에 따라 거부할 수 있습니다. 반송 알림이 자신이 아닌 원래 발신자에게 갈 수도 있지만, 반드시 알림 없이 삭제되는 것은 아닙니다.

이메일 별칭 전달의 세 가지 문제

전달 문제는 서로 다른 계층에서 발생하며, 각각 증상과 대응 방식이 다릅니다.

1. SPF 실패

SPF는 발송 서버 IP가 SMTP 봉투 발신자 도메인의 DNS 레코드에서 허용되는지 검사합니다. 전달 후의 새 연결에서는 원래 발신자의 IP 대신 자사 서버 IP가 사용됩니다. 원래 봉투 발신자를 유지하고 자사 IP가 허용되지 않았다면 목적지에서 SPF가 실패할 수 있습니다.

2. DMARC 거부

DMARC는 SPF 또는 DKIM이 성공하고 동시에 From: 도메인과 정렬될 것을 요구합니다. SPF가 실패해도 유효하고 정렬된 DKIM이 있으면 DMARC는 성공할 수 있습니다. 하지만 바닥글 추가나 서명된 헤더 변경 등은 DKIM을 무효로 만들 수 있습니다. 정렬된 검증이 모두 실패하면 p=quarantine은 격리를, p=reject는 거부를 요청합니다. 실제 적용 방식은 수신 시스템이 결정합니다.

3. 수신자에게 알리지 않는 손실

최악의 경우 목적지 서버가 NDR, 즉 배달 실패 보고서를 보내지 않고 메시지를 버릴 수 있습니다. 다만 DMARC 실패의 필수 결과는 아닙니다. SMTP 거부가 원래 발신자에게 알림을 만들 수도 있습니다. 별칭 수신자는 아무것도 보지 못할 수 있어 문제를 발견하기 어렵습니다.

SMTP 로그에서 찾아야 할 오류 코드

전달 메일이 사라졌다면 SMTP 로그를 확인하거나 제공업체에 NDR 기록을 요청하세요. 다음 세 코드는 조사에 도움이 되지만, 맥락에 따라 실제 원인을 확인해야 합니다.

Microsoft 365 차단(5.7.520)

Exchange Online은 테넌트 정책으로 외부 자동 전달을 차단할 수 있습니다. 데이터 유출 방지 설정이 정상적인 전달도 막을 수 있으므로 실제 설정과 현재 지침을 확인해야 합니다.

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

대응: 권한 있는 관리자가 위험을 평가한 뒤 Microsoft 365 관리 포털의 발신 스팸 필터 정책에서 예외를 허용할지 검토합니다. 명시적 리디렉션 규칙이 차단을 반드시 우회한다고 생각하지 말고, 테넌트 정책에서 허용하는 방식을 확인하세요.

라우팅 루프(5.4.14 / 5.4.6)

두 별칭이 서로 전달하거나 캐치올의 목적지가 원래 도메인으로 메시지를 되돌려 보내면 루프가 생길 수 있습니다.

554 5.4.14 Hop count exceeded - possible mail loop

대응: 전송 규칙을 점검하세요. 예를 들어 *@yourdomain.com 캐치올이 모든 수신 메일에 자동 응답하는 주소로 전달되는지 확인합니다. 부재중 응답만으로 반드시 루프가 생기지는 않지만, 순환 경로나 방지 장치 부족이 원인이 될 수 있습니다.

DMARC 인증 실패(550 5.7.1)

이 예시에서는 목적지 서버가 DMARC 인증 문제로 전달된 메시지를 거부했습니다.

550-5.7.1 Unauthenticated email from bank.com is not accepted due to domain's DMARC policy.

전달 중 나타날 수 있는 DMARC 오류의 예시이지만 코드만으로 전달이 원인이라고 단정할 수 없습니다. SPF와 DKIM 결과를 조사하세요. 서버 수준의 SRS와 ARC가 도움이 될 수 있지만 보장은 아니며 올바른 DNS 설정도 필요합니다.

완화 방법: SRS와 ARC

목적지 서버에 정책 예외를 강요할 수는 없습니다. SRS와 ARC는 외부 전달을 위한 상호 보완적인 방식이며 MTA, 즉 메일 전송 서버에 구현됩니다. 서버를 직접 관리하지 않는다면 제공업체에 지원 여부와 적용 방식을 확인하세요.

SRS(Sender Rewriting Scheme)

SRS는 Return-Path에 기록되는 SMTP 봉투 발신자를 전달 서버의 도메인으로 바꿉니다. 해당 도메인의 SPF 레코드가 서버를 올바르게 허용하고 다른 검증 조건도 충족하면 목적지에서 SPF가 성공할 수 있습니다.

SRS 없음:
봉투 발신자: client@bank.com
발송 IP: 자사 전달 서버
SPF 결과: 예시에서는 FAIL. 자사 IP가 bank.com 레코드에서 허용되지 않음

SRS 사용:
봉투 발신자: SRS0=Hash=TT=bank.com=client@yourdomain.com
발송 IP: 자사 전달 서버
SPF 결과: 예시에서는 PASS. 자사 IP가 yourdomain.com에서 허용됨

SRS는 바꾼 주소에 해시와 시간 정보도 넣어 유효성을 확인하고 악용을 제한합니다. 만료 기간은 보통 일 단위로 설정하며 구현에 따라 다릅니다. 주소 수집이나 모든 재사용을 막는다는 뜻은 아닙니다.

ARC(Authenticated Received Chain)

SRS는 목적지의 SPF를 개선할 수 있지만 SPF의 DMARC 도메인 정렬을 단독으로 복구하지는 않습니다. DMARC는 From: 도메인(bank.com)을 인증된 도메인과 비교합니다. SRS 이후 봉투는 yourdomain.com이고 From:은 여전히 bank.com이므로 서로 다릅니다. 다만 유효하고 정렬된 DKIM이 있으면 DMARC는 성공할 수 있습니다.

ARC는 RFC 8617에 정의되며, 각 단계에서 확인한 인증 결과를 서명된 체인으로 기록합니다. 서버는 전달 메시지와 기록한 결과에 봉인을 추가합니다. SPF와 DKIM이 모두 유효했다고 자동 선언하는 것이 아니라 실제 관찰한 결과를 문서화합니다.

지원되는 구성의 Gmail과 Outlook 등 수신 시스템은 ARC와 전달 서버의 평판을 판단에 활용할 수 있습니다. 유효한 봉인이 신뢰나 배달을 강제하지는 않습니다. ARC는 DMARC 도메인 정렬 자체를 바꾸지 않습니다.

둘 다 단순한 DNS 설정이 아닙니다. SRS 재작성과 ARC 봉인은 전송 계층의 지원이 필요합니다. 엄격한 DMARC 아래 외부 전달에서는 올바른 DNS, 손상되지 않은 DKIM, 수신자 정책이 여전히 중요합니다.

두 가지 운영상의 함정

SRS와 ARC를 사용해도 흔한 두 가지 구성이 문제를 일으킬 수 있습니다.

답장에서 개인 주소가 노출되는 문제

전달은 수신을 처리하며 발신 계정을 자동 설정하지 않습니다. Gmail에서 다른 발신자를 설정하지 않고 답장하면 From에 founder@gmail.com이 표시되고 sales@yourdomain.com은 표시되지 않을 수 있습니다. 고객은 개인 주소를 보게 됩니다.

가능한 방법은 현재 Gmail 계정 설정의 “다른 주소에서 메일 보내기”에서 별칭과 도메인의 허용된 SMTP 인증 정보를 추가하는 것입니다. 지원되는 발송 방식에서는 Gmail이 해당 서버를 사용합니다. 실제 답장 주소도 확인하세요. 연결 정보는 TrekMail 관리형 SMTP 설정을 참고하세요.

이 방법은 사용할 수 있지만 원문 절차에서는 계정마다 세 가지 설정 단계가 추가됩니다. SMTP 비밀번호를 바꾸면 Gmail 설정도 갱신해야 할 수 있습니다.

캐치올 외부 전달의 함정

캐치올(*@yourdomain.com)을 외부로 전달하지 않는 것이 좋습니다. 스팸 발신자는 알려진 도메인에 billing@, admin@, noreply12345@ 같은 로컬 부분을 시험합니다. 캐치올은 이런 메시지를 받고 필터를 통과한 스팸까지 전달할 수 있습니다.

많은 스팸을 전달하면 서버 IP의 평판이 나빠질 수 있습니다. 실제 메일함에서 발송한 정상적인 메일까지 스팸으로 분류될 수 있습니다. 평판 복구에는 시간이 걸리기도 하지만, 반드시 발생하는 결과나 정해진 기간은 아닙니다.

캐치올이 필요하면 별도의 로컬 수신함으로 보내고 직접 확인하는 편이 좋습니다. TrekMail 메일함 전달 문서를 참고해 불필요한 스팸 전달을 늘리지 않는 구성을 검토하세요.

별칭 전달과 실제 메일함: 무엇을 선택할까요?

자세한 선택 기준은 도메인 이메일 별칭과 메일함 비교 안내서를 참고하세요. 전달에 관한 요점은 다음과 같습니다.

비용만 아끼려고 별칭 전달을 실제 메일함의 영구 대체 수단으로 쓰는 것은 피하세요. 사용자 단위 가격에서는 매력적으로 보여도 추가 설정, 예외 처리, 인증 위험까지 평가해야 합니다.

TrekMail의 전달 처리 방식

SRS와 ARC를 직접 관리하려면 전송 설정, Postfix 통합, ARC 서명 키 관리와 교체가 필요합니다. 세부 사항은 시스템에 따라 다릅니다. 단순한 별칭 설정이 아닌 서버 관리 작업입니다.

원문은 TrekMail Pro와 Agency의 메일함 전달이 OpenARC 지원 전송 계층을 사용하며 전달 트래픽에 ARC 봉인을 자동 적용한다고 설명합니다. 목적지는 대시보드에서 설정하는 모델입니다. 현재 지원 여부, 한도와 동작은 문서에서 확인해야 합니다. 이 설명만으로 SRS 지원은 확인되지 않으며 배달도 보장되지 않습니다. 도메인의 DNS 인증은 여전히 올바르게 설정해야 합니다.

많은 경우 전달을 생략하고 전용 메일함을 쓰는 편이 더 간단합니다. 원문의 TrekMail 정액 모델은 사용자나 메일함당 추가 요금이 없습니다. support@yourdomain.com에 한 명이 로그인하든 열 명이 로그인하든 그 이유만으로 가격이 바뀌지 않는 모델이지만, 한도와 지원되는 접근 방식을 따라야 합니다. 현재 조건과 보안 요건을 확인한 뒤 선택하세요.

• 중소기업: support@에 전용 IMAP 로그인을 부여하고 발송용 SMTP를 설정하세요. 직접 접근하면 발신자 분리가 쉬워지고 외부 서비스의 발신 설정을 갱신할 필요가 줄어듭니다.
• 에이전시: 팀원의 개인 계정으로 전달하는 대신 고객 업무 주소에 전용 메일함을 만드세요. 허용된 접근과 올바른 클라이언트 설정이 있으면 팀이 정해진 업무 주소로 답장할 수 있습니다.

도메인의 SPF, DKIM, DMARC도 처음부터 설정한다면 기업용 이메일 보안 기본 설정에서 인증의 주요 요소를 함께 설명합니다.

결론

이메일 별칭 전달은 중요도가 낮은 용도에 적합할 수 있습니다. 특히 다음 위험을 확인하세요.

1. 원래 발신자가 엄격한 DMARC(p=quarantine 또는 p=reject)를 사용하고 정렬된 유효 인증이 남지 않음
2. 전달 서버에 SRS가 없어 목적지에서 원래 SPF가 실패할 수 있음
3. 전달 서버에 ARC가 없어 해당 서버가 관찰한 이전 결과를 서명된 ARC 기록으로 전달할 수 없음. SRS만으로 SPF가 DMARC와 정렬되지는 않지만 정렬된 DKIM은 충분할 수 있음
4. 캐치올을 외부로 전달해 스팸을 증폭할 수 있음
5. 별칭에서 답장해야 하지만 전달은 발신 계정을 자동 설정하지 않음

필요에 따라 SRS와 ARC를 포함한 적절한 프로토콜 지원을 제공업체에 요청하거나, 직접 로그인할 수 있는 실제 메일함으로 바꾸세요. 사용자당 요금에서는 전달이 매력적으로 보여도, 원문의 TrekMail 정액 플랜은 한도 내 메일함에 추가 라이선스가 발생하지 않는다고 설명합니다.

원문은 TrekMail Pro가 $10/월부터라고 안내합니다. 최대 도메인 100 개, ARC 봉인 적용 메일함 전달, 한도 내 메일함당 추가 요금 없음이 명시되어 있습니다. 또한 14 일 무료 체험에는 신용카드가 필요하지만 Nano에는 필요 없다고 설명합니다. 현재 가격과 조건을 확인하세요.