SMTP
IT 위키
Simple Mail Transfer Protocol(SMTP)는 인터넷 전자우편을 전송·중계·제출하기 위해 사용되는 응용 계층 프로토콜이다.
SMTP는 인터넷에서 이메일을 보내기 위해 이용되는 프로토콜이다. 현대까지 널리 사용되는 프로토콜로, TCP 25번의 잘 알려진 포트를 사용하고 있다.[1][2]
- 주로 이메일을 보내는 데 사용되며, 수신된 이메일을 저장하고 관리하는 것은 다른 프로토콜(IMAP, POP3 등)이 담당한다.
- 이메일 전송: SMTP는 클라이언트가 작성한 이메일을 지정된 수신자의 이메일 서버로 전달한다. 이 과정에서 발신자 주소, 수신자 주소, 메일 본문 등을 서버로 보내는 역할을 한다.
- 텍스트 기반 프로토콜: SMTP는 텍스트 기반의 명령어를 사용하여 통신한다. 각 명령어는 서버와 클라이언트 간의 명확한 대화를 가능하게 한다. 예를 들어, HELO(서버에 인사), MAIL FROM(발신자 지정), RCPT TO(수신자 지정), DATA(이메일 본문 전송) 등의 명령어가 사용된다.
- 연결 설정: SMTP는 이메일을 전송하기 전에 클라이언트와 서버 간에 TCP 연결을 설정하고, 전송이 완료된 후에는 연결을 종료한다. 보통 포트 25번을 사용하여 통신하지만, 보안이 강화된 SMTP over TLS 또는 메일 제출 용도에서는 465번과 587번 포트도 사용된다.[3][4]
- 다중 수신자 지원: SMTP는 한 번에 여러 명의 수신자에게 이메일을 보낼 수 있다. 여러 명의 수신자를 지정할 때, CC(Carbon Copy)나 BCC(Blind Carbon Copy)를 사용하여 각각의 수신자에게 메일을 전달할 수 있다.
- 스팸 필터링 및 인증: 현대 SMTP 서버는 스팸 메일을 필터링하거나, 발신자 인증을 통해 보안을 강화하는 기능도 추가로 지원한다. 인증되지 않은 사용자가 서버를 통해 이메일을 보내는 것을 방지하기 위해 SPF(Sender Policy Framework), DKIM(DomainKeys Identified Mail), DMARC(Domain-based Message Authentication, Reporting & Conformance) 등의 기술을 함께 사용한다.[5][6][7]
- 클라이언트와 서버 간 연결: 이메일 클라이언트가 SMTP 서버에 연결을 요청하고, 서버는 이를 받아들인다.
- 이메일 전송: 클라이언트는 이메일 발신자 정보, 수신자 정보, 본문 등의 데이터를 SMTP 명령어를 사용하여 서버에 전달한다.
- 이메일 수신자 서버로 전달: SMTP 서버는 수신자의 도메인을 확인한 후, 해당 수신자의 이메일 서버로 이메일을 전송한다.
- 연결 종료: 이메일이 성공적으로 전송되면 SMTP 서버는 클라이언트와의 연결을 종료한다.
- TCP 연결 설정: 클라이언트와 서버 간 TCP 3-way handshake로 연결 설정.
- EHLO/HELO: 클라이언트가 서버에 자신을 소개.
- 클라이언트가 서버에 연결을 설정한 후, HELO(또는 EHLO) 명령어를 통해 자신을 서버에 소개한다.
- HELO는 SMTP 초기 명령어이고, EHLO는 확장된 기능을 지원하는 경우 사용된다.
- C: EHLO example.com
- S: 250-Hello example.com
- S: 250-SIZE 35882577
- S: 250-8BITMIME
- S: 250-STARTTLS
- S: 250 OK
- MAIL FROM: 발신자 이메일 주소 전송.
- C: MAIL FROM:<[email protected]>
- S: 250 OK
- RCPT TO: 수신자 이메일 주소 전송.
- C: RCPT TO:<[email protected]>
- S: 250 OK
- C: RCPT TO:<[email protected]>
- S: 250 OK
- DATA: 이메일 본문과 헤더 전송, 마지막에 마침표로 전송 완료 알림.
- C: DATA
- S: 354 Start mail input; end with <CRLF>.<CRLF>
- C: From: [email protected]
- C: To: [email protected], [email protected]
- C: Subject: Test email
- C:
- C: This is the body of the email.
- C: .
- S: 250 OK: queued as 12345
- QUIT: 연결 종료 명령 전송.
- C: QUIT
- S: 221 Bye
- TCP 연결 종료: 클라이언트와 서버 간 TCP 4-way handshake로 연결 종료.
SMTP 명령어는 클라이언트가 서버에 요청을 보내고, 서버가 숫자 응답 코드와 설명을 반환하는 방식으로 동작한다. 기본 명령과 확장 기능의 골격은 RFC 5321에서 정의한다.[8]
| 명령어 | 용도 |
|---|---|
| HELO | 클라이언트가 서버에 자신을 알리는 기본 인사 명령 |
| EHLO | 확장 SMTP(ESMTP) 기능을 확인하기 위한 인사 명령 |
| MAIL FROM | SMTP envelope의 발신자 경로 지정 |
| RCPT TO | SMTP envelope의 수신자 지정. 여러 수신자에게 보낼 경우 반복 사용 |
| DATA | 메시지 헤더와 본문 전송 시작 |
| RSET | 현재 메일 트랜잭션을 취소하고 연결은 유지 |
| VRFY | 특정 사용자 또는 사서함의 존재 여부 확인 요청 |
| EXPN | 메일링 리스트나 별칭의 확장 결과 확인 요청 |
| NOOP | 연결 상태 확인용 무동작 명령 |
| QUIT | SMTP 세션 종료 |
| STARTTLS | 평문 연결을 TLS 연결로 전환 |
| AUTH | SMTP 인증 수행 |
VRFY와 EXPN은 사용자 계정이나 메일링 리스트 정보를 노출할 수 있으므로, 공개 SMTP 서버에서는 비활성화하거나 제한하는 경우가 많다.
SMTP 응답 코드는 세 자리 숫자로 표현되며, 첫 번째 숫자가 응답의 큰 범주를 나타낸다.
| 코드 범위 | 의미 | 예 |
|---|---|---|
| 2xx | 성공 | 250 OK |
| 3xx | 추가 입력 필요 | 354 Start mail input |
| 4xx | 일시적 실패. 이후 재시도 가능 | 421 Service not available, 450 Mailbox unavailable |
| 5xx | 영구 실패. 같은 조건에서는 재시도해도 실패 가능 | 550 Mailbox unavailable, 554 Transaction failed |
확장 상태 코드는 X.Y.Z 형태로 표현되며, 배달 실패 사유를 더 세밀하게 전달하는 데 사용된다.[9]
SMTP는 사용 목적에 따라 서로 다른 포트를 사용한다.
| 포트 | 명칭 | 주 용도 |
|---|---|---|
| TCP 25 | smtp | 메일 서버 간 전송 및 중계 |
| TCP 587 | submission | 메일 클라이언트가 인증 후 메일을 제출하는 용도 |
| TCP 465 | submissions | TLS가 즉시 적용되는 메일 제출 용도 |
RFC 6409는 메일 전송(message relay)과 메일 제출(message submission)을 분리하고, 메일 제출은 일반적으로 587번 포트를 사용한다고 설명한다.[10] RFC 8314는 전자우편 제출 및 접근에서 평문 사용을 오래된 방식으로 보고 TLS 사용을 권고하며, submissions 서비스의 포트 465 사용을 정리한다.[11]
SMTP는 초기 설계상 개방적이고 단순한 메일 전달을 목표로 했기 때문에, 현대 인터넷 환경에서는 다음과 같은 보안 문제가 발생할 수 있다.
| 취약점 | 설명 | 대응 |
|---|---|---|
| 오픈 릴레이 | 인증되지 않은 외부 사용자가 서버를 통해 임의의 메일을 중계할 수 있는 설정 오류 | 릴레이 대상 제한, SMTP AUTH, 네트워크 접근 제어 |
| 발신자 주소 위조 | MAIL FROM, From 헤더, HELO/EHLO 도메인을 임의로 작성할 수 있음 | SPF, DKIM, DMARC 적용 |
| 평문 전송 | 기본 SMTP는 평문으로 명령과 메시지를 주고받을 수 있음 | STARTTLS, implicit TLS, MTA-STS, DANE 적용 |
| STARTTLS 다운그레이드 | 공격자가 STARTTLS 광고를 제거하거나 TLS 협상을 방해해 평문 전송을 유도 | MTA-STS, DANE, TLS-RPT 적용 |
| 계정 열거 | VRFY, EXPN, 수신자 검증 응답 차이를 통해 사용자 존재 여부 추정 가능 | VRFY/EXPN 제한, 동일한 오류 응답 정책 |
| 스팸 및 피싱 악용 | 대량 발송, 도메인 사칭, 악성 링크 전파에 악용 가능 | 평판 기반 필터링, 인증 정책, 발송량 제한 |
| 무차별 대입 공격 | SMTP AUTH 계정에 대한 비밀번호 추측 공격 가능 | 계정 잠금, 속도 제한, 다중 인증, 강한 인증 방식 |
| 역산란 메일 | 위조된 반송 주소로 인해 무관한 사용자에게 반송 메일이 대량 전송됨 | 수신 단계 거부, SPF/DMARC 검증, 반송 정책 정비 |
- STARTTLS: 기존 SMTP 연결에서 STARTTLS 명령을 사용해 TLS 보안 채널로 전환한다. RFC 3207은 SMTP 클라이언트와 서버가 TLS를 사용해 통신을 보호할 수 있도록 하는 확장을 정의한다.[12]
- SMTP AUTH: SMTP 클라이언트가 서버에 인증 메커니즘을 제시하고 인증 절차를 수행할 수 있게 하는 확장이다. RFC 4954는 SMTP에 SASL 기반 인증을 적용하는 방식을 정의한다.[13]
- SPF: 도메인 소유자가 해당 도메인 이름으로 메일을 보낼 수 있는 호스트를 DNS에 게시하고, 수신 서버가 이를 검증한다.[14]
- DKIM: 발신 도메인이 메시지에 전자서명을 부여하고, 수신 서버가 DNS에 게시된 공개키로 서명을 검증한다.[15]
- DMARC: SPF와 DKIM 검증 결과를 도메인 정책과 연결하고, 실패한 메시지의 처리 방식과 보고 체계를 제공한다.[16]
- MTA-STS: 수신 도메인이 TLS 지원 여부와 정책을 게시하여, 송신 MTA가 신뢰 가능한 인증서를 가진 TLS 연결을 사용하도록 요구할 수 있게 한다.[17]
- DANE for SMTP: DNSSEC으로 보호되는 TLSA 레코드를 이용해 SMTP 서버의 TLS 인증을 강화한다.[18]
- SMTP TLS Reporting(TLS-RPT): STARTTLS, DANE, MTA-STS 등의 TLS 관련 실패를 보고하여 설정 오류나 공격 가능성을 파악할 수 있게 한다.[19]
- ↑ 《RFC 5321: Simple Mail Transfer Protocol》, https://datatracker.ietf.org/doc/html/rfc5321, 확인일: 2026-06-08.
- ↑ 《IANA Service Name and Transport Protocol Port Number Registry》, https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=smtp, 확인일: 2026-06-08.
- ↑ 《IANA Service Name and Transport Protocol Port Number Registry: 587》, https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=587, 확인일: 2026-06-08.
- ↑ 《IANA Service Name and Transport Protocol Port Number Registry: 465》, https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=465, 확인일: 2026-06-08.
- ↑ 《RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1》, https://datatracker.ietf.org/doc/html/rfc7208, 확인일: 2026-06-08.
- ↑ 《RFC 6376: DomainKeys Identified Mail (DKIM) Signatures》, https://datatracker.ietf.org/doc/html/rfc6376, 확인일: 2026-06-08.
- ↑ 《RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)》, https://datatracker.ietf.org/doc/html/rfc7489, 확인일: 2026-06-08.
- ↑ 《RFC 5321: Simple Mail Transfer Protocol》, https://datatracker.ietf.org/doc/html/rfc5321, 확인일: 2026-06-08.
- ↑ 《RFC 5248: A Registry for SMTP Enhanced Mail System Status Codes》, https://datatracker.ietf.org/doc/html/rfc5248, 확인일: 2026-06-08.
- ↑ 《RFC 6409: Message Submission for Mail》, https://datatracker.ietf.org/doc/html/rfc6409, 확인일: 2026-06-08.
- ↑ 《RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access》, https://datatracker.ietf.org/doc/html/rfc8314, 확인일: 2026-06-08.
- ↑ 《RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security》, https://datatracker.ietf.org/doc/html/rfc3207, 확인일: 2026-06-08.
- ↑ 《RFC 4954: SMTP Service Extension for Authentication》, https://datatracker.ietf.org/doc/html/rfc4954, 확인일: 2026-06-08.
- ↑ 《RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1》, https://datatracker.ietf.org/doc/html/rfc7208, 확인일: 2026-06-08.
- ↑ 《RFC 6376: DomainKeys Identified Mail (DKIM) Signatures》, https://datatracker.ietf.org/doc/html/rfc6376, 확인일: 2026-06-08.
- ↑ 《RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)》, https://datatracker.ietf.org/doc/html/rfc7489, 확인일: 2026-06-08.
- ↑ 《RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)》, https://datatracker.ietf.org/doc/html/rfc8461, 확인일: 2026-06-08.
- ↑ 《RFC 7672: SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)》, https://datatracker.ietf.org/doc/html/rfc7672, 확인일: 2026-06-08.
- ↑ 《RFC 8460: SMTP TLS Reporting》, https://datatracker.ietf.org/doc/html/rfc8460, 확인일: 2026-06-08.
