TLSレポートとは？ SMTP TLSレポートがメールの配信失敗をどのように検出するのか
by
最終更新日:
6 読了時間：約6分
SMTPのTLS関連の障害のほとんどは、誰にも気づかれることなく発生します。証明書の有効期限が切れたり、サーバーがSTARTTLSのサポートを中止したり、攻撃者によってダウングレードが強制されたりすると、メールは暗号化されずに送信されたり、そもそも届かなかったりしますが、その原因を説明するアラートは表示されません。TLSレポート機能は、こうした情報ギャップを埋めるために存在します。
RFC 8460で定義されているSMTP TLSレポート（TLS-RPT）は、ドメイン所有者がメールサーバー間でTLS暗号化が失敗したタイミングやその原因を把握するための標準化された手段を提供します。本記事では、SMTP TLSの仕組み、失敗する原因、実際のTLS-RPTレポートの各フィールドごとの内容、そしてレポートを読み解く際に遭遇する具体的な失敗の種類について解説します。
SMTP TLSとは何か、そしてなぜ失敗するのか？
TLS レポートがなぜ重要なのかを理解するには、そもそもなぜ SMTP にそれが必要だったのかを知っておくと役立ちます。
SMTPは暗号化を前提として設計されていなかった
SMTPの起源は1982年にさかのぼります。当時、電子メールは小規模で信頼性の高いネットワークであり、このプロトコルは暗号化層を備えずに設計されました。メッセージはデフォルトで平文のままサーバー間でやり取りされていました。
その脆弱性は数十年にわたって放置されたままだった。暗号化機能は後になって追加されたが、必須ではなくオプションとして導入されたため、そこから次の問題が生じ始めた。
STARTTLSにより、暗号化は必須ではなくなり、保証もされなくなった
STARTTLS を使用すると、送信側のサーバーは受信側のサーバーに対し、平文接続を暗号化接続にアップグレードするよう要求することができます。双方がこれをサポートしている場合、メッセージは暗号化されて送信されます。いずれか一方がサポートしていない場合、あるいはハンドシェイクに何らかの障害が生じた場合、接続は黙って平文に戻りますが、メールは問題なく送信されます。
そのフォールバックこそが、TLS-RPTが明らかにするために構築された根本的な問題なのです。標準のSMTPには、設定ミスによるものであれ、転送中に誰かが意図的にSTARTTLSコマンドを削除したためであれ、メッセージが暗号化されずに送信されたかどうかを示す仕組みは一切ありません。
TLSレポーティング（TLS-RPT）とは何か？
TLS-RPTは、RFC 8460で定義された報告規格であり、ドメイン所有者が、自身のドメイン宛てに送信された電子メールのTLS接続エラーに関する、定期的かつ構造化されたレポートを受け取れるようにするものです。この規格はエラーの発生そのものを防ぐものではありません。エラーがいつ発生したか、どのくらいの頻度で発生したか、そしてその原因を把握できるようにすることで、根本的な問題を解決できるよう支援します。
RFC 8460 のレポートフィールドの詳細な内訳や、TLS-RPT DNS レコードの公開方法については、TLS-RPT に関する当社の詳細ガイドをご覧ください。
TLS-RPTとMTA-STSの関係
TLS-RPTとMTA-STSはペアで機能します。MTA-STSは強制メカニズムであり、送信サーバーに対して、あなたのドメイン宛てのメールは暗号化・認証済みの接続を経由するか、さもなければ送信しないよう指示します。TLS-RPTは可視化メカニズムであり、その暗号化された接続が確立できなかった場合に、何が起きたかを報告します。一方がルールを設定し、もう一方がそのルールがトリガーされたことを通知する役割を担っています。
ご自身のドメインでMTA-STSを設定する方法の詳細な手順については、当社のMTA-STS実装ガイドをご覧ください。
SMTP TLS レポートの仕組み：手順を追って解説
- ドメイン所有者は、TLS-RPT DNSレコードを公開します。このレコードは、メールを送信するサーバーに対し、障害レポートをどこに送信すべきかを指示するものです。
- 送信サーバーは、通常STARTTLSを介して、TLSを使用してメールの配信を試みます。
- その試みが失敗した場合、送信サーバーは失敗の原因をログに記録します。
- およそ24時間に1回、送信サーバーはこれらの結果をJSON形式のレポートにまとめ、通常は電子メールまたはHTTPS POSTを介して、ドメインのTLS-RPTレコードに記載されたアドレスに送信します。
- ドメイン所有者はレポートを開き、どのサーバーに障害が発生しているか、どのくらいの頻度で発生しているか、そしてその原因といったパターンを探ります。
実際のTLS-RPTレポートの内容
TLS-RPTのレポートはJSON形式で返されますが、これは人間が直接読み取るには適していません。以下に、RFC 8460のフォーマットに基づいた、短縮版の実例を示します。成功したセッションの概要と失敗したセッションの概要を掲載し、その後に各フィールドの平易な解説を添えています。
JSON
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2026-07-01T00:00:00Z",
"end-datetime": "2026-07-01T23:59:59Z"
},
"contact-info": "[email protected]",
"report-id": "[email protected]",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: enforce",
"mx: mail.yourdomain.com",
"max_age: 604800"
],
"policy-domain": "yourdomain.com"
},
"summary": {
"total-successful-session-count": 4821,
"total-failure-session-count": 3
},
"failure-details": [
{
"result-type": "certificate-expired",
"sending-mta-ip": "209.85.220.41",
"receiving-mx-hostname": "mail.yourdomain.com",
"receiving-mx-helo": "mail.yourdomain.com",
"receiving-ip": "203.0.113.45",
"failed-session-count": 2,
"additional-information": "https://support.google.com/mail/answer/tls-rpt-cert-expired"
},
{
"result-type": "starttls-not-supported",
"sending-mta-ip": "209.85.220.41",
"receiving-mx-hostname": "mail2.yourdomain.com",
"receiving-ip": "203.0.113.46",
"failed-session-count": 1
}
}
}
]
}
各フィールドの実際の意味
- 組織名：レポートを送信した相手。通常、Google、Microsoft、Yahooなどの大手メールプロバイダーです。
- date-range：レポートの対象期間。多くの送信者は、24時間ごとのローリング方式でレポートを作成しています。
- contact-info / report-id：送信者への連絡方法、およびこの特定のレポートに割り当てられた一意のID。サポートチケット内でこのレポートを参照する必要がある場合に役立ちます。
- policy-type / policy-string:送信サーバーがその時点でドメインに対して確認した MTA-STS（または DANE）ポリシーで、取得されたままの形式で表示されます。これにより、公開しているポリシーが、送信者が実際に受信している内容と一致しているかを確認できます。
- 成功セッション総数 / 失敗セッション総数：最も注目すべき数値です。この例では、4,824回の配信試行のうち4,821回が成功し、3回が失敗しました。
- failure-details:障害の種類ごとに1つのエントリがあり、その件数が記載されています。これは対応が必要な部分です：
– certificate-expired:失敗したセッションのうち2つで、TLS証明書の有効期限が切れていました。対処法：証明書を更新して再インストールしてください。
– starttls-not-supported:1つのセッションにおいて、受信サーバー（mail2.yourdomain.com）がSTARTTLSにまったく応答しませんでした。対処法: サーバーのTLS設定に欠落や設定ミスの可能性があるので、確認してください。
レポートでよく見られるTLSエラーの種類
TLS-RPTレポートでは、結果タイプの値として固定のセットが使用されます。ここでは、最も頻繁に表示される値、それぞれの意味、および対処方法について説明します。
証明書の有効期限が切れています
受信サーバーのTLS証明書の有効期限が切れていました。有効期限が切れる前に証明書を更新し、次回の有効期限より十分に前にリマインダーを設定してください。
証明書名の不一致
提示された証明書は、送信元サーバーが期待していたホスト名と一致しません。これは通常、証明書の設定ミス、または誤ったホストを指すDNSレコードが原因です。
STARTTLS はサポートされていません
受信サーバーはSTARTTLSコマンドに対してまったく応答しませんでした。そのメールサーバーでTLSが正しく有効になっているか確認し、サーバーソフトウェアが実際にTLSをサポートしているか確認してください。
MTA-STS ポリシー取得の失敗
送信サーバーは、HTTPS経由でMTA-STSポリシーファイルを取得できませんでした。ポリシーファイルにアクセスできること、形式が正しいこと、および有効な証明書で提供されていることを確認してください。
TLSのバージョンが古すぎます
この接続では、送信元サーバーが古いか安全でないとみなすTLSバージョンのネゴシエーションが試みられました。メールサーバーのTLS設定を更新し、旧式のプロトコルバージョンを拒否するようにしてください。特に証明書関連の検証問題については、DANEに関するガイドをご覧ください。
SMTP TLS レポートが重要な理由
SMTP TLS レポートには、さまざまな利点があります。その一部を以下に挙げます。
セキュリティ：ダウングレード攻撃の検知
TLS-RPTは、接続が暗号化されていないチャネルに強制的に切り替えられたケースを検出しますが、これはまさにMITMダウングレード攻撃の背後にあるパターンそのものです。報告がなされなければ、そのような傍受は誰にも気づかれることなく、いつまでも続く可能性があります。
視認性：死角をなくす
TLS-RPTがなければ、ドメイン宛てのメールがなぜ配信に失敗したのか、あるいは暗号化されずに配信されたのかを確認する確実な方法はありません。レポートでは、推測に頼る必要がなく、TLS接続がどこで、なぜ切断されたのかが正確に示されます。
効率化トラブルシューティングの迅速化
配信の問題を特定するためにサーバーログを精査するには時間がかかります。TLS-RPTのレポートでは、障害が発生したサーバー、障害の種類、発生頻度が直接示されるため、トラブルシューティングにかかる時間を数日から数分に短縮できます。
まとめ：PowerDMARCがTLSレポート作成をいかに簡素化するのか
TLS-RPTレポートは生のJSONファイルとして届きますが、複数の送信元ごとに手作業で読み解くのはすぐに面倒になってしまいます。PowerDMARCは、これらのレポートを結果の種類や送信元ごとに集計し、読みやすいダッシュボードに自動的に変換するため、JSONファイルを1つも開かずに、何がどこで失敗しているかを確認できます。
当社はドメイン所有者の皆様を次のようにサポートしています：
- TLS-RPTレポートファイルを手動でデコードする必要がなく、生のJSONを自動的に解析して、読みやすいダッシュボードに変換します。
- 2つのレポート表示形式でフィルタリングします：送信元別（ポリシーモード、セッション数、配信総数）と結果別（上部に成功したセッション、下部に失敗したセッション）です。
- ドリルダウン操作で、失敗したセッションを展開し、受信サーバーのホスト名、IPアドレス、失敗回数、および原因を確認できないため、一目で解決策がわかるようになっています。
- JSON、ZIP、またはGZファイルをアップロードすると、アップロード履歴が記録されるため、過去のレポートをいつでも確認できます。
- ワンクリックでのDNS設定により、レポートの配信に必要なCNAMEレコードを自動生成・検証できるほか、集計レポートの送信先アドレスも設定可能です。
- チケット対応や詳細な調査のために元のファイルが必要な場合は、生のJSONファイルをエクスポートできます。アカウント内のどのユーザーがレポートをアップロードできるかを、きめ細かな権限設定で制御できます。
無料トライアルを開始するか、デモを予約して、ご自身のドメインのデータで実際にご確認ください。
よくあるご質問
1. TLSレポートはどのような目的で使用されますか？
TLSレポートは、問題が発生した内容とその原因について定期的にレポートを生成することで、証明書の有効期限切れ、サーバーの設定ミス、ダウングレード攻撃など、暗号化されたメールの配信における障害を検出・診断するために使用されます。
2. SMTP TLS レポートは TLS-RPT と同じものですか？
はい。「SMTP TLS レポーティング」と「TLS-RPT」は、同じ RFC 8460 規格を指しています。TLS-RPT は、このプロトコルの略称です。
3. 自分のドメインでTLSレポートを設定するにはどうすればよいですか？
ご自身のドメインで設定するには、レポートの送信先を指定したTLS-RPT DNSレコードを公開するだけです。当社のTLS-RPTレコードジェネレーターでレコードを生成し、TLS-RPTチェッカーで正常に動作していることを確認できます。
4. TLS-RPTを有効にしない場合はどうなりますか？
TLS-RPT を有効にしない場合でも、メールサーバーは独自に TLS 暗号化を試み続けますが、失敗した場合はその状況を把握することができません。ダウングレード攻撃、有効期限が切れた証明書、設定ミスのあるサーバーなどが、いつまでも気づかれないまま放置される可能性があります。
5. TLS-RPTはMTA-STSがなくても機能しますか？
はい、TLS-RPTはTLSの失敗について単独で報告することができます。しかし、MTA-STSと組み合わせて使用するのが最も有用です。なぜなら、MTA-STSは暗号化された配信を強制し、TLS-RPTはその強制が適用された際に何が起きたかを報告するからです。
6. SMTP TLS レポートはどのくらいの頻度で送信されますか？
ほとんどのプロバイダーでは、レポートをおよそ24時間に1回の頻度で生成・配信していますが、正確な間隔はプロバイダーによって異なる場合があります。
ドメインとメールセキュリティのエキスパートPowerDMARC
AhonaはPowerDMARCのマーケティングマネージャーで、サイバーセキュリティのトピックについて5年以上の執筆経験があり、ドメインと電子メールのセキュリティを専門としている。ジャーナリズムとコミュニケーションの卒業後学位を取得し、2019年からセキュリティ分野でキャリアを固めている。
最新記事 by Ahona Rudra(全て見る)
