안녕하세요! 프론트엔드 개발자 Garden, 오소현입니다.

이번 글에서는 프론트엔드 관련 글 보다, 제가 회사에서 맡고 있는 서버들 중 하나인 이메일 시스템에 대해 전체적으로 공부해보고, 개선한 과정을 시리즈로 작성해보려고 합니다 :D

최근에 이메일 시스템을 통해서 대량의 이메일을 발송했던 경험들이 많아지고 있어 약 1달 간 퇴근해서도 계속해서 공부했던 것 같아요 🥹 서버에 대한 지식이 부족했기에, 이해하고 적용해 구현하는 과정이 어려웠지만 이해한 내용을 바탕으로 시리즈를 발행해보려 합니다! 부족한 점이나 오 개념이 있을 경우 댓글로 알려 주시면 바로 대응하겠습니다 😆

오늘 첫 번째 시리즈는 전체적으로 이메일 시스템을 이해하기 위해 전통적 이메일 인프라 구조에 대한 내용을 공부한 내용을 가져왔습니다.

---

1. 신뢰받는 이메일 발송의 중요성

이메일 시스템은 단순한 송수신을 넘어, 스팸 방지와 인증 체계를 중심으로 발전해 왔습니다. 특히 AWS SES(Simple Email Service)를 이용한 대량 이메일 발송에서는 도메인 인증과 높은 전달 성공률 확보가 핵심입니다. 이 문서는 이메일 구조와 인증 기술(SPF, DKIM, DMARC), DNS 설정 등을 이해하고자 하는 개발자와 인프라 운영자를 위한 기술 개요입니다.

---

2. 이메일 시스템의 기본 개념

2.1 이메일 주소 구조

• 형식: local-part@domain
• local-part: 사용자 식별자(ID), 대소문자 구분은 있지만 대부분 무시됨
• domain: 메일 서버 도메인, 대소문자 구분 없음

2.2 이메일 시스템 구조와 프로토콜

예시로 소현이가 가든에게 메일을 보내고, 가든이 소현이가 보낸 메일을 받는 상황이라고 가정하고, 이를 도식화 해보았습니다.

🖥️ 메일 서버

위의 예시에서 서버 A와 서버 B는 각각 소현이와 가든이 사용하는 메일 서버입니다. 메일 서버는 사용자마다 사서함(Mailbox)을 관리하고, 서버 간 통신을 통해 메일을 중계하는 역할을 합니다.

발신자 소현이가 메일을 보내면, 해당 메일은 먼저 메일 서버 A에 도착합니다.

서버 A는 수신자 정보(예: sohyun@example.com)를 분석해, 메일 서버 B로 SMTP 프로토콜을 통해 메일을 전달합니다.

메일 서버 B는 해당 메일을 가든의 사서함에 저장합니다.

이처럼 메일 서버 간 통신은 시차와 무관하게 안정적인 메시지 전송을 가능하게 합니다.

💻 메일 클라이언트

메일 클라이언트는 사용자의 컴퓨터나 스마트폰에 설치되어 있으며, 메일을 작성하고 전송하거나, 서버로부터 메일을 가져오는 역할을 합니다.

소현이가 메일을 작성해 전송하면, 클라이언트 프로그램이 메일 서버 A에 메일을 업로드합니다.

가든은 클라이언트 프로그램을 통해 서버 B에 도착한 메일을 읽거나 다운로드할 수 있습니다.

이메일은 다음 구성 요소를 통해 발신자에서 수신자까지 전달됩니다:

• MUA (Mail User Agent): 사용자 인터페이스 (예: Gmail, Outlook)
• MSA (Mail Submission Agent): 사용자로부터 이메일 수신
• MTA (Mail Transfer Agent): 서버 간 메일 전송
• MDA (Mail Delivery Agent): 메일 최종 수신 및 저장

2.3 이메일 전송과 수신에 사용되는 주요 프로토콜

1. SMTP (Simple Mail Transfer Protocol)

이메일을 전송할 때 사용되는 프로토콜입니다.

SMTP는 아래의 두 상황에서 사용됩니다!

1) 클라이언트 → 서버: 사용자가 작성한 이메일을 서버로 전송할 때

2) 서버 → 서버: 메일 서버 A가 메일 서버 B로 메일을 전달할 때

예시 → 소현이가 메일을 보내면 SMTP를 통해 메일 서버 A로 전송되고, 서버 A는 다시 SMTP를 이용해 서버 B로 전달합니다.

2. POP3 (Post Office Protocol v3)

메일을 수신할 때 사용하는 프로토콜입니다.

클라이언트가 메일 서버의 사서함에 있는 이메일을 가져올 때 사용되며, POP3의 특징은 아래와 같습니다 !

1) 메일을 서버에서 클라이언트로 다운로드한 뒤 서버에서 삭제하는 방식이 일반적입니다.

2) 오프라인 환경에서 메일을 읽는 데 유리하지만, 여러 디바이스 간 메일 동기화에는 불리합니다.

3. IMAP (Internet Message Access Protocol)

메일을 수신할 때 사용하는 프로토콜입니다.

POP3와 유사하게 메일 수신용 프로토콜이지만, 메일을 서버에 그대로 두고 필요 시 동기화하여 읽는 구조입니다.

여러 디바이스에서 동일한 메일함을 관리할 수 있어, 현대 이메일 환경에서는 POP3보다 IMAP이 더 널리 사용됩니다.

4. POP3 vs IMAP

항목	POP3 (Post Office Protocol 3)	IMAP (Internet Message Access Protocol)
주요 특징	메일을 서버에서 다운로드 후 삭제	메일을 서버에 보관하며 동기화
저장 위치	클라이언트(PC/앱) 중심	서버 중심
서버 용량 영향	적음 (다운로드 후 삭제됨)	큼 (모든 메일이 서버에 유지됨)
여러 기기 사용	불편 (메일 상태 불일치)	편리 (기기간 메일 상태 동기화)
오프라인 사용	좋음 (한 번 다운로드하면 인터넷 없어도 읽기 가능)	제한적 (초기 로딩만, 전체 메일은 연결 필요)
메일 상태 유지	유지 불가 (읽음 여부, 폴더 정리 등이 반영 안됨)	유지 가능 (읽음 여부, 폴더 정리 동기화)
보안/백업 측면	메일 분실 가능성 높음 (클라이언트 손상 시)	백업 쉬움 (서버에서 관리)

따라서 멀티 디바이스 / 동기화 중심 / UX 중시하는 IMAP를 현대에서 많이 사용하는 구조입니다.

---

2.4 이메일 전송 흐름과 구성요소 매핑

이메일 시스템에서 실제 메일이 전달되는 흐름은 다음과 같이 MUA, MSA, MTA, MDA 역할로 나뉘며, 각 구성 요소가 담당하는 역할을 아래에 정리했습니다.

[소현] MUA (Gmail, Outlook 등)
   ↓ SMTP 전송
[메일 서버 A] MSA → MTA
   ↓ SMTP 중계
[메일 서버 B] MTA → MDA
   ↓
[가든] MUA (Gmail, Outlook 등)

구성 요소	역할 설명	예시
MUA (Mail User Agent)	사용자가 이메일을 읽고 쓰는 클라이언트	Gmail, Outlook, Apple Mail
MSA (Mail Submission Agent)	클라이언트로부터 이메일을 수신하여 MTA에 전달	Gmail SMTP 서버
MTA (Mail Transfer Agent)	발신 메일 서버에서 수신 메일 서버로 메일을 전송	Postfix, Exim, Sendmail
MDA (Mail Delivery Agent)	메일을 수신자의 사서함에 저장	Dovecot, Procmail 등

이를 통해, 이메일은 클라이언트-서버-서버-클라이언트 간 단계적 흐름을 통해 안정적으로 수신자에게 도달합니다.

---

3. DNS의 역할과 구조

3.1 개요

DNS(Domain Name System)는 우리가 일반적으로 사용하는 도메인 주소(e.g. example.com)를 네트워크가 이해할 수 있는 IP 주소(e.g. 192.0.2.1)로 변환해주는 시스템입니다. 이는 웹뿐만 아니라 이메일 시스템에서도 필수적인 요소이며, 특히 이메일 발송 시에는 단순한 주소 해석을 넘어 발신자 도메인에 대한 인증 정보를 제공하는 중요한 역할을 수행합니다.

예를 들어, 수신 서버는 발신자의 DNS에 등록된 SPF, DKIM, DMARC 레코드를 참조하여 메일의 신뢰성과 위변조 여부를 검증할 수 있습니다. 또한 수신 메일 서버를 지정하는 MX(Mail Exchange) 레코드 역시 DNS에 등록되어야 정상적인 수신이 가능해집니다.

요약하자면, 이메일 발송 시스템에서 DNS는 아래의 두 가지 핵심 기능을 담당합니다.

✅ 발신자 인증 정보를 수신 서버에 제공 (SPF, DKIM, DMARC)
✅ 수신 메일 서버 지정을 위한 MX 레코드 등록

3.2 DNS의 주요 구성 요소

구성 요소	설명
Domain Name Space	도메인의 계층적 구조. 루트 도메인(.)부터 시작해 .com, example.com 등의 형태로 확장됨
Name Server	DNS 질의에 대해 권한 있는 응답을 제공하는 서버. 도메인 정보를 관리하고 제공함
Resolver	클라이언트(브라우저, 애플리케이션 등)의 요청을 받아 Name Server에 질의하고 응답을 반환

실제로 이메일 발송 시, 수신 서버는 발신자의 도메인에 대한 DNS 조회를 통해 위 구성 요소들이 연계된 결과로 인증 정보를 확인하게 됩니다.

3.3 이메일 관련 주요 DNS 레코드

레코드 유형	용도	예시
MX	수신 메일 서버의 주소와 우선순위를 지정함	10 mail.example.com.
TXT	SPF, DKIM, DMARC와 같은 인증 정보를 기록함	"v=spf1 include:_spf.google.com ~all"
CNAME	다른 도메인을 가리키는 별칭을 설정할 때 사용됨	selector1._domainkey.example.com
A / AAAA	도메인을 IP 주소(IPv4/IPv6)로 변환함	example.com → 192.0.2.1

특히 TXT 레코드는 이메일 인증 설정의 핵심으로, 도메인에 대해 SPF, DKIM, DMARC 값을 명시하여 이메일의 신뢰도를 보장하는 기반이 됩니다.

---

4. 이메일 발신자 인증 기술

최근 이메일 수신 환경에서는 스팸, 피싱 메일을 차단하기 위해 발신자 인증 기술의 적용 여부를 매우 중요하게 보고 있습니다. Gmail, Yahoo, Naver 등 주요 이메일 서비스 제공업체들은 2024년부터 발신자 인증(SPF, DKIM, DMARC)이 적용되지 않은 메일에 대해 수신 지연, 스팸 처리, 또는 수신 거부 등의 정책을 강화했습니다.

아래는 이메일 인증을 위한 핵심 기술 3가지와 그 역할을 이해해 보겠습니다.

---

4.1 SPF (Sender Policy Framework)

SPF는 특정 도메인에서 이메일을 보낼 수 있는 IP 주소 목록을 정의하는 메커니즘입니다.

수신 서버는 발신 메일의 Return-Path 도메인에서 DNS에 등록된 SPF 레코드를 조회하여, 실제 발송 IP가 이 목록에 포함되어 있는지를 확인합니다.

역할은 발신자 도메인에서 승인된 IP 주소인지 검증하는 것이고,
설정 위치는 도메인의 DNS에 TXT 레코드 형태로 등록되는 것입니다.

SPF 레코드 예시:

v=spf1 ip4:203.0.113.5 include:_spf.google.com -all

구성 요소	설명
v=spf1	SPF 버전 명시
ip4	허용된 발신 IP 주소
include	다른 도메인의 SPF 정책을 포함
-all	이외의 모든 IP는 거부 (소프트 거부는 ~all)

TIP: SPF 설정 시, 메일 중계 서버나 외부 이메일 플랫폼을 사용할 경우 반드시 include 문법을 통해 반영해야 정상 작동합니다.

---

4.2 DKIM (DomainKeys Identified Mail)

DKIM은 이메일이 발송 중 변조되지 않았는지를 검증할 수 있는 디지털 서명 기반 기술입니다.

이메일이 발송될 때, 발신 서버는 메일의 본문 및 일부 헤더에 대해 개인키로 전자서명을 생성하고, 수신 서버는 DNS에 등록된 공개키로 서명값을 검증합니다.

역할은 메일 내용의 무결성과 발신 도메인 정합성 검증하는 것이고
설정 위치는 도메인 DNS에 공개키를 TXT 레코드로 등록 + 메일 헤더에 DKIM-Signature 포함하는 것입니다.

DKIM TXT 레코드 예시:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... (생략)

DKIM-Signature 헤더 예시:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...

구성 요소	설명
d	서명 도메인
s	서명 선택자 (selector)
bh	본문 해시
b	서명 값

---

4.3 DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC는 SPF 또는 DKIM 인증 실패 시 수신 서버가 어떻게 메일을 처리해야 하는지를 지시하고, 그 결과를 리포트로 수신자에게 전달할 수 있도록 해주는 정책 프레임워크입니다.

역할은 SPF/DKIM 실패 시 정책 지정 및 리포트 수신하는 것이고,
설정 위치는 도메인 DNS에 TXT 레코드로 등록하는 것입니다.

DMARC 레코드 예시:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s;

속성	설명
v	DMARC 버전
p	정책: none(관찰), quarantine(격리), reject(거부)
rua	인증 실패 보고서를 받을 이메일 주소
adkim / aspf	DKIM/SPF 도메인 일치 기준 (s: strict, r: relaxed)

---

이제 이메일 발신자 인증 기술이 단순한 보안 옵션이 아닌 전송 성공률 확보의 필수 조건이 되었다는 점에서, 도메인을 보유하고 있는 모든 조직은 DNS에 해당 설정을 올바르게 구성해야 합니다. 이를 통해 이메일의 신뢰도를 높이고, 수신 거부율이나 스팸 분류 확률을 획기적으로 낮출 수 있습니다.

🧾 마무리하며

이 글은 이메일 시스템 운영자 입장에서, 이메일 인프라를 어떻게 이해하고 개선했는지를 정리한 내용입니다. AWS SES를 비롯해 이메일 전송에 필요한 기본 개념, 프로토콜, 인증 기술들을 직접 정리해보며 인프라 지식의 중요성을 다시금 체감할 수 있었습니다. 😊