이메일은 매일 수십억 통씩 오가지만, 그 내부에서 어떤 일이 일어나는지 아는 사람은 많지 않습니다. 이 글에서는 이메일이 기기에서 상대방에게 전달되기까지의 과정과, 스팸·피싱으로부터 이메일을 지키는 보안 기술까지 차근차근 살펴보겠습니다.
이메일의 기본 구조: MUA, MTA, MDA
먼저 여러분은 MUA(메일 사용자 에이전트, Mail User Agent)를 사용해 기기에서 이메일을 읽고 보냅니다. Gmail이나 애플 기기의 기본 메일 앱이 대표적인 예로, 이런 프로그램은 사용자가 실행하는 동안에만 활성화됩니다.
일반적으로 MUA는 MTA(메일 전송 에이전트, Mail Transfer Agent)와 통신합니다. MTA는 메일 서버, MX 호스트, 메일 익스체인저라고도 불리며, 이메일을 받아 저장하는 역할을 담당합니다.
여러분이 MUA를 열어 메일함을 확인하기 전까지, 이메일은 원격 서버에 저장되어 있습니다. 그리고 실제로 받는 사람에게 메일을 배달하는 것은 MDA(메일 전달 에이전트, Mail Delivery Agent)이며, 보통 MTA와 함께 패키지 형태로 제공됩니다.
이메일 프로토콜의 변천사
SMTP: 이메일 전송의 표준
과거에는 메일이 SMTP(단순 메일 전송 프로토콜, Simple Mail Transfer Protocol)를 통해 메일 서버로 전송되었습니다. SMTP는 이메일을 위한 통신 프로토콜입니다.
지금도 Microsoft Exchange 같은 사유 시스템이나 Gmail 같은 웹메일 서비스는 내부적으로 자체 프로토콜을 사용하지만, 시스템 외부로 메시지를 전송할 때는 SMTP를 사용합니다. 예를 들어 Gmail 사용자가 Outlook 사용자에게 메일을 보낼 때가 그렇습니다.
POP3: 다운로드 방식의 시작
서버에 도착한 메일은 POP3(우체국 프로토콜, Post Office Protocol)를 통해 다운로드되었습니다. POP3는 애플리케이션 계층 프로토콜로, IP 네트워크를 통해 사용자 애플리케이션이 메일 서버의 메일함에 접속할 수 있게 해줍니다. 서버에 연결해 메시지를 가져와 클라이언트 컴퓨터에 저장하고, 서버에서 삭제하거나 보관할 수 있습니다.
POP3는 전화 접속(다이얼업)처럼 불안정하고 임시적인 인터넷 연결 환경을 고려해 설계되었습니다. 즉, 연결된 동안에만 메일을 받아오고, 오프라인 상태에서도 받아온 메시지를 볼 수 있었죠. 다이얼업이 널리 쓰이던 시절에는 이 방식이 인기가 많았습니다.
IMAP: 멀티 디바이스 시대의 해결책
현재는 IMAP(인터넷 메시지 접근 프로토콜, Internet Message Access Protocol)이 POP3를 대부분 대체했습니다. IMAP은 여러 클라이언트가同一个 메일함을 관리할 수 있게 해줍니다. 데스크톱, 노트북, 스마트폰 등 어느 기기에서 메일을 확인해도 모든 메시지가 동일하게 정리되어 있는 것이죠.
웹메일: 브라우저 하나면 충분
궁극적으로 웹메일이 두 방식을 모두 대체했습니다. 웹메일은 웹사이트에 로그인하기만 하면 어디서든 어떤 기기로든 메시지를 주고받을 수 있습니다. 다만 사용 중에는 인터넷에 연결되어 있어야 한다는 점이 필요합니다. 만약 Gmail처럼 웹사이트 자체가 MUA 역할을 한다면, SMTP나 IMAP 서버 설정을 직접 알 필요조차 없습니다.
이메일 보안은 어떻게 이루어질까?
안타깝게도 초기 이메일 프로토콜에는 보안이 제대로 내장되어 있지 않았습니다(대부분의 초기 인터넷 프로토콜이 그랬듯이). 서버들은 누가 보내든 어떤 메시지든 받아서, 최종 수신자(to: 필드의 받는 사람)에게 전달될 수 있는 다른 서버로 무조건 전달하기만 했습니다.
인터넷이 소수의 정부·연구기관의 전유물에서 전 세계가 모든 일에 사용하는 인프라로 확장되면서, 문제는 예상대로 터졌습니다. 스팸과 피싱 메일은 곧 모든 사람에게 큰 골칫거리가 되었고, 지금도 그렇습니다.
이에 대응해 우리는 두 가지 방향의 조치를 collectively 도입했습니다. 하나는 타인이 메시지를 읽지 못하게 하는 암호화(encryption), 다른 하나는 메시지가 실제로 명시된 발신자에게서 왔음을 검증하는 인증(authentication)입니다.
TLS: 전송 중 암호화
대부분의 시스템은 TLS(전송 계층 보안, Transport Layer Security)를 사용합니다. TLS는 SSL(보안 소켓 계층)을 대체한 암호화 프로토콜로, 전송 중인 데이터를 암호화합니다. 다만 메시지가 전송되는 동안만 보호할 뿐, 저장 상태(at rest)의 데이터, 예컨대 여러분 컴퓨터에 저장된 메일까지 보호하지는 않습니다.
TLS 덕분에 MTA 간에 메시지가 이동하는 동안 변조되거나 엿보이는 일은 막을 수 있습니다. 하지만 전송 경로에서 메시지가 수정되지 않았다는 것까지 검증해주지는 않습니다.
예를 들어 이메일이 최종 목적지에 도착하기 전 여러 메일 서버를 거친다면, TLS는 서버 간 구간의 암호화만 보장할 뿐, 각 서버가 메시지 내용을 변경할 가능성은 남아 있습니다. 이 문제를 해결하기 위해 SPF, DKIM, DMARC가 등장했습니다.
SPF(발신자 정책 프레임워크, Sender Policy Framework)
SPF는 도메인 소유자(예: google.com)가 DNS에 TXT 레코드를 설정하여, 해당 도메인에서 메일을 보낼 수 있는 서버가 어떤 것들인지 명시하도록 합니다.
SPF는 어떻게 작동하나?
이 레코드는 메일 발송이 허용된 장치들(보통 IP 기준)을 나열하며, 마지막에 다음 세 가지 옵션 중 하나로 끝납니다.
- -all: 검증 실패 시(발신 출처가 목록에 없으면) HardFail 처리. 대부분의 메일 시스템이 해당 메시지를 스팸으로 분류합니다.
- ?all: 검증 실패 시 neutral(중립) 처리. 주로 테스트 용도로 사용되며, 실제 운영 도메인에는 잘 쓰이지 않습니다.
- ~all: 검증 실패 시 SoftFail 처리. 메시지가 의심스럽지만 반드시 악성이라고 단정할 수는 없음을 의미합니다. 일부 메일 시스템은 스팸으로 표시하지만, 대부분은 그렇지 않습니다.
SPF 헤더는 메시지를 처리하는 서버 자체에도 유용합니다. 예를 들어 네트워크 경계에 있는 서버는 수신한 메시지가 발신자의 SPF 레코드에 명시된 서버에서 왔어야 한다는 것을 알 수 있어, 스팸을 더 빨리 걸러낼 수 있습니다.
그러나 좋아 보이는 만큼, SPF에는 몇 가지 중요한 한계가 있습니다.
- 처리 지침이 없음: SPF는 메일 서버에 메시지를 어떻게 처리할지 알려주지 않습니다. 따라서 SPF 검증에 실패한 메시지도 여전히 전달될 수 있습니다.
- 'From' 주소가 아닌 'Return-Path'를 검사: SPF 레코드는 사용자에게 보이는 from 주소가 아니라 return-path를 확인합니다. return-path는 편지에 적는 반송 주소와 같아서, 메일을 처리하는 서버들에게 메시지를 어디로 되돌려 보낼지 알려주며, 이메일 헤더(서버가 메일을 처리할 때 쓰는 기술 정보)에 저장됩니다.
즉, from 주소에 무엇을 적든 SPF 검사에는 영향을 주지 않으며, 실제로 해커는 두 주소를 모두 비교적 쉽게 위조(spoofing)할 수 있습니다. 암호화가 없기 때문에 SPF 헤더를 완전히 신뢰할 수 없는 이유입니다. - 지속적인 업데이트 부담: SPF 레코드는 항상 최신 상태로 유지해야 하는데, 규모가 크고 변화가 잦은 조직에서는 이것이 쉽지 않습니다.
- 메일 전달(forwarding) 시 SPF가 깨짐: google.com에서 온 메일을 bob@bobsburgers.com이 전달하면, 봉투 발신자(envelope sender)는 그대로 google.com으로 남습니다. 수신 메일 서버는 google.com을 사칭한다고 판단하지만 실제 발신지는 bobsburgers.com이므로 SPF 검증에 실패합니다. 실제로 메일이 google.com에서 왔음에도 말이죠.
특정 도메인에 SPF와 DMARC 레코드가 설정되어 있는지는 온라인 도구로 손쉽게 확인할 수 있습니다.
DKIM(DomainKeys Identified Mail)
DKIM은 SPF와 유사하게 발신 도메인의 DNS에 있는 TXT 레코드를 사용하며, 여기에 더해 메시지 자체에 대한 인증을 제공합니다. 전송 과정에서 메시지가 변조되지 않았음을 검증하는 것이 목표입니다.
DKIM은 어떻게 작동하나?
발신 도메인은 공개키/개인키 쌍을 생성하고, 공개키를 도메인의 DNS TXT 레코드에 등록합니다.
그다음 도메인의 메일 서버들(외부 경계에 있는, 도메인 밖으로 메일을 보내는 서버들, 예: gmail.com에서 outlook.com으로)이 개인키를 사용해 헤더를 포함한 메시지 본문 전체의 서명(signature)을 생성합니다.
서명 생성은 일반적으로 텍스트를 해싱(hash)하고 암호화하는 과정을 거칩니다.
수신 측 메일 서버는 DNS TXT 레코드의 공개키로 서명을 복호화한 뒤, 메시지와 관련 헤더들을 다시 해싱합니다. 여기서 관련 헤더란 발신자 인프라 내부에서 생성된 헤더들을 의미합니다. 예를 들어 gmail 서버 여러 대가 메일을 처리한 후 외부(outlook.com)로 전송된 경우가 그렇습니다.
서버는 두 해시값이 일치하는지 확인합니다. 일치한다면 메시지는 (발신자의 개인키가 유출되지 않았다면) 변조되지 않았고 명시된 발신자로부터 온 것이 맞습니다. 일치하지 않는다면, 메시지가 명시된 발신자에게서 온 것이 아니거나 전송 중 다른 서버에 의해 변경되었거나, 둘 다일 가능성이 있습니다.
DKIM은 '이 이메일이 전송 중 변조되었거나 명시된 발신자에게서 온 것이 아닌가?'라는 아주 구체적인 질문 하나에는 탁월하게 답합니다. 하지만 그게 전부입니다. 검증에 실패한 메일을 어떻게 처리해야 하는지, 어떤 서버가 메시지를 변경했는지, 어떤 변경이 가해졌는지는 알려주지 않습니다.
또한 DKIM은 일부 ISP(인터넷 서비스 제공업체)가 도메인 평판을 평가하는 데에도 사용됩니다. 스팸을 많이 보내고 있지는 않은지, 참여율이 낮지는 않은지, 메일 반송률은 얼마나 되는지 등을 판단하는 근거가 되죠.
DMARC(Domain-Based Message Authentication, Reporting & Conformance)
DMARC는 본질적으로 메일 서버에게 SPF와 DKIM 결과를 어떻게 처리할지 지시하는 정책입니다. 스스로 어떤 검사를 수행하지는 않지만, SPF와 DKIM이 수행한 검증 결과를 어떻게 다룰지 메일 서버에 알려줍니다.
참여하는 ISP는 공개된 DMARC 레코드를 확인하여 DKIM 또는 SPF 검증 실패 시 어떻게 대응할지 결정합니다. 예를 들어 사칭 피해가 잦은 브랜드는 'DKIM 또는 SPF 검증에 실패하면 메시지를 폐기(drop)하라'는 DMARC 레코드를 게시할 수 있습니다.
또한 많은 ISP가 여러분 도메인의 활동에 대한 리포트를 보내줍니다. 메일의 발신 출처와 DKIM/SPF 통과 여부가 포함되어 있어, 누군가 여러분의 도메인을 사칭하거나 메시지를 변조하는 시점을 파악할 수 있습니다.
DMARC를 도입하려면 필요에 따라 DMARC 레코드를 생성해야 합니다. 이메일 트래픽을 모니터링하며 모든 발신 소스를 파악하는 단계부터, DKIM이나 SPF 검증에 실패하는 메일은 거부(reject)하도록 조치를 요청하는 단계까지, 목적에 맞게 설정할 수 있습니다.
마무리: 완벽하지 않지만 함께 강해지는 이메일 보안
이 보안 조치들 중 어느 하나도 완벽하지 않습니다. 하지만 함께 사용하면 전 세계 이메일 시스템의 보안을 상당히 개선하는 데 기여합니다.
이런 조치를 채택하는 조직이 많아질수록(오픈소스 구현체를 쓰든 유료 제품을 쓰든) 모두에게 좋습니다. 프로토콜이나 제품이 개발된 후에 보안을 덧붙이는 것은, 처음부터 보안을 내장하는 것보다 비용이 더 들고 효과도 떨어지며 구현도 어렵기 때문입니다.
문제는 현재 인터넷이 의존하는 대부분의 프로토콜이 초기 인터넷, 즉 소수의 열성가, 과학자, 정부 관계자를 위해 설계되었다는 점입니다. 오늘날 우리는 이 네트워크 위에서 건물, 스마트 기기, 대중교통, 심지어 원자력 발전소(!)까지 운영하고 있습니다.
따라서 인터넷이 계속 확장되는 만큼, 우리가 의존하는 시스템을 지키기 위한 새로운 방법을 끊임없이 고민하고 발전시켜 나가야 합니다.