TLS-RPTレポートの読み方｜メール配送のTLS失敗を監視する方法
メールが相手企業へ届かないとき、SPF・DKIM・DMARCだけを確認しても、配送経路のTLS障害は見つかりません。受信側の証明書切れ、STARTTLS未対応、MTA-STSポリシーの公開ミスがあると、送信ドメイン認証に成功していても、暗号化配送が失敗したり、MTA-STSの設定によってはメールが再送待ちになったりします。
結論：TLS-RPTレポートは、日付範囲、報告組織、policy-domain、mx-host、成功・失敗セッション数、result-typeの順に読みます。件数だけで障害と決めず、複数の送信元で同じ失敗が続くか、MTA-STSがtestingかenforceか、証明書・DNS・MXの変更と時刻が一致するかを確認します。TLS-RPT監視は「レポートを受け取った時」ではなく、「失敗を担当者と復旧行動へ結び付けた時」に完了します。
本記事のポイント
- TLS-RPTはメール本文やDMARC認証ではなく、受信ドメインまでのSMTP接続でTLSと配送ポリシーが成立したかを集計します。
- 成功・失敗セッション数を母数にし、result-type、mx-host、報告組織、発生日を組み合わせて原因と影響範囲を切り分けます。
- 単発の件数だけで判断せず、複数送信元での継続、MTA-STSのmode、証明書・DNS変更履歴、配送ログを突合して対応します。
TLS-RPTとは何を報告する仕組みか
TLS-RPT（SMTP TLS Reporting）は、受信ドメインへメールを送ろうとした送信側MTAが、TLS接続と配送ポリシーの成功・失敗を受信ドメインの管理者へ集計報告する仕組みです。受信ドメインはDNSの_smtp._tlsへv=TLSRPTv1と報告先ruaを公開します。報告先にはメールアドレスまたはHTTPSエンドポイントを指定できます。
RFC 8460では、TLS-RPTをMTA-STSまたはDANEと組み合わせ、送信側が受信側へのポリシー準拠TLS接続に成功したか、どの検証で失敗したかを共有する仕組みとして定義しています。メール本文、宛先個人、開封、クリックを報告するものではなく、集計単位は主にSMTPの接続セッションです。
| 仕組み | 主に確認すること | 代表的な確認対象 | TLS-RPTとの関係 |
|---|---|---|---|
| TLS-RPT | SMTP配送経路のTLS・ポリシー検証結果 | 成功・失敗セッション、証明書、STARTTLS、MTA-STS | 結果を集計して知らせる |
| MTA-STS | 受信側が要求するTLS配送条件 | 許可MX、証明書、mode、max_age | 検証失敗の判断基準になる |
| DMARC | 送信ドメインとSPF・DKIMの整合 | なりすまし、認証結果、適用ポリシー | 目的が異なる別の集計レポート |
| 配送ログ | 自社MTAでの個別配送と再送状態 | キュー、SMTP応答、バウンス、遅延 | TLS-RPTで見えない個別事象を補う |
DMARCとTLS-RPTは、どちらもDNSで報告先を公開し、集計レポートを受け取るため混同されやすい仕組みです。しかし、DMARCは主に送信者認証、TLS-RPTは受信側までの暗号化配送を見ます。SPF・DKIM・DMARCとメール到達率全体の関係は、メール到達率の原因チェックと運用KPIで整理しています。
MTA-STSは、_mta-stsのTXTレコードとHTTPS上のポリシーファイルを使い、許可するMXとTLS検証条件を受信側が示します。RFC 8461では、modeをtesting、enforce、noneに分けています。testingでは違反を報告しながら配送を許容でき、enforceではSTARTTLS、MX一致、証明書検証に失敗した配送を許可しません。
TLS-RPTレポートで最初に見る項目
レポートはJSON、またはJSONをgzip圧縮した添付ファイルとして届くことがあります。最初から個々のエラーコードを追うより、報告期間と対象ポリシーを確定し、成功・失敗の母数を見てからfailure-detailsへ進む方が誤判定を減らせます。
| 確認順 | JSON項目 | 読み取る内容 | 注意点 |
|---|---|---|---|
| 1 | date-range / report-id | 集計期間とレポートの一意性 | UTCの日付境界と重複取り込みを確認 |
| 2 | organization-name | どの送信組織が報告したか | 全送信者を網羅するレポートではない |
| 3 | policy-type / policy-domain | MTA-STS、DANE、ポリシーなしのどれか | 自社が意図したポリシーと一致するか確認 |
| 4 | mx-host / policy-string | 検証対象の受信MXと適用条件 | 旧MXや想定外ホストが混ざっていないか確認 |
| 5 | total-successful-session-count / total-failure-session-count | 成功・失敗した接続セッション数 | メール通数や受信者数とは限らない |
| 6 | failure-details | 失敗種別、対象MX・IP、失敗セッション数 | 複数の失敗種別が重複計上される場合がある |
RFC 8460は、レポート期間を原則としてUTCの1日分とし、成功セッション数を「レポート機能が動いていることを示すheartbeat」と位置付けています。失敗率を出す場合は、同じ報告組織、期間、policy-domain、mx-hostの中で、失敗 ÷（成功＋失敗）を見ると比較しやすくなります。ただし、failure-detailsの内訳は重複し得るため、result-type別件数を合計して総失敗数にしないでください。
添付レポートは外部から届くデータです。専用メールボックスや受信APIへ集約し、MIME種別、送信元ドメインのDKIM、ファイルサイズ、展開後サイズ、JSON形式を検証してから処理します。作業端末で不明な添付を直接実行したり、無制限に展開したりしない運用が必要です。
result-typeから失敗原因を切り分ける
result-typeは「直す担当」を決める入口です。証明書、受信MTA、DNS・Web公開、MTA-STSポリシーを分けると、メール担当がすべてを抱えずに済みます。まず同じresult-typeがどのmx-host、receiving-ip、報告組織に集中しているかを集計します。
| result-type | 意味 | 最初に確認する場所 | 主な担当 |
|---|---|---|---|
| starttls-not-supported | 対象MXがSTARTTLSを提供しなかった | 受信MTAのTLS設定、LB・中継、対象ポート | メール基盤 |
| certificate-expired | 提示証明書の有効期限が切れている | 全MXの証明書、更新ジョブ、反映先 | インフラ・証明書管理 |
| certificate-host-mismatch | 証明書のSANと接続先MX名が一致しない | MX名、証明書SAN、LBの証明書割当 | DNS・インフラ |
| certificate-not-trusted | 信頼できるCAへのチェーン等を検証できない | 中間証明書、証明書チェーン、受信MTA設定 | インフラ |
| sts-policy-fetch-error | MTA-STSポリシーを取得できない | mta-stsホスト、HTTPS、DNS、応答状態 | Web・DNS |
| sts-policy-invalid | MTA-STSポリシー全体の形式が不正 | version、mode、mx、max_age、改行・Content-Type | メール・Web |
| sts-webpki-invalid | ポリシー公開先のHTTPS証明書を検証できない | ポリシーホストの証明書名、期限、チェーン | Web・証明書管理 |
| validation-failure | 既定分類に当てはまらない検証失敗 | failure-reason-code、additional-information、同時刻ログ | メール基盤から切り分け |
例えばcertificate-host-mismatchが新しいMXだけで増えたなら、証明書自体の期限ではなく、MX切り替え先とSANの不一致を疑います。sts-policy-fetch-errorが複数の報告組織で同時に増えたなら、ポリシー公開先のDNS、HTTPS応答、CDN、証明書を確認します。外部公開ドメインや証明書の更新責任が曖昧な場合は、企業ドメインの更新期限・権限・復旧手順と同じ台帳へ、MTA-STSホストと証明書の所有者を追加すると抜けを減らせます。
DMARC enforcementはTLS配送の強制とは別です。BIMI導入などでDMARCを強化していても、受信MTAのTLS証明書やMTA-STSポリシーが正しいとは限りません。送信者認証側の条件は、BIMIとDMARCの関係で確認できます。
受信から復旧確認までを6ステップで運用する
TLS-RPTは、レポートを人が読むだけでは継続監視になりません。受信、検証、正規化、集計、修正、回復確認を同じ処理単位にし、担当者と期限を決めます。重要な配送ドメインでは、変更前後の比較とロールバック条件も残します。
- 報告先を専用化する：
_smtp._tlsのruaを専用メールボックスまたは受信APIへ向け、担当者の個人受信箱や転送だけに依存しない構成にします。 - 安全に検証・展開する：重複report-id、報告期間、送信元、DKIM、MIME、圧縮形式、展開後サイズ、JSONスキーマを確認し、不正・破損レポートを隔離します。
- 同じ粒度へ正規化する：報告組織、policy-domain、mx-host、receiving-ip、result-type、成功・失敗セッション数を保存し、元レポートへの参照を残します。
- 影響と原因を分類する：複数送信元への広がり、継続日数、失敗率、MTA-STSのmode、対象MXを見て、証明書、STARTTLS、ポリシー公開、DNSの担当へ割り当てます。
- 変更を一つずつ実施する：証明書更新、SAN修正、STARTTLS有効化、ポリシーファイル修正、MX更新を変更記録と承認に結び、同時変更で原因が見えなくなることを避けます。
- 回復を別経路でも確認する：次回レポートの成功率だけでなく、配送キュー、外部テスト、SMTPログ、バウンスを確認し、複数の主要報告組織で回復が続いたら閉じます。
Google Workspace管理者ヘルプのMTA-STSとTLSレポート設定は、MTA-STS用の_mta-stsとTLSレポート用の_smtp._tlsを分けて公開する手順を示しています。MTA-STSのポリシーを変更したときは、ポリシーファイルだけでなく、送信側へ更新を知らせるTXTレコードのpolicy IDも更新します。
メール配信ツールやリレーを選ぶ段階では、自社ドメインのSPF・DKIM設定だけでなく、配送ログの保持、TLSエラーの確認、バウンスの取得、障害時の問い合わせ先まで要件化します。選定項目はBtoBメール配信ツールの機能要件と合わせて確認してください。
対応優先度と監視の限界を決める
優先度は「失敗件数が多い順」だけでは決めません。enforce中の配送停止、複数の主要送信組織への波及、全MXへの広がり、証明書期限切れ、DNS変更直後の急増を上位にします。少数でも、取引先や本人確認など重要通知の送信元で継続する場合は、事業影響を加味します。
| 優先度 | 目安 | 初動 | 閉じる条件 |
|---|---|---|---|
| 緊急 | enforce中に複数報告元・全MXで失敗、証明書切れ、STARTTLS停止 | 配送影響を確認し、変更停止、担当招集、復旧または安全な切り戻し | 配送ログと複数報告元で回復 |
| 高 | 一部MXで継続、主要送信元で急増、ポリシー取得不能 | 対象MXを切り分け、DNS・証明書・Web公開を修正 | 失敗率が基準内へ戻り再発なし |
| 中 | testing中のポリシー不一致、少数だが複数日継続 | enforce移行前に設定差分と所有者を修正 | testingで主要送信元の失敗が解消 |
| 観察 | 単一報告元の単発、汎用validation-failure、一時的変動 | 基準値へ記録し、翌日以降と配送ログを比較 | 継続せず、個別配送にも影響なし |
TLS-RPTは、TLS-RPTを実装した送信側から届く集計です。すべての送信元が参加するわけではなく、RFC 8460ではネットワーク混雑やTCPタイムアウトなどの一時障害は報告必須ではありません。レポートがゼロだから配送障害もゼロとは判断せず、外形監視、配送キュー、バウンス、サポート問い合わせと合わせます。
Google Workspace管理者ヘルプのMTA-STS設定確認では、_mta-sts、ポリシーファイル、_smtp._tlsの3点を検証対象にしています。設定修正後は、一つ目のエラーが消えたことだけで終えず、再検証して残りの問題も解消したか確認します。
新しい送信ドメインの立ち上げでは、受信側TLSの監視と送信側レピュテーションの管理を分けます。送信量、苦情、バウンスを見ながら増減する手順は、送信ドメインのウォームアップを参考にしてください。
よくある質問
TLS-RPTとは何ですか？
TLS-RPTは、受信ドメインへメールを届けようとした送信側MTAが、TLS接続とMTA-STSまたはDANEのポリシー検証結果を集計して返す仕組みです。メール本文、個人別の受信結果、開封状況を報告するものではありません。
TLS-RPTレポートのどの項目を確認しますか？
date-range、organization-name、policy-domain、mx-host、total-successful-session-count、total-failure-session-count、failure-detailsのresult-typeを順に確認します。件数はメッセージ数ではなくセッション数で、失敗種別が重複する場合があります。
証明書エラーとMTA-STSポリシー不一致をどう見分けますか？
certificate-expired、certificate-host-mismatch、certificate-not-trustedは受信MXの証明書を確認します。sts-policy-fetch-error、sts-policy-invalid、sts-webpki-invalidはMTA-STSポリシーの公開先、形式、HTTPS証明書を確認します。mx-hostとreceiving-ipを併せて見ると対象を絞れます。
TLS配送エラーを見つけたら何から対応しますか？
同じresult-typeを報告組織とmx-hostで集計し、MTA-STSのmodeと配送ログを確認します。enforceで複数送信元に影響している場合は、証明書、STARTTLS、DNS、ポリシー公開の担当をすぐに決め、復旧または安全な切り戻しを進めます。
TLS-RPTだけでメール配送障害をすべて検知できますか？
できません。TLS-RPTを実装している送信側からの集計であり、すべての送信者や一時的なネットワーク障害が必ず含まれるわけではありません。配送ログ、キュー、バウンス、外形監視、利用者からの問い合わせと併用します。
DMARC集計レポートとTLS-RPTは何が違いますか？
DMARC集計レポートはSPF・DKIMの整合と送信ドメインのなりすましを主に確認します。TLS-RPTは受信側までのSMTP配送で、暗号化接続やMTA-STS・DANEの検証が成立したかを確認します。どちらか一方で代用するものではありません。
仕様と設定を確認できる公式資料
- RFC Editor：RFC 8460 SMTP TLS Reportingでは、DNSレコード、JSONスキーマ、成功・失敗セッション数、result-type、メール・HTTPSでのレポート配送を確認できます。
- RFC Editor：RFC 8461 SMTP MTA Strict Transport Securityでは、MTA-STSポリシー、MX・証明書検証、testing・enforce・noneの動作を確認できます。
- Google Workspace管理者ヘルプ：MTA-STSとTLSレポートを有効にするでは、
_mta-stsと_smtp._tlsの設定例を確認できます。 - Google Workspace管理者ヘルプ：MTA-STSの設定を確認するでは、DNS、ポリシーファイル、TLSレポート設定の検証方法を確認できます。
