550 5.4.1 수신자 주소 거부 해결

Problem

메일이 영구 반송 리포트로 튕깁니다: 550 5.4.1 Recipient address rejected: Access denied. 메시지는 사서함에 닿지 못했고 발신자는 수신자 주소를 가리키는 NDR을 받습니다. Microsoft 365 / Exchange Online이 메일을 경계에서 거부하는 전형적인 지문입니다.

Symptoms

• NDR이 정확히 550 5.4.1 <recipient@domain>: Recipient address rejected: Access denied.
• 바운스의 리포팅 서버가 protection.outlook.com 또는 다른 Exchange Online 호스트.
• 그 도메인의 일부 수신자는 정상 수신 — 특정 주소만 튕김.
• 주소는 맞아 보이고 수신자는 사서함이 존재한다고 우김.
• 마이그레이션 후 메일 사용 공용 폴더나 배포 지점으로 가던 메일이 튕기기 시작.

What This Error Actually Means

향상된 상태 코드를 두 개의 별개 주장으로 읽으세요. 550은 영구 SMTP 거부 — 재시도 마세요, 저절로 안 고쳐집니다. 5.4.1에 Recipient address rejected: Access denied 문구는 수신 시스템이 이 주소를 인식하지 못해 경계에서 거부했다는 Microsoft의 신호입니다.

핵심: 이 거부는 콘텐츠 필터링·스팸 점수·발신자 인증 이전에 일어납니다. 당신이 누구인지, SPF가 통과하는지의 문제가 아닙니다. 수신 디렉터리가 보기에 당신이 보낸 주소가 존재하느냐의 문제입니다. 그래서 그렇게 자주 오진됩니다 — 사람들은 “Access denied”를 보고 SPF·DKIM을 강화하기 시작하지만, 수신자는 그것들을 들여다보지도 않았습니다.

Microsoft 365에서 이 동작엔 이름이 있습니다: Directory-Based Edge Blocking(DBEB). 수락 도메인이 Authoritative로 표시되면 Exchange Online은 자기 디렉터리를 그 도메인의 완전하고 최종적인 유효 수신자 목록으로 취급하고, 매칭 못 하는 건 전부 튕깁니다. DBEB는 기능입니다 — 지어낸 주소로 오는 스팸과 백스캐터를 비용이 들기 전에 죽여줍니다. 경계가 확인하는 디렉터리에서 정당한 수신자가 빠졌을 때만 당신 눈에 버그로 보입니다.

Top 3 Causes

1. 수신자 주소가 디렉터리에 없음 — 오타, 삭제·비활성 사서함, 혹은 아직 프로비저닝 중인 사서함. DBEB가 디렉터리를 확인하고 아무것도 못 찾아 거부합니다. DBEB가 제 일을 정확히 하는 겁니다.
2. 공유 도메인이 Internal Relay여야 하는데 Authoritative로 설정됨 — 도메인이 쪼개져 일부 사서함은 Microsoft 365에, 일부는 온프렘 Exchange나 타사 호스트에 있습니다. 수락 도메인이 Authoritative면 Microsoft는 자기가 호스팅하지 않는 모든 주소를 막습니다. Internal Relay로 설정하면 Exchange Online이 미지-하지만-유효한 주소를 튕기지 않고 앞으로 넘깁니다.
3. 메일 사용 공용 폴더 또는 미동기화 객체 — 메일 사용 공용 폴더는 Entra ID에 동기화되지 않아 DBEB가 못 보고 거부합니다. 디렉터리 동기화(Entra Connect)가 새로 만든 수신자를 아직 전파 못 했을 때도 같은 공백이 생깁니다.

Diagnose with DechoNet

• Email 진단을 수신자 도메인에 돌려 메일이 실제로 어디로 라우팅되는지 확인하세요 — MX가 *.protection.outlook.com을 가리키면 Exchange Online이고 DBEB가 유력 용의자입니다.
• Email Header 분석으로 바운스 자체를 읽으세요: 리포팅 MTA, 정확한 향상된 코드, 그리고 실패가 5.7.x(인증)가 아니라 5.4.1(디렉터리)임을 확인 — 가장 결정적인 한 가지 점검입니다.
• DNS 진단으로 수신자 도메인의 MX와 분할 라우팅 레코드를 확인해, 그 주소가 애초에 Microsoft 365에 살아야 하는지 아니면 다른 곳으로 릴레이돼야 하는지 파악하세요.

Resolution Checklist

• 코드가 “Recipient address rejected: Access denied”와 함께 5.4.1인지 확인 — 5.7.1/5.7.26이 아님. 5.7.x라면 인증·정책 문제이니 SPF·미인증 메일 가이드를 보세요.
• 수신자 주소가 존재하고 철자가 맞는지 확인. Exchange 관리 센터에서 확인하거나 수신자 관리자에게 사서함이 활성이고 디렉터리에 보이는지 물어보세요.
• 수신자가 정당하지만 공유/분할 도메인이라면, 수신자 관리자가 Mail flow > Accepted domains에서 그 수락 도메인을 Authoritative에서 Internal Relay로 바꾸게 하세요.
• 수신자를 최근에 만들었다면 디렉터리 동기화(Entra Connect)를 기다리거나 강제하세요 — 주소가 관리 콘솔엔 유효해도 경계엔 아직 없을 수 있습니다.
• 객체를 고친 뒤에도 DBEB 캐시가 완고하면, 수락 도메인을 Authoritative → Internal Relay → Authoritative로 토글해 디렉터리를 즉시 재조회시키세요.
• 메일 사용 공용 폴더는 DBEB가 못 보므로 Internal Relay 또는 문서화된 공용 폴더 우회로 라우팅하세요.

When to Escalate

• 이 바운스는 수신자의 메일 시스템이 생성합니다. 그래서 대부분의 수정은 당신이 아니라 수신자 관리자 몫입니다. 정확한 NDR 텍스트와 함께 넘기세요 — 5.4.1 코드와 리포팅 호스트가 그쪽 관리자에게 어떤 수락 도메인/디렉터리 설정을 볼지 정확히 알려줍니다.
• 당신이 수신자 관리자인데 유효한 사서함이 디렉터리 동기화 후에도 계속 튕긴다면, 메시지 추적과 함께 Microsoft 지원에 에스컬레이션하세요 — 올바르게 동기화된 수신자 객체에도 살아남는 DBEB 거부는 그쪽 백엔드 동기화 결함을 가리킵니다.