문제
메일이 550 5.7.1 Unable to relay로 튕기고, 그게 Microsoft 메일 서버 — 온프레미스 Exchange, 내장 IIS SMTP 서비스, 또는 Exchange Online — 에서 옵니다. 메시지가 통째로 거부된 것: 서버가 전달을 거절했습니다. 스팸 판정도, 사서함 부재도 아닙니다. 권한 거부입니다 — 서버가 이 특정 메시지를 이 특정 목적지로 운반할 권한이 없다고 판단한 겁니다.
증상
- NDR에
550 5.7.1 Unable to relay(Exchange/IIS) — 또는 Microsoft 365에선550 5.7.54 Unable to relay recipient in non-accepted domain이나550 5.7.64 TenantAttribution; Relay Access Denied가 뜹니다. - 외부 수신자로 메일을 보내는 프린터·스캐너·복합기·업무용 앱이 실패하는데, 같은 서버의 내부 사서함으로 가는 메일은 통과합니다.
- 사용자의 Outlook이나 폰은 잘 보내는데, 같은 서버를 쓰는 미인증 기기·스크립트는 튕깁니다.
- 마이그레이션, 발신 IP 변경, 복합기 펌웨어 업데이트, 또는 옛 오픈 릴레이에서 잠긴 릴레이로 전환한 뒤 시작됐습니다.
- 자기 내부 도메인으로는 보내지는데, Gmail·고객사·아무 외부 도메인으로 보내면 550 5.7.1이 납니다.
이 오류의 진짜 의미
“릴레이(relay)“는 SMTP 서버가 메시지를 받아서 자기가 호스팅하지 않는 사서함 쪽으로 전달하는 동작입니다. 모든 현대 메일 서버는 신뢰하지 않는 발신자를 위한 릴레이를 거부합니다 — 오픈 릴레이는 수십 년 전 스패머에게 파헤쳐졌고, 그래서 어디서나 기본값은 이제 “아는 사람이 아니면 아무에게도 릴레이 안 함”입니다. Exchange가 550 5.7.1 Unable to relay라고 하면 정확히 그 뜻입니다: 당신이 서버가 책임지지 않는 도메인으로 전달해 달라 했고, 서버는 당신에게 그 요청을 할 권한이 없다고 본 겁니다.
확장 상태는 RFC 3463의 X.7.1, “전달 미승인, 메시지 거부”입니다. 550 기본 코드는 영구 거부 — 같은 미승인 발신자가 같은 제출을 재시도해도 아무것도 바뀌지 않습니다.
핵심 구분, 사람들이 몇 시간씩 놓치는 그것: Exchange는 릴레이 권한을 메일의 내용이 아니라 누가, 어떻게 접속하는가로 결정합니다. 메시지가 외부 수신자로 릴레이되도록 허용되는 건 발신자가 인증됐거나, “accept any recipient” 권한이 명시적으로 부여된 Receive Connector의 IP에서 붙었을 때뿐입니다. 둘 다 못 맞추면 아무 외부 수신자나 550 5.7.1을 유발합니다 — 서버 입장에선 자기가 호스팅하지 않는 외부 주소가, 제3자에게 메일을 세탁해 달라는 낯선 요청과 똑같아 보이니까요.
이것은 Postfix·Sendmail의 554 5.7.1 Relay access denied와 같은 권한 거부입니다 — 같은 확장 상태, 같은 근본 원인, Microsoft의 문구와 타이밍일 뿐.
상위 3가지 원인
- 기기·앱이 외부 수신자로 익명 릴레이(전형적 케이스). 프린터·스캐너·모니터링 스크립트·CRM이 인증 없이 25번 포트에 붙어 외부 도메인으로 보내려 합니다. 기본 Receive Connector는 익명 메일을 자기 수락 도메인에 대해서만 받습니다 — 내부 사용자 앞으로 온 메시지는 받지만, 익명 발신자를 위한 외부 주소 릴레이는 거부합니다. 수신자가 외부가 되는 순간 550 5.7.1이 납니다. 이 바운스의 압도적 다수가 이것입니다.
- 발신 IP가 릴레이 커넥터에 범위 지정되지 않음. 익명 릴레이 Receive Connector를 만들었(거나 물려받았)지만 기기의 소스 IP가 그
RemoteIPRanges안에 없거나, 더 넓은 범위의 다른 커넥터가 연결을 먼저 잡습니다. Exchange는 가장 구체적으로 매칭되는 IP 범위로 커넥터를 고르므로, 호스트를 옮긴 앱·새 NAT/이그레스 주소·갓 만든 VM IP가 조용히 엉뚱한 커넥터 — 릴레이를 허용하지 않는 — 로 떨어질 수 있습니다. - 수신자 도메인이 내부여야 하는데 수락 도메인이 아님. 마이그레이션이나 하이브리드 분할 후, 호스팅한다고 생각한 도메인으로 가는 메일이 수락 도메인으로 추가된 적이 없어서(혹은 라우팅하던 커넥터가 사라져서) 외부로 취급됩니다. 서버에 그 도메인을 책임진다는 기록이 없으니, 거기로의 릴레이는 낯선 곳으로의 릴레이와 똑같이 거부됩니다. Microsoft 365에선 이게 바로 5.7.54 케이스입니다.
DechoNet으로 진단하기
- 수신자 도메인에 이메일 점검을 돌리면 그 주소가 정말 외부인지, MX가 어디를 가리키는지 확인됩니다. 내부라고 여긴 수신자가 실제론 외부 메일 호스트로 해석되면, 빠진 수락 도메인을 찾은 겁니다 — 서버가 릴레이라 부른 게 맞습니다. 정당하게 외부라면 수정은 발신 쪽: 인증이나 범위 지정 릴레이 커넥터입니다.
- 이메일 헤더 분석기는 바운스(NDR)를 읽어 어느 호스트·커넥터가 어느 SMTP 단계에서 거부했는지 알려줍니다. 코드가
5.7.1릴레이 거부인지 확인하세요 —5.1.1(잘못된 사서함)도, 비슷해 보이지만 해법이 완전히 다른5.7.606/5.7.511(IP·발신자 차단)도 아닌지. - DNS 점검은 수신자 도메인의 MX 레코드를 보여줍니다. 마이그레이션이 남긴 낡거나 분할된 MX는, 호스팅하려던 도메인의 메일이 조용히 외부로 취급되는 흔한 이유입니다.
해결 체크리스트
- 방향과 수신자를 확정하세요. 실패하는 메일이 외부 도메인으로 가나요, 아니면 호스팅한다고 믿는 도메인으로 가나요? 수신자에 이메일 점검을 돌리면 판가름 나고 — 아래 전부가 여기서 갈립니다.
- 외부 수신자로 보내는 익명 기기: 인증 제출을 우선하세요. 기기·앱을 587 포트에 사서함/서비스 계정 자격증명과 STARTTLS로 붙이세요. 인증된 발신자는 릴레이가 허용되므로 커넥터를 손댈 필요가 없습니다.
- 기기가 인증 못 하면: 전용 익명 릴레이 Receive Connector를 만들고,
RemoteIPRanges를 그 기기의 정확한 IP로 좁히고,-PermissionGroups AnonymousUsers를 설정한 뒤Add-ADPermission ... -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"로 릴레이를 부여하세요. 통제하지 않는 서브넷 전체로 범위를 넓히지 마세요. - 더 넓은 Receive Connector가 연결을 먼저 잡지 않는지 확인하세요 — Exchange는 가장 구체적인
RemoteIPRanges매칭을 씁니다. 두 커넥터가 한 IP에서 겹치는 건 전형적인 조용한 오라우팅입니다. - 수신자가 내부여야 하면: 그 도메인을 수락 도메인으로 추가하고(라우팅/커넥터도 확인), 재발송하세요. Microsoft 365에선 테넌트에서 도메인을 검증하세요.
- Microsoft 365에서 외부 도메인으로:
smtp.office365.com:587의 클라이언트 SMTP 제출, 자기 도메인으로의 direct send, 또는 제대로 된 인증서/IP 범위 커넥터를 쓰세요 — 시나리오에 맞는 지원 경로를 고르면 됩니다. 임의의 외부 수신자로의 익명 릴레이는 제공되지 않습니다. - 변경할 때마다 재발송하세요.
550은 영구라, 발신자가 실제로 권한을 얻기 전엔 아무것도 풀리지 않습니다.
언제 에스컬레이션할까
- 기기가 587에서 유효한 자격증명으로 인증하는데도 계속 550 5.7.1로 튕기면, SMTP 트랜스크립트를 Exchange 조직 관리자에게 넘기세요 — 사서함이 클라이언트 제출에서 차단됐거나 전송 규칙이 가로채고 있을 수 있습니다.
- 메일 서버를 직접 운영하지 않는다면(호스팅 Exchange나 제공자를 통해 릴레이한다면) 릴레이 권한 부여는 그들 몫입니다. 정확한 바운스와 소스 IP를 주세요.
550 5.7.1과 보고 호스트가 어느 커넥터에 당신 발신자가 필요한지 정확히 알려줍니다. - 소유한 수신자 도메인이 수락 도메인으로 추가한 뒤에도 외부로 취급되면, 서버 쪽 라우팅·커넥터 설정 오류일 가능성이 큽니다 — SMTP 트랜스크립트가 Exchange 관리자에게 그 지점을 가리킵니다.
내 도메인에서 바로 확인
무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.