이 글에서 다룰 내용
이 글에서는 Email이 실제로 어떤 구조를 통해 전달되는지, 전체 아키텍처 관점에서 정리함
단순히 메일이 오가는 과정이 아닌,
MUA·MSA·MTA·MDA로 역할이 분리된 구조를 기반으로 Submit과 Relay가 어떻게 나뉘고, DNS(MX)를 통해 전달 경로가 어떻게 결정되는지까지 연결해서 설명함
학습 목표
- Email 전송을 구조와 흐름 기준으로 이해할 수 있음
MUA·MSA·MTA·MDA의 역할과 책임을 구분할 수 있음Sumbit과Relay의 구조 차이를 이해할 수 있음- Email Security가 개입되는 위치의 연결 가능 상태를 확보할 수 있음
Email 전송 구조 개요
Email은 여러 구성요소가 역할을 나누어 처리하는 구조를 가짐.
메일은 생성된 이후 하나의 서버를 거치는 것이 안니라, 여러 서버를 순차적으로 통과하여 전달됨.
각 서버는 메일을 수신하면 다음 서버로 바로 전달하기 않고, 내부 Queue에 저장한 뒤 전달 가능한 시점에 전송을 수행함
이 전송 방식이 Sotre & Forward 모델이며, 네트워크 지연이나 수신 서버 상태에 영향을 받은 환경에서 안정적인 전달을 가하게 함.
능
전달 경로는 수신 도메인을 기준으로 결정되며, 도메인에 설정된 MX 레코드를 조회하여 목적지 서버를 선택하고, 해당 서버로 SMTP 연결을 통해 메일을 전달함
이 과정에서 하나 이상의 중간 서버를 거치는 홉 기반 전송이 발생하게 됨
이 구조는 SMTP(RFC 5321)와 Internet Mail Architecture(RFC 5598)에서 정의됨
Email 구성요소
Email 시스템은 역할 단위로 구성되며, 각 구성요소는 전송 흐름 내에서 서로 다른 책임을 가짐
전체 구조
메일은 사용자에게 시작해 사용자로 전달됨
전송 과정은 다음과 같은 흐름으로 구성됨
중간 전달 단계에서는 하나 이상의 MTA가 포함될 수 있으며, 내부 시스템과 외부 시스템 간 경계가 구분되는 구조로 운영됨
MUA: Mail User Agent
메일을 생성하고 확인하는 클라이언트 역할
사용자는 이 단계에서 메시지를 작성하고 전송 요청을 발생시킴. 생성된 메시지는 이후 단계에서 전송 처리됨
MSA: Mail Submission Agent
사용자가 생성한 메일을 받아 전송 가능한 상태로 처리하는 서버
이 단계에서 사용자 인증이 수행되며, 인증된 사용자만 메일을 전송할 수 있음
MSA 주요 수행 동작
- STMP AUTH 기반 사용자 인증
- 기본 정책 적용
- 내부 전달 준비
메일은 이 단계에서 발신자 기준으로 신뢰가 부여된 상태로 전환됨
MTA: Mail Transfer Agent
메일 전달을 담당하는 핵심 구성요소
수신 도메인을 기준으로 DNS 조회를 수행하고, MX 레코드를 통해 전달 대상 서버를 결성함
MTA 주요 수행 동작
- MX 조회를 통한 목적지 선택
- SMTP 연결을 통한 메일 전달
- 전송 실패 시 큐 기반 재시도
메일은 이 단계에서 여러 서버를 거쳐 전달되며, 전체 전송 흐름이 유지되게 됨.
MDA: Mail Delivery Agent
메일이 최종적으로 저장되는 단계
전달이 완료된 메일은 Mailbox에 저장되며, 사용자는 이후 클라이언트를 통해 메일을 확인함
Email 전송 흐름
Email 전송은 Submit, Relay, 수신 처리, Delivery 단계로 구분됨.
각 단계를 서로 다른 역할과 처리 기준을 가짐
Submit
사용자가 메일을 전송하는 단계.
사용자 인증이 수행되며, 전송 구간은 TLS 기반으로 보호됨
이 단계에서 메일은 전송 가능한 상태로 처리됨
Relay
메일어 서버 간에 전달되는 단계
MTA는 수신 도메인의 MX 레코드를 조회하여 목적지 서버를 결정하고, SMTP를 통해 메일을 전달함
이 과정에서 내부 릴레이, 외부 게이트웨이, 다중 경유 경로가 포함될 수 있으며, 전송 실패 시 재시도 로직이 적용됨
수신 처리
수신 서버에 도달한 메일은 저장 이전에 검증 단계를 거침
수행되는 동작
- SPF / DKIM / DMARC 기반 도메인 인증
- 스팸 및 악성 콘텐츠 검사
- 정책 기반 필터링
대부분의 Email Security 기능이 이 구간에서 적용됨
Delivery
메일이 Mailbox에 저장되고, 사용자 접근이 가능한 상태로 전환됨.
이 시점에서 전송 과정이 종료 됨
Submit vs Relay
Submit과 Relay는 전송 흐름 내에서 구분되는 두 영역이며, 처리 기준과 신뢰 형성 방식이 다름
Submit
- 사용자 → 서버
- 사용자 인증 기반 처리
- 정책 적용 가능
사용자 신원을 기준으로 처리되느 ㄴ구간
Relay
- 서버 → 서버
- 도메인 및 경로 기반 전달
- 기본적으로 인증 없음
메일이 네트워크를 통해 전달되는 구간
차이
두 구간은 신뢰 형성 기준이 다르게 적용됨
Relay 구간에서는 발신자 신원을 직접 검증하지 않기 때문에, 도메인 인증 및 보안 검증이 필요함.
이 구조가 Email Security 기술의 적용 배경이 됨
운영 핵심 포인트
구간 분리
Submission과 Relay는 포트와 정책 기준으로 구분됨.
587→ Submission25→ Relay
추척
메일은 여러 서버를 거치므로 전달 경로 추적이 필요함
- Recived 헤더
- Message-ID
이 정보를 통해 메일의 이동 경로와 처리 상태를 확인할 수 있음
역할 구분
각 구성요소는 역할과 책임이 명확하게 분리되어야 함
- 제출 처리 영역
- 전달 처리 영역
- 저장 영역
이 구분이 운영 및 장애 대응의 기준이 됨
정리
Emila은 역할 기반으로 분리된 구성요소가 협력하여 동작하는 전송 시스템
전체 흐름
- Submit → Relay → Delivery
각 단계는 서로 다른 책임을 가짐
- Submit → 사용자 인증 및 전송 시작
- Relay → 서버 간 전달 및 경로 선택
- Delivery → 최종 저장 및 사용자 접근
전달 구조 핵심
메일은 단일 서버가 아니라 여러 서버를 거치며 전달되며, 각 서버는 메일을 저장한 뒤 다음 서버로 전달하는 Store & Forward 방식으로 동작
경로 결정 방식
- DNS 조회를 통해 수신 도메인의 MX 레코드를 확인
- MX 우선순위에 따라 전달 대상 서버가 선택됨
신뢰 구조
- Submit → 사용자 인증 기반 신뢰
- Relay → 도메인 및 경로 기반 신뢰
Relay 구간에서는 발신자 신원을 직접 확인하지 않기 때문에, 추가적인 인증 및 보안 검증이 필요함
