Gmail·Outlook 메일 반송, 오류 코드로 원인 찾기

반송 메일에서 먼저 읽을 네 가지

배달하지 못한 이유를 알려주는 메일을 NDR 또는 DSN이라고 부릅니다. 보통 사람이 읽는 안내문, 서버가 처리할 상태 정보, 원래 보낸 메일의 일부가 함께 들어 있습니다. 전달 버튼으로 다른 사람에게 보내면 이 구조가 줄어들기도 하므로, 가능하면 ‘원본 보기’나 원본 파일 저장 기능을 이용합니다.

Reporting-MTA: dns; smtp.crm.example

Final-Recipient: rfc822; buyer@example.net
Action: failed
Status: 5.7.26
Remote-MTA: dns; mx.receiver.example
Diagnostic-Code: smtp; 550 5.7.26
 This email has been blocked because the sender is unauthenticated.

위 주소와 서버 이름은 설명용으로 바꿨습니다. 실제 반송에는 제공사의 서버 이름, 발신 IP, 인증 결과, 도움말 주소 등이 더 붙을 수 있습니다. 줄바꿈 뒤의 내용도 앞 문장에 이어지는 설명이므로 첫 줄만 캡처하지 않는 것이 좋습니다.

Reporting-MTA는 이 알림을 만든 서버입니다. 이것을 메일을 거부한 서버와 혼동하면 엉뚱한 업체에 문의하게 됩니다. 예를 들어 CRM 발송 서버가 Gmail의 거부 응답을 받아 반송 안내를 만들 수 있습니다. 배달 상태 알림 형식 ↗

상태 코드의 첫 숫자가 4면 일시적인 실패, 5면 영구적인 실패 범주입니다. 여기서 ‘영구적’은 도메인을 영원히 차단했다는 뜻이 아닙니다. 같은 조건으로 재시도하는 것만으로 해결되기를 기대하기 어렵다는 의미입니다. Action: delayed라면 아직 발송 서버가 재시도 중일 수 있으니 대기열과 최종 결과부터 확인합니다. 확장 상태 코드의 의미 ↗

앱 이름보다 실제 발송 경로를 확인하세요

“아웃룩에서 보냈다”는 말만으로는 발송 업체를 알 수 없습니다. Outlook 앱에 Google Workspace, 네이버웍스, Microsoft 365 계정을 연결해 사용할 수 있기 때문입니다. 반대로 회사 주소를 쓰는 견적서라도 웹메일이 아닌 CRM의 발송 서버를 거칠 수 있습니다.

회사 웹메일은 성공하고 CRM만 실패한다면 두 경로를 나눠 조사합니다. 로그인 성공이나 CRM의 ‘발송 완료’ 표시는 마지막 수신 서버까지 배달됐다는 증거가 아닐 수 있습니다. 발송 서비스가 요청을 접수한 뒤 나중에 반송을 기록하는 방식도 있기 때문입니다.

이때 비교할 항목은 From 주소, 실제 발신 IP, 메일을 전송할 때 쓰는 MAIL FROM 도메인, DKIM 서명 도메인입니다. MAIL FROM은 배달 실패 알림을 돌려보내는 주소로 쓰이며, 수신된 메일에서는 보통 Return-Path로 확인합니다. 화면에 보이는 From과 다를 수 있습니다. Microsoft의 발신 주소와 SPF 설명 ↗

회사 SPF에 직원용 메일 서비스를 등록했다는 사실만으로 CRM까지 인증되는 것은 아닙니다. SPF 설정 가이드에서 실제 발송 서비스와 검사 대상 도메인을 먼저 맞춰 보세요. 기본 개념이 낯설다면 이메일 인증의 동작 원리부터 읽어도 좋습니다.

Gmail 550 5.7.26: 숫자 뒤의 세 가지 사유를 구분합니다

Google은 같은 550 5.7.26을 서로 다른 인증 실패 상황에 사용합니다. 다음 표현 중 무엇이 있는지 찾고, 그 뒤에 표시된 도메인과 IP를 함께 기록하세요. 아래 표는 오류 원문 전체를 옮긴 것이 아니라, 검색할 단서만 뽑은 것입니다.

Google의 공식 오류 목록에는 이 세 유형이 별도로 설명돼 있습니다. 특히 오류 메시지에 나온 IP와 도메인을 생략하면 필요한 단서를 잃습니다. Gmail SMTP 오류 목록 ↗

발신 인증이 없다는 사유라면

DNS에 레코드가 존재하는지와 해당 메일이 인증을 통과했는지는 다른 문제입니다. 예를 들어 DKIM 공개키만 올려 놓고 발송 서비스에서 서명을 켜지 않으면 메일에 서명이 붙지 않습니다. 반대로 서명은 있지만 잘못된 selector의 키를 조회하거나, 전송 중 서명 대상 내용이 바뀌어 실패할 수도 있습니다.

발송 서비스의 도메인 인증 화면과 실제 메일을 함께 확인합니다. Google Workspace의 DKIM도 DNS 등록, 서명 시작, 실제 메일 검증이 각각 필요합니다. 다른 서비스를 쓰면 그 서비스가 발급한 값과 활성화 절차를 따라야 합니다. Google DKIM 설정 절차 ↗

SPF의 -all과 발신 IP가 나온다면

-all은 앞선 허용 조건에 맞지 않는 서버를 SPF 실패로 처리한다는 뜻입니다. 먼저 그 서버가 회사가 승인한 발신처인지 확인합니다. 정상 CRM이 맞다면 공식 SPF 안내, 실제 MAIL FROM, 기존 발신처 목록을 대조해야 합니다. 모르는 IP를 반송에 나왔다는 이유만으로 허용해서는 안 됩니다.

회사 최상위 도메인에 SPF를 추가해도 실제 검사 대상이 서비스 소유 도메인이면 그 검사 결과는 바뀌지 않습니다. 또한 -all을 ~all로 바꾸는 것은 실패의 취급을 바꾸는 것이지, 누락된 서버를 인증에 통과시키는 작업이 아닙니다. SPF의 검사 대상과 실패 결과 ↗

DMARC 정책이 이유라면

From이 회사 도메인인데 SPF와 DKIM은 외부 서비스 도메인으로만 통과할 수 있습니다. DMARC는 통과한 인증 중 하나가 From 도메인과 정렬되는지도 봅니다. 따라서 정상 발신처의 회사 도메인 서명이나 MAIL FROM 구성을 확인해야 합니다. 도메인 정렬은 이름이 비슷한지가 아니라, 적용된 정렬 규칙에 맞는지를 판단하는 관계입니다. DMARC 인증과 정렬 조건 ↗

p=none으로 낮추면 모든 문제가 해결된다는 조언은 조심해야 합니다. 이 값은 DMARC 실패를 이유로 격리·거부를 요청하지 않는 정책입니다. 인증 실패를 PASS로 바꾸거나 수신 서버의 다른 거부 기준을 없애지는 않습니다. 이미 보호 중인 도메인은 영향 범위와 복구 계획을 검토하고, 우선 정상 발신 경로를 바로잡는 편이 좋습니다.

Outlook.com 550 5.7.515: SPF와 DKIM 모두 확인합니다

550 5.7.515는 Outlook.com·Hotmail·Live·MSN 등 Microsoft 개인용 메일 서비스가 대량 발신자의 인증 요건을 검사하며 사용하는 오류입니다. Outlook 앱 자체의 로그인 오류나 모든 Microsoft 365 회사 메일의 오류를 뜻하지 않습니다.

이 요건은 Microsoft 개인용 수신 서비스로 대량 발신하는 도메인에 적용됩니다. 자신의 발송량이 작아 보이더라도 직원용 메일만 세지 말고, 같은 From 도메인을 쓰는 뉴스레터·CRM 등 외부 발송 서비스가 있는지 확인하세요. 해당 코드가 발생했다면 반송의 From 도메인과 실제 발송 경로부터 대조합니다.

이 세 조건은 함께 확인합니다. DMARC 자체는 정렬된 DKIM 하나로 통과할 수 있지만, 대량 발신자 요건에서 SPF까지 생략할 수 있다는 뜻은 아닙니다. 유효한 DMARC 정책 레코드도 필요하며 Microsoft가 안내하는 최소 정책에는 p=none이 포함됩니다. 기존의 더 강한 정책을 낮춰야 한다는 의미는 아닙니다. Microsoft의 5.7.515 해결 안내 ↗

회사 메일은 정상인데 뉴스레터만 실패한다면 그 뉴스레터에서 세 조건을 각각 확인합니다. 회사 도메인의 DNS 조회 결과만 받아 놓고 ‘설정 완료’로 마무리하지 말고, 실제 발송 서비스가 어느 도메인으로 서명하는지까지 요청하세요.

가상 사례: 웹메일은 되는데 CRM 견적서만 반송될 때

가온상사는 회사 도메인을 이미 p=reject로 운영하고 있었는데, 새로 도입한 CRM의 발신 인증을 빠뜨렸습니다. 직원은 웹메일과 CRM에서 모두 sales@example.com을 사용합니다. 회사 웹메일은 도착하지만 CRM 견적서는 Gmail에 보낼 때 DMARC 관련 5.7.26으로 반송됩니다. 담당자는 CRM의 발송 기록과 인증 설정을 확인해 다음처럼 정리했습니다. 아래는 실제 고객 자료가 아닌 설명용 사례입니다.

이 경우 회사 SPF에 CRM의 include를 무작정 더하는 것보다, CRM이 지원하는 회사 도메인 DKIM을 설정하는 것이 원인에 맞는 조치입니다. SPF가 통과한 mailer.example.net은 회사 From인 example.com과 다른 도메인이기 때문입니다. 서명 도메인을 회사 도메인으로 연결하면 DKIM 경로로 정렬을 충족할 수 있습니다. 외부 발신 서비스와 DMARC 정렬 ↗

1. CRM에서 발급값을 확인합니다

   회사 도메인 인증 기능이 있는지 확인하고, example.com에 발급된 DKIM TXT 또는 CNAME의 이름과 값을 받습니다. 다른 회사나 직원용 메일 서비스의 값을 섞지 않습니다.

2. DNS에 등록하고 서명을 활성화합니다

   기존 DKIM selector와 충돌하지 않는지 확인합니다. DNS 조회와 CRM의 확인 절차를 거친 뒤 실제 견적서 발송에도 회사 도메인 서명이 적용되는지 점검합니다.

3. 같은 CRM에서 새 견적서를 보냅니다

   웹메일로 우회한 테스트만으로 끝내지 않습니다. 문제가 났던 템플릿과 발송 경로를 사용해 새 Message-ID로 보내고 결과를 비교합니다.

From: 가온상사 영업팀 <sales@example.com>
Return-Path: <bounce@mailer.example.net>
DKIM-Signature: v=1; d=example.com; s=crm; ...

Authentication-Results: mx.receiver.example;
 spf=pass smtp.mailfrom=mailer.example.net;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com

Return-Path는 이전과 같지만, 회사 도메인의 DKIM이 통과해 DMARC도 통과했습니다. SPF와 DKIM 모두 PASS이므로 앞서 본 Outlook.com 인증 요건도 각각 점검할 수 있는 상태입니다. 다만 실제 Outlook.com 수신 결과는 별도로 확인해야 합니다. Gmail에서 성공했다는 사실이 다른 수신 서비스의 수락까지 증명하지는 않습니다.

거부된 메일에는 최종 수신 서버가 만든 인증 헤더가 없을 수 있습니다. 위 헤더를 반송 원문에서 반드시 찾을 수 있는 것으로 오해하지 마세요. 수정 전에는 오류 상세 사유와 발송 로그, 수정 후에는 도착한 새 메일의 수신 측 결과를 함께 비교합니다. 구체적인 설정은 DKIM 설정 가이드와 도메인 정렬 문제 해결 글에서 이어 볼 수 있습니다.

PTR·TLS·IP 차단은 다른 담당 작업입니다

인증을 고쳤는데도 반송되면 새 오류가 이전과 같은지 읽어야 합니다. 첫 번째 검사에서 막혔다가 그 문제를 고친 뒤 다음 문제가 드러날 수도 있습니다. 다음 항목은 DKIM 키나 DMARC 정책만 바꿔 해결할 수 있는 문제와 구분해야 합니다.

PTR은 IP에서 서버 이름을 찾는 역방향 DNS입니다. 이름에서 다시 원래 IP를 찾을 수 있는지도 확인합니다. 발송 서비스의 공용 IP를 쓴다면 회사 도메인의 DNS 화면만 고쳐서는 해결하기 어렵습니다. TLS 역시 회사 홈페이지의 HTTPS 인증서와 별개로 메일 서버 사이 연결을 확인해야 합니다. Google의 발신 인프라 요건 ↗ 오류 코드별 설명 ↗

국내 서비스에서도 IP 차단은 별도로 발생했습니다

네이버웍스는 2026년 3월 4일, Outlook 개인용 도메인으로 보내는 일부 메일이 S3150으로 반송되는 현상을 공지했습니다. 제공사가 Microsoft에 차단 해제를 요청한 사안이며, 공지에는 같은 날 19시에 해결됐다고 명시돼 있습니다. 지금도 지속되는 장애라는 뜻이 아닙니다. 네이버웍스의 해결 완료 공지 ↗

이 사례처럼 발신 제공사의 IP나 네트워크 관련 문제라면, 고객사마다 SPF 레코드를 바꾸는 것보다 제공사에 실제 오류와 IP를 전달하는 것이 먼저입니다. S3150을 5.7.515와 같은 인증 오류로 취급하면 대응 방향이 달라집니다. 반송에 나온 주소로 무작정 해제 요청을 보내기보다 제공사의 공식 지원 창구를 이용하세요.

지원팀에는 이 자료를 한 번에 전달하세요

“Gmail로 안 갑니다”만으로는 같은 날 발생한 여러 문제를 구분하기 어렵습니다. 아래 양식은 메일 제공사, CRM 운영사, 사내 관리자에게 전달하기 위한 예시입니다. 개인 이메일 주소와 메일 본문은 필요한 범위에서만 공유하고, 전체 원문이나 고객 명단을 공개 게시판에 올리지 않습니다.

[증상]
CRM 견적서만 Gmail 수신자에게 반송됩니다.
회사 웹메일에서 같은 수신자에게 보낸 메일은 도착합니다.

[발생 정보]
발송 일시·시간대: YYYY-MM-DD HH:mm, KST (UTC+9)
실제 발송 서비스·기능: [서비스명 / 견적서 자동 발송]
발신 From 도메인: [회사 도메인]
수신 도메인·확인된 수신 서비스: [예: gmail.com / Gmail]
발생 범위: [전체·특정 도메인·일부 수신자 / 확인한 건수]
최근 변경: [DNS·SMTP·플러그인·템플릿 변경 여부]

[추적 정보 — 공식 비공개 지원 채널로 전달]
원본 메일 Message-ID: [확인된 값]
발송 서비스 메시지 ID 또는 대기열 ID: [확인된 값]
상대 서버·발신 IP: [반송이나 로그에 있는 경우]
오류 코드와 상세 사유: [줄바꿈 뒤 설명까지 복사]

[요청]
어느 발송 경로와 도메인의 인증이 실패했는지 확인해 주세요.
필요한 DNS 값과 발송 서비스 내 조치를 구분해 안내해 주세요.
수정 후 같은 경로의 재검증 방법도 부탁드립니다.

Message-ID는 메일 한 통을 찾는 단서이고, 서비스의 메시지 ID나 대기열 ID는 별도 값일 수 있습니다. 모두 같다고 가정하지 말고 보이는 이름 그대로 적습니다. 받는 사람이 원문을 제공할 수 없다면 발송 서비스 로그에서 확인할 수 있는 범위를 먼저 전달해도 됩니다.

비밀번호, SMTP 인증키, DKIM 개인키는 이 조사에 필요한 첨부물이 아닙니다. 담당자가 원본 파일을 요청하면 회사가 정한 비공개 채널로 제공하고, 수신 주소 등 추적에 필요한 정보의 공유 범위를 확인합니다. 핵심은 많은 자료를 보내는 것보다 한 번의 실패와 해당 로그를 정확히 연결하는 데 있습니다.

수정 완료는 새 메일의 결과로 확인합니다

DNS 화면에 초록색 표시가 떴다는 것만으로 반송이 해결됐다고 끝내지 않습니다. DNS 캐시, 서명 활성화, 발송 서버별 설정 때문에 실제 결과가 다를 수 있습니다. 기존에 실패한 메일을 다시 읽으면 과거 결과만 보이므로 변경 후 새로 보낸 메일을 사용합니다.

1. 문제가 있던 경로로 소량 재발송합니다

   회사 웹메일·CRM·홈페이지 자동 알림을 구분합니다. Gmail과 Outlook.com도 각각 확인하고 테스트 시간과 Message-ID를 남깁니다.

2. 발송 로그와 수신 원본을 맞춰 봅니다

   이전 오류가 없어졌는지, SPF·DKIM·DMARC와 각 도메인은 어떻게 나오는지 비교합니다. 중간 전달 서버가 있었다면 그 경로도 기록합니다.

3. 수락과 실제 수신 위치를 따로 기록합니다

   최종 수신 서버가 수락했는지와 받은편지함·스팸함 중 어디에 도착했는지를 구분합니다. 재시도 중인 메시지는 최종 결과까지 확인합니다.

견적서 한 통이 정상 도착한 뒤에는 같은 서비스를 쓰는 다른 템플릿이나 자동 발송도 확인하세요. 담당자가 수동으로 보내는 메일과 월말에 실행되는 일괄 발송의 경로가 다를 수 있습니다. 발신처별 확인 내역을 남겨 두면 다음 변경 때 무엇을 다시 시험해야 하는지도 분명해집니다.

반송은 사라졌는데 스팸함에 들어간다면 조사할 범위가 달라집니다. 그때는 SPF·DKIM·DMARC는 PASS인데 스팸함에 가는 이유에서 평판과 수신 결과를 확인하는 순서로 이어가세요.

도메인 인증을 어디서부터 확인할지 어렵다면 회사 도메인의 공개 DNS 진단부터 시작할 수 있습니다. 다만 DNS만으로 특정 반송의 원인이나 받은편지함 도착을 확정할 수는 없습니다. 반송 원문, 실제 발송 경로, 새 메일의 결과를 함께 준비하면 인증 설정 문제인지, 발송 업체가 확인해야 할 문제인지 훨씬 빠르게 나눌 수 있습니다.