문제

Microsoft 365 또는 Exchange 주소로 보낸 메일이 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient <주소> not found by SMTP address lookup라는 영구 반송(NDR)으로 돌아옵니다. 메일은 사서함에 닿지 못했습니다. 수신자는 사서함이 있다고 하고, 관리 센터에서도 실제로 보입니다. 이 반송은 “그런 사용자 없음”보다 더 구체적인 걸 말합니다. Exchange의 카테고라이저가 그 주소를 디렉터리에 대조해 해석하려다 아무것도 못 찾았다는 것입니다.

이건 라우팅·디렉터리 실패이지 인증 실패가 아닙니다. 여기서 SPF나 DKIM을 쫓으면 오후를 통째로 낭비합니다.

증상

  • NDR에 550 5.1.10과 RESOLVER.ADR.RecipientNotFound, 그리고 not found by SMTP address lookup 문구가 들어 있음.
  • 반송이 해석 못 한 정확한 수신자 주소를 적시함.
  • 같은 도메인의 다른 사람은 메일을 잘 받는데, 특정 주소(또는 특정 방식으로 만든 주소)만 반송됨.
  • 수신자 사서함이 Microsoft 365 관리 센터에 보이고 잘 작동하는데도 특정 발신자의 메일은 반송됨.
  • 하이브리드 조직에서 온프레미스 발신자가 클라우드 사용자에게 보낸 메일이 반송되거나, 조정(moderation)·수락 메시지가 실패함 — 반면 클라우드끼리는 잘 감.

이 오류가 실제로 뜻하는 것

보고서를 두 조각으로 읽으세요. 550은 영구 SMTP 거부입니다 — 재시도하면 같은 주소가 같은 벽에 부딪힙니다. 5.1.10은 5.1.x 주소 지정(addressing) 클래스에 속합니다. 문제는 평판·콘텐츠·인증이 아니라 목적지 주소 자체입니다. (5.1.x 주소 지정 클래스는 RFC 3463에서 옵니다. 5.1.10은 그 안의 Microsoft 고유 세부 코드라, 숫자보다 사람이 읽는 RESOLVER.ADR.RecipientNotFound가 더 중요합니다.)

RESOLVER.ADR.RecipientNotFound가 무슨 일이 일어났는지 알려주는 부분입니다. Exchange의 카테고라이저 — 메시지가 어디로 갈지 정하는 구성요소 — 가 수신자 주소를 디렉터리(하이브리드면 온프레미스 Active Directory, Exchange Online이면 클라우드 디렉터리)에 대조해 해석하려다 그에 맞는 객체를 못 찾았습니다. 객체가 없으면 경로가 없으니 메시지를 영구 거부합니다.

함정은 “있다”는 말입니다. 관리 센터에 존재하는 것과, 이 특정 메시지를 처리한 카테고라이저가 해석할 수 있는 것은 다릅니다. 하이브리드 배포에서 그 둘은 서로 다른 디렉터리일 수 있습니다. 사서함이 클라우드엔 완벽히 실재하면서도, 그에 대한 객체가 없는 온프레미스 카테고라이저에겐 안 보일 수 있습니다 — 그 틈이 바로 5.1.10이 보고하는 것입니다.

상위 3가지 원인

  1. 주소가 정말로 해석되지 않음 — 오타, 삭제·이름 변경된 수신자, 주소가 회수된 퇴사자, 배포 목록의 낡은 항목. 카테고라이저가 찾아보고 객체가 없으면 거부합니다. 5.1.10이 제 일을 하는 경우입니다.
  2. 온프레미스 객체 없는 클라우드 사서함(하이브리드) — “있는데 반송되는” 가장 흔한 경우. 사용자를 Microsoft 365에 바로 만들었는데 온프레미스 Exchange엔 라우팅할 대응 객체가 없습니다. 온프레미스 발신자(그리고 조정·수락 흐름)가 5.1.10에 부딪힙니다. 카테고라이저가 클라우드 수신자를 해석 못 하기 때문이죠. 해결은 온프레미스에 원격 사서함이나 메일 사용 사용자(New-RemoteMailbox)를 만들고 디렉터리 동기화를 돌리는 것입니다.
  3. 낡은 디렉터리 데이터 또는 잘못된 전달 — 이름 변경·이전 후 갱신 안 된 옛 proxyAddresses 값, 갱신 안 된 전역 주소 목록(GAL), 또는 이제 없는 주소로 재전송하는 전달 규칙(발신자 쪽이든 수신자 쪽이든). 보이는 사서함은 멀쩡하고, 실제로 해석되는 주소가 그렇지 않습니다.

DechoNet으로 진단

  • 수신자 도메인에 이메일 점검을 돌리면 그 메일이 실제로 어디로 라우팅되고 어느 제공자가 호스팅하는지 보입니다. MX가 Microsoft(mail.protection.outlook.com)를 가리키면 어느 카테고라이저가 반송을 냈는지, 그리고 이게 전달 경로가 아니라 디렉터리 문제라는 걸 알 수 있습니다.
  • 이메일 헤더 분석기는 반송 자체를 읽어줍니다. 코드가 5.1.10 + RESOLVER.ADR.RecipientNotFound인지 확인하세요 — 5.1.1(일반 사용자 없음), 5.4.1(디렉터리 기반 엣지 차단), 5.7.x(인증·정책)가 아닙니다. 정확한 문자열이 어느 해법을 쓸지, 디렉터리 동기화가 관련됐는지를 정합니다.
  • DNS 점검은 도메인의 MX와 최근 변경을 확인합니다. 이전 후 남은 MX, 또는 내부 릴레이여야 하는데 권위(authoritative)로 설정된 도메인은, 응답한 서버가 유효한 수신자를 해석 못 하게 만드는 고전적 원인입니다.

해결 체크리스트

  • 코드가 5.1.10 / RESOLVER.ADR.RecipientNotFound인지 확인 — 5.1.1·5.4.1·5.7.x가 아님. 정확한 문자열이 주소·디렉터리·인증 중 어디를 볼지 알려줍니다.
  • 수신자 주소를 한 글자씩 다시 확인. 다시 타이핑하지 말고 확실한 출처에서 복사·붙여넣기 — 글자 하나 틀린 게 단일 최다 원인입니다.
  • 조직이 하이브리드면 수신자에게 온프레미스 객체(원격 사서함 또는 메일 사용 사용자)가 있는지 확인. 클라우드 전용으로 만들었다면 온프레미스 객체를 만들고 디렉터리 동기화를 강제하세요.
  • 낡은 proxyAddresses, 오래된 전역 주소 목록, 삭제된 주소로 향하는 전달 규칙을 발신자·수신자 양쪽에서 점검하세요.
  • 수신자 도메인을 관리한다면 MX가 사서함을 실제로 호스팅하는 제공자를 가리키는지, 도메인의 수락 도메인 유형(권위 vs 내부 릴레이)이 토폴로지와 맞는지 확인하세요.
  • 하드 반송된 주소는 발송 목록에서 제거하세요. 5.1.10 주소를 반복해서 때리는 건 스팸 신호이고 발신자 평판을 깎습니다.

언제 에스컬레이션하나

  • 이 반송은 수신자 Exchange 조직이 낸 것이라, 해결은 대개 그쪽 관리자 몫입니다. 정확한 NDR — 5.1.10 코드, RESOLVER.ADR.RecipientNotFound 문자열, 해석 못 한 주소 — 를 전달하면 어느 객체나 동기화가 빠졌는지 정확히 알 수 있습니다.
  • 하이브리드 조직을 운영하는데 온프레미스 객체를 만들고 동기화까지 했는데도 클라우드 사서함이 여전히 5.1.10으로 반송되면, 메시지 추적을 열어 카테고라이저의 해석을 확인하세요 — 확인된 객체가 여전히 해석 안 되면 사서함이 아니라 동기화나 수락 도메인 결함입니다.
  • 주소·디렉터리·MX가 모두 맞는데 유효한 수신자가 여전히 반송되면 추적 결과와 함께 메일 제공자에 에스컬레이션하세요. 대문에는 보이는데 카테고라이저가 해석 못 하는 수신자는 그쪽의 라우팅 결함입니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.