TLS-RPT（SMTP TLS Reporting）
概要
TLS-RPT（SMTP TLS Reporting） は、メール送信サーバーが受信ドメインとの SMTP 接続で発生した TLS エラーを報告する仕組みです。RFC 8460（2018年）で定義されています。
MTA-STS や DANE を導入した受信ドメインは、送信サーバーが TLS 接続に失敗した場合にメールが配送されない可能性があります。TLS-RPT はこの「見えない配送失敗」を可視化します。送信サーバーが TLS 接続の成功・失敗の統計を JSON レポートとして受信ドメインに送付するため、ドメイン管理者は証明書の問題や設定ミスを早期に発見できます。
DMARC の集計レポート（rua）がメール認証の結果を報告するのに対し、TLS-RPT は SMTP トランスポート層の暗号化状態を報告する補完的な仕組みです。MTA-STS を導入する場合、TLS-RPT を併用してエラーを監視します。
仕組み
送信サーバーが TLS 接続の成否を 24 時間単位で集計し、受信ドメインの DNS で指定されたアドレスに JSON レポートを送付します。
レポートの生成と送信
TLS-RPT のフローは次の通りです。
- 送信サーバーが受信ドメインへの SMTP 接続で TLS ネゴシエーションを試みる
- 接続の成功・失敗を記録する
- 一定期間（通常 24 時間）の集計結果を JSON レポートとして作成する
- 受信ドメインの
_smtp._tls.ドメインの TXT レコードで指定されたアドレスにレポートを送信する
DNS TXT レコード
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"v=TLSRPTv1 はバージョン、rua= はレポートの送信先です。メールアドレスのほか、HTTPS エンドポイント（rua=https://tls.example.com/report）も指定できます。
レポートの内容
TLS-RPT レポートは JSON 形式で、次の情報を含みます。
- 報告対象期間（開始日時・終了日時）
- 受信ドメイン名
- ポリシーの種類（MTA-STS / DANE）と適用されたポリシーの内容
- 成功した接続数
- 失敗した接続数と失敗の種類
失敗の種類には次のようなものがあります。
| 失敗タイプ | 意味 |
|---|---|
starttls-not-supported | 受信サーバーが STARTTLS に対応していない |
certificate-host-mismatch | 証明書のホスト名が MX と一致しない |
certificate-expired | 証明書の有効期限が切れている |
certificate-not-trusted | 証明書がパブリック CA から発行されていない |
validation-failure | MTA-STS ポリシーの検証に失敗した |
sts-policy-fetch-error | MTA-STS ポリシーファイルを取得できなかった |
DMARC レポートとの違い
DMARC の rua レポートはメール認証（SPF、DKIM、DMARC）の結果を報告します。TLS-RPT はメール配送の暗号化（STARTTLS、TLS バージョン、証明書の有効性）に関する報告です。どちらも rua= タグを使いますが、DNS レコードの場所が異なります（DMARC は _dmarc.ドメイン、TLS-RPT は _smtp._tls.ドメイン）。
設定例
レポートの送信先にはメールアドレスと HTTPS エンドポイントの両方を指定できます。
基本設定（メールでレポートを受信）
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"HTTPS エンドポイントへ送信
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=https://tls-reports.example.com/v1/report"大量のレポートを受信する場合、HTTPS エンドポイントで自動処理する方が効率的です。
複数の送信先を指定
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com,https://tls-reports.example.com/v1/report"メールと HTTPS の両方にレポートを送信できます。
MTA-STS との併用
TLS-RPT は MTA-STS と組み合わせて使います。
_mta-sts.example.com. IN TXT "v=STSv1; id=20240201"
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"MTA-STS を mode: testing で導入し、TLS-RPT でエラーを監視してから mode: enforce に移行するのが推奨フローです。
確認方法
TLS-RPT の DNS レコードは dig で確認できます。
dig TXT _smtp._tls.example.com;; ANSWER SECTION:
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"v=TLSRPTv1 で始まるレコードが存在すれば TLS-RPT が設定されています。
外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から TXT レコードを取得できます。
curl "https://labee.dev/api/dns?domain=_smtp._tls.example.com&type=TXT"{
"success": true,
"data": {
"domain": "_smtp._tls.example.com",
"records": {
"TXT": [["v=TLSRPTv1; rua=mailto:tls-reports@example.com"]]
}
},
"error": null,
"meta": { "responseTime": 123 }
}よくある問題
TLS-RPT は MTA-STS または DANE と組み合わせないと実効性が低く、レポートの量や解析方法にも考慮が必要です。
MTA-STS なしで TLS-RPT だけ設定する
TLS-RPT は MTA-STS または DANE と組み合わせて使う仕組みです。どちらも設定していない場合、送信サーバーが TLS-RPT レポートを生成する動機がありません。MTA-STS の導入と同時に TLS-RPT を設定します。
レポートが大量に届いてメールボックスを圧迫する
TLS-RPT レポートは JSON を gzip 圧縮した添付ファイルとして届きます。大量のメール送信を受けるドメインでは、レポートが 1 日に数百通届くことがあります。専用のメールアドレスを用意するか、HTTPS エンドポイントで自動処理する構成に変更します。
レポートの JSON を解析できない
TLS-RPT レポートの JSON は RFC 8460 で構造が定義されていますが、手動で読み解くのは手間がかかります。Hardenize や Postmark の TLS-RPT 解析ツールを使うと、視覚的にエラーの傾向を把握できます。
証明書のエラーに気づかない
TLS-RPT レポートを設定していても、定期的に確認しなければ証明書の有効期限切れや設定ミスを見逃します。レポートを自動解析し、エラー率が閾値を超えたらアラートを送る仕組みを構築します。