TLS-RPTとは？
TLS-RPT（SMTP TLS Reporting）は、送信サーバーからのTLS接続失敗に関する日次レポートをドメインが受け取れるようにし、メールが安全でない方法で配信されているのを検知できるようにします。IPeekは_smtp._tlsのTXTレコードを読み取り、レポートの送信先を表示します。MTA-STSやDANEを補完し、それらのポリシーが実環境でどう機能しているかの可視性を与えます。
TLS-RPTレポートの仕組み
TLS-RPTは、_smtp._tls.your-domainの単一のDNS TXTレコードとして公開されます。レコードは、バージョンタグと、レポートの送信先（mailtoアドレスまたはHTTPSエンドポイント）を列挙するrua=タグを保持します。標準に対応する送信サーバーは、自社のMXホストとのTLSネゴシエーションの結果を1日分集約し、それらの送信先へJSONレポートを配信します。各レポートは成功したセッションと失敗したセッションを集計し、証明書検証エラーやSTARTTLSが利用できないといった失敗を分類して、実際の配信に関するフィードバックループを与えます。
TLS-RPT結果の読み解き方
IPeekは、_smtp._tlsのTXTレコードが存在するかを確認し、解析したrua送信先を表示します。バージョンがTLSRPTv1であること、各ruaターゲットが実際に監視している有効なメールボックスまたはHTTPS URLであることを確認してください。レコード自体は何も強制せず、レポートを要求するだけなので、その存在は送信側がTLS失敗データの送り先を知っていることを意味します。レポートが届いたら、失敗の種類に注目してください。certificate-expired、検証失敗、starttls-not-supportedはそれぞれ、静かな配信問題を引き起こす前に、受信インフラ側の特定の修正を示します。
TLS-RPTとMTA-STS・DANEの関係
MTA-STSとDANEは受信メールにTLSを強制しますが、強制は実トラフィックへの影響を見られる場合にのみ安全です。TLS-RPTがその可視性を提供します。MTA-STSをtestingモードで展開すると、enforceに切り替える前に、どの送信側がTLS失敗に遭遇するかをレポートが明らかにします。同じことがDANE TLSAの不一致にも当てはまります。TLS-RPTは、強制の仕組みの代わりではなく並行して展開する、TLS態勢の監視層と捉えてください。そうすれば証明書や設定の問題を早期に発見できます。