다른 주소로 이메일 전달: 인증과 장애 진단 안내

전달 규칙을 설정하고 테스트 메일을 보냅니다. 정상적으로 도착하면 다음 일로 넘어갑니다.

그런데 고객이 답장을 받지 못했다고 합니다. 반송 메일도 NDR도 보이지 않습니다. 서버 사이 어딘가에서 배달되지 않았지만, 확인 가능한 알림은 없습니다.

다른 주소로 이메일을 전달할 때 이런 문제가 생길 수 있습니다. 전달 서버는 목적지에 새 SMTP 연결을 엽니다. 목적지는 원래 발신자의 IP가 아니라 전달 서버의 IP로 SPF를 검사합니다. 이 IP가 봉투 발신자 도메인에서 허용되지 않으면 SPF가 실패할 수 있습니다. 정렬된 DKIM 서명도 없거나 전송 중 변경으로 무효화되면 DMARC가 실패합니다. p=reject 정책은 거부를 요청하지만, 수신 서버의 실제 처리와 반송 여부는 정책과 경로에 따라 달라집니다.

설정 오타만의 문제는 아닙니다. 전달 방식과 현대적인 인증 방식이 충돌할 수 있습니다. 이메일 전달 설정과 문제 해결 종합 가이드는 여러 상황을 다룹니다. 이 글에서는 인증 실패 유형, 오류 코드, 대응 방법에 집중합니다.

다른 주소로 전달할 때 인증이 실패할 수 있는 이유

전달된 메일을 받는 MTA는 전달 서버의 IP로 SPF를 검사합니다. 이메일에는 서로 다른 식별 계층이 있으며 전달 과정에서 도메인 정렬이 어긋날 수 있습니다. SPF는 봉투 식별자를 검사하고, DMARC는 표시되는 발신자 도메인과 정렬된 SPF 또는 DKIM 성공을 요구합니다. 실패한 메일의 처리는 수신 정책에 달려 있습니다.

서버 A가 전달 서버 B에 보내면 B는 목적지 C와 새 TCP 연결을 엽니다. C는 B의 IP를 봅니다. SPF는 봉투 도메인의 DNS에 "이 IP가 이 도메인으로 발송하도록 허용되어 있는가?"를 묻습니다. 원래 봉투 발신자를 유지하고 B가 허용되지 않았다면 SPF가 실패할 수 있습니다. 모든 전달에서 예외 없이 실패하는 것은 아닙니다.

DMARC는 SPF 또는 DKIM 중 하나가 성공하고 도메인 정렬도 맞으면 통과합니다. 따라서 원래 발신 도메인과 정렬된 유효한 DKIM 서명이 전달된 메일을 구할 수 있습니다. 서명 대상 본문이나 헤더의 변경은 정규화 방식과 서명 범위에 따라 DKIM을 깨뜨릴 수 있습니다. 정렬된 성공 결과가 없다면 DMARC가 실패합니다. p=reject는 거부 요청이지 최종 처리의 보장이 아닙니다.

알아두어야 할 세 가지 실패 유형

이메일 전달 중에는 서로 다른 원인의 문제가 발생할 수 있습니다. 아래 유형마다 조사할 설정과 해결 방법이 다릅니다. 실제 오류 코드는 환경에 따라 달라질 수 있지만, 유형을 구분하면 진단 범위를 좁힐 수 있습니다.

1. Microsoft 365 발신 차단 (550 5.7.520)

Microsoft 365는 데이터 유출을 막기 위해 자동 외부 전달을 기본적으로 차단할 수 있습니다. 테넌트 외부로 전달하는 사서함 규칙을 만들면 Exchange Online이 발송 전에 차단할 수 있습니다. 해당 사용자에게 실제 적용되는 정책을 확인하세요.

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

이는 프로토콜 오류가 아니라 정책 차단입니다. 권한 있는 관리자가 다음을 확인할 수 있습니다.

1. Microsoft 365 Defender Portal을 엽니다.
2. Email & collaboration → Policies & rules → Threat policies → Anti-spam으로 이동합니다.
3. 승인된 사용자 또는 그룹으로 범위가 제한된 Outbound spam filter policy를 편집합니다.
4. 허용된 경우 해당 범위의 Automatic forwarding을 On - Forwarding is enabled로 설정합니다.

전역 활성화는 계정 탈취 시 위험을 높입니다. 승인된 계정으로 허용 범위를 제한하고 MFA를 적용하며 변경 후 발신량을 모니터링하세요. 전달을 차단하는 다른 정책이나 규칙도 확인해야 합니다.

2. DMARC에 필요한 정렬된 인증 결과 부재

이 문제는 겉으로 잘 드러나지 않을 수 있습니다. 전달 시 IP가 바뀌어 SPF가 실패하더라도 정렬된 유효 DKIM이 있으면 DMARC는 통과할 수 있습니다. 다만 정규화로 흡수되지 않는 서명 대상 본문이나 헤더 변경은 DKIM을 무효화할 수 있습니다.

DKIM을 깨뜨릴 수 있는 흔한 변경은 다음과 같습니다.

• 백신 소프트웨어가 추가하는 바닥글: "[제품명]으로 검사됨"
• 목적지 게이트웨이의 제목 태그: [EXT] 또는 [EXTERNAL], Subject가 서명된 경우
• HTML 본문에 삽입되는 "외부 발신자" 경고 배너
• 서명된 헤더를 다시 쓰거나 구독 해지 바닥글을 추가하는 메일링 리스트 소프트웨어

정렬된 SPF 성공도 DKIM 성공도 없다면 DMARC (RFC 7489) 결과는 FAIL입니다. p=reject는 거부를 요청하지만 수신 서버가 실제 처리를 결정합니다. SMTP 거부 후 NDR이 발생할 수도 있고, 다른 처리에서는 눈에 띄는 알림이 없을 수도 있습니다. 로그와 인증 결과를 확인하세요.

3. 라우팅 루프 (554 5.4.14)

서버가 메시지를 계속 서로 돌려보내면 홉 수 제한 등에 걸릴 수 있습니다. NDR이 발생할 수 있지만 즉시 생성된다고 보장할 수는 없습니다. 루프는 메일 큐를 과부하시키고 다른 배달까지 지연시킬 수 있습니다.

흔한 원인은 다음과 같습니다.

• 사용자 A가 B로 전달하고, B가 다시 A로 전달하는 규칙을 설정한 경우.
• A가 B로 전달하고 B의 부재중 자동 답장이 다시 전달 경로에 들어가는 경우. 반복 여부는 규칙과 루프 방지에 달려 있으며 올바른 자동 답장은 보통 반복을 억제합니다.
• 캐치올 주소가 사서함으로 전달하고, 그 사서함이 같은 도메인의 존재하지 않는 주소로 다시 전달하는 경우.

554 5.4.14 Hop count exceeded - possible mail loop

운영 환경에서 다른 주소로 이메일을 전달하기 전에 자동 답장과 캐치올 목적지를 포함한 전체 경로를 검증하세요.

대응 수단: SRS와 ARC

SRS와 ARC는 전달 인증 문제를 줄이는 서버 측 수단이지 배달 보장 장치는 아닙니다. SRS는 봉투 발신자를 바꾸어 올바른 DNS와 발신 IP 설정에서 SPF가 통과하도록 돕습니다. ARC는 앞선 인증 결과를 기록하며 수신자가 재량으로 DMARC 실패 처리에 참고할 수 있습니다. 둘 다 클라이언트 규칙만으로 구현되는 것은 아닙니다.

SRS: Sender Rewriting Scheme

SRS는 봉투 발신자 (P1)를 자신이 관리하는 도메인으로 다시 씁니다. 발송 권한이 없을 수 있는 alice@bank.com을 봉투 발신자로 유지하는 대신 전달 서버는 Return-Path를 다음처럼 바꿀 수 있습니다.

SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.com

이제 SPF는 전달 도메인을 검사합니다. 해당 SPF 레코드가 발신 IP를 허용하고 나머지 검사도 정상이라면 SPF가 통과할 수 있습니다. 그러나 이것만으로 원래 From: 도메인과 정렬되는 것은 아닙니다.

해시와 타임스탬프는 반송 경로 검증을 지원합니다. NDR이 SRS 주소로 오면 서버가 검증하고 복원하여 Alice에게 전달할 수 있습니다. 이 주소는 유효 기간과 목적이 제한됩니다. 비밀키 관리와 주소 검증은 중요하지만, 오픈 릴레이 방지를 위한 릴레이 제한이나 다른 남용 방어를 대신하지 않습니다.

ARC: Authenticated Received Chain

SRS는 SPF를 통과시킬 수 있지만 봉투와 표시 헤더 사이의 정렬을 자동 복구하지 않습니다. ARC (RFC 8617)도 정렬을 복구하지 않습니다. 전달 서버는 수신 시 확인한 인증 상태를 서명된 정보로 메시지에 남깁니다.

Google과 Microsoft는 신뢰하는 중계자의 유효한 ARC 체인을 배달 판단에 사용할 수 있습니다. 좋은 평판과 유효한 체인이 있어도 Gmail이나 Outlook 배달이 보장되지는 않습니다. 누구를 신뢰하고 DMARC 실패를 어떻게 처리할지는 수신자가 정합니다.

ARC를 메시지 처리 경로의 증빙 기록으로 생각하세요. 참여하는 전달 홉은 관찰한 인증 상태에 서명합니다. 다음 수신자는 체인을 검증하고 일반적인 DMARC 검사에 실패한 경우에도 이를 신뢰할지 선택할 수 있습니다.

Gmail과 Microsoft 365는 지원되는 경로에서 ARC를 적용할 수 있으므로 실제 메시지 헤더를 확인하세요. ARC가 없으면 그 증빙은 없지만 원래의 정렬된 DKIM이 유효하면 DMARC는 여전히 통과할 수 있습니다. ARC 부재가 곧 DMARC 실패를 뜻하지는 않습니다.

구현: 두 가지 방식

자체 MTA에서 전달 인증을 관리하거나 필요한 기능을 지원하는 관리형 인프라를 선택할 수 있습니다. 어느 방식이든 실제 경로, 구성, 테스트 결과를 확인해야 합니다. 배달 실패를 완전히 없앤다고 보장할 수는 없습니다.

방식 A: Postfix + postsrsd (직접 관리)

Linux의 Postfix 서버에서는 postsrsd로 봉투 재작성을 구현할 수 있습니다. 아래 예시는 구형 TCP 테이블을 사용하는 구성입니다. 최신 주요 버전은 이 구성과 호환되지 않는 socketmap 테이블을 사용합니다. 적용 전에 설치 버전의 문서를 확인하세요.

# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

이 방식에서 직접 관리할 항목은 다음과 같습니다.

• SRS 비밀키 관리. 키 유출은 위조된 SRS 주소와 반송 경로 남용을 가능하게 할 수 있으며 별도의 릴레이 제한이 필요합니다.
• 로컬 도메인과 전달되지 않는 메일에 적절한 예외를 적용하여 내부 경로가 재작성 때문에 손상되지 않도록 하기.
• 발신 IP 평판 관리. 평판은 인증, 메시지 내용, 수신 정책과 함께 Gmail과 Outlook 배달에 영향을 줍니다.
• ARC 서명을 별도 구성하기. postsrsd만으로 ARC 서명이 제공되지는 않습니다.

이 방식은 효과적일 수 있지만 지속적인 유지보수가 필요합니다. 전문 플랫폼은 지원하는 기능과 경로에 따라 일부 작업을 대신할 수 있습니다.

방식 B: TrekMail (관리형 전달)

TrekMail을 사용할 때는 선택한 전달 경로에 자동 SRS 재작성, ARC 서명, 관리형 SMTP 릴레이가 제공되는지 확인하세요. 지원 여부는 요금제와 구성에 따라 달라질 수 있습니다. 관리형 인프라는 유지보수를 줄일 수 있지만 배달이나 특정 평판을 보장하지는 않습니다.

개인 창업자라면 info@yourdomain.com을 개인 받은편지함으로 전달하기 위해 사서함당 월 $6를 내는 대신 정액 옵션도 비교해 보세요. 여기 언급한 Starter의 월 $3.50, 최대 50개 도메인, 사용자별 추가 요금 없음은 참고 수치이며 현재 조건의 보장이 아닙니다. 실제 가격, 전달 권한, 한도를 확인하세요. TrekMail 사서함 전달 방식도 참고할 수 있습니다.

여러 고객의 DNS를 관리하는 대행사는 전달 도메인의 SPF 문제 진단에 많은 시간을 쓸 수 있습니다. 필요한 기능이 제공된다면 통합 대시보드가 관리를 단순화할 수 있습니다. 별칭과 사서함 규칙 중 선택할 때는 이메일 별칭 전달 가이드에서 차이를 확인하세요.

다른 주소로 이메일을 전달하기 전 점검표

운영 규칙을 활성화하기 전에 네 가지를 확인하세요. 관련 실패 위험을 줄이는 점검이지만, 배달 테스트와 로그 감시, 수신 정책 확인을 대체하지는 않습니다.

1. 필요한 경로에서 SRS가 작동하는지 확인합니다. 도착한 테스트 메일의 Return-Path를 검사하세요. SRS를 쓰는 경로에서는 재작성 주소가 전달 도메인을 사용해야 하며 실제 SPF 결과도 확인해야 합니다.
2. 서명된 내용을 보존합니다. DKIM을 깨뜨리는 백신 바닥글, 제목 태그, HTML 경고 삽입을 피하세요. 보안 검사는 끄지 말고 메시지를 변경하지 않는 동등한 보호를 유지하세요. 모든 변경이 DKIM을 깨뜨리는 것은 아니며 정규화와 서명 필드가 중요합니다.
3. 루프 방지를 검증합니다. 역방향 전달 규칙, 캐치올 경로, 자동 답장을 확인하세요. 부재중 답장이 항상 루프를 만든다고 가정하지 말고 실제 방지 동작을 테스트하세요.
4. M365 발신 정책을 확인합니다. Exchange Online에서는 Defender 포털의 범위 제한 정책으로 승인된 사용자나 그룹에만 "Automatic Forwarding"을 허용하세요. 실제 적용 정책과 다른 차단 규칙도 확인해야 합니다.

다른 주소로 전달하지 않는 편이 나은 경우

전달이 항상 최선은 아닙니다. 여러 도메인의 메일을 같은 로컬 받은편지함에서 받으려면 도메인 별칭으로 추가 전달 홉을 피할 수 있습니다. 다만 별칭이 외부 주소로 전달한다면 같은 인증 문제가 발생할 수 있으므로 실제 경로를 확인하세요.

도메인 이메일 별칭과 사서함 비교는 선택 기준을 설명합니다. 이전 제공업체에서 이동하는 경우 계정에 제공되는 TrekMail IMAP 마이그레이션 도구로 기존 메일을 직접 가져올 수 있습니다. 하지만 이것만으로 전환 중 새 메일의 라우팅까지 해결되지는 않습니다.

요약

전달 시 SPF는 전달 서버의 IP를 봅니다. 원래 봉투 도메인이 그 IP를 허용하지 않으면 SPF가 실패할 수 있습니다. 정렬된 원래 DKIM이 유효하면 DMARC는 통과할 수 있고, 그렇지 않으면 실패할 수 있습니다. 거부, 반송, 다른 처리는 수신자와 경로에 따라 달라집니다.

대응은 서버 측에서 이루어집니다. SRS는 봉투 발신자를 바꾸어 해당 도메인의 SPF 통과를 돕고, ARC는 수신자가 재량으로 참고할 서명된 인증 기록을 제공합니다. 둘 다 도메인 정렬이나 배달을 보장하지 않습니다. 직접 구현하거나 관리형 플랫폼의 실제 지원을 확인하세요.

SRS 키, ARC 구성, 발신 평판 관리 부담을 줄이려면 TrekMail이 필요한 경로와 기능을 제공하는지 확인하세요. 언급한 Starter 월 $3.50, 최대 50개 도메인, 정액제 및 사용자별 요금 없음은 최신 조건과 대조해야 합니다. 모든 요금제 보기.