TLS-RPT（SMTP TLS Reporting）記錄檢測工具
獲取域名的_smtp._tls TXT記錄，診斷TLS連線失敗時的報告發送地址（rua）是否按RFC 8460規範正確配置。適用於MTA-STS/DANE部署後的運維監控。
診斷 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:格式的Web端點，也可以用逗號分隔指定多個目標。
- 報告以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 的報告之中。
常見問題
閒話 ― 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強制化的落地。