용어 · Office 365 SMTP 설정 정보

Office 365 SMTP 설정 정보란 무엇이며 애플리케이션 이메일에 어떤 영향을 주나요?

Office 365 SMTP 세부 정보는 하나의 범용 호스트와 비밀번호가 아닙니다. Microsoft는 smtp.office365.com을 통한 인증된 클라이언트 제출, 테넌트 MX 엔드포인트를 통한 커넥터 기반 SMTP 릴레이, 내부 Microsoft 365 수신자로의 Direct Send 등 여러 애플리케이션 및 장치 패턴을 문서화합니다. 이들은 인증, TLS, 포트, 발신자 ID, 외부 수신자 지원, 라이선스, 제한, 관리 설정이 다릅니다. 워크로드와 신뢰 경계에서 패턴을 선택하고, 클라이언트 제출에 해당하면 OAuth를 사용하며, SMTP AUTH를 좁게 활성화하고, 정확한 엔벨로프 및 From ID를 테스트하며, 릴레이 접수는 최종 전달 또는 받은편지함 도달과 별개로 다루세요.

Office 365 SMTP 세부 정보는 여러 경로를 설명합니다

Microsoft 365 및 Office 365 문서는 클라이언트 SMTP 제출, SMTP 릴레이, Direct Send를 구분합니다. 클라이언트 제출은 Exchange Online 메일함으로 인증하고 smtp.office365.com을 통해 발송합니다. SMTP 릴레이는 애플리케이션이나 장치를 조직의 메일 서버로 취급하며 인바운드 커넥터로 연결을 인증합니다. Direct Send는 조직 내 수신자를 대상으로 테넌트의 Microsoft 365 MX 엔드포인트에 익명으로 제출합니다. 비슷한 SMTP 명령 뒤에 있지만 운영 방식이 서로 다른 제품입니다. 어떤 경로를 의도하는지 정하지 않은 채 포럼에서 호스트 이름과 포트를 복사해 오지 마세요. 먼저 테넌트, 승인된 도메인, 관리자, 워크로드, 발신자 ID, 발신 네트워크, 수신자 범위, 인증 방식, TLS 정책, 발송량, 장애 담당자를 기록하세요. SMTP 전송은 원인이 된 비즈니스 이벤트를 승인하지도, 수신자 동의를 확립하지도, 애플리케이션 큐를 지속형으로 만들어 주지도 않습니다.

클라이언트 SMTP 제출 설정

Microsoft의 현재 설정 가이드는 클라이언트 제출용 DNS 이름으로 smtp.office365.com을 문서화하고 IP 주소로 대체하지 말라고 안내합니다. TCP 587번 포트를 권장하고, 문서화된 시나리오에서는 25번 포트를 허용하며, STARTTLS를 활성화한 TLS 1.2 또는 TLS 1.3을 요구합니다. 애플리케이션은 라이선스가 있는 Microsoft 365 또는 Office 365 메일함으로 인증하며, 문서화된 한도 안에서 내부 및 외부 수신자에게 발송할 수 있습니다. 메일함 주소를 명시적인 ID로 사용하고, 보이는 From이 다를 때는 Send As 권한을 테스트하세요. 자격 증명이나 토큰은 서버 측 시크릿 관리자에 보관하세요. 계정 로그인에 성공했다고 해서 보이는 From이 허용되었다는 것, 수신자가 유효하다는 것, 메시지가 받은편지함에 도달한다는 것이 증명되지는 않습니다. 클라이언트 제출은 메일함 단위 경로이므로, 사용자 정지, 라이선스 변경, 조건부 액세스 결정, SMTP AUTH 설정 때문에 달라진 것이 없어 보이는 애플리케이션도 중단될 수 있습니다.

OAuth를 사용하고 SMTP AUTH는 좁게 활성화하기

Microsoft는 클라이언트 SMTP 제출에 OAuth를 사용하는 최신 인증을 권장합니다. OAuth 문서는 SMTP.Send 범위와 SASL XOAUTH2 형식을 정의하며, 위임형 및 애플리케이션 지향 흐름은 Microsoft Entra 등록과 Exchange 권한을 따릅니다. 액세스 토큰과 갱신 토큰은 시크릿으로 취급하고, 필요한 권한만 요청하고, 테넌트와 메일함 바인딩을 검증하고, 애플리케이션 자격 증명을 교체하고, 사용하지 않는 부여는 제거하세요. Microsoft는 또한 Exchange Online 조직 전체에서 SMTP AUTH를 비활성화하고 여전히 필요한 메일함에만 활성화하도록 권장합니다. 조직 전체 설정과 메일함별 재정의가 모두 있으며, 메일함 설정이 우선할 수 있습니다. 보안 기본값은 SMTP AUTH를 비활성화합니다. 레거시 장치 하나를 유지하려고 테넌트 전체의 보안 기준을 끄지 마세요. 워크로드가 OAuth와 TLS 요건을 충족할 수 없다면 커넥터, 지원되는 최신 클라이언트, 온프레미스 릴레이, 또는 문서화된 다른 서비스를 선호하세요.

클라이언트 제출 한도는 애플리케이션 설계에 영향을 줍니다

Microsoft의 현재 비교 문서는 클라이언트 SMTP 제출 스로틀링을 하루 수신자 10,000명, 분당 메시지 30통으로 문서화합니다. 이 수치는 바뀔 수 있으며 다른 Exchange Online 한도와 상호 작용할 수 있는 현재 서비스 한도로 취급하세요. 메시지 수뿐 아니라 To, Cc, Bcc, 재시도, 팬아웃 전체에 걸쳐 수신자를 세세요. 애플리케이션 속도, 테넌트 간 공정성, 동시성, 시도, 큐 보관 기간 제어는 서비스 상한보다 낮게 두세요. 공유 메일함 경로는 사람의 사용과 자동화된 사용 사이에 경합을 일으킬 수 있고, 여러 애플리케이션이 하나의 자격 증명을 쓰면 담당 주체가 가려집니다. 속도와 수신자 여유를 모니터링하되, 메일함이나 발신 도메인을 돌려 가며 한도를 회피하지 마세요. 워크로드가 메일함 제출 한도에 자주 근접한다면, 최신 Microsoft 안내를 바탕으로 커넥터 릴레이, 대상이 되는 내부 트래픽의 High Volume Email, 애플리케이션 전달용 Azure Communication Services Email, 또는 목적에 맞게 만들어진 다른 전송 방식을 평가하세요.

커넥터 기반 SMTP 릴레이 설정 정보

Microsoft 365 SMTP 릴레이는 smtp.office365.com이 아니라 테넌트의 MX 엔드포인트와, 조직의 발송 시스템을 식별하는 인바운드 커넥터를 사용합니다. Microsoft는 TLS 인증서로 커넥터를 인증하도록 권장하며, 공용 고정 IP 주소는 문서화된 또 다른 식별 방법입니다. 애플리케이션은 TCP 25번 포트로 연결하고, 발신자마다 라이선스가 있는 메일함을 요구하지 않고도 승인된 도메인의 주소에서 발송할 수 있습니다. 이 패턴은 인증서와 네트워크 소유권이 안정적인 통제된 메일 서버, 어플라이언스, 게이트웨이에 적합합니다. 그만큼 관리 부담이 큽니다. 커넥터 범위, 인증서 수명 주기, 공용 IP 변경, 역방향 DNS, 승인된 도메인 정책, 악용 방지, 차단 목록 모니터링이 필요합니다. 오픈 릴레이를 만들지 마세요. 게이트웨이가 수락하는 내부 시스템, 테넌트, 발신자, 수신자, 메시지 유형을 제한하세요. 커넥터는 연결을 조직의 것으로 인식할 뿐, 임의의 애플리케이션 입력이 정당하다는 것을 검증하지는 않습니다.

Direct Send는 내부 수신자 전달이며 일반 릴레이가 아닙니다

Direct Send는 메일함이나 커넥터로 인증하지 않고 외부 SMTP 서버로서 테넌트의 MX 엔드포인트에 제출합니다. Microsoft는 이를 Microsoft 365 또는 Office 365 조직 내 수신자에게 전달하는 방법으로 문서화하며, 임의의 외부 주소로 가는 경로로 안내하지 않습니다. 장치나 애플리케이션에는 TCP 25번 포트 접근이 필요하며 승인된 도메인의 발신자를 사용해야 합니다. 인터넷에 노출되는 서비스의 관점에서 이 경로는 익명이므로 발신자 평판, DNS, 발신 IP, 스푸핑 방지 결정이 중요합니다. Direct Send 게이트웨이를 신뢰할 수 없는 네트워크에 노출하거나 메일함 인증을 우회하는 데 사용하지 마세요. 프린터나 애플리케이션이 반송 메시지를 안전하게 받지 못할 수 있으므로 미전달 보고서와 지원 담당을 모델링하세요. 외부 전달이 필요하다면 ID와 발송량을 평가한 뒤 클라이언트 제출, 커넥터 릴레이, Azure Communication Services Email 또는 지원되는 다른 방법을 선택하세요.

엔벨로프 ID, 보이는 From, 인증을 분리해서 관리하기

모든 경로에는 SMTP 엔벨로프 발신자와 수신자 명령, 그리고 RFC 5322의 보이는 헤더가 함께 실립니다. 엔벨로프 발신자는 전송 반송을 제어하며 SPF ID인 경우가 많고, 보이는 From은 독자에게 보이는 내용을 제어하며 DMARC의 핵심 ID입니다. OAuth 메일함 인증, 커넥터 ID, 발신 IP 수락이 모든 사용자 지정 From 도메인에 대해 SPF, DKIM, DMARC 정렬을 자동으로 만들어 주지는 않습니다. 통제된 수신 샘플에서 정확한 MAIL FROM, From, Reply-To, DKIM d= 도메인과 셀렉터, 연결한 IP를 목록으로 정리하세요. 해당 도메인에 유효한 SPF 정책 하나를 게시하고, 지원되는 곳에서는 DKIM 서명을 구성하고, DMARC 정렬을 평가하세요. 장치 하나를 고치려고 두 번째 SPF 레코드를 추가하거나 조직의 DMARC 정책을 완화하지 마세요. 상태 모델에서 Microsoft의 접수, 수신 서버의 수락, 이후의 반송, 메일함 필터링, 받은편지함 도달, 사람의 동작을 분리하세요.

지속형 애플리케이션 경계 구현하기

Microsoft 365 SMTP는 권한이 있는 서버 워커나 통제된 릴레이 뒤에 두세요. 연결하기 전에 안정적인 멱등성 키, 테넌트, 메시지 유형, 템플릿 리비전, 승인된 발신자와 수신자, 수신 동의 또는 필요성 근거, 발송 제외 상태, 시도 이력을 포함한 비즈니스 이벤트를 저장하세요. SMTP 명령을 만들기 전에 테넌트별 발신자와 수신자 규칙을 적용하세요. 메시지 크기, 수신자 팬아웃, 첨부 파일, 헤더 값에 상한을 두세요. 토큰, 비밀번호, 인증서 개인 키, 커넥터 관리 정보는 소스, 로그, 분석, 티켓, 프롬프트 밖에 보관하세요. 유한한 타임아웃을 설정하고, 전체 확장 진단과 Microsoft 안내에 따라 4xx 응답은 상한 있는 재시도 후보로, 5xx 응답은 해당 시도에서 영구적인 것으로 분류하세요. DATA 이후 최종 응답 전에 연결이 끊어지는 경우는 결과가 모호하므로, 재발송하기 전에 해당 시도를 보존하고 대조하세요. SMTP에는 제품 수준의 정확히 한 번(exactly-once) 보장이 없습니다.

배포 전에 구성과 장애 모드 테스트하기

전용 통제된 수신자와 프로덕션과 같은 발신 네트워크를 사용하세요. DNS 확인, 포트 도달 가능성, STARTTLS 협상, 인증서 호스트 이름과 체인, OAuth 토큰 획득과 범위, SMTP AUTH 조직 및 메일함 설정, Send As 권한, 커넥터 일치, 승인된 도메인, MX 엔드포인트 선택을 검증하세요. 일반 텍스트, HTML, 첨부 파일, 유니코드, 반송, 예상 발송량 샘플을 보내세요. 고객 콘텐츠는 보관하지 않으면서 원본 헤더, 신뢰할 수 있는 Authentication-Results, SMTP 응답, 추적 식별자, 메시지 추적 증거를 기록하세요. 부정 테스트에는 폐기된 토큰, 만료된 커넥터 인증서, 변경된 공용 IP, 비활성화된 메일함 SMTP AUTH, 보안 기본값, 유효하지 않은 From, Direct Send를 통한 외부 수신자, 분당 한도와 수신자 한도, 일시 지연, 영구 거부, DATA 전후의 연결 끊김이 포함되어야 합니다. 영구적인 정책이나 수신자 실패를 우회하지 않으면서 워크로드를 일시 중지하고 지속형 작업을 옮기는 절차를 미리 연습하세요.

최신 Microsoft 지침을 사용하고 테넌트를 테스트하세요

Microsoft 365 SMTP 구성은 테넌트 정책, ID, 커넥터, 네트워크 환경에 따라 달라집니다. 프로덕션 이메일에 의존하기 전에 최신 Microsoft Learn 문서를 사용하고 테넌트에서 선택한 경로를 테스트하세요.

자주 묻는 질문

Microsoft 365 클라이언트 SMTP 호스트 이름은 무엇인가요?

Microsoft는 현재 인증된 클라이언트 제출용으로 smtp.office365.com을 문서화하며, 고정된 서비스 IP 주소가 아니라 DNS 이름을 사용하라고 안내합니다.

클라이언트 SMTP 제출에는 어떤 포트를 사용해야 하나요?

Microsoft는 TCP 587번 포트를 권장하고 지원되는 클라이언트 제출 시나리오에서는 25번 포트도 문서화하며, STARTTLS와 TLS 1.2 또는 TLS 1.3을 요구합니다.

Microsoft 365 클라이언트 제출은 OAuth를 지원하나요?

네. Microsoft는 OAuth를 권장하며 SMTP.Send 범위와 SASL XOAUTH2를 문서화합니다. 테넌트 등록, 권한, 토큰 보관, 메일함 바인딩은 여전히 신중한 구성이 필요합니다.

SMTP 릴레이와 Direct Send는 무엇이 다른가요?

커넥터 릴레이는 조직의 메일 시스템을 인증하며 외부 수신자를 지원할 수 있습니다. Direct Send는 커넥터 없이 테넌트 MX 엔드포인트를 사용하며 내부 수신자를 대상으로 합니다.

모든 메일함에 SMTP AUTH를 활성화해야 하나요?

아니요. Microsoft는 조직 전체에서 비활성화하고 여전히 필요한 메일함에만 활성화하도록 권장하며, 최신 인증과 지원되는 대안을 우선하라고 안내합니다.

Office 365 SMTP가 메일을 접수했다면 받은편지함에 전달된 것인가요?

아니요. 접수는 범위가 한정된 전송 결과입니다. 이후의 전달, 미전달, 수신 측 필터링, 메일함 폴더 배치, 사람의 참여는 각각 별도의 증거로 남습니다.

애플리케이션이 Microsoft 클라이언트 제출에 465번 포트를 사용할 수 있나요?

Microsoft의 현재 가이드에 따르면, 기본값이 465번 포트인 장치는 이 Microsoft 365 경로에 필요한 클라이언트 제출 TLS 버전을 지원하지 않습니다.

Microsoft 365 SMTP 구성은 어디에서 검증해야 하나요?

프로덕션 이메일에 의존하기 전에 최신 Microsoft Learn 문서를 사용하고 테넌트에서 선택한 경로를 테스트하세요.

출처

더 알아보기

SMTP 릴레이 서비스 평가 방법제출 보안, 인증, 큐, 재시도 동작, 한도, 전송 이벤트, 발송 제외 처리, 격리, 마이그레이션 적합성을 기준으로 SMTP 릴레이 서비스를 평가하세요.Google SMTP 릴레이 서비스 평가 가이드권한 부여 모델, TLS, 발신자 ID, 할당량, 오류 처리, 인증, 관측 가능성, 마이그레이션 위험을 기준으로 Google Workspace SMTP 릴레이를 평가하세요.SMTP 메일 프로토콜: 애플리케이션 이메일이 이동하는 방식SMTP 제출, 릴레이, 엔벨로프, 응답 코드, TLS, 재시도, 메시지 내용이 애플리케이션 이메일 워크플로를 어떻게 형성하는지 알아보세요.SMTP 포트 25, 465, 587 실전 가이드역할과 TLS 모드에 맞는 SMTP 포트를 고른 뒤, 연결, 핸드셰이크, 인증, 메시지 수락 실패를 진단하세요.이메일 전달성 서비스 평가 방법범위, 증거, 인증, 피드백 루프, 발송 제외 처리, 개인정보 보호, 이식성, 운영 적합성을 기준으로 이메일 전달성 서비스를 평가하세요.