이메일 전송 과정: SMTP·IMAP·POP3와 MX 레코드 역할

메일을 “SMTP로 보내고 POP3로 받는다”라고만 외우면 서버 사이 전달과 사용자의 메일함 접근이 섞인다. SMTP는 메시지를 제출하고 메일 서버 사이에서 전달하는 데 쓰이고, IMAP과 POP3는 도착한 메일함을 사용자가 읽는 방식이다. 목적과 신뢰 경계가 다르므로 포트와 TLS 설정도 따로 본다.

메일 한 통이 이동하는 순서

alice@example.com이 bob@example.net으로 메일을 보낸다고 가정하면 일반적인 흐름은 다음과 같다.

Alice의 메일 앱
  ↓ SMTP submission
example.com 제출 서버
  ↓ DNS에서 example.net의 MX 조회
example.com 송신 MTA
  ↓ server-to-server SMTP
example.net 수신 MTA
  ↓ 메일함에 저장
Bob의 메일 앱
  ↑ IMAP 또는 POP3

1. 메일 앱인 MUA(Mail User Agent)가 인증된 제출 서버에 메시지를 맡긴다.
2. 제출 서버와 송신 MTA가 받는 사람 도메인의 MX 레코드를 조회한다.
3. 송신 MTA가 선택한 수신 MTA로 SMTP 연결을 시도한다.
4. 수신 서버가 메시지를 받아 필터링하고 Bob의 메일함에 저장한다.
5. Bob의 메일 앱은 IMAP 또는 POP3로 메일함을 읽는다.

각 단계가 비동기적으로 이어질 수 있어 “보내기 버튼이 성공했다”는 사실이 최종 메일함 배달을 보장하지는 않는다. 제출 성공, 송신 큐 적재, 상대 MTA 수락, 최종 메일함 저장을 로그와 상태로 구분한다.

SMTP는 제출과 서버 간 릴레이로 나뉜다

SMTP 대화의 핵심은 envelope과 message content를 구분하는 데 있다.

EHLO mail.example.com
MAIL FROM:<alice@example.com>
RCPT TO:<bob@example.net>
DATA
From: Alice <alice@example.com>
To: Bob <bob@example.net>
Subject: hello

message body
.

MAIL FROM과 RCPT TO는 전송 경로에서 사용하는 envelope 주소다. 메시지 본문의 From, To 헤더와 같을 때가 많지만 항상 같은 것은 아니다. 반송 처리와 메일링 리스트를 조사할 때 두 층을 나눠 봐야 한다.

용도별 대표 포트는 다음과 같다.

용도	대표 포트	설명
서버 간 SMTP relay	TCP 25	MTA가 다른 MTA로 메일을 전달한다.
Message submission	TCP 587	사용자·애플리케이션이 인증 후 메일을 제출한다.
Submission over implicit TLS	TCP 465	연결 시작부터 TLS를 사용하는 제출 서비스다.

애플리케이션에서 메일을 보낼 때 TCP 25를 외부 릴레이처럼 직접 쓰기보다, 제공자의 인증된 submission endpoint를 사용한다. RFC 6409는 메시지 제출을 일반 SMTP 전달과 분리해 설명한다.

MX 레코드는 받는 서버의 우선순위를 알려 준다

송신 서버는 수신자 이메일 주소의 도메인을 보고 DNS MX 레코드를 조회한다.

dig example.net MX

예를 들어 다음 결과에서 숫자가 작은 대상이 더 높은 우선순위를 가진다.

example.net.  300  IN  MX  10  mx1.example.net.
example.net.  300  IN  MX  20  mx2.example.net.

MX가 여러 개라고 해서 모든 서버에 동시에 한 통씩 보내는 것은 아니다. 우선순위와 연결 결과에 따라 대상을 고르고, 일시적인 실패라면 송신 큐에서 나중에 다시 시도할 수 있다.

MX 레코드는 메일 서버의 호스트 이름을 가리킨다. 그 호스트의 A·AAAA 주소를 다시 찾아 연결한다. MX를 비롯한 레코드의 구조는 DNS 레코드 종류와 읽는 법에서 따로 정리한다.

IMAP과 POP3는 메일함을 다르게 다룬다

구분	IMAP	POP3
중심 모델	서버의 메일함과 상태를 동기화	서버에서 메시지를 조회·다운로드
폴더·플래그	서버 폴더와 읽음 상태 등을 다룸	기본 프로토콜은 단순한 단일 maildrop 중심
여러 기기	같은 서버 상태를 공유하기에 적합	클라이언트 보관 정책에 따라 상태가 갈리기 쉬움
TLS 대표 포트	993	995

IMAP은 메시지를 서버에 둔 채 폴더, 플래그, 검색과 동기화를 다룬다. POP3는 서버의 maildrop에서 메시지를 나열하고 가져오며 삭제 표시를 할 수 있는 더 단순한 모델이다. 오늘날 여러 기기에서 같은 메일함을 쓴다면 대체로 IMAP 모델이 자연스럽지만, 보관 요구와 제공자 정책에 따라 선택한다.

TLS와 인증은 어느 구간에서 필요한가

RFC 8314는 메일 제출과 접근에서 TLS 사용을 권고한다. 사용자의 비밀번호와 메일 내용을 보호하려면 메일 앱과 제출·IMAP·POP 서버 사이에서 인증서 검증이 된 TLS를 사용해야 한다.

다만 사용자 앱과 서버 간 TLS 설정이 서버 간 모든 SMTP 구간의 종단 간 암호화를 보장하는 것은 아니다. MTA 간 전송은 상대 서버의 지원과 정책에 따라 TLS 협상이 달라질 수 있다. 메일 본문 자체의 종단 간 기밀성이 필요하다면 S/MIME이나 OpenPGP 같은 별도 메시지 보호 모델을 검토한다.

운영 설정에서는 다음을 피한다.

• 인증서를 검증하지 않는 TLS 옵션
• 소스 코드나 저장소에 SMTP 비밀번호를 직접 기록하는 방식
• 발신 권한을 제한하지 않은 공용 릴레이
• 일시 오류와 영구 오류를 구분하지 않는 무한 재시도

전달 실패를 좁히는 순서

1. 클라이언트가 submission 서버에 인증하고 메시지를 넘겼는지 확인한다.
2. 송신 서버 큐에서 대상 도메인과 마지막 SMTP 상태 코드를 본다.
3. dig 도메인 MX로 MX와 우선순위를 확인한다.
4. MX 대상의 A·AAAA 조회와 TCP 25 연결 경로를 확인한다.
5. 상대 서버가 4xx 임시 실패를 반환했는지 5xx 영구 실패를 반환했는지 구분한다.
6. 수신 서버가 수락한 뒤라면 스팸 격리, 사용자 필터, 메일함 용량을 확인한다.

SMTP 응답은 세 자리 코드의 첫 숫자로 성공(2xx), 추가 단계(3xx), 일시 실패(4xx), 영구 실패(5xx)를 구분한다. 애플리케이션 로그에는 비밀번호나 전체 메일 본문을 남기지 말고 message ID, 대상 도메인, 응답 코드와 큐 ID처럼 추적에 필요한 최소 정보만 기록한다.

참고 자료

• RFC 5321: Simple Mail Transfer Protocol
• RFC 6409: Message Submission for Mail
• RFC 9051: IMAP4rev2
• RFC 1939: Post Office Protocol, Version 3
• RFC 8314: Cleartext Considered Obsolete for Email Submission and Access