

목 차
1. 이메일 시스템의 기본 개념.
2. DNS의 역할과 구조.
3. 이메일 발신자 인증 기술.

최근 웨더핏 프로젝트에서 '회원가입' 기능을 만들면서, 이메일 인증을 구현했었습니다.
구현 당시에는 '구현'자체에 더 몰입하느라, 깊게 알아보지 못 했던게 아쉬워서
이메일 시스템에 대해서 한 번 자세히 정리해보려고 합니다.
이메일은 단순한 텍스트 메시지를 넘어서
첨부파일, 인증서, 암호화된 통신까지 포함하는 인터넷 기반의 메시징 시스템입니다.
HTTP가 브라우저와 서버 간의 요청/응답이라면, 이메일은 서버 대 서버 간의 메시지 교환이 핵심입니다.
특히 AWS SES(Simple Email Service)를 이용한 대량 이메일 발송에서는
도메인 인증과 높은 전달 성공률 확보가 핵심입니다.
이 시스템은 다음 세 가지 큰 축으로 작동합니다:
작성/발송 (Submission & Sending)
전송/중계 (Relaying & Routing)
수신/저장/열람 (Delivery & Access)
형식 : local-part@domain
ex) 소현이가 가든에게 메일을 보내고,
가든이 소현이가 보낸 메일을 받는 상황이라고 가정하고, 이를 도식화

위의 예시에서 서버 A와 서버 B는 각각 소현이와 가든이 사용하는 메일 서버입니다.
메일 서버는 사용자마다 사서함(Mailbox)을 관리하고,
서버 간 통신을 통해 메일을 중계하는 역할을 합니다.
발신자 소현이가 메일을 보내면, 해당 메일은 먼저 메일 서버 A에 도착합니다.
서버 A는 수신자 정보(예: sohyun@example.com)를 분석해,
메일 서버 B로 SMTP 프로토콜을 통해 메일을 전달합니다.
메일 서버 B는 해당 메일을 가든의 사서함에 저장합니다.
이처럼 메일 서버 간 통신은 시차와 무관하게 안정적인 메시지 전송을 가능하게 합니다.
메일 클라이언트는 사용자의 컴퓨터나 스마트폰에 설치되어 있으며,
메일을 작성하고 전송하거나, 서버로부터 메일을 가져오는 역할을 합니다.
소현이가 메일을 작성해 전송하면, 클라이언트 프로그램이 메일 서버 A에 메일을 업로드합니다.
가든은 클라이언트 프로그램을 통해 서버 B에 도착한 메일을 읽거나 다운로드할 수 있습니다.
이메일은 다음 구성 요소를 통해 발신자에서 수신자까지 전달됩니다:
sequenceDiagram
participant UserA as 사용자 A (MUA)
participant MSA as Submission Agent
participant MTA_A as 송신 서버 (MTA A)
participant MTA_B as 수신 서버 (MTA B)
participant MDA as Mail Delivery Agent
participant UserB as 사용자 B (MUA)
UserA->>MSA: 메일 작성 후 발송 (SMTP 587)
MSA->>MTA_A: 인증 및 헤더 검사 후 위임
MTA_A->>MTA_B: MX 레코드 조회 후 전달 (SMTP 25)
MTA_B->>MDA: 수신자 메일박스에 저장
UserB->>MDA: 메일 조회 요청 (IMAP/POP3)
MDA-->>UserB: 메일 내용 전송
| 프로토콜 | 용도 | 기본 포트 | 주요 특징 | 보안 |
|---|---|---|---|---|
| SMTP | 메일 전송 | 25, 587 | 전송 위주, 수신 불가 | STARTTLS 또는 SMTPS(465) |
| POP3 | 메일 수신 | 110 | 수신 후 로컬 저장, 서버 정리 | SSL(995) |
| IMAP | 메일 수신 | 143 | 서버-클라이언트 동기화 중심 | SSL(993) |
Tip: 백엔드 개발자가 직접 메일 서버를 운영할 경우,
IMAP은 메일 상태관리(읽음/답장/삭제)를 위해 필수. !
이메일을 전송할 때 사용되는 프로토콜입니다.
SMTP는 아래의 두가지 상황에서 사용됩니다.
1) 클라이언트 -> 서버 : 사용자가 작성한 이메일을 서버로 전송할 때
2) 서버 -> 서버 : 메일 서버 A가 메일 서버 B로 메일을 전달할 때
ex) 메일을 보내면 SMTP를 통해 메일 서버 A로 전송되고,
서버 A는 다시 SMTP를 이용해 서버 B로 전달합니다.
메일을 수신할 때 사용하는 프로토콜입니다.
클라이언트가 메일 서버의 사서함에 있는 이메일을 가져올 때 사용되며,
POP3의 특징은 아래와 같습니다 !
1) 메일을 서버에서 클라이언트로 다운로드한 뒤 서버에서 삭제하는 방식이 일반적입니다.
2) 오프라인 환경에서 메일을 읽는 데 유리하지만, 여러 디바이스 간 메일 동기화에는 불리합니다.
메일을 수신할 때 사용하는 프로토콜입니다.
POP3와 유사하게 메일 수신용 프로토콜이지만,
메일을 서버에 그대로 두고 필요 시 동기화하여 읽는 구조입니다.
여러 디바이스에서 동일한 메일함을 관리할 수 있어,
현대 이메일 환경에서는 POP3보다 IMAP이 더 널리 사용됩니다.

이메일 시스템에서 실제 메일이 전달되는 흐름은 다음과 같이 MUA, MSA, MTA, MDA 역할로 나뉘며,
각 구성요소가 담당하는 역할은 아래와 같습니다.
[소현] MUA (Gmail, Outlook 등)
↓ SMTP 전송
[메일 서버 A] MSA → MTA
↓ SMTP 중계
[메일 서버 B] MTA → MDA
↓
[가든] MUA (Gmail, Outlook 등)

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

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

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

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

최근 이메일 수신 환경에서는 스팸, 피싱 메일을 차단하기 위해 발신자 인증 기술의 적용 여부를 매우 중요하게 보고 있습니다.
Gmail, Yahoo, Naver 등 주요 이메일 서비스 제공업체들은
2024년부터 발신자 인증(SPF, DKIM, DMARC)이 적용되지 않은 메일에 대해
수신 지연, 스팸 처리, 또는 수신 거부 등의 정책을 강화했습니다.
이메일 인증 구성은 도메인 설정(TXT 레코드) 작업이 핵심이며,
발송 서비스(Amazon SES 등)와 연동 필수.
| 보안 기술 | 역할 | 동작 방식 | 실무 적용 포인트 |
|---|---|---|---|
| SPF | 허용된 발신 서버 지정 | DNS TXT 레코드에 IP 명시 | 도메인 도용 방지 |
| DKIM | 메시지 위조 방지 | 공개키 기반 서명 | 전송 중 무결성 확보 |
| DMARC | 정책 기반 필터링 | SPF/DKIM 조합+정책 | 수신 서버가 처리 지침 따름 (거부/격리/허용) |
SPF는
"이 도메인에서 이메일을 보낼 수 있는 컴퓨터(IP)는 이 목록에 있어!"라고 선언하는 명부입니다.
예를 들어, example.com이라는 도메인이 있다면, 그 도메인 주인은 DNS 설정에 "우리 회사 메일은 이 IP들에서만 보낼 거야"라고 적어둡니다.
이후 누군가 example.com을 발신자로 해서 이메일을 보내면, 수신 서버가 DNS를 확인해서 해당 IP가 진짜 승인된 IP인지 검사합니다.
목적: 도메인 도용(스푸핑)을 막는 것!
형태: DNS의 TXT 레코드에 기록됨 (예: v=spf1 ip4:192.0.2.1 -all)
v=spf1 ip4:203.0.113.5 include:_spf.google.com -all

TIP: SPF 설정 시, 메일 중계 서버나 외부 이메일 플랫폼을 사용할 경우
반드시 include 문법을 통해 반영해야 정상 작동합니다.
DKIM(DomainKeys Identified Mail)은 이메일이 발송되는 동안 내용이 바뀌지 않았는지(무결성),
그리고 정말 해당 도메인에서 보낸 것이 맞는지(도메인 정합성)를 확인하는 기술입니다.
쉽게 비유하면 DKIM은 마치 “봉인된 편지”에 도장을 찍고 보내는 것입니다.
받는 사람이 도장을 확인해서, “이 편지는 원본 그대로고, 보낸 사람이 맞군!” 하고 확인하는 과정이죠.
🔑 작동 원리.
수신 서버는 받은 메일의 서명을 공개키로 검증합니다.
서명이 유효하면: “이 메일은 중간에 변조되지 않았고, 발신 도메인도 맞음”
서명이 무효하면: 스팸 또는 위조 가능성 있음
📌 구성 요소.
| 구성 요소 | 설명 |
|---|---|
| 서명 | 메일 본문 + 헤더 일부를 개인키로 암호화한 전자서명 |
| 공개키 | DNS의 TXT 레코드에 저장된 키, 수신 서버가 검증 시 사용 |
| DKIM-Signature | 메일 헤더에 포함되어 있는 서명 필드 |
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... (생략)
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...

DMARC(Domain-based Message Authentication, Reporting, and Conformance)는
이메일 인증(SPF, DKIM) 실패 시 수신 서버가 어떻게 대응해야 할지를 알려주고,
그 결과를 도메인 관리자에게 보고할 수 있도록 도와주는 정책 프레임워크입니다.
🧩 어떻게 동작할까?
수신 서버는 이메일을 받을 때:
SPF 또는 DKIM이 통과(pass)되었는지 검사
DMARC 정책이 있다면 정책에 따라 행동 (예: reject, quarantine, none)
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-report@example.com"
p=quarantine: 인증 실패 시 격리 (스팸함으로 이동)
rua=...: 리포트 수신 주소
