TLS-RPT（SMTP TLS Reporting）レコードチェッカー
ドメインの_smtp._tls TXTレコードを取得し、TLS接続に失敗した際のレポート送付先（rua）がRFC 8460準拠で正しく設定されているかを診断します。MTA-STS・DANE導入時の運用監視に。
Tips
- TLS-RPTは受信側ではなく送信側のメールサーバーが、TLS接続に失敗した際の統計レポートを送るための宛先を宣言する仕組みです。
- rua には mailto: 形式のメールアドレスと https: 形式のWebエンドポイントの両方、またはカンマ区切りで複数指定できます。
- レポートは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強制化のロールアウトを安全に進められます。