TLS-RPT 参加している送信システムに、集約されたSMTP TLS結果を共有するよう要求します。 DNSレコードは別のものです MTA-STS 発見してから分離する DMARC 報告。有効なレコードを公開すると、レポート要求が有効になります。トランスポートの強制を有効にしたり、すべての送信者がレポートを提出することを保証したりするものではありません。
所有する宛先を選択してください
参考文献: RFC 8460 §3, RFC 8460 §5.4.
たとえば、 example.comでは、 TXTリソース レコードを_smtp._tls.example.comに公開します。最小の例示的な値はv=TLSRPTv1; rua=mailto:tls-reports@example.com.サンプルのアドレスを、あなたが管理し、使用を許可されているメールボックスまたは収集サービスに置き換えます。配信能力、処理、保持、および結果のレポートに誰がアクセスできるかを確認します。
RFC 8460 、mailto および https レポート URI をサポートします。 HTTPS レポートではMTA-STSポリシーの取得に使用される GET ではなく POST が使用されます。 TLS-RPT宛先はポリシーホスト URL ではありません。一般的な Web サイトや任意のベンダー アドレスにレポートを送信するのではなく、コレクターが実際にサポートするエンドポイントと認証プロセスを使用します。
該当するレコードを 1 件公開する
参考文献: RFC 8460 §3.
version フィールドは正確な TLSRPTv1 値を最初に指定する必要があり、rua が必要です。複数の宛先は、同じレコード内のカンマ区切りの URI 値です。 URI 内の区切り文字の意味を持つ文字には、適切なエンコーディングが必要です。レポート送信者は、複数のエンドポイントのうち 1 つだけを試行できます。同一のコピーがどこにでも届くとは考えないでください。
複数の場合 TXTレコード が返されますが、レコードはv=TLSRPTv1;捨てられます。 TLS-RPT検出には、該当するレコードが 1 つだけ残る必要があります。 1 つのTXTレコード内の複数の文字列は、スペースを挿入せずに連結されます。 2 つの独立したTLS-RPTポリシーは、1 つの宛先リストにマージされません。
レコード境界チェックを再現する
1 つのv=TLSRPTv1; rua=mailto:tls-reports@example.comレコードと無関係な検証TXT値。意図した選択では候補が 1 つ残ります。 2 番目の独立した TLSRPTv1 レコードを追加すると、検出カウントが無効になります。提供されたオフライン フィクスチャはこのレビュー用に再実行され、この狭い候補者選択ケースを実行します。これは、完全な URI 検証ツール、 DNSサーバー、またはレポート クライアントではありません。
実際のドメインについては、絶対所有者を照会します。 _smtp._tls.YOURDOMAIN. 各機関から直接、再帰リゾルバーを介してタイプTXTを使用します。 TTL、完全なレコード、およびエイリアスを保持します。次に、文書化されたテスト ワークフローを使用して、コレクターを個別に検証します。この記事には、ライブDNS公開、レポート送信、確認済みレポート受信は含まれません。
受信したレポートを信頼する前に検証する
参考文献: RFC 8460 §3, RFC 8460 §7.
SMTPによって配信されるレポートの場合、 RFC 8460では有効な DKIM署名 レポートドメインによって禁止されています DKIM l= body-length limitation. Reports lacking the required valid signature must be ignored. The DKIM key should declare the tlsrpt service type; the specification permits a collector to ignore reports lacking that declaration.
パーサーのサイズ制限を適用し、レポーターの ID とレポート期間を保持します。沈黙を健全な輸送と解釈することは避けてください。トラフィック量、送信者のサポート、レポートのスケジュール、コレクターの障害はすべて、到着に影響を与える可能性があります。受信したトランスポート レポートを、名前付きポリシーおよびSMTPルートとして扱うのではなく、関連付けます。 SPF、通常のメッセージのDKIMまたはDMARC結果。
保持されている歴史的証拠と残された範囲
以下は、このレビューのために再実行されたネットワーク実験ではなく、保存された 2026 年 11 月 7 日の観測結果について説明します。新しく実行されたオフライン チェックは個別に記録されます。
保存された履歴パッケージには、実際のループバックSMTPホスト名の障害にリンクされた合成TLS-RPT JSON レポートが含まれています。そのポリシー ドメインは example.test、 MXはmx.old.example .test、結果の種類は証明書ホスト不一致、失敗したセッション数は 1 です。レポートの期間はラボの実行を示し、その概要には、選択したシナリオの失敗したセッションが 1 つと成功したセッションが 0 つ含まれています。一致するSMTPイベントは、ホスト名検証エラーとともにvalid=falseを記録します。このレポートは、監視されたイベントからローカルで生成されたものであり、独立した送信者から受信したものではなく、 DKIM認証も受けていません。すべての名前と住所は研究室専用であるため、編集は必要ありませんでした。オプションの追加情報フィールドは省略されています。 RFC 8460その値を URI として定義しているため、説明的な出所はそのフィールドに配置されるのではなく、レポートの外部に保持されます。これは、レポートと問題のマッピングを示していますが、実際のDNS公開、コレクターの受信、署名の検証、および運用固有の証拠は、この教育用の例から分離されたままです。