550 5.1.1 User Unknown 해결

Problem

메일이 영구 반송 리포트로 튕기며 550 5.1.1과 함께 User unknown, No such user, Mailbox not found, 또는 the email account that you tried to reach does not exist 같은 문구가 붙습니다. 메시지는 사서함에 닿지 못했고 발신자는 수신자 주소를 지목하는 NDR을 받습니다. 인터넷에서 가장 흔한 영구 바운스이며, 뜻은 딱 하나입니다: 응답한 서버에 당신이 보낸 주소가 존재하지 않는다.

Symptoms

• NDR에 550 5.1.1과 User unknown, No such user here, Recipient address rejected: User unknown, does not exist 같은 문구가 있습니다.
• Gmail 바운스는 gsmtp로 끝나며 550-5.1.1 The email account that you tried to reach does not exist로 읽힙니다.
• Microsoft 바운스는 RESOLVER.ADR.RecipNotFound 또는 does not exist를 인용합니다.
• 같은 도메인의 다른 수신자는 메일을 잘 받고, 오직 한 주소만 튕깁니다.
• 주소는 맞아 보이고 수신자는 사서함이 있다고 단언합니다.

What This Error Actually Means

확장 상태 코드를 두 개의 별개 주장으로 읽으세요. 550은 영구 SMTP 거부입니다 — 재시도하지 마세요, 같은 주소는 또 튕깁니다. 5.1.1은 RFC 3463의 확장 상태 X.1.1, “Bad destination mailbox address”: 수신 서버가 @ 왼쪽에 지정된 사서함을 찾았는데 아무것도 없었다는 뜻입니다.

이 결정은 이른 단계인 RCPT TO에서, 서버가 당신의 평판·SPF·본문을 따지기 전에 내려집니다. 그래서 오진이 잦습니다. 사람들은 하드 550을 보고 인증을 강화하기 시작하지만, 수신자는 누가 보냈는지 신경 쓸 만큼 진도가 나가지도 않았습니다. 주소를 거부한 것, 그게 전부입니다.

함정은 “존재”라는 단어입니다. 서버는 인터넷 전체에 대한 주장을 하는 게 아니라 오직 자기 자신에 대해 말합니다. 5.1.1이라 하면 나에겐 그런 사서함이 없다는 뜻입니다. 사서함이 실제로 어딘가에 있어도, 그걸 호스팅하지 않는 서버에 메일이 도착했다면 여전히 5.1.1이 납니다. 주소는 진짜지만 배달 대상이 틀린 것 — 같은 코드를 쓴 두 개의 다른 실패입니다.

Top 3 Causes

1. 주소가 정말 틀렸거나 사라짐 — 오타, 삭제·이름 변경된 사서함, 퇴사한 직원, 제거된 별칭, 혹은 메일링 리스트의 오래된 항목. 서버가 검사해 사서함을 못 찾고 거부합니다. 5.1.1이 제 일을 하는 겁니다.
2. 메일이 엉뚱한 서버에 도착함 — 주소는 존재하는데, 메시지가 도착한 곳이 아닐 뿐입니다. 도메인 MX 레코드가 그 사서함을 호스팅하지 않는 공급자를 가리킵니다: 이전 후 남은 MX, 깨진 분할 배달, 혹은 비활성화돼 공백을 더는 가려주지 못하는 catch-all. MX가 실제로 사서함을 가진 호스트를 가리키기 전엔 사서함을 고쳐도 소용없습니다.
3. 사서함은 있지만 아직 배달 가능한 대상이 아님 — 만든 적 없는 별칭·닉네임·배포 주소, 프로비저닝됐지만 메일 사용 설정이나 라이선스가 없는 Google Workspace·Microsoft 365 사용자, 혹은 방금 만든 수신자를 아직 전파하지 못한 디렉터리. 관리자 콘솔에선 “실재”하지만 SMTP 정문에는 안 보입니다.

Diagnose with DechoNet

• Email Check로 수신자 도메인의 메일이 실제 어디로 라우팅되는지 확인합니다. MX가 예상 밖 — 옛 공급자, 파킹된 호스트, 혹은 쓸모없는 곳 — 을 가리키면 사서함을 건드리지 않고도 “존재하지만 엉뚱한 서버” 케이스를 찾은 겁니다.
• Email Header Analyzer로 바운스 자체를 읽습니다: 코드가 5.1.1(디렉터리 차단 5.4.1도, 인증 5.7.x도 아님)인지 확인하고 보고 호스트를 식별하세요. gsmtp는 Google이 응답한 것, protection.outlook.com은 Microsoft. 누구의 규칙과 싸우는지 알려줍니다.
• DNS Check로 도메인의 MX 우선순위와 최근 변경을 봅니다. 강등되거나 중복되거나 남겨진 MX 레코드가 조용히 메일을 가로채는 것은 유효한 주소가 5.1.1로 튕기는 전형적 원인입니다.

Resolution Checklist

• 코드가 5.1.1인지 확인 — 5.4.1(Microsoft 경계/디렉터리 차단)이나 5.7.x(인증/정책)가 아님. 숫자가 어느 해법을 적용할지 결정합니다.
• 주소를 한 글자씩 재확인. 다시 타이핑하지 말고 검증된 출처에서 복사-붙여넣기 — 한 글자 오타가 가장 흔한 단일 원인입니다.
• 수신자 관리자에게 사서함·별칭이 존재하고 활성이며 메일 사용 설정됐는지 확인 요청. 라이선스가 있는 사용자가 항상 배달 가능한 주소는 아닙니다.
• 수신자 도메인을 통제한다면, MX가 실제로 사서함을 호스팅하는 공급자를 가리키는지 확인. 이전이나 분할 배달 변경으로 남은 오래된 MX 레코드를 정리하세요.
• 사서함을 최근에 만들었다면, 고장 났다고 단정하기 전에 프로비저닝과 디렉터리 전파를 기다리세요.
• 하드 바운스한 주소는 발송 목록에서 제거. 5.1.1 주소를 반복해 두드리는 건 스패머 신호이며 발신자 평판을 갉아먹습니다.

When to Escalate

• 이 바운스는 수신자 서버가 생성하므로, 해법은 보통 당신이 아니라 수신자 관리자에게 있습니다. 정확한 NDR을 전달하세요 — 5.1.1 코드와 보고 호스트가 어느 사서함·별칭·디렉터리 항목이 빠졌는지 정확히 짚어줍니다.
• 수신자 도메인을 당신이 소유하고 MX가 올바른데도 유효한 사서함이 5.1.1로 튕긴다면, 메시지 추적과 함께 메일 공급자에게 에스컬레이션하세요. 확인된 메일 사용 수신자를 정문이 여전히 못 본다면 그쪽의 라우팅·프로비저닝 결함을 가리킵니다.