사람들이 이메일 인증을 “켜면 되는” 스택처럼 말한다.

SPF, DKIM, DMARC, MTA-STS, BIMI. 약어 5개, 체크박스 5개, 끝.

그 환상은 실제 인터넷이 어떻게 설정돼 있는지 들여다보는 순간 깨진다. 모양이 뻔해진다. 스택이 아니다. 깔때기다. 첫 번째 관문은 많은 도메인이 통과한다. 갈수록 줄어든다. 5개 전부, 올바르게 설정된 도메인을 세려고 하면 생태계를 세는 게 아니라 서류가 완비된 작은 클럽을 세고 있다.

그래서 제목의 질문. 솔직한 답은 아무도 깔끔한 숫자를 줄 수 없다는 것이고, 그 이유가 꽤 시사적이다. SPF, DMARC, MTA-STS, BIMI는 정해진 DNS 이름에 있으니 누구나 스캔할 수 있다. DKIM은 아니다. 키가 발신자가 고른 셀렉터 이름 — google._domainkey, s1._domainkey, 아무거나 — 아래에 있고, 그 목록을 뽑아낼 방법이 없다. “다섯 개 전부”를 세려는 스캔은 하나같이 다섯 중 하나를 추측으로 세는 셈이다. 그래도 부분적인 측정들이 한목소리로 보여주는 건 있다. 깔때기 모양이다.

SPF: 거의 다 있다 (얼추)

SPF가 깔때기 맨 위에 있다. 다섯 중 가장 오래됐고, 게시하기 가장 쉽고, 메일 사업자들이 가장 오래 잔소리해 온 항목이다. 레코드 설정을 들여다보기 전까지는 좋아 보인다.

상당수가 ~all — softfail — 로 끝난다. 그것만 놓고 보면 softfail은 수신 서버가 메일을 어차피 전달해도 되고 실제로 자주 전달한다는 뜻이다. 그 자체가 틀린 건 아니다. DMARC 아래에서는 softfail도 “SPF 통과 못 함”으로 셈하고, 집행은 원래 DMARC가 맡을 일이다. 하지만 ~all인데 집행하는 DMARC가 없는 도메인이라면, 레코드는 기술적으로 존재하고 보호는 사실상 없다.

그리고 10회 조회 제한이 있다. SPF 레코드는 include: 메커니즘으로 다른 도메인 레코드를 포함할 수 있다. include마다 DNS 조회가 생긴다. 합쳐서 10회를 넘기면 SPF는 통과 대신 영구 오류를 낸다. 경고해주는 반송 메일 같은 건 없다. 큰 조직은 이 한도에 수시로 걸린다 — 이메일 서비스 제공자, 마케팅 플랫폼, CRM 도구가 여러 개라 각각 include:가 필요하다. 레코드가 커진다. 깨진다. 누군가 DMARC 리포트를 읽기 전까지 아무도 모른다.

DKIM: 셀프 호스팅이 탈락하는 지점

DKIM은 암호화 서명을 쓴다. 발신 서버가 본문과 지정한 헤더 몇 개에 개인키로 서명한다. 공개키는 DNS에 있다. 수신 서버가 검증한다.

Google Workspace나 Microsoft 365를 쓰면 DKIM은 체크박스에 가깝다. 제공자가 키를 관리한다. DNS 레코드 한두 개 추가하면 작동한다.

셀프 호스팅이거나, 어플라이언스와 SaaS 발신자가 뒤섞여 있으면, DKIM은 키 관리 문제가 된다. 각 발신 시스템마다 별도의 셀렉터와 키 쌍이 필요하다. 키는 주기적으로 교체해야 한다. 키가 빠졌거나 교체 과정에서 내려갔으면 서명 검증이 멈추고, 아무도 에러 메시지를 받지 못한다.

셀렉터를 나열할 수 없으니 DKIM은 다섯 중 세기가 가장 어렵다. 내가 아는 가장 나은 시도는 2022년 USENIX Security 논문이다. 추측 대신 5년 치 패시브 DNS 데이터와 수억 건의 실제 서명을 썼고, Alexa 상위 100만 도메인 중 28.1%가 DKIM을 켜 두었으며 그중 2.9%는 설정이 잘못돼 있었다고 밝혔다. 클라우드 기본 설정이 채택을 위로 끌어올린다. 나머지는 암호가 라이프사이클 관리에 비하면 쉽다는 걸 발견하게 된다.

DMARC: 보조 바퀴에 머무는 정책

DMARC가 SPF와 DKIM을 정책으로 묶는다. DMARC 레코드 게시는 2024년 2월 Gmail과 Yahoo가 대량 발신자에게 이를 요구하면서 크게 늘었다. 그런데 요구한 게 뭔지 보라. 레코드다. p=none 정책으로도 조건은 충족된다.

분포가 기울어지는 지점이 여기다. 어느 스캔을 봐도 p=none — 지켜보고, 리포트 받고, 아무것도 안 바꾸는 — 에 머문 도메인이 대량으로 나온다.

p=none에서 p=reject로 가려면 DMARC 리포트를 읽고, 인가된 발신자를 전부 식별하고, 각각이 SPF나 DKIM을 정렬된 상태로 통과하는지 확인하고, 스위치를 눌러야 한다. 대부분의 조직이 이 과정을 시작하고 끝내지 못한다. 감시 전용 레코드는 경유지이지 목적지가 아니다. 너무 많은 도메인이 경유지에 집을 지었다.

MTA-STS: 아무도 못 들어본 그것

여기서 깔때기가 절벽으로 떨어진다.

MTA-STS는 이메일이 검증된 TLS 연결로 암호화돼 전달되도록 한다. 없으면 SMTP의 STARTTLS 업그레이드가 선택적이라 중간자가 암호화를 벗기면 이메일이 평문으로 전달된다. 발신자도 수신자도 모른다.

MTA-STS는 https://mta-sts.example.com/.well-known/mta-sts.txt에 정책 파일을 두고 DNS TXT 레코드를 추가해서 고친다. 정책이 말한다: 검증된 TLS로만 내 서버에 전달해라.

채택률? 드물다. 대형 메일 사업자 밖에서는 거의 찾아보기 어렵다.

문제는 노력 대비 효과 비율이다. HTTPS 엔드포인트, 정책 파일, DNS 레코드가 필요하고 동기화를 유지해야 한다. 얻는 보호 — 암호화된 메일 전달 — 는 대부분 이미 되고 있다고 생각하는 것이다. (자주 안 되고 있다.) 막는 공격 — TLS 스트리핑 — 은 실제이지만 누군가를 밤에 깨울 정도는 아니다.

MTA-STS는 사용자에게 가시성도 0이다. “이 이메일은 안전하게 전달됐습니다”라는 표시가 없다. 배포해도 크레딧이 안 붙는다. 안 해도 비난이 안 온다.

BIMI: 벨벳 로프

BIMI는 받은편지함에서 이메일 옆에 브랜드 로고를 보여준다. 요구사항: DMARC가 p=quarantine 이상, 게시된 BIMI 레코드, 제한된 SVG 형식의 로고, 그리고 Gmail과 Apple Mail이라면 마크 인증서. Apple은 등록 상표가 있어야 받을 수 있는 VMC(Verified Mark Certificate)를 요구하고, Gmail은 더 새로운 CMC(Common Mark Certificate)도 받아준다. Yahoo는 인증서 없이도 로고를 보여준다.

이 인증서는 발급 기관에 따라 대개 연 수백 달러에서 천 달러를 훌쩍 넘는 수준이다.

채택률은 미미하다. 중소기업이 이메일 옆에 로고 넣으려고 그 돈을 쓰지 않는다. 많은 대기업도 마찬가지.

깔때기의 바닥

관문을 흔한 순서대로 세우면 이렇다.

  • SPF 레코드: 흔하다
  • DKIM: 클라우드 사업자가 설정해 준 곳에선 흔하고, 나머지는 세기 어렵다
  • DMARC 레코드: 흔하다. 2024년 대량 발신자 규정 이후 더 흔해졌다
  • DMARC 집행: 훨씬 드물다
  • MTA-STS: 드물다
  • BIMI: 그보다 더 드물다

이제 다섯 개 전부를 제대로 — 조회 한도 안의 SPF, 정렬된 DKIM, p=reject인 DMARC, enforce 모드의 MTA-STS, 마크 인증서를 갖춘 BIMI — 갖춘 도메인을 묻는다. 나는 1%에 한참 못 미친다는 쪽에 걸겠다. 다만 그건 내기지 측정이 아니다. 앞서 말한 DKIM 문제 때문에 다섯 개를 모두 볼 수 있는 스캔은 아직 아무도 내놓지 못했다. 그래도 내려갈수록 관문은 앞의 것보다 좁아지고, 마지막 둘은 아주 좁다.

깔때기가 아니다. 체다.

깔때기가 깨지는 이유

각 표준이 다른 그룹이 다른 시기에 다른 문제를 풀려고 설계했다. 통합 시스템으로 설계되지 않았다. “이메일 보안 활성화” 스위치 같은 건 없다.

복잡성이 누적된다. SPF는 DNS 레코드. DKIM은 키 관리가 필요. DMARC는 모니터링 인프라가 필요. MTA-STS는 웹 엔드포인트 호스팅이 필요. BIMI는 인증서 구매가 필요. 각 레이어가 다른 종류의 운영 부담을 추가한다 — DNS, 암호학, 모니터링, 웹 호스팅, 조달.

프로토콜 5개. 20년의 개발. 그리고 다섯 개를 진짜로 다 구현한 도메인의 비율은 너무 작아서, 조사들이 대부분 묻지도 않는다.