문제

발송 메일이 550 5.7.350 Remote server returned message detected as spam로 바운스됩니다. 당신은 거의 틀림없이 Exchange Online이나 Microsoft 365로 보내고 있고, 순서는 이렇습니다: Microsoft가 메시지를 받아들여 수신자 서버로 전달하려 했고, 그 서버가 스팸으로 거부했습니다. Microsoft는 원격 거부를 5.7.350 코드로 감싸 비전달 보고서(NDR)로 당신에게 돌려줬습니다. 메시지는 받은편지함에 닿지 못했고, 같은 내용을 같은 방식으로 다시 보내도 또 바운스됩니다.

증상

  • NDR에 550 5.7.350과 “Remote server returned message detected as spam” 문구가 있습니다.
  • 그 뒤에 수신자 자신의 판정이 이어지는 경우가 많습니다 — 자주 554 5.7.1과 “rejected due to high probability of spam” 같은 문구.
  • 일부 도메인으로는 전달되는데 다른 도메인(또는 한 대형 제공업체)으로는 바운스됩니다.
  • 새 메일 플랫폼으로 옮기거나, 마케팅/트랜잭션 서비스를 추가하거나, 발송량이 급증한 뒤 시작되거나 심해졌습니다.
  • 첨부(특히 압축 파일)나 링크가 많은 본문이 평범한 답장보다 더 많이 바운스됩니다.

550 5.7.350의 실제 의미

두 사실로 나누세요. 550은 RFC 5321의 영구 거부입니다 — 메일이 지연된 게 아니라 거부됐으니, 그대로 재시도해도 소용없습니다. 5.7.350은 Microsoft의 향상된 상태 코드이고, 정확한 문구가 핵심입니다: Remote server returned message detected as spam. 그 문장의 주어는 원격 서버입니다. 여기서 당신 메시지를 스팸이라 부르는 건 Microsoft가 아니라, 목적지가 그랬다고 Microsoft가 보고하며 그 거부를 당신에게 되올려 주는 것입니다.

이 한 가지 디테일이 조사 전체의 방향을 바꿉니다. 사람들은 Microsoft 코드를 보고 자기 Microsoft 365 관리 센터에서 켜고 끌 스위치를 찾아 헤맵니다. 하지만 그 결정은 당신이 통제하지 못하는 메일 서버가, 당신 도메인·발송 IP·콘텐츠에 자기 필터를 적용해 내린 것입니다. 당신이 통제할 수 있는 것은 그 서버가 당신을 신뢰할지 판단할 때 쓰는 신호입니다: 도메인이 SPF·DKIM·DMARC를 게시하는지, 메시지가 실제로 From 주소와 정렬되는 도메인으로 서명됐는지, 그리고 콘텐츠와 발송 패턴이 이 필터들이 잡도록 튜닝된 대량·비요청 메일처럼 보이는지.

가장 흔한 근본 원인은 실제 발송 경로에 대한 인증이 없거나 정렬되지 않은 것입니다. SPF 레코드가 커버하지 않는 새 서비스나 릴레이에서 온 메시지, 또는 정렬된 도메인으로 DKIM 서명되지 않은 메시지는 미인증으로 보입니다 — 그리고 평판 없는 IP에서 온 미인증 메일은 교과서적 스팸 프로필입니다. 인증과 발송 위생을 고치면 원격 필터가 당신을 거부할 이유가 훨씬 줄어듭니다.

주요 원인 3가지

  1. 발송 소스에 대한 인증 누락 또는 미정렬. 실제로 메일을 보내는 서비스가 SPF 레코드에 없거나, From에 정렬되는 도메인으로 DKIM 서명하지 않아서, 수신자가 유효하고 정렬된 인증을 못 보고 메시지를 불신합니다. 지문: 바운스되거나 수신된 헤더의 Authentication-Results에 spf=fail/none이나 dkim=none이 뜨고, 실패 소스가 최근 추가한 플랫폼입니다.
  2. 발신자·IP 평판 저하. 새롭거나 공유된 발송 IP, 이력 없는 도메인, 최근 불만 급증이 당신 지위를 낮추면, 평판 기반 필터가 정크로 분류하는 대신 아예 거부하기 시작합니다. 지문: 간헐적이고 제공업체별로 갈립니다 — 한 대형 수신자는 거부하는데 다른 곳은 여전히 받아들이고, 플랫폼 변경이나 발송량 증가와 상관관계가 있습니다.
  3. 스팸 휴리스틱을 건드리는 콘텐츠·패턴. 스팸성 문구, 위험하거나 압축된 첨부, 링크가 많거나 이미지만 있는 본문, 콜드 수신자 대상 메일머지 발송이 스팸 점수를 올립니다. 지문: 평범하고 개인적인 답장은 통과하는데, 같은 도메인으로 보낸 템플릿·첨부 캠페인은 바운스됩니다.

DechoNet으로 진단

  • Email Check는 발송 도메인의 SPF·DKIM·DMARC 레코드를 가져와 평가합니다 — 레코드가 당신 생각대로 끝나는지, SPF 10회 조회 한도(RFC 7208 §4.6.4) 안에서 해석되는지, 그리고 실제로 메일을 보내는 서비스를 커버하는지 확인할 수 있습니다. 여기의 빈틈이 스팸 거부의 가장 고치기 쉬운 원인입니다.
  • Email Header Analyzer는 바운스되거나 전달된 사본의 Authentication-Results 줄을 읽어, 수신자가 spf=pass·dkim=pass와 DMARC 정렬을 봤는지 보여 줍니다 — 이것이 인증 실패인지, 순수 평판/콘텐츠 문제인지 가장 빨리 증명하는 방법입니다.

해결 체크리스트

  • 전체 NDR을 읽고 두 코드를 확인하세요 — 5.7.350(Microsoft가 원격 거부를 중계) 그리고 뒤따르는 5.7.1/수신자 판정 — 그래야 이게 테넌트 오설정이 아니라 하류 스팸 거부임을 압니다.
  • From 주소의 도메인에 Email Check를 돌려 SPF·DKIM·DMARC가 모두 존재하고 유효한지 확인하세요.
  • 실제 발송 서비스가 승인됐는지 확인하세요: 그 SPF include:가 있고, From에 정렬되는 도메인으로 DKIM 서명하는지 — 실제 메시지 헤더를 Email Header Analyzer로 확인하세요.
  • 인증이 깨끗하다면 평판이나 콘텐츠 문제로 다루세요: 새 IP는 발송량을 점진적으로 늘려 워밍업하고, 위험한/압축 첨부를 빼고, 스팸 유발 문구와 콜드 대량 발송 패턴을 줄이세요.
  • 한 제공업체에 대한 지속적 차단이라면 그들의 postmaster/발신자 도구와, 제공된다면 제외(delisting)·피드백 절차를 쓰세요 — 단, SPF/DKIM/DMARC가 명백히 통과한 뒤에만.
  • 테스트 메시지를 보내고 정상 발송을 재개하기 전에 헤더에서 spf=pass·dkim=pass·dmarc=pass를 재확인하세요.

에스컬레이션 시점

  • 도메인이 깨끗하게 인증되는데도(정렬된 SPF·DKIM, DMARC 통과) 특정 대형 수신자가 여전히 5.7.350을 돌려준다면, 전체 바운스를 들고 그 수신자의 postmaster나 발신자 지원으로 에스컬레이션하세요 — 결정은 그들 몫이고, 그들만이 자기 측 평판·콘텐츠 차단을 설명할 수 있습니다.
  • 바운스가 원격 서버가 아니라 Microsoft 자체의 아웃바운드 보호를 가리킨다면(다른 코드, 예: 고위험 배달 풀로 라우팅된 메일), 이는 테넌트 측 전달성 문제입니다 — 탈취된 계정, 아웃바운드 스팸 정책, 그리고 Microsoft 365 관리 센터의 고위험 풀을 조사하세요.

내 도메인에서 바로 확인

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