SMTP TLS レポートポリシー
DNS とレコード
DNS ルックアップ あらゆるドメインのすべての DNS レコード A レコードルックアップ ドメインの IPv4 アドレス AAAA レコードルックアップ ドメインの IPv6 アドレス MX ルックアップ ドメインのメールサーバー NS ルックアップ 権威ネームサーバー TXT ルックアップ TXT レコード、SPF、検証 CNAME ルックアップ 正規名（エイリアス）レコード SOA ルックアップ Start of Authority レコード SRV ルックアップ サービスロケーションレコード CAA ルックアップ どの CA が証明書を発行できるか 逆引き DNS（PTR） IP アドレスからホスト名へ DNSSEC チェック ドメインは署名され検証されているか？ DNS ヘルスチェック 委任と DNS の総合診断レポートメール到達性
SPF チェック Sender Policy Framework レコードを検証 DMARC チェック DMARC ポリシーを検査・評価 DKIM チェック DKIM 公開鍵を検索・検証 ブラックリストチェック IP をメールブロックリスト（DNSBL）と照合 SMTP テスト メールサーバーに接続し STARTTLS をチェック MTA-STS チェック 受信メールに対する強制 TLS ポリシー BIMI チェック メール用のブランドロゴレコード TLS-RPT チェック SMTP TLS レポートポリシーネットワークとウェブ
SSL 証明書チェック サイトの TLS 証明書と有効期限を検査 HTTP ヘッダーチェック レスポンスヘッダー、リダイレクト、セキュリティを検査 Ping（TCP） TCP 経由での到達性と遅延 ポートチェック どの一般的なポートが開いているかドメイン
WHOIS ルックアップ ドメイン、IP、ASN の登録データTLS-RPT（SMTP TLS Reporting）は、送信サーバーからのTLS接続失敗に関する日次レポートをドメインが受け取れるようにし、メールが安全でない方法で配信されているのを検知できるようにします。IPeekは_smtp._tlsのTXTレコードを読み取り、レポートの送信先を表示します。MTA-STSやDANEを補完し、それらのポリシーが実環境でどう機能しているかの可視性を与えます。
TLS-RPTは、_smtp._tls.your-domainの単一のDNS TXTレコードとして公開されます。レコードは、バージョンタグと、レポートの送信先（mailtoアドレスまたはHTTPSエンドポイント）を列挙するrua=タグを保持します。標準に対応する送信サーバーは、自社のMXホストとのTLSネゴシエーションの結果を1日分集約し、それらの送信先へJSONレポートを配信します。各レポートは成功したセッションと失敗したセッションを集計し、証明書検証エラーやSTARTTLSが利用できないといった失敗を分類して、実際の配信に関するフィードバックループを与えます。
IPeekは、_smtp._tlsのTXTレコードが存在するかを確認し、解析したrua送信先を表示します。バージョンがTLSRPTv1であること、各ruaターゲットが実際に監視している有効なメールボックスまたはHTTPS URLであることを確認してください。レコード自体は何も強制せず、レポートを要求するだけなので、その存在は送信側がTLS失敗データの送り先を知っていることを意味します。レポートが届いたら、失敗の種類に注目してください。certificate-expired、検証失敗、starttls-not-supportedはそれぞれ、静かな配信問題を引き起こす前に、受信インフラ側の特定の修正を示します。
MTA-STSとDANEは受信メールにTLSを強制しますが、強制は実トラフィックへの影響を見られる場合にのみ安全です。TLS-RPTがその可視性を提供します。MTA-STSをtestingモードで展開すると、enforceに切り替える前に、どの送信側がTLS失敗に遭遇するかをレポートが明らかにします。同じことがDANE TLSAの不一致にも当てはまります。TLS-RPTは、強制の仕組みの代わりではなく並行して展開する、TLS態勢の監視層と捉えてください。そうすれば証明書や設定の問題を早期に発見できます。
_smtp._tls.your-domainに公開されるTXTレコードで、TLS失敗レポートを要求するものです。レコードには、v=TLSRPTv1バージョンタグと、レポートの送り先をmailtoアドレスまたはHTTPS URLとして指定するrua=タグが含まれます。TLS-RPTに対応する送信サーバーは、これを使って、自社ドメインへのTLS接続に関する日次集約レポートをどこへ配信すべきかを把握します。
TLS-RPTレポートは、送信サーバーと自社MXホスト間の1日分のTLSネゴシエーションを要約したJSONドキュメントです。成功したセッションと失敗したセッションを集計し、期限切れ証明書、証明書検証エラー、STARTTLSが利用できないなど、失敗を種類別に分類します。これにより、どの受信ホストや証明書が安全でない配信や失敗した配信を引き起こしているかを特定できます。
いいえ。TLS-RPTは純粋に報告の仕組みであり、それ自体は何も強制しません。強制は、TLSを必須とし安全でない配信をブロックできるMTA-STSやDANEによって行われます。TLS-RPTはそれらのポリシーと並んで監視層として位置し、TLSがどれだけ成功または失敗しているかの可視性を与え、強制を自信を持って展開できるようにします。
_smtp._tls.your-domainに、v=TLSRPTv1と、監視しているメールボックスまたはHTTPSエンドポイントを指すrua=タグ（例：rua=mailto:tlsrpt@your-domain）を含むTXTレコードを公開します。レポートはJSONとして日次で届くため、実際に監視している送信先を選んでください。MTA-STSやDANEと組み合わせれば、レポートが強制されたTLSポリシーの動作を記述するようになります。
TLS-RPTは、MTA-STSを安全に展開可能にする可視性を提供します。MTA-STSポリシーをtestingモードで公開すると、送信サーバーがTLS失敗をTLS-RPT経由で報告するため、enforceへ切り替える前にどの送信側がブロックされるかが分かります。両者は連携するよう設計されており、MTA-STSがポリシーを設定し、TLS-RPTがそれが実際にどう機能しているかを伝えます。