TLS-RPT（SMTP TLS Reporting）記錄檢測工具
獲取域名的_smtp._tls TXT記錄，診斷TLS連線失敗時的報告發送地址（rua）是否按RFC 8460規範正確配置。適用於MTA-STS/DANE部署後的運維監控。
使用提示
- TLS-RPT並非由接收方聲明後自用，而是由傳送郵件伺服器讀取並使用，用於在與你的域名建立TLS連線失敗時，知道該把統計報告發往何處。
- rua欄位可以同時列出mailto:格式的郵箱地址和https:格式的Web端點，也可以用逗號分隔指定多個目標。
- 報告以JSON格式（application/tlsrpt+json，也可能經過gzip壓縮）傳送，建議準備專用的解析工具或郵箱，而不是指望人工閱讀。
- 剛部署MTA-STS或DANE之後，建議持續關注一段時間的TLS-RPT報告，以便及時發現可能遺漏的配置錯誤。
- Google、Microsoft、Yahoo等主要郵件服務商均支援傳送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強制化的落地。