TLS-RPT(SMTP TLS Reporting) 레코드 검사기

도메인의 _smtp._tls TXT 레코드를 조회하여, TLS 연결 실패 시 보고서를 받을 주소(rua)가 RFC 8460에 따라 올바르게 설정되어 있는지 진단합니다. MTA-STS/DANE 도입 시 운영 모니터링에 유용합니다.

마지막 업데이트: 2026-09-20

TLS 연결 실패 보고(TLS-RPT)를 진단하기

MTA-STS나 DANE를 들여도 한 가지는 보이지 않습니다. **배달이 실제로 실패하고 있는지는 보내는 쪽만 압니다.** TLS-RPT는 그 구멍을 메우는 약속으로, `_smtp._tls`의 TXT 레코드에 보고받을 곳을 적어 두면 **보내는 쪽 서버가 날마다 보고를 보내 줍니다.** 이 도구는 그 레코드를 가져와 RFC 8460에 맞는 꼴인지를 보고합니다.

**TLS-RPT 자체는 방어가 아니라 관측을 위한 장치입니다.** 공격을 막는 몫은 없고, TLS를 세우는 데 몇 번 실패했는지를 알려 줄 뿐입니다. **그러나 이 관측이 없으면 MTA-STS를 `enforce`로 나아가게 할지를 판단할 수 없습니다.** 강제로 바꾼 순간 배달이 멈춰도 상대가 불평해 올 때까지는 알아챌 길이 없기 때문입니다. **그래서 실무의 차례는, 먼저 TLS-RPT를 두고 MTA-STS를 `testing`으로 굴리며 보고를 읽어 아무것도 실패하지 않음을 확인한 뒤에 `enforce`로 나아가는 것입니다.**

사용하는 방법

도메인을 넣습니다 `example.com`처럼 도메인만 넣으면 됩니다.
TXT 레코드를 확인합니다 **`v=TLSRPTv1`과 `rua=`가 있는지 봅니다.**
보고받을 곳의 꼴을 확인합니다 `mailto:`나 `https:`로 적습니다. **그 주소가 실제로 받을 수 있는지도 확인해 주십시오.**
보고를 읽을 사람을 정합니다 **두기만 하고 읽지 않으면 뜻이 없습니다.** 누가 언제 볼지를 정해 둡니다.

더 잘 활용하기 위한 팁

TLS-RPT는 수신 측 도메인이 선언하지만, 실제로는 발신 측 메일 서버가 이를 참조하여 해당 도메인과의 TLS 연결이 실패했을 때 통계 보고서를 어디로 보낼지 알아내는 데 사용합니다.
rua 필드에는 mailto: 형식의 이메일 주소와 https: 형식의 웹 엔드포인트를 함께, 또는 쉼표로 구분하여 여러 개 지정할 수 있습니다.
보고서는 JSON 형식(application/tlsrpt+json, gzip 압축인 경우도 많음)으로 도착하므로, 직접 눈으로 읽기보다는 전용 파서나 메일함을 마련해 두는 것이 운영에 도움이 됩니다.
MTA-STS나 DANE을 도입한 직후에는 한동안 TLS-RPT 보고서를 지켜보며 놓친 설정 오류가 없는지 확인하는 것이 좋습니다.
Google, Microsoft, Yahoo 등 주요 메일 제공업체는 모두 TLS-RPT 보고서 전송을 지원하므로, 이들과 메일을 많이 주고받는 도메인일수록 도입 효과가 큽니다.

이럴 때 쓸 수 있습니다

MTA-STS를 강제로 나아가게 하기 전에

**`testing`인 동안 실패가 있는지를 잴 수 있으며**, 그것이 판단의 재료가 됩니다.

배달의 탈을 일찍 알아챌 때

상대의 신고를 기다리지 않고도 실패가 일어나고 있음을 알 수 있습니다.

DANE를 들인 뒤 지켜볼 때

**인증서와 TLSA의 어긋남은 보고에 실패로 드러납니다.**

설정의 꼴을 확인할 때

`rua`를 잘못 적으면 보고가 한 통도 오지 않는 꼴로 나타납니다.

TLS-RPT 용어

_smtp._tls TXT: **보고받을 곳을 적는 DNS 레코드입니다.** `v=TLSRPTv1; rua=mailto:...` 꼴로 적습니다.
rua: 보고가 갈 곳입니다. **전자우편 주소나 받을 채비가 된 HTTPS 엔드포인트를 적습니다.**
RFC 8460: TLS-RPT의 꼴과 보고의 내용을 정한 규격입니다.
일일 보고: 보내는 쪽 서버가 하루치를 모아 보내는 보고입니다. 성공과 실패의 건수, 실패의 까닭이 담깁니다.
MTA-STS: TLS를 강제하는 얼개입니다. **TLS-RPT는 그 강제가 실제로 어떻게 듣고 있는지를 보려고 짝지어 씁니다.**
DANE: DNSSEC를 전제로 인증서를 검증하는 얼개입니다. **이쪽의 탈도 TLS-RPT의 보고에 드러납니다.**

자주 묻는 질문

MTA-STS는 TLS 연결을 강제하는 방어 메커니즘이고, TLS-RPT는 강제한 결과 TLS 연결이 실제로 실패하지 않았는지 보고서로 확인하는 관측 메커니즘입니다. 두 가지는 독립적으로 설정할 수 있으며, 한쪽만 도입하는 것도 가능합니다.

"미도입" 자체는 많은 도메인에서 흔한 상태이며, 즉시 위험하다는 의미는 아닙니다. 다만 MTA-STS나 DANE을 도입한 경우에는 설정 오류를 감지하기 위해 TLS-RPT도 함께 설정하는 것을 권장합니다.

TXT 레코드의 rua에 지정된 mailto: 이메일 주소 또는 https: 웹 엔드포인트로 전송됩니다. 여러 수신 주소를 쉼표로 구분하여 지정할 수도 있습니다.

보고서는 JSON 형식의 구조화된 데이터이므로, 사람이 직접 눈으로 읽기보다는 모니터링 도구나 스크립트로 자동 집계하는 운영 방식이 일반적입니다. 전용 분석 서비스를 이용하는 업체도 많습니다.

이 도구는 TXT 레코드의 구문과 필수 항목(v, rua)의 존재 여부만 확인합니다. 실제로 보고서가 도착하는지까지는 검증하지 않으므로, 설정 후에는 며칠 기다려 실제로 보고서 메일이 도착하는지 확인해 주세요.

여담 ― 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 강제화 도입을 안전하게 진행할 수 있습니다.

모든 여담 보기