용어 · smtp 포트

애플리케이션은 이메일에 어떤 SMTP 포트를 사용해야 하나요?

대부분의 애플리케이션은 이메일 제공업체가 문서화한 제출 엔드포인트와 포트를 사용해야 합니다. 포트 587은 표준 메시지 제출 포트이며 보통 STARTTLS 업그레이드 전 일반 SMTP로 시작합니다. 포트 465는 암시적 TLS를 사용하는 메시지 제출이므로 TLS 핸드셰이크가 즉시 시작됩니다. 포트 25는 일반적인 인증 애플리케이션 제출이 아니라 주로 서버 간 SMTP 릴레이용입니다. 작동하는 구성은 호스트 이름, 포트, TLS 모드, 인증 방법 네 가지가 함께 일치해야 합니다.

SMTP 포트는 프로토콜 역할과 연결 모드를 선택합니다

포트 번호는 같은 서비스로 통하는 서로 바꿔 쓸 수 있는 문이 아닙니다. 서버가 어떤 SMTP 역할을 제공하는지, 연결이 어떻게 시작되는지를 구분하는 데 도움이 됩니다. 메시지 제출은 애플리케이션이나 사용자 에이전트가 제출 서비스로 처음 넘기는 단계입니다. 릴레이는 메일 서버 사이의 메일 전송입니다. 표준이 이 둘을 분리하는 이유는, 제출에는 인증, 발신자 승인, 메시지 정책 검사가 필요할 수 있는데 공개 메일 릴레이에는 이것이 같은 방식으로 적용되지 않기 때문입니다. 포트는 클라이언트가 SMTP 명령으로 시작해 나중에 STARTTLS로 업그레이드하는지, 아니면 곧바로 TLS 핸드셰이크로 시작하는지도 나타낼 수 있습니다. 제공업체의 호스트 이름, 포트, TLS 모드, 인증 지침을 하나의 구성 묶음으로 취급하세요. 관련 없는 제공업체의 포트를 복사하거나 오류가 난 뒤 포트만 바꾸면, 원래 원인은 고치지 못한 채 네트워크 문제가 TLS 또는 인증 실패로 바뀔 수 있습니다.

25번 포트는 주로 메일 서버 릴레이용입니다

25번 포트는 한 메시지 전송 에이전트(MTA)가 다른 MTA로 메일을 넘길 때 사용하는 관례적인 SMTP 릴레이 포트입니다. RFC 6409는 릴레이를 25번 포트에 두고 새 메시지 제출을 587번 포트로 분리합니다. 따라서 애플리케이션은 수신자의 메일 서버로 25번 포트 직접 연결을 하는 것이 제품 이메일을 보내는 일반적인 방법이라고 가정해서는 안 됩니다. 직접 릴레이에는 큐잉, DNS 라우팅, 반송 처리, 남용 통제, 평판 관리, 표준을 준수하는 재시도 동작이 필요합니다. 네트워크와 호스팅 제공업체가 아웃바운드 25번 포트를 제한할 수도 있습니다. 예를 들어 AWS는 Amazon EC2의 25번 포트 이메일 트래픽을 기본적으로 제한한다고 문서화하고 있습니다. 25번 포트가 제공업체나 통제된 인프라 내부에서 문서화된 옵션일 수는 있지만, 사용할 수 있다고 해서 선호되는 제출 선택지가 되는 것은 아닙니다. 담당 서비스가 해당 엔드포인트, 보안 모드, 운영 모델을 명시적으로 문서화한 경우에만 사용하세요.

587번 포트는 표준 메시지 제출 포트입니다

RFC 6409는 587번 포트를 메시지 제출용으로 예약하고, 인증되지 않은 메일을 거부하고, 인증을 요구하고, 새 메시지를 수락하기 전에 정책을 적용할 수 있는 제출 서비스를 설명합니다. 일반적인 587번 포트 세션은 SMTP로 시작해 `EHLO` 이후 STARTTLS 확장을 알리고, 연결을 TLS로 업그레이드하고, `EHLO`를 다시 보내고, 인증한 다음 메시지를 제출합니다. 일반적이라는 말이 중요합니다. 정확한 인증 메커니즘과 요구 사항은 제공업체의 최신 문서와 서버의 기능에 따릅니다. 안전한 클라이언트는 예상되는 TLS 업그레이드를 필수로 요구하고 서버 인증서를 검증해야 하며, 협상이 실패한 뒤 평문으로 계속 진행해서는 안 됩니다. 처음의 암호화되지 않은 프로토콜 인사를 보호되지 않은 인증 세션과 혼동하지 마세요. STARTTLS는 자격 증명과 메시지 데이터를 보내기 전에 그 연결을 업그레이드하도록 설계되었습니다. 587번 포트는 제출 서비스를 식별할 뿐이며, TLS를 성공적으로 강제하는지는 올바른 클라이언트 정책에 달려 있습니다.

465번 포트는 제출에 암시적 TLS를 사용합니다

465번 포트는 암시적 TLS를 통한 메시지 제출용으로 등록되어 있습니다. 암시적 TLS에서는 TCP 연결이 열리자마자 클라이언트가 TLS 핸드셰이크를 수행하고, 보호된 채널 안에서만 SMTP 명령을 보냅니다. 이는 클라이언트가 먼저 SMTP 인사를 받은 뒤 업그레이드를 요청하는 STARTTLS 방식의 587번 포트와 다릅니다. RFC 8314는 제출에 암시적 TLS를 권장하면서도, 제공업체와 클라이언트가 암시적 TLS를 사용하는 465번 포트와 STARTTLS를 사용하는 587번 포트를 모두 지원할 수 있는 전환 상황을 설명합니다. 이 RFC는 TLS가 필수라면 올바르게 구현된 클라이언트와 서버가 어느 모드로든 실질적으로 동등한 보안을 제공할 수 있다고 언급합니다. 실용적인 규칙은 하나의 포트가 보편적으로 옳다고 선언하지 않는 것입니다. 제공업체가 지원하는 정확한 엔드포인트와 모드를 사용하세요. 암시적 TLS 리스너에 STARTTLS를 구성하거나, STARTTLS 리스너에 암시적 TLS를 구성하면 보통 인증 이전에 실패합니다.

제공업체별 대체 포트는 명시적인 계약입니다

일부 제공업체는 네트워크 제한을 우회하기 위해 대체 포트를 제공하지만, 이 번호는 모든 서비스에 통용되는 SMTP 표준이 아닙니다. Amazon SES는 현재 25, 587, 2587번 포트에서 STARTTLS를, 암시적 TLS를 가리키는 자체 용어인 TLS Wrapper를 465, 2465번 포트에서 제공한다고 문서화하고 있습니다. SES는 암호화된 연결을 요구하며 리전별 SMTP 엔드포인트를 게시합니다. 이는 포트를 일반적인 목록이 아니라 선택한 제공업체의 문서에서 가져와야 하는 이유를 보여 줍니다. 2587번 포트가 어디서나 STARTTLS를 뜻하지는 않으며, 2465번 포트가 임의의 호스트에서 암시적 TLS 서비스를 식별하지도 않습니다. 대체 포트가 발신자 검증, 자격 증명 범위, 할당량, 제공업체 정책을 우회해 주지도 않습니다. 운영자가 의도한 제공업체 설정과 몇 년 전에 환경 변수로 복사된 정체불명의 매직 넘버를 구별할 수 있도록, 프로덕션 구성에 출처 URL과 확인 날짜를 기록하세요.

호스트 이름, 포트, TLS, 인증을 함께 구성하세요

견고한 SMTP 구성은 하나의 묶음입니다. 제공업체 호스트 이름, 포트, 전송 보안 모드, 인증서 검증 정책, 인증 메커니즘, 사용자 이름, 시크릿, 연결 타임아웃, 발신 ID가 여기에 포함됩니다. TLS 인증서는 호스트 이름을 기준으로 검증되고 제공업체가 리전별로 다른 엔드포인트를 제공할 수 있으므로 호스트 이름이 중요합니다. 포트와 TLS 모드는 일치해야 합니다. 인증은 의도한 보호 채널이 만들어진 뒤에만 이루어져야 하며, 시크릿은 소스 코드, 브라우저 번들, 로그, 진단 출력이 아니라 시크릿 관리자에 두어야 합니다. 로컬 테스트가 실수로 프로덕션을 통해 발송되지 않도록 환경별로 자격 증명과 구성을 분리하세요. 유한한 연결 및 명령 타임아웃을 설정하되, 메시지 재시도는 내구성 있는 애플리케이션 큐가 제어하게 하세요. `secure`라는 라이브러리 옵션은 한 SDK에서는 암시적 TLS를 뜻하고 다른 SDK에서는 STARTTLS를 요구한다는 뜻일 수 있으므로, 옵션 이름에 의존하지 말고 라이브러리의 정의를 확인하고 협상된 동작을 테스트하세요.

시크릿을 노출하지 않고 연결을 계층별로 테스트하세요

애플리케이션과 같은 런타임 네트워크에서 DNS 확인과 TCP 도달 가능성부터 시작하세요. 연결 전에 타임아웃이 발생하면 라우팅, 방화벽, 제공업체의 이그레스 정책, 잘못된 호스트 이름, 닫힌 포트를 의심할 수 있습니다. 다음으로 예상되는 TLS 모드를 테스트하세요. 암시적 TLS에서는 TLS 클라이언트가 인증서를 받은 뒤 SMTP 인사를 받아야 합니다. STARTTLS에서는 SMTP를 이해하는 클라이언트가 인사를 받고, `EHLO`를 보내고, STARTTLS가 알려지는 것을 확인하고, 업그레이드를 요청하고, 인증서를 검증하고, TLS 이후 `EHLO`를 다시 보내야 합니다. RFC 3207은 클라이언트와 서버가 핸드셰이크 이전에 얻은 정보를 폐기하도록 요구하며, 그래서 두 번째 `EHLO`가 중요합니다. 그 후에야 통제된 계정으로 인증을 테스트하세요. 로그를 공유하기 전에 사용자 이름, 토큰, 수신자 주소, 전체 서버 트랜스크립트, 메시지 내용을 가리세요. 연결 확인용 프로브에는 프로덕션 발송이나 실제 고객 주소가 필요하지 않습니다.

실제로 실패한 단계별로 실패를 분류하세요

연결 거부는 TCP 대상이 연결을 적극적으로 거절했다는 뜻이고, 타임아웃은 제한 시간 안에 쓸 만한 응답이 도착하지 않았다는 뜻입니다. TLS 핸드셰이크 오류는 모드 불일치, 인증서 문제, 프로토콜 비호환, 가로채기, 또는 잘못된 엔드포인트를 가리킵니다. 인증 오류는 그 이후에 발생하며, 무작위로 포트를 바꿔서 해결할 것이 아니라 자격 증명, 메커니즘, 계정, 권한 구성 문제로 조사해야 합니다. `MAIL FROM`, `RCPT TO`, `DATA` 중의 SMTP 응답 코드는 그보다 더 나중 단계의 정책과 메시지 결정을 설명합니다. 단계, 타임스탬프, 엔드포인트, 시도 횟수, 숫자 응답 코드, 개인정보를 걸러 낸 응답을 보존하세요. 시도한 명령에 대해 SMTP 4xx 응답은 보통 일시적이고 5xx 응답은 보통 영구적이지만, 재시도에는 상한이 있어야 하고 수신자를 고려해야 합니다. 제공업체가 메시지 데이터를 접수했다면, 이후 애플리케이션 요청이 타임아웃되었다는 이유로 무작정 중복 제출하지 말고 제공업체 식별자와 이벤트 기록으로 대조하세요.

포트 연결 성공은 메시지 전달이나 받은편지함 도달이 아닙니다

TCP 연결이 성공했다는 것은 리스너가 응답했다는 것만 증명합니다. 인증서 검증이 성공했다면 TLS 핸드셰이크 성공은 인증된 엔드포인트에 대한 보호된 연결을 증명합니다. 인증은 서버가 해당 세션에서 제시된 클라이언트 ID를 수락했음을 증명합니다. 메시지 데이터 이후의 SMTP `250` 응답은 응답한 서버가 프로토콜에 따라 책임을 수락했다는 뜻이지, 사람이 메시지를 받았거나 읽었다는 뜻이 아닙니다. 이후의 릴레이가 실패할 수도 있고, 수신 시스템이 메일을 수락하고도 기본 받은편지함 밖으로 분류할 수도 있습니다. 애플리케이션 기록과 모니터링에서 이러한 상태를 구분해서 유지하세요. 네트워크 가용성, TLS 협상, 인증, 제공업체 접수, 대상 서버 접수, 반송, 스팸 신고, 참여도는 서로 다른 관찰입니다. 이렇게 구분하면 포트 프로브가 전달 테스트로 잘못 보고되는 것을 막고, 받은편지함 도달을 증명할 수 없다는 이유만으로 접수된 메시지가 재시도되는 것을 막습니다.

SMTP 제출과 이메일 API를 신중하게 선택하세요

시스템에 성숙한 SMTP 클라이언트가 있거나 필수 플랫폼이 지원 연동으로 SMTP를 노출하거나 프로토콜 수준 제어가 특별히 필요할 때 SMTP 제출을 사용하세요. 구조화된 요청, 범위 지정 토큰, 멱등성, 일괄 리소스, 기계 판독 가능한 이벤트 레코드가 워크로드에 맞으면 HTTPS 이메일 API가 더 나은 애플리케이션 경계가 될 수 있습니다. 제공업체는 수신자 메일 시스템에 도달하기 위해 다운스트림에서 SMTP를 계속 사용할 수 있으므로 API가 메일 전송을 없애지는 않습니다. 제공업체 대상 인계의 포트, TLS, 인증, 재시도 책임을 애플리케이션 SMTP 구성 밖으로 옮깁니다.

자주 묻는 질문

애플리케이션은 SMTP 587번 포트와 465번 포트 중 무엇을 써야 하나요?

제공업체가 문서화한 포트와 TLS 모드를 사용하세요. 587번 포트는 보통 STARTTLS를, 465번 포트는 암시적 TLS를 사용합니다. 올바르게 구현하고 필수로 적용하면 둘 다 제출을 보호할 수 있으며, 클라이언트 구성은 서버 리스너와 일치해야 합니다.

SMTP 25번 포트가 차단되거나 타임아웃되는 이유는 무엇인가요?

호스팅 플랫폼, ISP, 방화벽 또는 대상 정책이 25번 포트를 제한할 수 있습니다. 이 포트는 메일 서버 릴레이에 사용되며 남용이 잦기 때문입니다. 네트워크 정책을 확인하고, 임의의 포트로 제한을 우회하지 말고 제공업체가 문서화한 제출 엔드포인트를 사용하세요.

다른 것은 바꾸지 않고 587번 포트에서 465번 포트로 전환해도 되나요?

보통은 그렇지 않습니다. 587번 포트는 일반적으로 SMTP로 시작해 STARTTLS로 업그레이드하고, 465번 포트는 즉시 TLS 핸드셰이크로 시작합니다. 제공업체와 라이브러리 문서에 따라 포트와 클라이언트의 TLS 모드를 함께 바꾸세요.

587번 포트는 기본적으로 암호화되나요?

포트는 메시지 제출을 식별할 뿐이며, 암호화는 여전히 STARTTLS 협상과 클라이언트 정책에 달려 있습니다. 클라이언트가 업그레이드 성공을 필수로 요구하고, 인증서를 검증하고, 보호된 제출을 설정할 수 없으면 자격 증명이나 메시지 데이터의 전송을 거부하도록 구성하세요.

SMTP 연결 거부(connection refused)는 무엇을 의미하나요?

SMTP 협상 이전에 TCP 대상이 연결을 거부했다는 뜻입니다. 흔한 원인으로는 잘못된 호스트나 포트, 수신 대기 중이지 않은 서비스, 방화벽 거부, 해당 네트워크에서 사용할 수 없는 제공업체 엔드포인트가 있습니다.

SMTP 포트 테스트에 성공하면 이메일 전달이 증명되나요?

아니요. TCP나 TLS처럼 테스트가 실제로 완료한 단계만 증명합니다. 인증, 메시지 접수, 대상 서버 접수, 반송 처리, 메일함 분류, 수신자 참여도에는 각각 별도의 증거가 필요하며 별도로 보고해야 합니다.

출처

더 알아보기

SMTP 메일 프로토콜: 애플리케이션 이메일이 이동하는 방식SMTP 제출, 릴레이, 엔벨로프, 응답 코드, TLS, 재시도, 메시지 내용이 애플리케이션 이메일 워크플로를 어떻게 좌우하는지 알아봅니다.SMTP 릴레이 서비스를 평가하는 방법제출 보안, 인증, 큐, 재시도 동작, 한도, 전송 이벤트, 발송 제외 처리, 격리, 마이그레이션 적합성을 기준으로 SMTP 릴레이 서비스를 평가합니다.제품 팀을 위한 이메일 API 구현 가이드검증된 도메인, 큐 기반 발송, 안정적인 식별자, 통제된 재시도, 전송 이벤트, 발송 제외 처리, 테넌트 격리를 갖춘 안전한 이메일 API 연동을 설계합니다.이메일 전달성 서비스를 평가하는 방법범위, 증거, 인증, 피드백 루프, 발송 제외 처리, 개인정보 보호, 이식성, 운영 적합성을 기준으로 이메일 전달성 서비스를 평가합니다.