MTA-STS 정책 검사기
도메인의 _mta-sts TXT 레코드와 mta-sts.txt 정책 파일을 가져와, 메일 전송 시 TLS 암호화 강제(MTA-STS)가 올바르게 설정되었는지 진단합니다.
메일 배달의 TLS 강제(MTA-STS)를 진단하기
SMTP의 암호화는 본디 「되면 한다」는 임의의 장치여서, 도중에 끼어든 공격자가 STARTTLS의 알림을 깎아 내면 평문으로 떨어뜨릴 수 있습니다. MTA-STS는 이 구멍을 막는 약속으로, **「이 도메인 앞으로 오는 메일은 반드시 TLS로 보내라」고 보내는 쪽에 이릅니다.** 이 도구는 `_mta-sts`의 TXT 레코드와 정책 파일을 함께 가져와 설정이 갖춰졌는지를 보고합니다.
**이 얼개에서 헷갈리는 대목은, DNS에 정책 자체가 놓이지 않는다는 점입니다.** TXT 레코드가 지니는 것은 판을 나타내는 `id`뿐이고, **실체는 `https://mta-sts.도메인/.well-known/mta-sts.txt`에서 HTTPS로 내려집니다.** 곧 이 장치의 믿음은 DNS가 아니라 웹 인증서에 놓여 있습니다. **그리고 가장 자주 발이 묶이는 곳이 `mode`를 `testing`인 채로 두는 일입니다.** 그 상태에서는 TLS가 실패해도 배달이 그대로 통하며, **실제로 강제되는 것은 `enforce`로 두었을 때뿐입니다.** 들이는 차례로는 `testing`에 머물며 TLS-RPT 보고를 읽어 탈이 없음을 확인한 뒤에 `enforce`로 나아가는 것이 정석입니다.
사용하는 방법
- 도메인을 넣습니다 `example.com`처럼 도메인만 넣으면 됩니다.
- TXT 레코드를 확인합니다 **`v=STSv1`과 `id=`가 있는지 봅니다.** `id`는 정책을 고칠 때마다 바꿉니다.
- 정책 파일의 내용을 읽습니다 `mx`·`max_age`·`mode`의 셋이 늘어서 있습니다.
- mode를 확인합니다 **`testing`인 채라면 아무것도 강제되지 않습니다.** 효력을 얻으려면 `enforce`가 필요합니다.
더 잘 활용하기 위한 팁
- MTA-STS는 "보내는 쪽" 서버가 확인하는 방식입니다. 정책을 공개하면 다른 서버들이 여러분의 도메인으로 메일을 보낼 때 TLS를 강제하게 됩니다.
- enforce로 전환하기 전에 몇 주에서 한 달 정도 testing 모드로 운영하며 예상치 못한 전달 거부가 발생하지 않는지 모니터링하는 것이 안전합니다.
- max_age（정책 유효 기간）는 보통 604800초（7일）~31557600초（1년） 범위로 설정합니다. 값이 너무 짧으면 정책 파일을 자주 다시 가져와야 합니다.
- mx 필드에는 와일드카드（*.example.com）를 사용할 수 있지만, TLS 인증서의 SAN（Subject Alternative Name）이 해당 와일드카드와 일치해야 합니다.
- DNS 레코드나 정책 파일 중 하나만 설정해서는 작동하지 않습니다. 둘 다 갖춰져야 비로소 MTA-STS가 유효하게 작동합니다.
이럴 때 쓸 수 있습니다
우리 도메인의 설정을 점검할 때
**DNS와 HTTPS가 둘 다 갖춰져야 굴러가므로 어느 한쪽의 누락을 찾아낼 수 있습니다.**
enforce로 나아가기 전에 확인할 때
`testing`인 동안에 설정의 잘못을 걷어 낼 수 있습니다.
MX를 더한 뒤 되짚어 볼 때
**새 MX 호스트를 정책의 `mx`에 덧적는 것을 잊으면 그 호스트로의 배달이 막힙니다.**
거래처의 대응을 알고 싶을 때
상대가 자기 메일에 TLS를 강제하는지를 알 수 있습니다.
MTA-STS 용어
- _mta-sts TXT
- **정책의 판을 나타내는 `id`를 두는 DNS 레코드입니다.** 정책 본체는 여기에 들지 않습니다.
- 정책 파일
- `https://mta-sts.도메인/.well-known/mta-sts.txt`에 두는 본체입니다. **HTTPS로 내리므로 유효한 인증서가 있어야 합니다.**
- mode
- `enforce`·`testing`·`none` 가운데 하나입니다. **`testing`에서는 검사에 실패해도 메일이 배달됩니다.**
- max_age
- 보내는 쪽이 정책을 캐시해도 되는 초수입니다. 길게 잡으면 보호가 두터워지지만 변경이 퍼지는 데 시간이 걸립니다.
- mx
- TLS를 강제할 MX 호스트의 목록입니다. **여기에 없는 호스트로는 배달되지 않습니다.**
- STARTTLS 하향
- 중간에 선 자가 STARTTLS 알림을 깎아 평문으로 떨어뜨리는 공격입니다. **MTA-STS는 이를 막고자 만들어졌습니다.**
자주 묻는 질문
여담 ― STARTTLS의 약점과 MTA-STS가 등장하게 된 배경
SMTP의 전송 구간 암호화는 오랫동안 1999년에 표준화된 STARTTLS 방식에 의존해 왔습니다. 이는 평문으로 연결을 시작한 뒤 나중에 암호화로 전환하는 방식입니다. 그런데 2014년, 보안 연구자들은 실제로 존재하는 "STARTTLS 스트리핑" 공격을 확인했습니다. STARTTLS 협상 자체가 암호화가 시작되기 전 평문으로 이루어지기 때문에, 경로상의 공격자가 서버 응답을 조작해 STARTTLS 지원 여부를 숨기고 상대방이 평문으로 되돌아가도록（fallback） 속일 수 있었습니다.
근본 원인은 STARTTLS가 상대방이 TLS를 지원하지 않을 경우 의도적으로 평문으로 되돌아가도록 설계되었다는 점이었습니다. 이는 호환성을 위한 기능이었지만, 공격자는 단순히 TLS를 지원하지 않는 척함으로써 이를 악용할 수 있었습니다. 2015년 무렵 구글 자체 조사에 따르면 일부 국가와 통신사에서 STARTTLS 스트리핑이 광범위하게 이루어지고 있음이 드러났습니다.
MTA-STS（RFC 8461, 2018년 공개）는 이러한 문제에 대한 업계의 대응으로, 구글・마이크로소프트・야후 등이 공동으로 제정한 표준입니다. 도메인은 DNS TXT 레코드로 "MTA-STS를 지원한다"고 선언하고, HTTPS로 가져오는 정책 파일에 허용된 MX 호스트와 TLS 요구 사항을 명시합니다. 정책을 한 번 가져오면 max_age 기간 동안 캐시되므로, 이후 평문으로 되돌리려는 시도가 있으면 조용히 허용되는 대신 탐지하고 거부할 수 있습니다.
비슷한 목적을 가진 TLS-RPT（TLS Reporting, RFC 8460）와 함께 사용하면 TLS 연결이 실패했을 때 보고서를 받을 수 있습니다. MTA-STS는 "방어", TLS-RPT는 "가시성"이라는 역할을 나누어 맡으며, 두 가지를 함께 사용하는 것이 현재의 모범 사례입니다.