TLS-RPT とは
メールはサーバー間で SMTP により配送されます。 その際に TLS で暗号化するのが一般的ですが、 設定ミス・中間者・古いサーバーなどでTLS ネゴシエーションが失敗することがあります。
TLS-RPT（SMTP TLS Reporting）は、 ドメインの DNS にレポート受け先を書いておき、 他社メールサーバーからTLS 失敗の集計レポートが送られる仕組みです。 SPF / DKIM / DMARC とは別系統で、 配送経路の暗号化品質の可視化が目的に近いです。
SPF・DMARC との違い
| 仕組み | 主な目的 |
|---|---|
| SPF / DKIM / DMARC | 送信ドメインのなりすまし・認証失敗時の扱い |
| TLS-RPT | メール配送時の TLS 失敗・ポリシー違反の報告受け |
| Web の TLS 証明書 | HTTPS サイトの証明書（別レイヤー） |
「DMARC を入れたからメールは全部安全」ではありません。 配送経路の TLS 問題を別チャンネルで把握する仕組みの一つ、 という位置づけです。
サンプル報告書の F-22
架空の報告書サンプルでは、 TLS-RPT 用 DNS レコードが見つからないことを 重要度低の所見（F-22）として載せ、 「メール送受信の TLS 失敗を把握する場合は導入を検討」としています。
未設定＝即脆弱、ではなく、 監視・運用の選択肢を取っていない事実として記録する例です。
外部攻撃面レビューでの扱い
公開 DNS に TLS-RPT 用レコード（_smtp._tls.example.co.jp 等）があるかを確認し、
報告書に有無を載せることがあります。
レポートの受信・解析代行や、MTA-STS（より厳格な TLS ポリシー）の設計は標準スコープ外です。
含まないこと
- TLS-RPT / MTA-STS レコードの作成・ホスティング代行
- レポートメールの受信インフラ構築
- メールサーバー設定変更
調査データは閉域環境内で扱います
調査結果は閉域環境内のみで保管・処理します。 報告書は基本メールで納品します。
メール認証の本流は DMARC → SPF → DKIM → ポリシー強化 の順で読むと整理しやすいです。 御社ドメインの公開 DNS 整理はお問い合わせください。