SMTP TLSレポート（TLS-RPT）とは？TXTレコードの書き方・レポート内容・診断基準

SMTP TLSレポート（TLS-RPT）とは

**SMTP TLSレポート（TLS-RPT）**とは、自ドメイン宛てのメールを配送しようとした送信側メールサーバーが「TLS接続に成功したか、失敗したならなぜか」を集計し、毎日レポートとして受信ドメインの管理者へ送ってもらう仕組みです。RFC 8460で定められており、DNSの _smtp._tls.<ドメイン> にTXTレコードで報告先を公開するだけで有効になります。

_smtp._tls.city.example.lg.jp. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@city.example.lg.jp"

MTA-STSやDANEでメール経路の暗号化を強制すると、証明書の期限切れやMX名の不一致などの設定ミスがあった場合、正規のメールが届かなくなります。しかも配送失敗は送信側で起きるため、受信側の管理者は気づけません。TLS-RPTは、こうした障害やダウングレード攻撃の兆候を受信側が把握するための「監視の目」です。DMARCの集計レポート（rua）がなりすまし対策の可視化を担うのと同様に、TLS-RPTは経路暗号化の可視化を担います。

セキュリティAIチェッカーのこの項目は、自治体のメールドメインに、RFC 8460に適合したTLS-RPTレコードが1件公開され、有効な報告先が指定されているかを確認します。暗号化を強制する側の設定は「MTA-STS」、DMARCのレポート先は「DMARC集計レポート送信先」の各項目で評価します。

TLS-RPTの仕組み（レコードの書式とレポートの内容）

TLS-RPTレコードの書式（RFC 8460 §3）

_smtp._tls.city.example.lg.jp. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@city.example.lg.jp"

• v=TLSRPTv1 で始まり、区切りの ; の前後には空白を入れられます。
• rua に報告先URIを指定します。mailto:（メールで受信。送信側はDKIM署名を付ける）と https:（HTTPS POSTで受信）が使え、カンマ区切りで複数指定できます。
• 送信側は、v=TLSRPTv1; で始まらないTXTを捨て、残りが1件でなければ「TLS-RPT未実装」とみなさなければなりません（MUST）。つまり、レコードを2件公開すると無効になります。

レポートの内容（§4）

レポートはI-JSON形式で、gzip圧縮されることがあります（メディアタイプ application/tlsrpt+json、application/tlsrpt+gzip）。通常、UTCの1日（00:00〜24:00）分をまとめて送ります。主な内容は次のとおりです。

• 報告者（送信組織）と対象期間
• 適用されたポリシー（MTA-STSのポリシー本文、DANEのTLSA、ポリシーなし）
• 成功したセッション数と失敗したセッション数
• 失敗の種類と、失敗した送信元・受信MXのIPアドレス

失敗の種類（result-type）の読み方

失敗の種類（result-type）はRFC 8460 §4.3で次のように定義されています。

ポリシーが無い場合も、適用ポリシー種別を no-policy-found としてレポートが作られます。

MTA-STS・DANEとの関係

TLS-RPTは単独でも公開できますが、意味のある情報が得られるのは、MTA-STSまたはDANEのポリシーがある場合です。特にMTA-STSを testing モードで運用する段階では、TLS-RPTのレポートが enforce に移行してよいかを判断する唯一の根拠になります。RFC 8461もtestingモードを「TLSRPTを実装した送信側が失敗を報告するモード」と説明しています。

TLS-RPTについてよくある誤解

• 「TLS-RPTを設定すれば暗号化される」：報告を受け取るだけで、配送の動作は変わりません。
• 「ruaにはDMARCと同じアドレスを書けばよい」：書くこと自体は可能ですが、形式の異なるJSONレポートが混在するため、専用アドレスや解析サービスを分けると運用しやすくなります。
• 「レポートが来ないのは設定が間違っているから」：TLS-RPTに対応した送信者（Google、Microsoftなど）から実際にメールが届いた日だけ送られます。受信量が少ないドメインでは届かない日もあります。

SMTP TLSレポート（TLS-RPT）の診断基準（セキュリティAIチェッカー）

取得対象

• 対象ドメイン：最終URLのホスト名から先頭の www. を除いたもの。
• DNS-over-HTTPS（dns.google）で MX と _smtp._tls.<ドメイン> のTXTを照会します（タイムアウト5秒）。複数文字列に分割されたTXTは連結します。

有効なレコードの条件

1. v=TLSRPTv1 の後に ;（前後の空白可）が続くTXTだけを残します。
2. 残ったレコードがちょうど1件で、その中に rua= があり、値が mailto: または https: で始まれば「有効」とします。

判定条件

重大度はlowです。TLS-RPTの欠如は直接の脆弱性ではなく、監視体制の不足を示すためです。ただし、MTA-STSを導入している、あるいは導入予定の場合は、実質的に必須の設定です。要確認の場合、根拠欄には該当レコードの件数を表示します。

自治体サイトでの判定例

判定の限界

ruaのメールアドレスが実際に受信可能か、レポートが解析・確認されているかは評価できません。_smtp._tls のTXT照会に失敗した場合は、レコードなしと同じ要確認になります（MXの照会失敗は上表のとおり対象外として区別します）。

TLS-RPTが無いとどんなリスクがあるか

• 障害に気づけない：MTA-STSの enforce やDANEを導入後、証明書の更新漏れやMX変更の反映漏れが起きると、対応送信者からのメールが配送されません。TLS-RPTが無いと、住民や事業者からの「メールが届かない」という問い合わせで初めて発覚します。
• 攻撃の兆候を見逃す：特定の送信元からのみ starttls-not-supported が多発するなど、経路上でのSTARTTLS除去（ダウングレード）を示す兆候を把握できません。
• 段階導入が進まない：レポートが無いとMTA-STSを testing から enforce へ移行する根拠が得られず、保護効果のない状態が長期化します。

TLS-RPTの設定方法（DNS・HTTPS受信・Webサーバー）

設定の手順

1. レポート受信用のアドレス（例 tlsrpt@）または解析サービスを用意します。大量のJSONメールが届くため、個人の受信箱は避けます。
2. _smtp._tls.<ドメイン> にTXTレコードを1件だけ公開します。
3. 1〜2週間後、レポートが届いているか、失敗セッションが無いかを確認します。
4. MTA-STSを testing で公開している場合は、レポートの失敗がゼロであることを確認して enforce へ移行します。

DNSゾーンファイル

; メールで受け取る
_smtp._tls.city.example.lg.jp. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@city.example.lg.jp"

; 解析サービスとの併用（1レコード内でカンマ区切り）
_smtp._tls.city.example.lg.jp. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@city.example.lg.jp,https://tlsrpt.example-analytics.net/v1/report"

RFC 8460は、報告先を自ドメイン外（委託先の解析サービス等）に指定できることを認めていますが、DMARCのような外部報告先の承認確認の仕組みは定義していません（セキュリティ上の考慮事項でこの点に言及しています）。外部に送る場合は、レポートに含まれるIPアドレスやポリシー情報の取り扱いを契約で定め、信頼できる事業者を選定します。

HTTPSで受信する場合（参考実装：Next.js Route Handler）

// app/api/tlsrpt/route.ts
import { gunzipSync } from "node:zlib";

export async function POST(req: Request) {
  const type = req.headers.get("content-type") ?? "";
  const body = Buffer.from(await req.arrayBuffer());
  if (body.length > 5_000_000) return new Response("too large", { status: 413 });
  // 展開後のサイズにも上限を設ける（圧縮爆弾対策。超えると例外）
  const json = type.includes("gzip") ? gunzipSync(body, { maxOutputLength: 20_000_000 }).toString("utf8") : body.toString("utf8");
  const report = JSON.parse(json);
  await storeReport(report); // 保存・集計（実装は運用環境に合わせる）
  return new Response(null, { status: 201 });
}

受信エンドポイントは認証なしで外部から呼ばれるため、受信サイズと展開後サイズの上限・JSON検証（不正なJSONは例外になるため実運用ではtry/catchで400を返す）・レート制限を設け、他の業務システムとは分離します。

Apache / nginx / IIS

TLS-RPTはDNSレコードだけで完結するため、Webサーバー設定は不要です。HTTPS受信を選んだ場合のみ、上記のような受信アプリケーションを用意し、Webサーバーでリクエストボディの上限（Apache LimitRequestBody、nginx client_max_body_size、IIS maxAllowedContentLength）を設定します。

設定後の確認方法

dig +short TXT _smtp._tls.city.example.lg.jp

Resolve-DnsName -Type TXT _smtp._tls.city.example.lg.jp

レコードが1件だけ表示され、v=TLSRPTv1; で始まり、rua=mailto: または rua=https: を含むことを確認します。その後、セキュリティAIチェッカーで再診断します。

運用の注意点（ガードレール）

• レコード追加はメール配送に影響しないため、安全に導入できます。最初に設定し、MTA-STSの準備に役立てるのが効率的です。
• 受信アドレスに迷惑メールフィルタや容量制限が掛かっていないか確認します。
• 委託事業者がDNSを管理している場合は、既存の _smtp._tls レコードを上書き・重複させないよう作業手順に明記します。

よくある質問（FAQ）

参考資料

• RFC 8460「SMTP TLS Reporting」
• RFC 8461「SMTP MTA Strict Transport Security (MTA-STS)」
• Google Public DNS「JSON API for DNS over HTTPS (DoH)」

「SMTP TLSレポート（TLS-RPT）」と関連する診断項目

• MTA-STSmedium
• DMARC集計レポート送信先low
• SPFレコードmedium
• SPFの終端ポリシーmedium
• DMARCレコードhigh
• DMARC強制ポリシーmedium
• CAAレコードlow
• DNSSECmedium