용어 · SMTP 메일 프로토콜

메일 프로토콜 SMTP란 무엇이며 애플리케이션 이메일에 어떤 영향을 주나요?

SMTP(Simple Mail Transfer Protocol)는 메일 시스템이 발신 이메일을 제출하고, 릴레이하고, 넘겨줄 때 사용하는 표준 기반 프로토콜입니다. 애플리케이션은 보통 완성된 메시지를 인증된 제출 서비스에 전달하고, 이후 메일 서버가 SMTP 명령과 DNS 라우팅으로 각 수신자를 향해 메시지를 이동시킵니다. SMTP 응답은 특정 홉이 수신자를 수락했는지 거부했는지 알려 주지만, 수락이 받은편지함 도달과 같지는 않습니다. 애플리케이션에는 여전히 지속형 큐, 안전한 재시도, 메시지 식별자, 인증, 반송 처리가 필요합니다.

SMTP는 책임 있는 시스템 간에 메일을 전송합니다

SMTP는 저장 후 전달(store-and-forward) 방식의 전송 프로토콜입니다. 클라이언트가 서버와 세션을 열고, 자신을 식별하고, 엔벨로프 발신자를 제시하고, 하나 이상의 엔벨로프 수신자를 제안하며, 서버가 수신에 동의한 뒤 메시지 내용을 전송합니다. 서버는 일부 수신자는 수락하고 다른 수신자는 거부할 수 있으므로, 상태는 메시지 전체가 아니라 수신자와 트랜잭션에 속합니다. 서버가 책임을 넘겨받으면 로컬에서 전달하거나, DNS Mail Exchanger 레코드로 선택한 다른 시스템으로 메시지를 릴레이할 수 있습니다. 이러한 홉 단위 설계 때문에 애플리케이션은 이메일 상태를 하나의 sent 불리언으로 축소해서는 안 됩니다. 애플리케이션, 제출 서비스, 릴레이, 수신 서버, 메일함 필터링 시스템은 각각 결과의 서로 다른 부분을 알고 있습니다. SMTP는 시스템 간에 메시지를 옮기고, 제품 수준의 레코드와 제공업체 이벤트는 그 이동을 사용자와 운영자가 이해할 수 있게 해 줍니다.

제출과 릴레이는 서로 다른 프로토콜 역할입니다

RFC 6409는 메시지 제출과 메시지 릴레이를 구분합니다. 제출은 권한이 있는 사용자나 애플리케이션이 Message Submission Agent에 처음 넘기는 단계이며 보통 587번 포트를 사용합니다. 릴레이는 Message Transfer Agent 간의 전송이며 관례적으로 25번 포트를 사용합니다. 제출 서비스는 새 메일을 누가 만드는지 알기 때문에 인증을 요구하고, 메시지 필드를 검증하거나 보완하고, 발신자 정책을 적용할 수 있습니다. 공개 릴레이 서버는 다른 도메인과 상호 운용되어야 하며 다른 신뢰 규칙을 따릅니다. 따라서 애플리케이션 코드는 수신 서버에 임의로 25번 포트 연결을 열지 말고, 제공업체가 문서로 안내한 제출 엔드포인트에 연결하거나 HTTP API를 사용해야 합니다. 이러한 구분은 자격 증명의 의미도 분명히 합니다. SMTP 사용자 이름이나 토큰은 특정 서비스에 대한 제출을 승인할 뿐, 수신 도메인에 대한 권한을 부여하지 않습니다. 제출 자격 증명은 서버 측에 보관하고, 제공업체가 지원하면 발송 워크로드로 범위를 제한하고, 메시지 내용이나 클라이언트 소프트웨어에 포함하지 않은 채 교체하세요.

SMTP 엔벨로프는 화면에 보이는 메시지 헤더와 다릅니다

SMTP 트랜잭션은 `MAIL FROM`과 하나 이상의 `RCPT TO` 명령으로 이루어진 엔벨로프를 전달합니다. 전송되는 내용은 별도로 RFC 5322가 정의한 인터넷 메시지 형식을 따르며, From, To, Date, Subject, Message-ID 같은 필드와 본문으로 구성됩니다. MIME 표준은 HTML, 대체 파트, 첨부 파일, 비ASCII 데이터를 위해 이 내용을 확장합니다. 엔벨로프 발신자는 전송 실패에 사용되는 주소이며 화면에 보이는 From 작성자와 다를 수 있습니다. Bcc처럼 엔벨로프 수신자도 보이는 To와 Cc 필드와 다를 수 있습니다. 신뢰할 수 없는 문자열을 이어 붙여서 이러한 구조를 만들지 마세요. 유지 관리되는 메시지 라이브러리를 사용하고, 주소를 검증하고, 헤더 필드에 줄바꿈이 주입되지 않도록 막고, 안정적인 Message-ID를 보존하세요. 문제를 해결할 때는 두 계층을 모두 확인하세요. 올바른 From 필드가 승인되지 않은 엔벨로프 ID를 고쳐 주지 못하고, 유효한 엔벨로프가 잘못된 MIME이 올바르게 표시되게 해 주지도 않습니다.

트랜잭션을 상태 머신으로 읽기

기본적인 Extended SMTP 세션은 서버 인사말로 시작한 다음, 서버가 확장 기능을 알릴 수 있도록 `EHLO`를 보냅니다. 제출을 위해 클라이언트는 TLS와 인증을 협상할 수 있습니다. 이후 메일 트랜잭션은 `MAIL FROM`, 수신 대상마다 하나의 `RCPT TO`, `DATA`, SMTP 프레이밍에 맞게 종료되는 전체 메시지, `QUIT`를 사용합니다. 이 예를 근거로 와이어 프로토콜을 직접 구현하지는 마세요. 성숙한 SMTP 라이브러리가 줄 끝, 점 투명성(dot transparency), 기능 협상, 인증, TLS 상태를 더 안전하게 처리합니다. 자격 증명이나 전체 메시지 본문은 로그에 남기지 않으면서, 라이브러리를 명령 범주와 응답 코드 수준으로 계측하세요. 어떤 수신자가 어느 단계에서 실패했는지, 서버가 메시지 데이터를 받은 뒤 책임을 넘겨받았는지를 기록하세요. 이 경계에 따라 재시도가 적절한지, 중복 가능성이 있는지, 즉각적인 응답이 아니라 나중에 오는 전송 상태 알림이 실패를 알릴지가 정해집니다.

재시도를 결정하기 전에 응답 코드 분류하기

SMTP 응답 클래스는 취해야 할 동작을 나타냅니다. 2xx 응답은 해당 명령이 성공적으로 완료되었음을 뜻합니다. 4xx 응답은 일시적인 부정 완료이므로, 큐에 넣은 발신자는 지연 후 재시도할 수 있습니다. 5xx 응답은 시도한 명령에 대한 영구적인 부정 완료이며, 보통 반복 재시도가 아니라 수정, 발송 제외 처리, 사람의 조사가 필요합니다. 확장 상태 코드는 주소, 메일함, 시스템, 라우팅, 프로토콜, 콘텐츠, 보안 및 정책 조건에 대한 구조화된 `X.Y.Z` 진단을 더합니다. 숫자 코드와 서버 텍스트는 모두 진단 가치가 있으므로 함께 보존하되, 수신자 데이터가 포함된 원본 응답을 폭넓게 노출하지는 마세요. 일시적인 실패에는 지터가 포함된 지수 백오프와 최대 큐 수명을 적용하세요. 일시적인 수신처 문제를 악용에 가까운 트래픽으로 만들 만큼 공격적으로 재시도하지 마세요. 영구적인 주소 실패라면 해당 수신처로의 자동 발송을 중단하고 발송 제외 상태를 갱신하세요. 정책이나 인증 실패라면 다시 시도하기 전에 ID, DNS, 자격 증명, 콘텐츠를 고치세요.

암호화되고 인증된 제출 사용하기

SMTP는 신뢰 가정이 서로 다른 네트워크를 가로지르는 전송 프로토콜로 출발했기 때문에, 안전한 제출은 확장 기능과 배포 정책에 의존합니다. STARTTLS는 SMTP 연결을 TLS로 업그레이드하며, 이후 클라이언트는 핸드셰이크 이전에 파악한 기능을 폐기하고 `EHLO`를 다시 보내야 합니다. RFC 8314는 평문 접근과 제출을 폐기 대상으로 보고 제출에 암시적 TLS를 사용하도록 설명하며 제출 지침을 갱신합니다. RFC 4954에서 표준화된 SMTP AUTH는 제출 서버가 알린 메커니즘으로 클라이언트를 인증하게 합니다. 조합을 추측하지 말고 제공업체의 현재 호스트 이름, 포트, TLS 모드, 인증 안내를 사용하세요. 서버 인증서를 검증하고, 워크로드가 보호된 제출을 요구한다면 평문으로 조용히 되돌아가지 마세요. 비밀번호나 토큰은 시크릿 관리자에 보관하고, 환경별로 자격 증명을 분리하고, 폐기된 인증 메커니즘은 비활성화하세요. TLS는 연결의 한 홉을 보호하지만, 모든 다운스트림 수신자에게 메시지 작성자를 인증하거나 SPF, DKIM, DMARC의 ID 정렬을 대체하지는 않습니다.

애플리케이션 이메일 실패를 홉 단위로 진단하기

애플리케이션의 지속형 발신 레코드부터 시작하세요. 제품 이벤트가 승인되었는지, 큐에 있는 작업 하나만 이를 가져갔는지 확인합니다. 다음으로 제출 단계를 점검하세요. DNS 확인, TCP 연결, TLS 협상, 인증서 검증, 인증, 엔벨로프 발신자 승인, 수신자별 응답, 최종 DATA 응답이 대상입니다. 제출 서비스가 메시지를 접수했다면 요청을 무작정 재전송하지 말고 해당 메시지 식별자와 이벤트 스트림을 따라가세요. 제공업체가 처리한 상태와 수신 서버가 수락한 상태를 구분하세요. 초기 접수 이후에도 나중에 반송이 영구 실패를 알릴 수 있습니다. 수신 서버가 메시지를 수락했다면 SMTP 전송 실패라고 부르지 말고 인증 결과, 평판, 수신자 정책, 콘텐츠, 메일함 분류를 조사하세요. 엔벨로프와 헤더 ID를 모두 확인하고, 타임스탬프, 응답 코드, 큐 시도 횟수, 제공업체 식별자를 보관하세요. 테스트에는 통제된 수신자를 사용하세요. 프로덕션 SMTP 자격 증명이나 고객 메시지 전문을 티켓, 프롬프트, 터미널 기록, 공개 진단 도구에 붙여 넣지 마세요.

접수, 전달, 받은편지함 도달 구분하기

제품 인터페이스에서는 프로토콜의 정확성이 중요합니다. 애플리케이션 접수는 로컬 시스템이 요청을 기록했다는 뜻입니다. 제출 접수는 첫 번째 메일 서비스가 처리 책임을 넘겨받았다는 뜻입니다. 수신 서버 전달은 수신처 SMTP 서버가 인계에 성공을 반환했다는 뜻입니다. 받은편지함 도달은 수신 환경 내부에서 이루어지는 이후의 정책 및 분류 결정입니다. 메시지가 한 상태를 통과하더라도 다음 상태에서 실패하거나 다르게 분류될 수 있습니다. SMTP는 현재 트랜잭션에 대한 직접적인 증거를 제공하고 나중에 전송 상태 알림이 생길 수도 있지만, 수신자의 최종 폴더는 알려 주지 않습니다. 모든 250 응답을 받은편지함 전달로 표시하지 말고 이러한 상태를 독립적으로 저장하세요. 수신처의 SMTP 성공 응답이 포함된 제공업체 이벤트는 서버 전달 상태를 뒷받침할 수 있습니다. 반송은 실패 또는 발송 제외 처리를 뒷받침합니다. 어느 쪽도 노출, 열람, 참여에 대한 약속을 뒷받침하지는 않습니다. 이 모델은 상태를 정직하게 유지하고, 책임이 이미 넘어간 뒤에 안전하지 않은 재시도가 일어나는 것을 막아 줍니다.

SendHQ의 문서화된 API 사용

애플리케이션은 제공업체 라이브러리를 통해 SMTP를 사용하거나, 제공업체가 해당 인터페이스 아래에서 인터넷 메일 전송을 처리하는 HTTP 이메일 API를 호출할 수 있습니다. SendHQ는 검증된 도메인 확인, 발신 및 수신 메시지 리소스, 이벤트, 발송 제외, 수신함, 워크스페이스 리소스 경계를 갖춘 워크스페이스 단위 이메일 API를 제공합니다. HTTP API는 직접 SMTP 제출과 함께 구조화된 요청, 식별자, 이벤트를 제공할 수 있습니다. 대상 서버 동작을 변경하거나 SMTP 수락, 받은편지함 도달, 수신자 참여를 확립하지는 않습니다.

자주 묻는 질문

SMTP는 무엇의 약자인가요?

SMTP는 Simple Mail Transfer Protocol의 약자입니다. 명령, 응답, 엔벨로프, 메시지 데이터, 그리고 인증과 TLS 같은 기능을 위한 확장을 통해 메일 클라이언트와 서버가 발신 메시지를 제출하고 전송하는 방식을 정의합니다.

SMTP로 받은편지함의 이메일을 읽나요?

아니요. SMTP는 주로 발신 메일을 제출하고 전송하기 위한 프로토콜입니다. 받은편지함 접근에는 IMAP, POP, 제공업체별 메일함 API, 저장된 수신 메시지를 노출하는 애플리케이션 이메일 API 같은 다른 인터페이스를 사용합니다.

25번, 587번, 465번 포트는 무엇이 다른가요?

25번 포트는 관례적으로 서버 간 릴레이에 사용됩니다. 587번 포트는 표준 메시지 제출 서비스이며 보통 TLS를 협상합니다. 465번 포트는 암시적 TLS 기반 제출용으로 등록되어 있습니다. 포트를 임의로 바꿔 가며 시도하지 말고 제공업체가 문서로 안내하는 엔드포인트와 보안 모드를 따르세요.

SMTP 성공은 이메일이 받은편지함에 도착했다는 증거인가요?

아니요. 성공 응답은 응답한 SMTP 서버가 해당 명령이나 메시지에 대한 책임을 수락했다는 것만 증명합니다. 수신 시스템은 이후에도 정책을 적용하거나, 지연된 실패를 생성하거나, 수락한 메일을 기본 받은편지함 밖으로 분류할 수 있습니다.

애플리케이션은 4xx SMTP 응답을 모두 재시도해야 하나요?

4xx 코드는 일시적인 부정 결과를 나타내지만, 재시도에는 지속형 큐, 지터가 포함된 지수 백오프, 유한한 수명, 수신자를 고려한 시도 한도를 사용해야 합니다. 무한정 재시도하지 말고 반복되는 일시 실패를 조사하세요.

HTTP 이메일 API는 SMTP를 대체하나요?

애플리케이션 코드에서는 SMTP를 대체할 수 있지만, 제공업체는 보통 수신자의 메일 시스템과 통신할 때 여전히 SMTP를 사용합니다. API는 전송 계층 위에 구조화된 인증, 페이로드, 리소스 범위 지정, 식별자, 이벤트 처리를 더합니다.

출처

더 알아보기

제품 팀을 위한 이메일 API 구현 가이드검증된 도메인, 큐를 통한 발송, 안정적인 식별자, 통제된 재시도, 전송 이벤트, 발송 제외 처리, 테넌트 격리를 갖춘 안전한 이메일 API 연동을 설계하세요.