MTA-STS 정책 검사기
도메인의 _mta-sts TXT 레코드와 mta-sts.txt 정책 파일을 가져와, 메일 전송 시 TLS 암호화 강제(MTA-STS)가 올바르게 설정되었는지 진단합니다.
팁
- MTA-STS는 "보내는 쪽" 서버가 확인하는 방식입니다. 정책을 공개하면 다른 서버들이 여러분의 도메인으로 메일을 보낼 때 TLS를 강제하게 됩니다.
- enforce로 전환하기 전에 몇 주에서 한 달 정도 testing 모드로 운영하며 예상치 못한 전달 거부가 발생하지 않는지 모니터링하는 것이 안전합니다.
- max_age（정책 유효 기간）는 보통 604800초（7일）~31557600초（1년） 범위로 설정합니다. 값이 너무 짧으면 정책 파일을 자주 다시 가져와야 합니다.
- mx 필드에는 와일드카드（*.example.com）를 사용할 수 있지만, TLS 인증서의 SAN（Subject Alternative Name）이 해당 와일드카드와 일치해야 합니다.
- DNS 레코드나 정책 파일 중 하나만 설정해서는 작동하지 않습니다. 둘 다 갖춰져야 비로소 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는 "가시성"이라는 역할을 나누어 맡으며, 두 가지를 함께 사용하는 것이 현재의 모범 사례입니다.