550 5.7.1 오류: 반송 메일로 원인을 찾고 해결하는 방법

550 5.7.1 반송(바운스)은 수신 서버가 메일을 확인한 뒤 받지 않기로 했다는 뜻입니다. 이유는 대개 보안 규칙이나 정책 규칙입니다. 이메일 주소가 없어졌거나 삭제되었다는 뜻은 아닙니다. 대부분의 경우 상대방의 메일함에는 문제가 없습니다. 어려운 점은 같은 코드가 전혀 다른 문제에 쓰인다는 것입니다. SPF 레코드가 없는 경우도 있고, 사내 메일만 받는 배포 그룹이 원인인 경우도 있습니다. 그래서 코드만으로는 무엇을 고쳐야 하는지 알 수 없습니다. 코드 뒤에 오는 문구와 반송 메일을 보낸 서버의 이름을 보면 알 수 있습니다.

반송 메일에서 먼저 확인할 세 가지

이메일 플랫폼이 보여 주는 요약이 아니라 반송 메일 전체를 여십시오. 확인할 것은 코드, 메일을 거부한 서버, 코드 뒤의 문구입니다.

Gmail이 거부한 경우 반송 메일 원문은 다음과 같습니다.

Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 [203.0.113.10] Our system has detected that this message is likely unsolicited mail. To reduce the amount of spam sent to Gmail, this message has been blocked. - gsmtp

이 예에서 응답한 서버는 Remote-MTA 줄에 있는 gmail-smtp-in.l.google.com입니다. 코드는 Diagnostic-Code 줄에 550-5.7.1로 표시됩니다. IP 주소 뒤의 문구는 Gmail 필터가 이 메일을 스팸으로 판단했다는 뜻입니다. 끝에 붙은 - gsmtp 문자열은 Gmail이 이 반송 메일을 만들었다는 표시입니다. 대신 gcdp 표시가 있다면 수신자 측 Google Workspace 관리자가 만든 규칙에 따른 거부입니다. 예를 들면 550 5.7.1 This message violates example.com email policy. - gcdp <sessionid> - gsmtp 같은 문구입니다.

Outlook.com에서 온 같은 코드는 문구가 전혀 다릅니다.

Remote-MTA: dns; outlook-com.olc.protection.outlook.com
Diagnostic-Code: smtp; 550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150).

호스트 이름이 protection.outlook.com으로 끝나면 Microsoft 서버가 거부한 것입니다. outlook-com.olc.protection.outlook.com 같은 이름은 기업의 Microsoft 365 환경이 아니라 개인용 Outlook.com과 Hotmail의 서버입니다. 코드는 Gmail 예시와 같지만 원인은 전혀 다릅니다. S3150은 발송에 사용한 IP 주소 또는 그 네트워크의 일부가 Microsoft 차단 목록에 올라 있다는 뜻입니다. 수신자의 주소와는 관계가 없습니다.

내 반송 메일의 550 5.7.1 문구 찾기

메일 시스템마다 550 5.7.1의 문구가 다릅니다. 반송 메일의 문구를 아래 표의 행과 비교하십시오.

가장 모호한 경우는 RFC 3463의 기본 문구인 “550 5.7.1 Delivery not authorized, message refused”만 있고 그 뒤에 아무것도 없는 경우입니다. 스팸 발송자가 필터 조건을 알아내지 못하도록 일부러 이유를 짧게 쓰는 서버도 있습니다. 릴레이 서버나 스마트호스트를 거쳐 발송한다면, 먼저 앱이 발송 전에 실제로 로그인(SMTP AUTH)하는지 확인하십시오. 인증하지 않은 연결은 발신자 측에서 흔한 원인입니다. 로그인하고 있다면 수신자에게 자신의 메일 로그에서 그 메일을 찾아봐 달라고 요청하십시오. 실제 이유가 기록된 곳은 대개 그 로그뿐입니다.

발신자 측에 문제가 있는 경우

반송 메일이 인증, 평판, 릴레이 문제를 가리킨다면 수신자의 도움 없이 고칠 수 있습니다. 먼저 인증을 확인하십시오. SPF나 DKIM이 실패하는 동안에는 평판을 개선해도 효과가 없습니다.

지금은 Gmail과 Outlook.com 모두 인증되지 않은 메일을 상당수 바로 거부합니다. 그러므로 DNS부터 확인하십시오. 발송 도메인에는 SPF, DKIM, DMARC 레코드가 필요합니다(DKIM은 이메일 서비스 제공업체가 주는 CNAME인 경우가 많습니다). 먼저 SPF 레코드를 확인하십시오. SPF 레코드에는 발신자를 대신해 메일을 보내는 모든 서버 IP와 발송 서비스가 들어 있어야 합니다. RFC 7208은 도메인당 SPF 레코드를 1개, DNS 조회를 10회까지로 제한합니다. 레코드를 여러 개 게시하거나 조회가 10회를 넘으면 자동으로 PermError로 실패합니다. 다음으로 자신에게 테스트 메일을 보내고 헤더를 여십시오. Gmail의 “원본 보기” 화면에는 SPF, DKIM, DMARC가 PASS 또는 FAIL로 표시됩니다. DNS 레코드를 읽는 것보다 빠릅니다. DMARC 레코드는 _dmarc.yourdomain.com에 있습니다. 그리고 보낸 사람(From) 주소의 도메인은 SPF 또는 DKIM을 통과한 도메인과 일치해야 합니다.

인증을 통과했는데도 Gmail이 “likely unsolicited mail”(원치 않는 메일일 가능성이 높음)이라고 한다면, 문제는 대개 평판입니다. 평판은 수신자가 과거 메일에 어떻게 반응했는지를 뜻합니다. Google Postmaster Tools에서 스팸 신고율을 볼 수 있습니다. Google은 발신자에게 이 비율을 0.1% 미만으로 유지하고 절대 0.3%에 도달하지 않도록 요구합니다. 비율이 오르고 있다면 발송량을 더 늘리지 말고 캠페인을 일시 중지하십시오. 평판이 계속 떨어지면 스팸함으로 가던 메일이 아예 반송되기 시작하는 경우가 많습니다.

리스트 품질은 이 평판에 바로 영향을 줍니다. 오래된 리스트에는 버려진 메일함이 많습니다. 일부 메일 서비스는 오래전에 사용이 끝난 주소를 스팸 트랩으로 바꿉니다. 이런 주소로 메일을 보내거나 더 이상 없는 주소에서 반송이 많이 나오면, 필터는 리스트를 깨끗하게 관리하지 않는 발신자로 판단합니다. 리스트가 몇 달 이상 되었거나 스크래핑 또는 구매로 모은 것이라면, 발송 전에 이메일 리스트 정리(영어)로 리스트를 확인하십시오.

릴레이 오류는 별개의 문제입니다. “Unable to relay” 또는 “Invalid credentials for relay [IP]” 오류는 발송에 사용하는 서버가 앱을 사용 허가된 발신자로 인식하지 않는다는 뜻입니다.

Google Workspace SMTP 릴레이 서비스를 거쳐 메일을 보낸다면 Google 관리 콘솔을 열고 “앱”, “Google Workspace”, “Gmail” 순서로 이동한 뒤 “라우팅”을 여십시오. 그곳에서 SMTP 릴레이 서비스 설정을 확인합니다. IP 주소로 인증한다면 서버 IP가 허용 목록에 있는지 확인하십시오. 인증 정보로 인증한다면 애플리케이션이 TLS를 사용해 포트 587로 연결하고 올바른 계정 인증 정보를 쓰는지 확인하십시오. Microsoft 365를 통해 발송한다면 Exchange 관리 센터를 열고 메일 흐름 커넥터를 확인하십시오. CRM이나 사무실 스캐너처럼 Microsoft 365를 통해 메일을 보내는 앱과 기기는 보통 커넥터를 거칩니다. 그 커넥터의 IP 주소나 인증서 이름이 잘못된 것이 “550 5.7.1 Unable to relay”의 흔한 원인입니다.

수신자만 해결할 수 있는 경우

차단이 의도된 것일 때도 있습니다. Microsoft 365나 Google Workspace를 쓰는 회사는 외부 발신자가 특정 주소로 메일을 보내지 못하도록 규칙을 정해 두는 경우가 많습니다.

흔한 예는 all-staff@처럼 사내 메일만 받는 배포 목록입니다. 외부에서 이 주소로 메일을 보내면 Exchange Online이 550 5.7.1로 반송하며, 그룹 이름을 알려 주는 경우가 많습니다. Microsoft의 문제 해결 페이지에도 보통 발신자는 이 문제를 해결할 수 없다고 나와 있습니다. 그룹 소유자나 Exchange 관리자가 Microsoft 365 관리 센터에서 그룹을 편집해 발신자의 주소를 허용된 발신자 목록에 추가해야 합니다.

Google Workspace도 같은 방식입니다. Gmail 반송 메일에 gcdp 문자열이 있으면, 관리자가 Google 관리 콘솔에서 만든 사용자 지정 규칙이 내용, 첨부 파일, 발신자 도메인을 근거로 메일을 거부했다는 뜻입니다. 발신자 측에서 무엇을 바꿔도 이 규칙을 피할 수 없습니다.

이 경우에는 수신자에게 반송 메일을 IT 팀에 전달해 달라고 요청하십시오. 발신 주소, 수신 주소, 반송된 시각, 반송 메일 전체를 함께 알려 줍니다. 예를 들면 다음과 같습니다.

안녕하세요, [이름]님. [날짜] [시간]에 보내 드린 메일이 550 5.7.1 정책 오류로 반송되었습니다. 귀사 메일 시스템의 규칙에 따라 차단된 것으로 보입니다. 제 주소에서 보낸 메일을 받으실 수 있도록 아래 반송 정보를 IT 팀에 전달해 주시겠습니까?
발신자: [내 이메일]
수신자: [상대방 이메일]
진단 정보: [Diagnostic-Code 줄 붙여넣기]

550 5.7.1과 함께 나올 수 있는 코드

같은 반송 보고서에 자주 나오는 SMTP 오류 코드입니다. 주소가 없어졌다는 뜻인 코드도 있고, 주소는 정상이며 발신 설정을 고쳐야 한다는 뜻인 코드도 있습니다.

일시적 반송과 영구적 반송이 일반적으로 어떻게 다른지는 하드 바운스와 소프트 바운스 안내를 참고하십시오. 실제로는 550 5.1.1 뒤에는 주소를 삭제하고, 550 5.7.26 뒤에는 주소를 유지하십시오. 550 5.7.26의 경우 주소에는 문제가 없고 실패한 것은 인증이기 때문입니다.

550 5.7.515는 대량 발신자에게만 적용됩니다. 2025년 5월 5일부터 Microsoft는 Outlook.com, Hotmail, Live 주소로 하루 5,000통 이상 보내는 도메인의 메일을 거부하고 있습니다. SPF 통과, DKIM 통과, 그리고 둘 중 하나와 정렬되는 DMARC 레코드(p=none이면 충분)를 모두 갖춘 경우에만 메일을 받습니다.

온라인에서는 이 코드를 5.7.15로 적은 글도 있지만, 그것은 다른 코드(우선순위가 너무 낮음)입니다. Microsoft의 반송 메일에 표시되는 코드는 5.7.515입니다.

자주 묻는 질문

550 5.7.1 오류 코드는 어떻게 해결합니까? 반송 메일의 진단 줄을 읽고 실패 원인이 인증, 평판, 수신자 측 규칙 중 무엇인지 확인하십시오. 인증에 실패했다면 SPF, DKIM, DMARC 레코드를 업데이트하고 발신 SMTP 인증 정보를 확인하십시오. 수신자 측 관리자의 규칙이나 제한된 그룹 때문에 차단되었다면, 반송 메일의 헤더를 수신자에게 보내 IT 팀이 발신자의 주소를 허용하도록 하십시오.

550 5.7.1 unsolicited mail은 무엇입니까? Gmail 필터가 메일을 스팸으로 판단했다는 뜻입니다. 판단은 주로 발신자 평판을 근거로 합니다. 흔한 원인은 수신자의 스팸 신고, 새 도메인이나 IP에서의 갑작스러운 발송량 증가, 오래된 리스트로의 발송입니다. Google Postmaster Tools에서 스팸 신고율을 확인하고, 0.1% 미만으로 돌아올 때까지 발송 속도를 낮추십시오.

Outlook 상태 코드 5.7.1은 무슨 뜻입니까? Microsoft 365에서 Outlook의 5.7.1은 보통 Exchange 정책이나 그룹 제한이 전달을 막았다는 뜻입니다. 개인용 Outlook.com과 Hotmail 계정에서는 코드 S3150이 함께 표시되는 경우가 많습니다. S3150은 Microsoft가 발송 IP를 개인용 서비스 차단 목록에 올렸다는 뜻입니다. S3150이 보이면 발송 서버를 운영하는 담당자에게 연락하고, 반송 메일에 포함된 문제 해결 링크를 알려 주십시오.

“550 5.7.1 outbound relay not allowed”는 무슨 뜻입니까? 발송 애플리케이션이 유효한 인증 없이 SMTP 서버를 통해 메일을 보내려 했다는 오류입니다. 메일 서버는 스팸 발송자가 악용하지 못하도록 인증하지 않은 발신자의 메일을 중계하지 않습니다. 해결하려면 애플리케이션이 유효한 사용자 이름과 비밀번호로 인증하고 포트 587에서 TLS로 연결하도록 설정하십시오.

원인이 무엇이든 반송 메일 전체를 보관하십시오. 수신자의 IT 팀이나 이메일 서비스 제공업체가 가장 먼저 요청하는 자료입니다.

반송 대부분이 5.7.1이 아니라 550 5.1.1이라면 문제는 리스트에 있습니다. 다음 발송 전에 Giggal.ai 이메일 리스트 정리(영어)로 리스트를 검증하는 것이 좋습니다.