세 프로토콜 한눈에 비교
| 구분 | SMTP | POP3 | IMAP |
|---|---|---|---|
| 역할 | 메일 제출과 서버 간 전달 | 메일 내려받기 | 서버의 메일함을 원격으로 다루기 |
| 현행 문서 | RFC 5321 | RFC 1939 | RFC 9051 (이전 RFC 3501) |
| 평문 포트 | 25(서버 간), 587(제출, STARTTLS로 전환) | 110 | 143 |
| 처음부터 TLS | 465 | 995 | 993 |
| 읽음·폴더 상태 | 해당 없음 | 서버에 저장하지 않음 | 서버에 저장되어 기기 간 동기화 |
표의 포트는 RFC 8314와 위키백과 정리에서 확인한 값입니다. 587은 제출(submission) 포트로 RFC 6409에 정리되어 있고, 465는 한때 폐기된 것으로 취급되다가 RFC 8314에서 "암시적 TLS 제출" 포트로 다시 인정되었습니다.
STARTTLS와 암시적 TLS, 무엇이 다른가
STARTTLS(RFC 3207)는 평문으로 연결한 뒤 "암호화로 전환하자"고 제안하는 방식입니다. 서버가 제안하고 클라이언트가 받아들여야 하므로, 중간의 공격자가 제안 부분을 지워 평문 연결로 몰아가는 STRIPTLS 공격이 가능하다는 점이 알려져 있습니다. 암시적 TLS는 연결 즉시 TLS를 시작하므로 이런 다운그레이드 여지가 적습니다. RFC 8314는 암시적 TLS를 STARTTLS보다 우선하라고 권고하되, 전환 기간에는 클라이언트와 서버가 587의 STARTTLS와 465의 암시적 TLS를 모두 구현하라고 말합니다. 그래서 "465는 구식, 587이 정답" 같은 단정은 현재 표준 문서와 맞지 않습니다.
실제 사례
사례 1. 465번 포트의 부활 (표준이 방향을 바꾼 사례)
465번은 암호화된 SMTP를 위해 일찍부터 쓰이던 포트였는데, STARTTLS 방식이 표준으로 자리 잡으면서 공식적으로는 폐기된 것으로 취급되었습니다(위키백과 기준 RFC 2487 이후). 그럼에도 현장에서는 계속 쓰였습니다. RFC 8314는 이 현실과 "처음부터 암호화하는 편이 안전하다"는 판단을 반영해 465를 제출용 암시적 TLS 포트로 다시 인정했고, 이미 널리 쓰이던 포트라 IANA가 이례적으로 한 번 예외 등록을 했다고 문서에 적혀 있습니다. 배울 점은 포트 번호의 "정답"이 고정불변이 아니라 보안 환경과 표준 개정에 따라 바뀐다는 것입니다. 설정은 서비스 제공자의 최신 안내를 기준으로 합니다.
사례 2. 지메일의 발신자 요건 강화 (인증이 사실상 의무가 된 사례)
구글의 공식 발신자 가이드에 따르면 2024년 2월 1일부터 개인 지메일 계정으로 보내는 모든 발신자에게 SPF 또는 DKIM 설정, 유효한 정방향·역방향 DNS, TLS 사용 등이 요구되고, 하루 5,000통을 넘게 보내는 대량 발신자에게는 SPF·DKIM·DMARC를 모두 설정하고(DMARC 정책은 none이어도 됨) 구독 메일에 원클릭 수신 거부를 제공하도록 요구합니다. 스팸 신고율은 0.3% 미만이어야 한다고 명시되어 있습니다. 이 규칙은 메일 프로토콜 표준이 아니라 대형 수신 사업자의 운영 정책이라는 점이 중요합니다. 표준(SMTP)은 "보낼 수 있게" 해 주지만, 받아 주느냐는 수신 측 정책이 정한다는 것을 보여 줍니다.
사례 3. 가상 예시: 메일 앱 수동 설정이 실패하는 이유
가상 예시입니다. 회사 도메인 메일을 새 스마트폰에 수동으로 등록하는 A씨가 수신 서버는 IMAP 993번(처음부터 TLS)으로 맞게 넣었지만, 발신 서버는 587번(STARTTLS)을 넣고 보안 설정을 "SSL/TLS"(처음부터 TLS)로 골랐다고 해 봅시다. 앱은 연결 즉시 TLS를 시도하지만 서버는 평문 인사말부터 보내므로 연결이 실패합니다. 받기는 되는데 보내기만 실패하는 전형적인 증상입니다. 이럴 때는 (1) 발신과 수신 설정이 따로라는 점, (2) 포트와 보안 방식이 짝이라는 점, (3) 서비스의 공식 안내를 먼저 확인하세요.
SPF·DKIM·DMARC: 보낸 사람이 진짜인가
SMTP 자체는 보낸 사람 주소를 강하게 검증하지 않습니다. 이를 보완하는 도메인 인증이 세 가지입니다. SPF(RFC 7208)는 도메인이 DNS에 "이 IP에서 우리 메일을 보낸다"고 게시하고 수신 서버가 대조하는 방식입니다. DKIM(RFC 6376)은 메일에 전자서명을 넣고 공개키를 DNS에 게시해 변조 여부를 확인합니다. DMARC(RFC 7489, 2015)는 SPF·DKIM 결과가 From 주소의 도메인과 맞는지(정렬)를 보고, 실패 시 none·quarantine·reject 중 어떻게 처리할지 도메인이 게시하며 보고서도 받게 합니다. 참고로 RFC Editor에는 RFC 9989가 RFC 7489를 대체하는 표준 트랙 문서로 올라와 있으므로, 구현할 때는 최신 문서를 확인하세요. 세부 설정은 이메일 인증 가이드에서 이어서 볼 수 있습니다.
직접 확인해 보기: 체크리스트
- 메일 앱 설정에서 발신(SMTP)과 수신(IMAP/POP3) 서버 주소를 각각 확인한다.
- 포트와 보안 방식을 짝으로 확인한다: 587은 STARTTLS, 465·993·995는 처음부터 TLS가 일반적이다.
- 평문 포트(25·110·143)로 계정 비밀번호를 보내는 설정은 피한다.
- 여러 기기를 쓰면 IMAP, POP3를 쓴다면 "서버에 사본 남기기" 옵션 여부를 먼저 확인한다.
- 도메인을 운영한다면 SPF·DKIM·DMARC 레코드가 DNS에 게시되어 있는지 점검한다.
흔한 오해와 정정
- 오해: POP3는 무조건 서버에서 메일을 지운다. 실제: 클라이언트가 삭제 표시를 한 메일이 세션 종료 때 지워지는 구조이며, 클라이언트가 서버에 남겨 둘 수도 있습니다.
- 오해: 587번만 안전하고 465번은 구식이다. 실제: RFC 8314는 암시적 TLS(465)를 오히려 우선 권고합니다.
- 오해: SPF만 설정하면 사칭 메일이 막힌다. 실제: SPF는 봉투 발신 주소(MAIL FROM)를 대상으로 하고 사용자가 보는 From과는 별개라, DMARC의 정렬 검사가 함께 필요합니다.
- 오해: IMAP이면 메일이 안전하게 백업된다. 실제: IMAP은 서버와의 동기화일 뿐이라 서버에서 지우면 모든 기기에서 사라집니다. 백업은 별개입니다.
한계와 더 알아볼 점
전송 구간 TLS는 "내 기기와 서버 사이"나 "서버와 서버 사이"를 보호할 뿐, 메일이 서버에 저장된 뒤의 내용까지 지켜 주지는 않습니다(종단 간 암호화와는 다른 개념). 또 메일 서버 간 TLS가 항상 적용되는지는 상대 서버 설정에 달려 있습니다. 이 글의 대량 발신 기준은 구글 공식 문서(2024년 2월 시행 기준)이며 사업자 정책은 바뀔 수 있습니다.
포트 번호 전체를 한눈에 보고 싶다면
웹·데이터베이스 포트까지 자주 쓰는 포트 번호를 모두 정리한포트 번호 총정리 페이지도 함께 확인해보세요.
메일 서버 이름을 도메인 설정에서 확인하려면
내가 관리하는 도메인의 메일 수신 서버가 어디로 지정되어 있는지는DNS 레코드 타입 완전정복의 MX 레코드 항목에서 확인할 수 있습니다. TLS가 어떻게 협상되는지는 TLS 핸드셰이크 가이드를 참고하세요.
자주 묻는 질문
지메일이나 네이버 메일도 이 프로토콜을 그대로 쓰나요?
네, 지메일·네이버 메일·아웃룩 같은 웹메일 서비스도 스마트폰 기본 메일 앱이나 아웃룩 프로그램에 계정을 등록할 때는 내부적으로 SMTP·IMAP(또는 POP3)를 그대로 사용합니다. 다만 웹 브라우저에서 직접 메일함에 접속할 때는 이 프로토콜 대신 일반적인 웹(HTTPS) 통신을 사용합니다.
465번과 587번 중 어떤 포트를 써야 하나요?
두 포트 모두 암호화된 발신에 널리 쓰이고 있어 어느 한쪽이 "구식"이라고 단정하기 어렵습니다. 587번은 STARTTLS 방식, 465번은 처음부터 암호화된 연결(암시적 TLS) 방식이라는 차이가 있으며, 정확히 어떤 포트를 지원하는지는 이용 중인 메일 서비스의 공식 설정 안내를 따르는 것이 가장 확실합니다.
메일은 받아지는데 보내기만 안 되는 이유는 무엇인가요?
수신(IMAP/POP3)과 발신(SMTP)은 서버 주소, 포트, 인증 설정이 따로입니다. 발신 서버 인증 여부, 포트와 보안 방식 불일치, 또는 사용 중인 네트워크가 25번 포트를 막은 경우가 흔한 원인이며, 서비스의 공식 설정 안내와 하나씩 대조해 보세요.
평문 포트(25·110·143)는 이제 쓰면 안 되나요?
25번은 서버 간 전달에서 여전히 쓰이지만, 사용자가 비밀번호를 보내는 접속에서는 암호화 포트나 STARTTLS를 쓰는 것이 원칙입니다. RFC 8314도 평문 접근을 가능한 한 빨리 없애는 방향을 권고합니다.
IMAP과 POP3를 동시에 쓸 수 있나요?
같은 계정에 둘 다 접속하는 것을 허용하는 서비스도 있지만, POP3 클라이언트가 서버에서 메일을 지우면 IMAP 쪽에서도 사라질 수 있어 혼용은 권하지 않습니다.