실제 환경에서의 MTA-STS 정책 적용 현황

분석한 131,024개의 한국 도메인 중 강제 적용(enforce) 모드의 MTA-STS 정책을 게시한 곳은 단 3곳에 불과하다. 나머지 131,021개 도메인의 이메일 전송은 여전히 TLS 다운그레이드 및 중간자(MiTM) 공격에 취약한 상태다.

이번 글에서는 MTA-STS가 무엇인지, 왜 중요한지, 어떻게 작동하는지 살펴보고 직접 소유한 도메인에 적용하는 방법을 알아본다.

이메일 암호화는 기본적으로 비활성화되어 있다

메일 서버는 기회주의적(opportunistic) 방식으로 암호화를 진행한다. 송신 서버가 HELLO 메시지를 보내면, 수신 서버는 자신이 지원하는 모든 기능 목록으로 응답한다. 이 목록에는 STARTTLS가 포함될 수도 있고 포함되지 않을 수도 있다.

250-mail.example.com
250-PIPELINING
250-SIZE 35882577
250-STARTTLS
250 ENHANCEDSTATUSCODES

송신 서버가 STARTTLS 줄을 인식하면 TLS 연결을 시작한다. 결과적으로 메일 메시지는 암호화되어 인터넷을 거쳐 전달된다.

하지만 수신 서버가 STARTTLS를 보내지 않으면, 송신 서버는 일반 평문(cleartext) 전송 방식으로 되돌아간다.

2002년 SMTP에 TLS 기능을 추가한 표준 규격인 RFC 3207은 자체 보안 섹션에서 이러한 한계로 인한 결과를 명시하고 있다.

RFC 3207 §6: "서버의 '250 STARTTLS' 응답을 삭제하는 것만으로 중간자 공격을 수행할 수 있다."

공격자는 한 줄만 삭제하고 나머지는 그대로 통과시켜 송신 서버가 수신 서버의 TLS 미지원을 믿게 만든다.

MTA-STS 작동 방식

MTA-STS는 RFC 8461에 정의되어 있다.

MTA-STS를 설정하려면 도메인은 두 가지를 게시해야 한다.

• DNS 포인터: _mta-sts.에 v=STSv1 및 id 값을 포함하는 TXT 레코드를 등록한다. id 버전 문자열은 정책에 변경 사항이 생겼음을 송신 측에 알리기 위해 정책이 변경될 때마다 반드시 수정되어야 한다.
• HTTPS 기반 정책 파일: https://mta-sts./.well-known/mta-sts.txt 경로에 위치하는 일반 텍스트 파일이다. 이 파일은 메일 수신이 허용된 MX 호스트를 지정하는 데 사용된다. max_age는 송신 측이 정책을 다시 확인해야 하는 주기를 정의하며, mode는 정책의 적용 방식을 결정한다.

mode에는 세 가지 값이 사용된다.

1. enforce - 지정된 MX 호스트 중 하나와 유효한 TLS 연결을 설정할 수 없는 경우, 송신 측은 메시지 전송을 반드시 거부해야 한다.
2. testing - 연결 실패 시에도 일단 메일을 전송하고 실패 내역을 보고한다.
3. none - 정책을 비활성화한다. 기존 정책을 폐기할 때 사용된다.

보고 기능은 TLS-RPT를 정의한 RFC 8460에 따라 수행된다. 이는 _smtp._tls.에 설정되는 TXT 레코드다. 이 주소는 송신 측이 연결을 시도했을 때 TLS 연결 성공 여부에 대한 일일 요약 보고서를 수신한다.

한국 도메인의 MTA-STS 적용 현황 조사

한국에서 MTA-STS가 얼마나 보급되어 있는지 확인하기 위해 Tranco 리스트, 한국 대상 Chrome UX 리포트, 상위 1,000만 개 도메인 목록, 공정거래위원회 통신판매사업자 등록 명단에서 수집한 217,129개의 .kr 도메인을 조회했다. 이 중 81,957개는 더 이상 존재하지 않았고, 4,148개는 SERVFAIL 응답을 반환하거나 시간 초과가 발생했다. 두 그룹을 제외한 최종 분석 대상은 131,024개의 활성화된 도메인이다.

이는 전체 도메인의 겨우 0.015%에 불과한 놀라운 수치다. 비교를 위해 살펴보면, URIports의 2026년 1월 스캔 결과 전 세계 상위 100만 개 도메인 중 7,377개(0.7%)가 정책을 게시하고 있었으며, 이는 2024년의 0.3%에서 증가한 수치다.

이는 한국의 MTA-STS 도입률이 전 세계 평균에 비해 약 45배 낮다는 것을 의미한다.

한국의 주요 대형 도메인 역시 상황은 다르지 않다. naver.com, kakao.com, daum.net, samsung.com, coupang.com, hyundai.com, skt.co.kr, kt.com, toss.im, shinhan.com, kbstar.com 중 어떤 곳도 두 레코드를 게시하지 않고 있다. 반면 google.com, gmail.com, microsoft.com은 두 레코드를 모두 게시하고 있다.

예외적인 한국 도메인 6곳

조사 대상 중 MTA-STS를 강제 적용(enforce)하고 있는 한국 도메인은 goodoc.co.kr, 8percent.kr, glitter.kr 단 3곳뿐이었다. 각 도메인의 정책은 mode: enforce 설정과 함께 HTTP 200을 반환하며, mx: 항목은 게시된 모든 MX 레코드를 포함하고 있다. 예를 들어 goodoc.co.kr은 5개의 MX 레코드와 정확히 일치하는 5개의 mx: 줄을 명시하고 있다. 이를 확인한 송신 측은 지정된 서버 외의 다른 어떠한 서버에도 메일을 전달하지 않는다.

추가로 3개 도메인은 mode: testing 상태로 유효한 정책을 제공하고 있었는데, 이는 전송 실패 시 보고서를 수신하면서도 메일 전달은 그대로 진행하는 방식이다.

DANE은 대체 수단이 아니다

DANE에 대해 들어본 적이 있을 것이다. DANE은 메일 전송 암호화를 고정하는 또 다른 방법이다. 사실 DANE이 더 강력하다. TLSA 레코드가 DNSSEC으로 서명된 DNS 내에 존재하므로 전송 경로상에 웹 서버가 필요 없기 때문이다.

DANE은 훌륭한 기술이지만, 사용 중인 MX 호스트 이름이 DS 레코드를 게시하지 않는다면 아무런 도움이 되지 않는다. 예를 들어 Google Workspace에서 이메일을 호스팅하는 경우 DANE은 선택지가 될 수 없다. 이번 조사 대상 도메인 중 8,808개는 1순위 MX 레코드로 Google 호스트를 사용하고 있어 TLSA 레코드를 검증하는 것 자체가 불가능하다.

다만 kr과 co.kr은 상위 영역(parent)에 DS 레코드를 보유하고 있으므로 한국 도메인은 원한다면 자체 영역에 서명할 수 있다. 131,024개 도메인 중 118개가 이를 적용했다.

MTA-STS 도입의 단점

대다수 도메인이 MTA-STS를 사용하지 않는 데는 이유가 있다. 많은 기업에게 이러한 설정을 유지 관리하는 일은 이점에 비해 수고가 너무 많이 들기 때문이다.

기업들이 우려하는 가장 큰 문제는 인증서 만료나 MX 정책 불일치로 인해 송신 측에서 메일 전송을 거부할 수 있다는 점이다. 성숙한 인증서 갱신 절차와 정립된 MX 관리 정책이 갖춰져 있지 않다면 조직의 이메일 수발신이 마비될 위험이 있다.

한 가지 궁금한 점이 있다. 이 글을 읽기 전 MTA-STS라는 기술의 존재를 알고 있었는가?

참고 문헌

1. IETF — RFC 8461: SMTP MTA Strict Transport Security (MTA-STS) (2018년 9월)
2. IETF — RFC 8460: SMTP TLS Reporting (2018년 9월)
3. IETF — RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security (2002년 2월)
4. URIports — MTA-STS adoption: three years of steady growth (상위 100만 개 도메인 스캔, 2026년 1월 첫째 주)
5. Panke — 이메일 스푸핑: 한국 도메인 10,000개 이상 조사 결과 (2026년 9월 1일)
6. Panke — 이메일 보안해설: 메일 한 건, 6가지 검증 단계 (2026년 9월 21일)
7. Panke — 217,129개 .kr 도메인(활성 131,024개) 대상 MTA-STS 및 TLS-RPT 실태 조사 (자체 측정, 2026년 9월 23일)
8. Google — Chrome UX Report, 한국 국가별 목록, 2026년 8월, crux-top-lists 경유 (Google CrUX 데이터셋, CC BY 4.0)