5.7.606 발신 IP 차단: 오피스365 해제

Problem

@outlook.com·@hotmail.com 또는 마이크로소프트365 호스팅 업무 도메인으로 보낸 메일이 550 5.7.606 Access denied, banned sending IP [당신의.IP.주소]로 반송됩니다. 수신자에게 아무것도 닿지 않았습니다. 이건 콘텐츠 필터나 스팸함 문제가 아닙니다 — 당신이 발신하는 IP가 마이크로소프트의 내부 차단 발신자 목록에 있어서, 연결 단계에서 거부한 것입니다.

Symptoms

• 반송문이 550 5.7.606(또는 5.7.607~5.7.614)에 “Access denied, banned sending IP”와 대괄호 안 당신 발신 IP를 담고 있다.
• 마이크로소프트 목적지만 거부한다 — Outlook·Hotmail·Live·마이크로소프트365 업무 테넌트 — 반면 지메일·네이버 등은 같은 메일을 받아준다.
• 확인하는 모든 공개 블랙리스트(Spamhaus·Barracuda·SORBS)에서 IP가 깨끗해, 차단이 설명 불가처럼 보인다.
• 새 IP, 새 VPS, 공유 호스팅 발신 플랫폼으로 옮긴 뒤 시작됐다.
• 혹은 도메인의 사서함 하나가 탈취돼 스팸을 한 차례 쏜 뒤 시작됐다.

550 5.7.606이 실제로 뜻하는 것

코드를 두 부분으로 읽으세요. 550은 영구 SMTP 거부(RFC 5321)입니다: 같은 메일을 재발송해도 소용없습니다. 5.7.606은 마이크로소프트 자체 확장 상태 코드이고 구체적입니다 — “Access denied, banned sending IP.” 마이크로소프트365는 당신 메시지나 도메인이 아니라 IP 주소를 차단합니다.

이 오류에서 가장 중요한 사실은 차단이 어디에 사는가입니다. 마이크로소프트365는 자체 차단 발신자 목록을 자체 신호 — 스팸 트랩, 불만율, 인증 실패, IP와 그 이웃의 평판 — 로 만들어 운영합니다. 이 목록은 Spamhaus가 아닙니다. 어떤 외부 DNSBL도 아닙니다. 그래서 대부분 발신자가 반사적으로 하는 것 — 공개 블랙리스트 확인, 아무것도 못 찾음, 차단이 실수라고 결론 — 은 엉뚱한 도시의 지도를 보는 셈입니다. 티끌 없는 DNSBL 결과와 마이크로소프트 차단은 완벽히 공존합니다. 서로 다른 것을 재기 때문이죠.

즉 해결할 곳은 정확히 하나입니다: 마이크로소프트 해제 포털 sender.office.com — 마이크로소프트365 고객이 아니어도 누구나 제거를 요청할 수 있습니다. 다만 포털은 현재 차단만 풉니다. 차단을 부른 행위가 계속되면 같은 IP가 다시 목록에 오르고, 반복 요청은 힘을 잃습니다. 마이크로소프트 안내에 따르면 해제는 반영까지 최대 24시간 걸릴 수 있고, 확인 메시지가 모든 수신 경로 복구의 증거는 아닙니다.

Top 3 원인

1. 스팸을 쏘는 탈취 계정 또는 오픈 릴레이. 뚫린 사서함, 잘못 설정된 릴레이, 탈취된 웹 폼이 당신 IP에서 정크를 보내고 있고, 당신보다 마이크로소프트 필터가 먼저 알아챘습니다. 신호: 당신 쪽 인프라 변경 없이 차단이 갑자기 나타났고, 발신 큐나 메일 로그에 알 수 없는 물량·수신자가 보임. 해제 전에 반드시 고쳐야 하는 원인입니다 — 안 그러면 며칠 안에 재차단됩니다.
2. 평판을 빌려 쓰는 공유·신규 할당 IP. 이전 임차인이 남용한 IP 위의 VPS·클라우드 인스턴스·공유 플랫폼에서, 혹은 발송 이력 없는 신규 주소에서 보냅니다. 마이크로소프트는 상속으로 불신합니다. 신호: 첫 발송부터 차단이 있었거나, IP가 회전율 높기로 알려진 클라우드/호스팅 대역이고, 당신이 이전 사용자를 통제한 적이 없음.
3. 발신 IP의 누락·일반 역방향 DNS. IP에 PTR 레코드가 없거나, 발신 호스트명과 안 맞는 클라우드 제공업체 기본 PTR입니다. 마이크로소프트는 역방향 DNS를 무겁게 보고, 그 부재는 — 특히 위 두 원인과 겹치면 — 평판을 차단 쪽으로 끕니다. 신호: 발신 IP의 역방향 DNS 조회가 아무것도, 또는 ip-x-x-x-x.provider.example 같은 일반 이름을 반환.

DechoNet으로 진단

• IP 조회는 발신 IP의 소유자·ASN·호스팅/클라우드 분류를 보여줍니다 — 평판을 통제할 수 없는 공유·데이터센터 대역에 있는지 알 수 있고, 이는 해결책이 “해제”인지 “전용 IP로 이전”인지를 가릅니다.
• 역방향 DNS 조회는 발신 IP에 실제 발신 호스트명으로 되돌아 해석되는(forward-confirmed) 유효한 PTR이 있는지 확인합니다. 누락·일반 PTR은 마이크로소프트가 알아채는 평판 저해 요소이며, 제대로 설정하는 것이 해제 시도가 의미 있으려면 선행돼야 합니다.

해결 체크리스트

• 반송문에서 정확한 확장 코드를 읽으세요. 5.7.606~5.7.614(“banned sending IP”)이면 해제 포털을 쓰세요. 5.7.511(“banned sender”)이면 포털을 쓰지 말고 [email protected]으로 메일하세요.
• 해제 전에 원인부터 찾으세요: 메일 로그·발신 큐에서 스팸 물량을 확인하고, 탈취된 사서함을 잠그고, 오픈 릴레이나 남용된 폼을 닫으세요. 계속 스팸을 쏘는 IP를 해제하는 건 시계만 리셋합니다.
• 발신 IP에 IP 조회를 돌리세요. 평판을 통제 못 하는 공유·클라우드 IP라면, 절대 깨끗이 유지 못 할 IP를 반복 해제하기보다 전용 발신 IP로 옮기는 걸 검토하세요.
• 역방향 DNS를 확인하고, 누락·일반이면 발신 호스트명과 일치하는 유효한 forward-confirmed PTR을 설정하세요.
• 메일 인증을 확인하세요 — 발신 도메인의 SPF·DKIM·DMARC 레코드 — 마이크로소프트가 신뢰를 재구축할 깨끗한 신원이 있도록.
• 이제야 sender.office.com에 IP를 제출하고, 발송되는 메일로 확인한 뒤, 최대 24시간 기다리세요. 확인을 완전 복구로 여기지 말고 — 실제 메시지로 재테스트하세요.

에스컬레이션 시점

• 원인을 고치고, 유효한 PTR을 설정하고, 메일을 인증했는데도 해제가 실패하거나 차단이 돌아온다면, 로그를 들고 해제 포털의 후속 지원 경로로 지원 요청을 여세요 — 깨끗한 전용 IP의 지속 차단은 마이크로소프트만 설명할 수 있습니다.
• 코드가 실제로 5.7.511이고 [email protected]으로도 안 풀린다면, 재제출하지 말고 마이크로소프트365 지원으로 에스컬레이션하세요; banned-sender 경로는 셀프서비스 포털이 아니라 사람이 처리합니다.