TLS-RPT(SMTP TLS Reporting) 레코드 검사기
도메인의 _smtp._tls TXT 레코드를 조회하여, TLS 연결 실패 시 보고서를 받을 주소(rua)가 RFC 8460에 따라 올바르게 설정되어 있는지 진단합니다. MTA-STS/DANE 도입 시 운영 모니터링에 유용합니다.
팁
- TLS-RPT는 수신 측 도메인이 선언하지만, 실제로는 발신 측 메일 서버가 이를 참조하여 해당 도메인과의 TLS 연결이 실패했을 때 통계 보고서를 어디로 보낼지 알아내는 데 사용합니다.
- rua 필드에는 mailto: 형식의 이메일 주소와 https: 형식의 웹 엔드포인트를 함께, 또는 쉼표로 구분하여 여러 개 지정할 수 있습니다.
- 보고서는 JSON 형식(application/tlsrpt+json, gzip 압축인 경우도 많음)으로 도착하므로, 직접 눈으로 읽기보다는 전용 파서나 메일함을 마련해 두는 것이 운영에 도움이 됩니다.
- MTA-STS나 DANE을 도입한 직후에는 한동안 TLS-RPT 보고서를 지켜보며 놓친 설정 오류가 없는지 확인하는 것이 좋습니다.
- Google, Microsoft, Yahoo 등 주요 메일 제공업체는 모두 TLS-RPT 보고서 전송을 지원하므로, 이들과 메일을 많이 주고받는 도메인일수록 도입 효과가 큽니다.
자주 묻는 질문
여담 ― TLS-RPT가 메운 "조용한 장애"라는 구멍
TLS-RPT(TLS Reporting, RFC 8460)는 2018년, MTA-STS(RFC 8461)와 거의 동시에 제정된 규격입니다. 두 규격은 같은 워킹 그룹에서 논의되었고, DNS TXT 레코드를 기반으로 한다는 점, Google·Microsoft·Yahoo 등 주요 제공업체가 공동으로 주도했다는 점 등 많은 공통점을 가지고 있지만, 맡은 역할은 전혀 다릅니다. MTA-STS가 "TLS를 강제하는" 방어 계층이라면, TLS-RPT는 "강제한 결과 실제로 무슨 일이 일어났는지"를 드러내는 관측 계층입니다.
TLS-RPT가 등장하기 전, SMTP 통신에서 TLS 핸드셰이크가 실패하면 대부분의 경우 발신 측 메일 서버 로그에만 기록될 뿐, 수신 측 도메인 관리자에게는 전혀 통보되지 않았습니다. 인증서가 만료되거나 MTA-STS 정책 설정에 오류가 있어도, 실제로 메일이 도착하지 않게 될 때까지 아무도 알아차리지 못하는 "조용한 장애"가 운영상 큰 과제였습니다.
TLS-RPT를 도입하면 rua에 지정한 주소로 매일 집계 보고서가 전송됩니다. 보고서는 application/tlsrpt+json 형식(gzip으로 압축되는 경우도 많음)으로, 성공·실패 건수와 실패 시 그 원인(인증서 불일치, STARTTLS 협상 실패 등)이 구조화된 데이터로 포함됩니다. 사람이 직접 읽기보다는 모니터링 시스템에 수집하여 이상을 탐지하는 용도에 적합합니다.
실무에서는 MTA-STS나 DANE을 도입할 때 TLS-RPT를 함께 설정하는 것이 일반적입니다. 방어 메커니즘만 도입하면 설정 오류로 인해 정상적인 메일까지 차단되고 있어도 이를 알아챌 방법이 없습니다. TLS-RPT 보고서를 모니터링함으로써 TLS 강제화 도입을 안전하게 진행할 수 있습니다.