Exchange Online: 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled

안녕하세요, BlueByte입니다. 몇 년째 smtp.office365.com 으로 메일을 보내던 복합기나 모니터링 스크립트, 사내 앱이 어느 날 AUTH 단계에서 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant. 으로 멈춥니다(응답은 aka.ms/smtp_auth_disabled 링크도 함께 보여줍니다). 비밀번호도 맞고 메일박스도 멀쩡한데, 클라이언트와 Exchange Online 사이 어딘가에서 SMTP AUTH 프로토콜 자체가 꺼진 상태입니다. 오늘은 이 응답을 만드는 세 개의 스위치, 문구만 보고 어느 스위치에 걸렸는지 가려내는 법, Microsoft 가 권하는 메일박스 단위 해결, 그리고 2026년 말 전에 Basic 인증에서 벗어나야 하는 이유까지 하나씩 짚어보겠습니다.

5.7.139 의 세 가지 문구는 서로 다른 스위치를 가리킵니다

서버가 어디서 멈췄는지 알려주므로 한 줄을 끝까지 읽는 것부터 시작합니다:

535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant.
535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Mailbox.
535 5.7.139 Authentication unsuccessful, the request did not meet the criteria to be authenticated successfully. Contact your administrator.

for the Tenant 는 조직 전체 설정이 꺼져 있고 메일박스가 그것을 물려받았다는 뜻입니다. for the Mailbox 는 그 메일박스 하나에서 꺼 두었다는 뜻이며, 이때 테넌트 설정은 더 이상 관계없습니다. did not meet the criteria 는 성격이 다릅니다. SMTP AUTH 는 켜져 있지만 Exchange 인증 정책이나 Microsoft Entra ID 의 보안 기본값이 SMTP 의 Basic 인증을 막고 있어, Exchange 가 비밀번호를 보기도 전에 거절합니다. 이런 문구 없이 535 5.7.3 Authentication unsuccessful 만 나오면 자격 증명이나 토큰 자체가 거절된 것입니다.

프로토콜이 꺼진 이유: 쓰지 않던 테넌트에서는 Microsoft 가 껐습니다

Microsoft 의 지침은 조직 전체에서 SMTP AUTH 를 끄고 아직 필요한 메일박스에서만 켜라는 것이고, 그쪽에서 두 가지 일이 있었습니다. 2020년 1월 이후 만들어진 테넌트는 처음부터 SMTP AUTH 가 꺼진 상태로 시작하고, Basic 인증 폐지 과정에서 Microsoft 는 SMTP AUTH 를 쓰지 않던 모든 테넌트에서 이를 비활성화했습니다. 그래서 최근 만든 테넌트나 측정 기간에 놀고 있던 장비는 조직 안에서 아무도 손대지 않았는데도 Tenant 문구를 만납니다. 세 번째 층이 보안 기본값입니다. Basic 인증을 쓰는 클라이언트 SMTP 제출은 보안 기본값과 호환되지 않으며, 그것이 did not meet the criteria 경우입니다.

Get-TransportConfig·Get-CASMailbox·Get-AuthenticationPolicy 로 어느 스위치인지 확인하기

Exchange Online PowerShell 에 연결해 조직부터 보고, 그다음 장비가 From 에 적는 주소가 아니라 실제로 로그인하는 메일박스를 봅니다:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
Get-CASMailbox -Identity scanner@contoso.com | Format-List SmtpClientAuthenticationDisabled

SmtpClientAuthenticationDisabled : True
 
SmtpClientAuthenticationDisabled :

문서는 메일박스 값을 정확히 정의합니다. True 는 비활성, False 는 활성, 빈 값($null)은 조직 설정을 따른다는 뜻입니다. 빈 값에 조직 값이 True 면 Tenant 문구, 메일박스 값이 True 면 Mailbox 문구가 나옵니다. 둘 다 활성인데도 did not meet the criteria 가 나오면 정책 층을 봅니다:

Get-OrganizationConfig | Format-List DefaultAuthenticationPolicy
Get-User -Identity scanner@contoso.com | Format-List AuthenticationPolicy
Get-AuthenticationPolicy | Format-List Name, AllowBasicAuthSmtp

사용자에게 할당됐거나 기본값으로 지정된 정책에 AllowBasicAuthSmtp : False 가 있으면 비밀번호가 막힙니다. 정책이 없다면 Microsoft Entra 관리 센터의 Properties → Manage security defaults 에서 보안 기본값을 확인해보세요. 문서는 보안 기본값이 켜져 있으면 Exchange Online 에서 SMTP AUTH 가 이미 비활성화된 상태라고 분명히 적고 있습니다.

원인별 해결: 테넌트가 아니라 메일박스를 엽니다

Tenant 와 Mailbox 문구라면 보내는 메일박스에서만 SMTP AUTH 를 켜고 조직 설정은 그대로 둡니다:

Set-CASMailbox -Identity scanner@contoso.com -SmtpClientAuthenticationDisabled $false
Get-CASMailbox -Identity scanner@contoso.com | Format-List SmtpClientAuthenticationDisabled

SmtpClientAuthenticationDisabled : False

메일박스 설정이 조직 설정보다 우선하므로 Get-TransportConfig 가 여전히 True 여도 동작합니다. 같은 토글이 Microsoft 365 관리 센터의 사용자 Mail → Manage email apps → Authenticated SMTP 에도 있습니다. Set-TransportConfig -SmtpClientAuthenticationDisabled $false 는 테넌트의 모든 메일박스에 프로토콜을 다시 여는 것이니 마지막 수단으로 남겨 두세요.

인증 정책 때문에 did not meet the criteria 가 나온다면, 그 서비스 계정 하나에 Basic SMTP 만 허용하는 전용 정책을 만들고 기본 24시간을 기다리지 않게 바로 반영합니다:

New-AuthenticationPolicy -Name "Allow SMTP AUTH for scanners" -AllowBasicAuthSmtp
Set-User -Identity scanner@contoso.com -AuthenticationPolicy "Allow SMTP AUTH for scanners"
Set-User -Identity scanner@contoso.com -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

스위치를 값 없이 지정하면 그 프로토콜만 허용되고, 새 정책의 나머지는 모두 차단 상태로 남습니다. 차단의 출처가 보안 기본값이라면 사용자별 예외는 없습니다. 클라이언트가 OAuth 로 옮기거나, 테넌트가 보안 기본값에서 서비스 계정을 제외하는 조건부 액세스 정책으로 옮기거나 둘 중 하나입니다. 복합기 한 대를 살리려고 보안 기본값을 끄면 모든 사용자의 보호 수준이 내려가니, OAuth 를 대안이 아니라 첫 번째 선택지로 두세요.

클라이언트 쪽에서도 맞아야 하는 설정

스위치를 열었더라도 클라이언트는 문서의 설정과 맞아야 합니다. smtp.office365.com(IP 주소는 금지), 포트 587(25 도 되지만 ISP 가 막는 경우가 많음), TLS 1.2 또는 1.3 의 STARTTLS, 그리고 메일박스 자체의 로그인 자격 증명입니다. 포트 465 를 고집하는 장비는 클라이언트 SMTP 제출이 요구하는 TLS 버전을 지원하지 않는 것입니다. 발신자는 하루 10,000 수신자, 분당 30 통으로 제한되며, From 주소가 다른 메일박스라면 로그인 계정에 그 메일박스의 Send As 권한이 있어야 합니다.

실제 사례: 스캔 메일이 끊긴 복합기

2021년에 만든 테넌트에서 복합기가 copier@contoso.com 으로 스캔을 보내고 있었습니다. 펌웨어 초기화 뒤 복합기가 535 5.7.139 ... disabled for the Tenant 를 보고합니다. 위 순서대로 직접 확인해 보면 Get-TransportConfig 는 True, Get-CASMailbox -Identity copier@contoso.com 은 빈 값이라 메일박스가 비활성 상태를 물려받고 있습니다. 관리자는 Set-CASMailbox -Identity copier@contoso.com -SmtpClientAuthenticationDisabled $false 를 실행하고, 복합기를 건드리기 전에 노트북에서 테스트합니다:

openssl s_client -starttls smtp -crlf -connect smtp.office365.com:587 -quiet
EHLO test.contoso.com
AUTH LOGIN
Y29waWVyQGNvbnRvc28uY29t
<base64 of the password>

235 2.7.0 Authentication successful

base64 줄은 printf 'copier@contoso.com' | base64 로 만듭니다. 변경 전에는 같은 세션이 535 5.7.139 줄에서 끝났고, 변경 후 235 2.7.0 이 그 메일박스에 프로토콜이 열렸음을 확인해 줍니다. 복합기는 설정을 하나도 바꾸지 않고 다시 보내기 시작합니다.

티켓을 닫기 전에 끝까지 확인하기

세 가지를 순서대로 봅니다. Get-CASMailbox 가 보내는 메일박스에 대해 False 를 보여주는지, 포트 587 로 직접 한 AUTH LOGIN 이 235 2.7.0 을 돌려주는지, 그리고 장비에서 보낸 실제 메일이 도착하면서 보낸 사람의 Sent Items 에도 남는지(릴레이 방식은 남기지 않습니다)입니다. 수동 테스트는 통과하는데 장비만 실패하면, 장비가 주장하는 것과 다른 계정·포트·TLS 버전을 쓰고 있는 것입니다.

2026년 12월 이후에도 동작하게 하기

Microsoft 는 2026년 1월 27일에 폐지 일정을 갱신했습니다. 2026년 12월까지 SMTP AUTH Basic 인증은 지금처럼 동작하고, 2026년 12월 말에 기존 테넌트에서 기본 비활성화되며 관리자는 필요하면 여전히 켤 수 있고, 그 이후 만들어지는 테넌트는 기본적으로 쓸 수 없으며 OAuth 가 지원 방식이 되고, 2027년 하반기에 최종 제거일을 발표합니다. 즉 위 해결은 시간을 벌어 줄 뿐 영구적이지 않습니다. Exchange 관리 센터의 SMTP AUTH Clients Submission Report 로 아직 비밀번호로 보내는 클라이언트를 파악하고(클라이언트별로 Basic 인지 OAuth 인지 표시됩니다) 발신자를 하나씩 옮기세요. 직접 관리하는 앱은 https://outlook.office.com/SMTP.Send 범위의 OAuth 를 쓰거나, 무인 발송이면 SMTP.SendAsApp 에 New-ServicePrincipal 과 Add-MailboxPermission 을 더해 쓸 수 있습니다. 내부 수신자 전용 대량 메일은 High Volume Email, 앱에서 외부로 보내는 메일은 Azure Communication Services, 평문 SMTP 밖에 못 하는 장비는 인증서나 고정 IP 로 인증하는 SMTP 릴레이 커넥터가 맞습니다. 메일박스 스위치는 자격 증명 종류가 아니라 프로토콜을 다루므로, OAuth 클라이언트도 자기 메일박스의 SmtpClientAuthenticationDisabled 가 False 여야 합니다.

5.7.60·단순 비밀번호 오류와의 차이

5.7.60 Client doesn't have permissions to send as this sender 는 인증은 성공했지만 From 주소가 Send As 권한 없는 다른 사람 것이라는 뜻입니다. 535 5.7.3 Authentication unsuccessful 은 자격 증명 자체의 문제로, 틀린 비밀번호, 만료된 토큰, 또는 MFA 가 강제된 계정이 프롬프트를 통과할 방법이 없는 경우입니다. 5.7.139 는 이 둘보다 앞에 있습니다. 프로토콜이 닫혀 있고, 열기 전까지는 자격 증명이 무엇이든 관계없습니다.

다음에 Microsoft 365 를 거쳐 보내던 장비가 멈추면 이 순서를 거꾸로 따라가 보세요. 문구를 읽고, 조직과 메일박스를 조회하고, 그다음 정책을 보고, 문제를 푸는 가장 작은 스위치를 연 뒤, 2026년 12월 전에 OAuth 나 릴레이로 옮길 목록에 그 발신자를 올리면 됩니다.