이 글을 들어가기 전 정독할 것
이 글에서 다룰 내용
Email이 도메인 기반으로 전달되는 구조를 중심으로, 주소 구성과 전달 방식이 어떻게 연결되는지 정리함.
이후 DNS가 메일 전달에 어떻게 관여하는지 이해할 수 있도록 기본 구조를 함께 다룸
학습 목표
- Email 주소와 Domain의 관계를 이해할 수 있음
- Domain을 기준으로 메일이 전달되는 구조를 이해할 수 있음
- Email 흐름에서 Domain이 가지는 역할을 파악할 수 있음
Domain과 Email 구조
Email 전송은 사용자 단위가 아니라 Domain 단위로 처리됨.
메일 주소에 포함된 도메인은 전달 경로를 결정하는 기준으로 사용됨
메일은 특정 사용자에게 직접 전달되는 것이 아니라, 먼저 해당 도메인을 담당하는 서버로 전달된 뒤 내부에서 사용자에게 분배되는 구조를 가짐
Email 주소와 Domain
Email 주소는 local-part@domain 형태로 구성됨
local-part: 사용자 식별자domain: 메일을 처리할 서버를 식별하는 정보
예를 들어 user@example.com에서 example.com은 메일을 수신할 서버를 찾기 위한 기준으로 사용됨
메일 전달 과졍에서 경로 결정은 domain을 기준으로 수행되며, 사용자(local-part)는 전달 경로 선택에 사용되지 않음
Domain 기반 전달 구조
메일 전송 흐름은 도메인을 기준으로 구성됨
- 발신 서버는 수신자의 domain을 기준으로 대상 서버를 조회
- 조회된 서버로 메일을 전달
- 수신 서버 내부에서 사용자 계정으로 분배
이 흐름은 MTA 동작과 직접 연결됨
Relay 단계에서 MTA는 수신자의 domain을 기준으로 다음 전달 대상 서버를 선택함
전송 구조는 다음과 같이 정리됨:
- 도메인 단위로 전달 경로 결정
- 서버 단위로 메일 전달 수행
- 사용자 단위로 최종 분배
이후 DNS(MX) 조회와 Email 인증 메커니즘이 동작함
DNS와 Email 전달
Email 전송에서 DNS는 전달 경로를 결정하는 역할을 수행함.
발신 서버는 수신자의 도메인을 기준으로 DNS 조회를 수행하고, 그 결과를 바탕으로 메일을 전달할 대상 서버를 선택함
이 과정은 Relay 단계에서 수행되며, 실제 메일 전달 흐름과 직접 연결됨
MX 레코드 역할
MX 레코드는 특정 도메인의 메일을 처리하는 서버를 지정하는 레코드임
[ DNS Response ]
메일을 전송하려는 서버는 수신자의 도메인에 대해 MX 레코드를 조회하고, 해당 도메인의 메일 서버 목록을 확인함
이대 반환되는 값은 단일 서버가 아니라, 여러 개의 메일 서버일 수 있음.
각 서버는 우선순위와 함께 제공되며, 전달 대상 선택 기준으로 사용됨
MX 레코드는 Email 전송에서 다음 서버를 결정하는 기준이 되며, 일반적인 웹 트래픽에서 사용하는 A 레코드와는 목적이 다름
MX 우선순위
MX 레코드는 우선순위 (priority) 값을 포함함
이 값은 메일 서버 선택 순서를 결정하는 기준으로 사용됨
- 숫자가 낮을수록 높은 우선순위
- 동일 도메인에 여러 MX 레코드 존재 가능
전송 서버는 우선순위가 가장 높은 서버부터 연결을 시도함.
해당 서버가 응답하지 않거나 전달이 실패할 경우, 다음 우선순위 서버로 전달을 시도함
이 구조를 통해 메일 시스템은 장애 상황에서도 전달 경로를 유지할 수 있음
메일 라우팅 흐름
메일 전달 과정에서 DNS 조회는 다음 흐름으로 수행됨
- 수신자의 domain 추출
- 해당 domain의 MX 레코드 조회
- 반환된 MX 목록 중 우선순위 기준 서버 선택
- 선택된 서버로 SMTP 연결 및 메일 전달
이 과정은 MTA에서 수행되며, Email 전송 경로를 결정하는 핵심 단계
메일은 이 흐름을 따라 전달되며, 중간에 여러 MTA를 거치는 경우에도 동일한 방식을 다음 전달 대상이 결정됨
Email 관련 DNS 레코드
Email 전송에서는 DNS는 단순 이름 해석이 아니라, 메일 처리와 인증에 필요한 정보를 함께 제공함.
메일 흐름에서는 특정 레코드만 사용되며, 각각의 역할이 구분되어 동작함
🔸MX 레코드
MX 레코드는 특정 도메인의 메일을 처리할 서버를 지정하는 레코드
메일을 전송하려는 서버는 수신자의 도메인을 기준으로 MX 레코드를 조회하고, 반환된 메일 서버 목록 중 하나를 선택하여 전달을 수행함.
MX 레코드는 여러 개의 레코드가 함께 설정될 수 있으며, 우선 순위 값을 기준으로 전달 대상이 결정됨
MX 레코드에서 확인되는 정보
▪️ 도메인 이름
▪️ 레코드 타입 (MX)
▪️ 우선 순위
▪️ 메일 서버 호스트 이름메일 서버는 호스트 이름 형태로 반환되며, 실제 연결을 위해서는 해당 호스트에 대한 A 레코드 추가로 조회하게 됨.
🔸TXT 레코드 (SPF/DMARC)
TXT 레코드는 문자열 형태의 데이터를 저장하는 레코드
[ DNS Response ]
Email에서는 발신 검증과 정책 전달에 사용됨
대표적으로
SPF- 해당 도메인에서 메일을 보낼 수 있는 서버 목록을 정의하는 구조
- 발신 서버의 정당성 확인에 사용
DMARCSPF와DKIM결과를 기반으로 정책을 적용하는 구조- 인증 실패 시 처리 방식과 리포트 수신 정보 포함
TXT 레코드는 전달된 메일의 신뢰성을 판단하는 기준으로 사용됨
🔸CNAME 레코드 (DKIM)
CNAME 레코드는 특정 모데인을 다른 도메인으로 매핑하는 레코드
[ DNS Response ]
Email에서는 DKIM 서명 검증을 위한 키 조회에 사용됨
DKIM은 메일에 포함된 서명을 검증하기 위해 공개키를 필요로 하며, 이 키는 DNS를 통해 조회됨.
이때 실제 키는 공급사 도메인에 존재하고, CNAME 레코드를 통해 해당 위치로 연결됨
수신서버는 DKIM 검증 과정에서
- 도메인에서 지정된 selector를 기준으로 DNS 조회 수행
- CNAME을 통해 실제 키가 있는 위치로 이동
- 해당 위치에서 공개키를 조회하여 서명 검증 수행
이 구조를 통해 DKIM 키 관리와 검증이 이뤄짐
Email 인증과 DNS
Email 인증은 도메인을 기준으로 수행됨. 인증에 필요한 정보는 DNS에 저장되며, 수신 서버는 해당 정보를 조회하여 메일의 신뢰성을 판단함
인증은 메일 전송 이후 단계에서 수행되며, 전달된 메시지와 DNS 정보를 비교하는 방식으로 동작함
⭐정리 포인트
- SPF → 발신 서버 검증
- DKIM → 메시지 서명 검증
- DMARC → 정책 및 최종 처리
🔹SPF 구조
SPf: Sender Policy Framework는 발신 서버가 해당 도메인을 대표하여 메일을 보낼 수 있는지 검증하는 방식
수신 서버는 메일을 수신하면서 서버의 IP 주소와 발신 도메인을 확인하고, DNS에서 SPF 정책 (TXT 레코드)을 조회함
이후 해당 IP가 정책에 포함되어 있는지를 비교하여 허용 여부를 판단함
SPF 검증 요소
- 발신 도메인
- 발신 서버 IP
- DNS에 정의된 SPF 정책
SPF는 전송 경로 기준 검증이며, 메일 내용 자체는 검증하지 않음.
🔹DKIM 구조
DKIM: DomainKeys Identified Mail은 메일에 포함된 서명을 기반으로 메시지 무결성과 도메인 책임성을 검증하는 방식
발신서버는 메일에 전자서명을 추가하며, 이 서명은 도메인과 연결된 개인키로 생성됨
수신 서버는 메일을 수신한 뒤 서명을 추출하고, DNS에서 공개키를 조회하여 서명의 유효성을 검증함
이 과정에서 공개키는 DNS TXT 레코드에 저장되며, CNAME을 통해 외부 도메인으로 연결되는 구조를 사용할 수 있음
DKIM 검증 요소
- 메일 서명 (DKIM-Signature)
- selector 및 domain 정보
- DNS에 저장된 공개키
🔹DMARC 구조
DMARC: Domain-based Message Authentication, Reporting and Conformance는 DKIM 결과를 기반으로 정책을 적용하는 구조
수신 서버는 SPF와 DKIM 검증 결과를 확인하고, 발신 도메인과 정렬(alignment)을 평가한 뒤, DNS에 정의된 DMARC 정책에 따라 메일을 처리함
DMARC 레코트에 포함되는 정보
- 정책 (none / quarantine / reject)
- 보고서 수신 주소 (rua)
- 정렬 기준
DMARC는 인증 결과를 조합하여 최종 처리 방식을 결정하는 역할
⭐운영 핵심 포인트
DNS 설정은 Email 전달과 인증에 직접적인 영향을 주기 때문에, 단순 설정이 아니라 운영 기준으로 관리되어야 함.
특히, MX, TXT(SPF,DMARC), CNAME(DKIM)은 서로 연결되어 동작하므로, 전체 흐름을 기준으로 관리하는 것이 중요함
MX 설정
MX 레코드는 메일 전달 경로를 결정하는 핵심 요소이기 때문에 설정 오류가 발생하면 메일이 전달되지 않거나, 예상하지 못한 서버로 전달될 수 있음
확인해야할 항목
- MX 레코드가 실제 메일 서버를 가르키는지 확인
- 여러 MX가 존재할 경우 우선순위 설정이 의도대로 구성되었는지 확인
- MX에 이정된 호스트가 실제로 SMTP 수신이 가능한 상태인지 확인
또한 MX 레코드는 도메인 단위로 적용되므로, 서브도메인이나 별도 도메인을 사용하는 경우 각각 개별 설정이 필요함
SPF 설정
SPF는 발신 서버 검증에 사용되므로, 실제 메일을 발송하는 모든 시스템이 포함되어야 함.
일부 발신 서버가 누락되면 정상 메일도 인증 실패로 처리될 수 있음
확인해야할 항목
- 자사 메일 서버뿐 아니라 외부 서비스 (메일 발송 서비스, CRM 등)가 포함되어 있는지 확인
- include 구문을 통해 외부 서비스 SPF를 정확히 참조하고 있는지 확인
- 정책 (
~all,-all)이 운영 단계에 맞게 설정되어 있는지 확인
SPF는 전달 과정에서 변경이 발생할 수 있으므로, 포워딩 환경에서는 인증 결과가 달라질 수 있음
DNS 변경 및 검증
DNS 설정은 변경 이후 즉시 반영되지 않으며, TTL(Time To Live)에 따라 일정 시간 동안 기존 값이 유지될 수 있음
변경 이후 반드시 확인해야할 항목
- DNS 조회를 통해 실제 레코드가 정상적으로 반영되었는지 확인
- 메일 헤더를 통해 SPF / DKIM / DMARC 결과가 기대값과 일치하는지 확인
- 메일 송수신 테스트를 통해 실제 전달 흐름이 정상 동작하는지 확인
DNS는 Email 전송의 기반이 되는 요소이기 때문에, 변경 시에는 반드시 검증 과정을 포함해야 함.
정리
Email 전송에서 DNS는 전달 경로와 인증에 필요한 정보를 제공하며, 수신 버서는 이를 기반으로 메일의 신뢰성을 판단함
메일은 수신자의 도메인을 기준으로 전달 대상 서버를 선택하고, DNS에서 MX 레코드를 조회하여 메일 서버를 확인함.
이후 선택된 서버에 대해 A 레코드를 조회하고, 해당 IP로 SMTP 연결이 수행됨
전달 과정에서 DNS는 메일 처리에 필요한 정보를 함께 제공함.
MX는 전달 경로를 정의하고, TXT는 정책과 인증 정보를 제공하며, CNAME은 DKIM키 조회를 위한 연결 역할을 수행함
메일이 수신 서버에 도달하면 DNS에 저장된 정보를 기반으로 인증이 수행됨
SPF는 발신 서버를 검증하고, DKIM은 메시지 서명을 검증하며, DMARC는 이 결과를 기반으로 처리 정책을 결정함
이 구조를 통해 Email은
- 전달 경로는 MX로 결정되고,
- 신뢰 검증은 TXT와 CNAME 기반으로 수행되며,
- 최종 처리는 DMARC 정책에 따라 결정됨
전체 흐름은 다음과 같음
Domain → MX 조회 → Mail Server 선택 → A 조회 → SMTP 전달
↓
SPF / DKIM / DMARC 검증