Microsoft 365 앱과 장치의 이메일: 2026년 12월 변경 전 확인 사항

스캐너, 청구 시스템 또는 보고 애플리케이션의 변경을 승인하기 전에 Exchange Online을 통해 SMTP AUTH 기본 인증으로 이메일을 보내는지 확인하세요. Microsoft의 2026년 12월 변경은 이 특정 의존성에 영향을 줍니다. 조직에서 Microsoft 365를 사용한다는 사실만으로 각 애플리케이션의 발송 방식을 알 수는 없습니다.

실무에서는 영향을 받는 발신 주체를 파악하고, 지원되는 전환 경로를 확인한 다음, 운영 설정을 바꾸기 전에 대표적인 업무 이메일을 검증해야 합니다. 이를 바탕으로 담당자나 예산 승인자는 필요한 작업을 판단할 수 있습니다.

12월 말에 달라지는 점

Microsoft의 SMTP AUTH 최신 일정에 따르면 2026년 12월까지 동작은 그대로 유지됩니다. 12월 말에는 기존 테넌트에서 SMTP AUTH 기본 인증이 기본적으로 비활성화됩니다. 관리자는 필요한 경우 계속 활성화할 수 있습니다. 이 기본값 변경은 최종 제거와 별개입니다.

2026년 12월 이후에 만들어진 신규 테넌트에서는 기본적으로 사용할 수 없으며, OAuth가 지원되는 인증 방식이 됩니다. Microsoft는 최종 제거 날짜를 2027년 하반기에 발표한다고 밝혔습니다. 이 기간은 날짜를 발표하는 시점이지, 제거 날짜가 아닙니다.

이 일정은 Exchange Online SMTP AUTH 기본 인증에 관한 것입니다. SMTP 자체가 종료된다는 뜻도 아니며, 모든 Microsoft 365 사서함과 장치가 같은 방식에 의존한다는 뜻도 아닙니다. 변경된 일정은 준비 시간을 제공하지만, 구체적인 설정 변경이 필요한지 평가해야 합니다.

업무 이메일부터 확인하기

중요한 이메일마다 공급업체나 관리자를 통해 실제 발송 경로를 확인하세요. 청구 애플리케이션은 Exchange Online에 직접 제출하거나, 로컬 릴레이를 사용하거나, 공급업체 서비스를 통해 보낼 수 있습니다. 이는 가정에 따른 예시이며 각각 다른 근거가 필요합니다. 보낸 사람 주소에 Microsoft 365 주소가 표시된다는 사실만으로는 판단할 수 없습니다.

다음 항목을 간단한 목록으로 정리하세요.

• 업무 이메일: 무엇을 언제 보내는지, 필요한 첨부 파일이나 본문 내용은 무엇인지.
• 발신 주체와 경로: 애플리케이션 또는 장치, 실제 발송 서비스, 인증 방식.
• 수신자: 조직 내부, 외부 또는 양쪽 모두.
• 시스템 담당자: 발신 주체와 공급업체 관계를 책임지는 사람.
• 지속 사용 방안: 지원되는 경로와 아직 해결되지 않은 호환성 또는 구성 질문.
• 검증 담당자: 필요한 이메일이 수신자에게 도착했는지 확인할 사람.

확인되지 않은 사항을 명시하고 해결 담당자를 지정하세요. 그러면 기본 인증 의존성이 확인된 발신 주체와 별도 조사가 필요한 발신 주체를 구분할 수 있습니다. 구매나 구성 변경 전에 공급업체에 구체적인 질문을 전달할 수도 있습니다.

수신자와 호스팅 환경에 맞춰 경로 선택하기

OAuth 클라이언트 제출은 가능한 전환 경로 중 하나입니다. Microsoft의 SMTP OAuth 문서는 애플리케이션 등록과 토큰을 포함한 인증 지원을 설명합니다. 해당 애플리케이션이나 장치가 필요한 지원을 구현해야 하며, 테넌트 구성에서도 사용을 허용해야 합니다. 제품이 “SMTP를 지원한다”는 말만으로는 호환성을 확인하기에 부족합니다. 정확한 모델이나 소프트웨어 버전을 공급업체에 문의하세요.

Microsoft의 애플리케이션 및 장치 발송 지침은 수신자 범위와 운영 요건에 따라 경로를 구분합니다. 클라이언트 제출과 자격 요건을 충족하는 커넥터 릴레이는 내부 및 외부 수신자에게 보낼 수 있습니다. 해당 비교에서 대량 이메일(HVE)과 Direct Send는 내부 전용입니다. 고객에게 보내는 청구서나 알림처럼 조직 외부로 전송하는 용도에는 적합하지 않습니다.

커넥터 릴레이에는 별도의 자격 요건이 있습니다. 인바운드 커넥터가 필요하고, 인증서 또는 요건을 충족하는 고정 공인 IP 주소로 인증해야 하며, 포트 25를 사용할 수 있어야 합니다. Microsoft는 Azure와 같은 타사 호스팅 서비스를 통한 이 경로의 릴레이를 허용하지 않습니다. 따라서 커넥터 릴레이를 선택지로 보기 전에 클라우드 호스팅 애플리케이션의 호스팅 환경을 확인해야 합니다.

Direct Send를 사용하면 이메일 서버 관리 책임도 따릅니다. Microsoft가 내부 및 외부 메일용 대안으로 설명하는 Azure Communication Services를 포함한 다른 발송 서비스도 호환성과 운영 측면에서 별도로 평가해야 합니다. 수신자 목록, 호스팅 환경, 이용 가능한 지원을 바탕으로 조사할 선택지를 정하세요. 하드웨어 교체는 지원되는 방법을 확인한 뒤 타당성을 판단해야 합니다.

운영 변경 전에 이메일 검증하기

누가 변경을 수행하고, 누가 업무 결과를 확인하며, 변경 후 문제는 누가 처리할지 합의하세요. 필요한 발신자 정보, 본문, 첨부 파일을 갖춘 대표적인 이메일을 사용하세요. 제출부터 의도한 수신자가 받기까지 추적하고, 업무 절차상 필요한 경우 외부 수신자에게도 도착하는지 확인하세요.

인증 성공은 전체 과정 중 한 부분만 확인해 줍니다. 공급업체가 지원을 확인하고 관리자의 연결 테스트가 성공해도 업무 이메일이 실제로 도착했는지 확인해야 합니다. 의존성, 호환되는 경로, 검증 책임자가 명확해진 뒤 운영 변경을 일정에 반영하세요.

애플리케이션이나 장치 발신자의 요건을 검토하는 데 도움이 필요하면 이메일 인프라 서비스를 통해 저희와 범위를 논의하실 수 있습니다.