이메일이 실제로 어떻게 동작하는지, SMTP·MX·SPF·DKIM·DMARC·스팸 필터·TLS까지 그 복잡한 내부 구조를 파헤쳐 본다.
Saurabh “Sam” Khawase Sam Khawase
25 Apr 2026
11 min read
이메일 인프라를 정확하게 묘사한 모습
나는 본업에서 이메일 시스템을 일상적으로 접하고, 이메일이 내부적으로 어떻게 동작하는지 자주 궁금해하곤 한다. 이 블로그 글은 그 세계를 파고든 결과물이다.
이메일은 지금까지 만들어진 가장 성공적인 커뮤니케이션 기술 중 하나이며, 매일 수십억 통의 이메일이 전송된다1. 그중 거의 절반은 스팸이고, 4분의 1은 마케팅 이메일이다. 그럼에도 불구하고 상당수는 비밀번호 재설정, 알림, 경고 등과 같은 트랜잭션성 이메일이다. 이메일의 아름다움은, 이메일 인프라를 움직이는 정신 나간 수준의 복잡성에도 불구하고 그냥 잘 작동한다는 데 있다.
이메일은 수년에 걸쳐 유기적으로 진화했으며, 그 기원은 1970년대 ARPANET의 학술 연구실로 거슬러 올라간다. 그 다양한 구성 요소는 서로 다른 사람들이, 서로 다른 시기에, 서로 다른 문제를 마주하며 설계했다. 이메일 생태계는 그 다양한 프로토콜을 규정하는 RFC가 100개 이상 존재하는 매우 복잡한 괴물이다.
Alice와 Bob의 고전적인 예시를 통해, 이 1970년대 기술이 어떻게 동작하는지 깊이 들어가 보자.
간단해 보이는가? 사실 전혀 그렇지 않다. 여기에는 엄청난 복잡성과 보안상의 함정이 너무도 뻔하게 숨어 있다. 실제로 내부에서 무슨 일이 벌어지는지 더 깊이 들어가 보자.
Alice가 보내기 버튼을 누를 때, 메일 클라이언트가 이메일을 보내는 것은 아니다. 단지 제출 할 뿐이다. 포트 587에서 대기 중인 서버 위의 Mail Submission Agent가 인증을 확인하고 message-ID를 찍는다. 이 시점에서 Alice의 클라이언트 역할은 끝나고, 이메일은 이제 다른 누군가의 문제가 된다.
그 다른 누군가는 Mail Transfer Agent, 즉 우체부다. 그 역할은 수신자의 주소를 찾아 메시지를 그곳에 배달하는 것이다. 이를 위해 MTA는 인터넷의 주소록인 DNS 시스템을 사용한다. DNS에 이런 질문을 한다. “이 도메인의 MX 레코드는 무엇인가?”
MX, 즉 Mail Exchanger 는 이메일 라우팅에 사용되는 특별한 유형의 DNS 레코드다. 이메일을 수신하려는 모든 도메인은 이를 공개해야 한다.
이런 식으로 생겼다:
example.com. IN MX 10 mail.example.com.
example.com. IN MX 20 mail2.example.com.
참고: 숫자 10, 20은 우선순위를 나타낸다.
mail.example.com이 다운되면, 송신 서버는 자동으로mail2.example.com을 시도한다.
대부분의 사람들은 이메일이 실시간이라고 생각하지만, 사실 그렇지 않다. 이메일은 재시도 로직이 있는 큐잉 시스템이다. 목적지 서버가 다운되어 있으면, 메시지는 큐에 머무르며 5분, 30분, 1시간 식으로 지수적 백오프로 재시도되고, 이렇게 4-5일 동안 계속될 수 있다. Bob이 Alice의 이메일을 즉시 받는다면, 아마 큐가 매우 빨리 비워졌기 때문일 것이다. 이메일은 속도를 신경 쓰지 않는 최종적 일관성 시스템이지만, 현대의 이메일 인프라는 그것이 엄청나게 빠른 것처럼 느껴지게 만든다.
송신 서버가 MX 조회 후 목적지를 찾으면 SMTP 연결을 연다. SMTP는 그냥 평문 텍스트다. 사실 누구나 터미널에서 직접 입력할 수 있다.
$ telnet smtp.example.com 587
220 smtp.example.com ESMTP
EHLO localhost
250 Hello
MAIL FROM:<[email protected]>
250 OK
RCPT TO:<[email protected]>
250 OK
DATA
354 Go ahead
From: [email protected]
Subject: Urgent: Verify Your Account
Click here immediately.
.
250 Message accepted
참고: 서버들은 메시지가 어디서 끝나는지 어떻게 알까? 자기 줄에 홀로 있는 마침표 하나
.로 알 수 있다. 이메일은 이런 자잘한 기묘함으로 가득하다.
눈치 빠른 독자라면 앞선 이메일에서 불일치를 발견했을지도 모른다. MAIL FROM: 에는 [email protected] 이라고 되어 있는데, 메시지 내부의 FROM: 헤더에는 [email protected] 이라고 적혀 있다. 안타깝게도 이것은 오류가 아니며, SMTP에 따르면 둘은 달라도 된다. 첫 번째(MAIL FROM:)는 서버가 라우팅에 사용하는 봉투 정보이고, 두 번째(From:)는 사람이 이메일을 읽을 때 보는 헤더다. 봉투는 실제 편지 겉면에 적힌 주소와 같고, 헤더는 편지에 적힌 발신자 서명과 같다. SMTP는 둘이 일치하는지 확인하지 않는다.
왜 이렇게 되어 있는지 궁금할 수도 있다. SMTP는 1970년대 후반2과 1980년대 초반3, 신뢰를 기반으로 하던 학술 협력 네트워크4를 위해 설계되었다. 당시에는 미래에 인터넷 뱅킹이 존재하리라고 아무도 상상하지 못했을 것이다. 이 노골적인 허점이 바로 피싱과 스팸이 먹히는 이유다.
좋은 것은 오래가지 않으며, 스패머들이 이 틈을 악용하는 데는 오래 걸리지 않았다. 피싱과 스팸이 폭발적으로 늘어나자, 업계의 대응은 SMTP를 고치는 것이 아니라 덕트 테이프를 더 붙이는 것이었다. 그때쯤 SMTP는 이미 너무 깊게 자리 잡았고 어디에나 배포되어 있었다. 그래서 전형적인 소프트웨어 개발 방식답게, 수년에 걸쳐 세 개의 별도 시스템이 발명되어 위에 덧붙여졌다. 이 세 총사를 살펴보자.
송신 도메인은 자신을 대신해 이메일을 보낼 수 있도록 허가된 IP 주소 목록을 공개한다. 권한 없는 도메인에서 이메일이 도착하면, 의심스러운 것으로 표시된다. SPF는 빠르고 단순하지만, 큰 결함 하나도 숨기고 있다. Bob이 Charlie에게 이메일을 전달하면, 전달 도메인이 원래 도메인의 SPF 레코드에 없기 때문에 SPF는 실패한다5. 무해한 이메일 전달이 스푸핑 시도로 바뀌는 것이다.
SPF 레코드는 이렇게 생겼다(TXT 레코드로 저장된다):
example.com. IN TXT "v=spf1 ip4:203.0.113.1 include:_spf.google.com ~all"
몇 년 후 SPF의 한계를 극복하기 위해 DKIM이 도입되었다. 송신 서버는 개인 키를 사용해 모든 발신 메시지에 암호학적 서명을 한다. 공개 키는 DNS에 DKIM 레코드로 저장된다. 그러면 어떤 수신 서버든 공개 키를 가져와 서명을 검증할 수 있다. 메시지가 변조되었다면 검증은 실패한다. 이 혁신 덕분에 DKIM은 전달 과정에서도 살아남지만, 대신 또 다른 문제를 추가한다. DKIM 서명은 만료되지 않는다. 공격자가 2020년에 서명된 이메일을 손에 넣고 재전송해도 서명 검사는 통과한다. 이 프로토콜에는 타임아웃이나 만료라는 개념이 전혀 없다.
DKIM 레코드는 이렇게 생겼다:
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3v4yMx1C8WnSBsz0WMH..."
DMARC는 이 문제를 해결하고 SPF와 DKIM을 하나로 묶기 위해 등장했다. SPF는 봉투 주소를 검사하고, DKIM은 서명을 검사하지만, 둘 다 사용자가 보는 From: 헤더는 검사하지 않는다. DMARC는 정렬(alignment)을 도입한다. 즉, From: 헤더는 SPF 또는 DKIM이 검증한 도메인과 일치해야 한다. DMARC는 또한 검사 실패 시 수신 서버가 무엇을 해야 하는지도 알려준다. 가질 수 있는 값은 다음과 같다:
none: 아무것도 하지 않고 보고만 함quarantine: 스팸으로 보냄reject: 완전히 차단함DMARC는 또한 자신을 사칭하려고 한 모든 서버 목록을 담은 일일 XML 보고서를 도메인 소유자에게 되돌려 보낸다. 다음은 DMARC 레코드의 예시다:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100"
SPF, DKIM, DMARC는 복잡한 시스템이며, 이 글의 범위를 벗어난다. 셋은 함께 잘 작동하지만, 각각 별도의 DNS 설정과 세밀한 유지보수가 필요한 서로 다른 세 시스템이다. 각각에는 사람이 잘못 설정하기 쉬운 많은 경우의 수가 있다. 그럼에도 이메일 신원의 신뢰망은 이 셋 위에 세워져 있다. 이 장치가 대부분의 시간에 꽤 잘 작동한다는 사실은 인상적이면서도(그리고 불안할 정도로) 놀랍다.
세 가지 인증 검사를 모두 통과했다고 해도, 이메일은 아직 전달된 것이 아니다. 스팸과 피싱의 기하급수적 증가는 모든 수신 서버가 이메일을 필터링 계층에 통과시켜야 함을 의미한다. 여기에 표준은 없으며, 각 제공자는 자신만의 맞춤형 방식을 사용한다. 시스템은 대체로 다음으로 구성된다:
송신 IP에는 Spamhaus 같은 제3자가 유지하는 지속적인 점수가 있다. 이를 IP의 과거 성적표라고 생각하면 된다. 공유 호스팅 플랫폼에 있고 다른 고객이 지난달 스팸을 보냈다면, 당신의 IP는 그 평판을 물려받는다. 사실 새로운 IP 주소에는 아예 평판이 없고, 새 메일 서버가 어느 정도 평판을 쌓는 데는 종종 몇 주가 걸린다. 이것이 AWS 같은 플랫폼이 AWS SES 요청 승인에 매우 신중한 이유다.
IP 평판 외에도 Google과 Microsoft는 수신자가 당신의 도메인에서 온 메일과 어떻게 상호작용하는지 추적한다. 높은 스팸 신고율과 낮은 참여도는 평판을 곤두박질치게 만든다.
스팸 필터는 이메일 콘텐츠도 스캔하고 수천 개의 규칙6에 따라 메시지에 점수를 매긴다. 스팸과의 싸움은 끝없는 소모전이며, 이러한 규칙은 수십 년 동안 엄청나게 진화해 왔다. LLM이 등장하기 전부터도 ML 모델이 대부분의 힘든 일을 해오고 있었다. 이는 그 논리가 필터를 운영하는 사람들에게조차 대체로 불투명하다는 뜻이다.
스팸과 피싱이 있다면, 바이러스도 멀지 않다. 방화벽 계층은 첨부파일에서 멀웨어 시그니처도 검사한다. 일부 제공자는 이런 의심스러운 이메일을 테스트하고 피해 반경을 연구하기 위한 전용 샌드박스를 갖고 있다.
어느 하나도 우연에 맡기지 않으며, 이메일 안의 링크조차 차단 목록과 대조해 검사한다. 일부 제공자는 메시지에 있는 모든 링크를 다시 써서, 클릭이 자신들의 보안 프록시를 거치도록 만든다.
이메일 서버가 URL을 다시 쓰고 텍스트를 스캔한다면, 우리의 이메일은 선로 위에서 평문으로 전송되고 있는 걸까? 좋은 소식은, 그렇다. 이메일은 TLS 표준을 사용한다. 나쁜 소식은, 당신이 생각하는 방식은 아니라는 점이다.
이메일은 Opportunistic TLS라는 것을 사용한다. 송신 서버는 수신 서버가 STARTTLS 를 지원하는지 확인하고, 지원하면 평문 연결을 암호화된 연결로 업그레이드한다. 수신자가 지원하면 암호화를 협상하고 안전하게 진행한다. 수신자가 지원하지 않으면? 음, 아무 일도 없었던 것처럼 평문으로 되돌아가 계속 진행한다.
클라이언트-서버 간 연결(예: Gmail/Outlook)에서는 사실상 필수지만, 서버-서버 연결에서는 여전히 기회주의적이다. 핵심은 TLS가 연결만 암호화할 뿐, 내용을 종단 간으로 암호화하지는 않는다는 점이다. 메일 서버는 항상 당신의 이메일을 읽어 왔고, 시스템은 원래 그렇게 설계되었다. 그래서 앞서 설명한 방화벽 계층이 작동할 수 있는 것이다.
MTA-STS, DANE, S/MIME 같은 표준은 제안되고 있는 반창고들이지만, 채택률은 매우 낮다. 우리가 이야기하는 것은 매일 수십억 통의 이메일을 처리하는 인프라라는 점을 기억하라.
이 모든 계층과 필터를 거치고 나면, 당신의 이메일에는 다음 셋 중 하나가 일어난다:
옵션 2는 트랜잭션성 이메일을 보내는 사람에게 악몽 같은 시나리오다. 서버는 메시지를 수락했고, 아무 문제도 없다고 말했으며, 그 후 그냥 묻어버렸다. RFC 5321은 이것을 금지하지 않는다. 완전히 합법적인 동작이다.
이메일은 1970년대의 삐걱거리는 오래된 Terminator 같은 존재다. 불평도 없이 계속 작동한다. 더는 존재하지 않는 세상을 위해 설계되었고, 선택적 암호화, 내장 인증 부재, 위에 덧대어진 3개 이상의 개조 보안 계층, 표준화되지 않은 필터링 계층, 그리고 수많은 다른 기묘함을 가지고 있다. 그런데도 매일 수십억 통의 이메일이 정확하게 도착한다.
이메일은 우아하지는 않지만, 그럼에도 Lindy하다7. agentic AI8의 새로운 시대에는, 이것이 또 다른 차원으로 변태해 갈 것이라고밖에 예상할 수 없다.
https://www.statista.com/statistics/456500/daily-number-of-e-mails-worldwide/↩
전달 서버가 Return-Path 를 올바르게 작성하면 동작할 수도 있지만, SRS를 구현하면 SPF alignment가 깨지고, 그로 인해 DKIM이 실패하고, 이어서 DMARC도 연쇄적으로 실패한다. 내가 말했듯이, 수백 개의 RFC와 엄청난 양의 덕트 테이프가 이 시스템을 붙들고 있다. ↩
https://cwiki.apache.org/confluence/display/SPAMASSASSIN/HowScoresAreAssigned↩
© 2026 Sam Khawase
512KB Club· powered by Astro