SMTP는 1982년에 설계됐다. 발신자 검증이라는 개념 자체가 없었다. “From” 필드에 아무거나 넣으면 수신 서버가 그냥 받아들였다. 인터넷에 호스트가 수백 개뿐이고 서로 얼굴을 아는 시절에는 그래도 괜찮았다.
지금은 1982년이 아니다.
목록만 필요해서 들어왔다면 여기 있다. 다섯 중 엄밀한 의미의 인증은 셋이다. SPF는 이 도메인으로 메일을 보내도 되는 서버를 밝히고, DKIM은 메시지에 서명하고, DMARC는 그 둘을 눈에 보이는 From 주소에 묶은 뒤 실패하면 어떻게 처리할지 수신 서버에 알려준다. 나머지 둘은 그 위에 얹힌다. MTA-STS는 전달 구간의 연결을 보호하고, BIMI는 DMARC를 집행하는 도메인에 로고를 붙여준다. 이 글은 거기까지 오는 데 왜 다섯 조각이 필요했는지에 대한 이야기다.
땜질의 시작
첫 번째 수정 시도는 SPF (2006). 아이디어는 단순했다. DNS 레코드에 “이 도메인으로 메일 보낼 수 있는 서버 목록”을 게시하고, 수신 서버가 확인해서 허가되지 않은 발신자를 거부하는 것.
주의: SPF에는 DNS 조회 10회 제한이 있다. 넘기면 검사 결과가 통과가 아니라 영구 오류(permerror)로 나오고, 많은 수신 서버가 이걸 실패와 똑같이 취급한다. 반송 메일 같은 건 오지 않는다. 검사 도구나 DMARC 리포트를 봐야 비로소 안다.
SPF에는 근본적인 결함이 하나 있다. 이메일이 포워딩되면 깨진다. 상대의 옛 학교 메일 주소가 Gmail로 자동 전달되도록 설정돼 있다고 해보자. 학교 서버는 당신 메일을 자기 IP에서 다시 보낸다 — 당신 도메인의 SPF 레코드에 없는 IP다. 정상적인 메일이 SPF 검증에 걸린다. 엣지 케이스가 아니다. 이메일이 원래 이렇게 작동한다.
그래서 DKIM (2007)을 만들었다. 발신 IP 대신 암호화 서명을 쓴다. 발신 서버가 본문과 지정한 헤더 몇 개에 개인키로 서명하고, 공개키를 DNS에 게시한다. 수신 서버가 서명을 검증한다. 단순 포워딩으로는 깨지지 않는다. 서명이 메시지와 함께 이동하니까.
DKIM은 작동한다. 문제는 SPF와 DKIM이 독립적으로 돌아간다는 것. 한 도메인이 SPF는 통과하고 DKIM은 실패할 수 있다. 반대도 마찬가지. 하나는 통과하고 하나는 실패할 때 뭘 해야 하는지 정해진 정책이 없다. 리포팅 메커니즘도 없다. 수신 서버에게 “둘 다 실패하면 거부해”라고 알릴 방법이 없다.
DMARC (2012) 등장. DMARC는 SPF와 DKIM 위에 올라가는 정책 레이어다. 수신 서버에게 “인증 실패 시 이렇게 처리해”라고 알려준다 — none, quarantine, reject. 리포팅도 추가돼서 누가 내 도메인으로 메일을 보내는지 볼 수 있다. 업계 규격으로 시작해 2015년에야 정보성 RFC(7489)가 됐고, 표준 트랙에 오른 건 2026년 5월 RFC 9989에 와서다.
DMARC가 이야기의 끝이었어야 했다. 아니었다.
스택은 계속 쌓인다
MTA-STS (2018)는 완전히 다른 문제를 해결한다. SPF, DKIM, DMARC가 다 있어도 실제 메일 전송은 암호화 없이 일어날 수 있다. SMTP의 STARTTLS 업그레이드는 선택적이라서 중간자가 벗겨버릴 수 있다. MTA-STS는 도메인이 “검증된 TLS로만 전달하라”고 요구할 수 있게 해준다. 웹에서 HSTS가 하는 것과 비슷하다.
대형 메일 사업자 밖에서는 MTA-STS를 보기 어렵다. 이걸 들여다볼 이유가 한 번도 없었던 메일 관리자도 많다.
BIMI가 최신 추가분인데, RFC조차 아니다. 아직 IETF 초안인 것을 메일 사업자들이 먼저 가져다 쓴 것이고, Gmail이 BIMI 로고를 본격적으로 보여주기 시작한 건 2021년이다. 받은편지함에서 이메일 옆에 브랜드 로고를 보여준다 — 단, DMARC가 p=quarantine이나 p=reject일 때만. 본질적으로 DMARC 도입을 유도하기 위한 당근이다. 보안 가치는 논쟁의 여지가 있고, 마케팅 가치는 확실하다.
왜 SMTP를 교체하지 않나?
누구나 하는 질문인데 아무도 실행에 옮기지 않는다.
답은 IPv6가 1998년에 표준이 됐는데 아직도 IPv4를 쓰는 것과 같은 이유다. 전환 비용. 전 세계 모든 이메일 서버가 SMTP를 쓴다. 교체하려면 모든 메일 사업자가 동시에 움직여야 한다. 그런 일은 일어나지 않는다.
그래서 40년 된 기반 위에 프로토콜을 계속 쌓는다. 각각은 특정 결함을 고친다. 근본 문제는 아무것도 못 고친다 — SMTP는 신뢰가 기본값인 세상을 위해 설계됐다.
현재 상황
프로토콜이 다섯 개인데, 대부분의 도메인이 전부 제대로 설정하지 못하고 있다:
| 프로토콜 | 연도 | 채택 | 현실 |
|---|---|---|---|
| SPF | 2006 | 높음 | 잘못 설정되는 경우가 많다. 10회 조회 제한이 큰 설정을 소리 없이 깨뜨림 |
| DKIM | 2007 | 중간 | 기술적으로는 건전하지만, alignment 확인 없이 키만 게시하는 곳이 많음 |
| DMARC | 2012 | 중간 | p=none으로 배포하는 곳이 많다 — “감시만 하고 차단 안 함.” 장식 |
| MTA-STS | 2018 | 낮음 | well-known 파일 + DNS 레코드가 필요. 마찰이 너무 큼 |
| BIMI | 2021년경 (초안) | 매우 낮음 | Gmail·Apple Mail은 유료 마크 인증서(VMC, Gmail은 CMC도 허용)를 요구. 주로 대형 브랜드 |
도구는 존재하는데 도입이 가용성보다 수년 뒤처지는 시스템. “RFC로 발표됨”과 “실제 배포됨” 사이의 간극에 대부분의 이메일 보안 문제가 산다.
여섯 번째 프로토콜은 오지 않는다. 지금 있는 다섯 개로 충분하다 — 사람들이 실제로 쓰기만 하면.