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 の書式とレポートの中身を定めた規格です。
- 日次レポート
- 送信側のサーバーが1日分をまとめて送る報告です。成功と失敗の件数、失敗の理由が入ります。
- 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強制化のロールアウトを安全に進められます。