← RFC Reference

RFC 8460: SMTP TLS レポーティング (TLSRPT)

なぜこれが存在するのか

2つの標準がサーバー間メールのTLSを強制します：MTA-STS（RFC 8461）とDANE（RFC 7672）。両者とも送信サーバーに「このドメインにメールを配信する前に有効なTLS接続を確立する必要があります」と伝えます。しかしTLSネゴシエーションが失敗すると、送信サーバーは平文にフォールバック（悪い）するか配信を拒否（メール喪失）するかのどちらかです。どちらの場合でも、受信ドメインは問題が存在することを知りません。

TLSRPTはこの可視性ギャップを埋めます。ドメイン所有者はTLSレポートをリクエストするDNSレコードを公開し、送信MTAはTLS接続結果を毎日のJSONレポートに集約し、メールまたはHTTPS経由で配信します。

TLSRPTなしでは、MTA-STSを証明書エラー付きでデプロイし、受信メールの相当な割合が拒否されるか安全でない方法で配信されていることに気付かないかもしれません。

仕組み

ステップ1：TLSRPT DNSレコードを公開する

_smtp._tls.yourdomain.comでTXTレコードを追加し、レポートの送信先を指定します：

ステップ2：送信サーバーがデータを収集する

送信MTAがあなたのドメインにメールを配信するとき、TLSネゴシエーション結果を記録します：有効な証明書によるセッション成功、ハンドシェイク失敗、証明書不一致、MTA-STSポリシー失敗、DANE検証失敗など。

ステップ3：毎日のレポート配信

送信MTAは1日1回、結果を集約してJSONレポートを送信します。メール経由で配信される場合、report-type=tlsrptのmultipart/reportメッセージとして到着します：

Content-Type: multipart/report; report-type=tlsrpt;
    boundary="TLSRPT-001"

--TLSRPT-001
Content-Type: text/plain

SMTP TLSレポート（example.com用）
報告期間：2026-03-10T00:00:00Z～2026-03-11T00:00:00Z

--TLSRPT-001
Content-Type: application/tlsrpt+json

{
  "organization-name": "Sender Corp",
  "date-range": {
    "start-datetime": "2026-03-10T00:00:00Z",
    "end-datetime": "2026-03-11T00:00:00Z"
  },
  "contact-info": "postmaster@sendercorp.com",
  "report-id": "2026-03-10-example.com",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce",
        "mx: mail.example.com", "max_age: 604800"],
      "policy-domain": "example.com"
    },
    "summary": {
      "total-successful-session-count": 9450,
      "total-failure-session-count": 12
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "198.51.100.1",
      "receiving-mx-hostname": "mail.example.com",
      "failed-session-count": 12
    }]
  }]
}

--TLSRPT-001--

主要な技術詳細

DNSレコード形式

失敗結果タイプ

ポリシータイプ

よくある間違い

• TLSRPTなしでMTA-STSを公開する。 enforceモードのMTA-STSは、TLSが失敗するとメール拒否を引き起こします。TLSRPTなしでは、それらの失敗を可視化できません。常に両者一緒にデプロイしてください。
• レポートを無視する。 TLSRPTレポートを受信することは、実際にそれらを解析して監視してこそ有用です。自動処理を設定するか、失敗を集約してアラート通知するサービスを使用してください。
• HTTPS配信のみを使用する。 HTTPS POSTは自動処理には洗練されていますが、一部の送信MTAはメール配信のみをサポートしています。可能であればmailto:とhttps:の両方のURIを提供してください。
• DNSレコード位置が間違っている。 レコードは_smtp._tls.yourdomain.comにある必要があり、_tls.yourdomain.comや_tlsrpt.yourdomain.comではありません。プレフィックスは具体的に_smtp._tlsです。
• 証明書を期限切れにしている。 TLSRPTで報告される最も一般的な失敗はcertificate-expiredです。証明書更新を自動化し（例えばLet's Encryptで）、有効期限の日付を監視してください。
• MXホスト名と証明書をチェックしていない。 TLS証明書はMTA-STSポリシーとMXレコードにリストされているホスト名をカバーしている必要があります。MXがmail.example.comでも証明書がexample.com用である場合、送信者はcertificate-host-mismatchを報告します。

配信可能性への影響

• TLS失敗の可視化。 TLSRPTなしでは、TLSネゴシエーション失敗は不可視です。先週証明書が期限切れになったため大量送信者からのメールが拒否されていることを知りません。
• 安全なMTA-STS強制の前提条件。 推奨されるデプロイメントパスは：MTA-STSをtestingモードで公開し、TLSRPTを有効にし、レポートの失敗を監視し、問題を修正してからenforceに切り替えます。監視ステップをスキップするとメール喪失のリスクがあります。
• 中間者攻撃の検出。 特定のネットワークからのcertificate-not-trustedまたはstarttls-not-supportedの急激な増加は、STARTTLS削除攻撃を示している可能性があります。TLSRPTがこれを可視化します。
• コンプライアンス証拠。 機密通信を扱うドメインの場合、TLSRPTレポートはインバウンド接続の大多数に対してTLSが正常にネゴシエートされていることの証拠を提供します。

Related RFCs