TLS-RPTとSMTP TLSレポートの究極ガイド

組織が主要なコミュニケーション手段として電子メールに依存するようになっているため、潜在的な脅威から電子メール・チャネルを保護することの重要性は、いくら強調してもし過ぎることはありません。トランスポート・レイヤー・セキュリティ（TLS）は、ネットワークを介して送信されるデータの機密性と完全性を保証します。

SMTP TLS Reporting (TLS-RPT)は、MTA-STSと共に動作し、電子メールの安全な配信を保証する重要なプロトコルです。メール配信の問題に関する詳細なフィードバックを提供することで、TLS-RPTはドメイン所有者が通信の完全性と機密性を維持するのに役立ちます。この包括的なガイドでは、SMTP TLS Reportingとは何か、どのように機能するのか、なぜ電子メールセキュリティ戦略に不可欠なのかを探ります。

いくつかのプロトコルは、サイバー攻撃者による電子メール通信の傍受を防ぐため、SMTPメッセージチャネルの暗号化に役立ちます。これにはSTARTTLS、DANE、MTA-STSが含まれます。しかし、これらのプロトコルを使用しているときに暗号化の試みが失敗すると、メールが配信されないことがあります。 TLS-RPT ( RFC 8460)は、このような配信の失敗を報告するフィードバックメカニズムを提供します。

TLS-RPTは、以下のものと組み合わせて使用することを強くお勧めします。 MTA-STSプロトコルと併用することを強く推奨する。これらのプロトコルがどのように連動して、電子メールのセキュリティを強化するのかを理解しよう。メールセキュリティ.

主なポイント

電子メールのセキュリティは、TLS-RPTやMTA-STSのようなプロトコルを実装することで大幅に強化することができます。
TLS-RPTは、TLS暗号化に関連するEメール配信の問題について重要なフィードバックを提供し、ドメイン所有者がEメールチャネルを効果的に監視できるようにします。
STARTTLS、DANE、MTA-STSプロトコルは、安全な電子メール通信を保証するために連携し、サイバー攻撃のリスクを低減します。
TLS-RPTレコードを設定するには、特定のサブドメインのDNS設定でTXTレコードを公開する必要があります。
TLS暗号化の失敗を認識し対処することは、メールの配信性とセキュリティを維持するために非常に重要です。

TLS-RPTとは何ですか？

TLS-RPT（Transport Layer Security Reporting）は、電子メールがTLSで暗号化されていない場合に、電子メール配信の問題を報告するための規格です。電子メール認証におけるその重要性は、電子メールのTLS暗号化を有効にする理由と密接に関係しています。

TLS暗号化により、送信されたメールはすべて安全に配信されます。接続が安全でない場合、メールが配信されないことが多々あります。TLS-RPTは、ドメイン所有者が電子メールの配信と接続障害を監視することを可能にします。レポートには以下の情報が含まれます：

MTA-STSポリシーの処理に関する問題
配達不能の理由と種類
メール送受信代行業者のIPアドレス
成功したTLS接続セッションと失敗したTLS接続セッションの合計数

これにより、メールチャネルを可視化し、配信上の課題に迅速に対処することができます。

PowerDMARC による SMTP TLS レポートの簡素化！

15日間のトライアルデモを予約する

TLSレポートの仕組み

SMTP電子メール通信では、TLS暗号化は「日和見的」である。つまり、暗号化チャネルがネゴシエートできない場合、電子メールは暗号化されていない（プレーンテキスト）フォーマットで送信される。実際、40年近く前、SMTP電子メールプロトコルはTLS暗号化をサポートしていなかった。後にSTARTTLSコマンドという形で後付けしなければならなかったのだ。

STARTTLSコマンドは、SMTP通信で双方がTLS暗号化をサポートしている場合にのみ発行される。そうでない場合、メールはプレーンテキストのまま送信される。

SMTP における日和見的暗号化を排除するために、MTA-STS が導入された (RFC 8461).MTA-STSプロトコルは、電子メールが配信される前に暗号化されることを保証します。メールサーバーまたはメール転送エージェント（MTA）は、受信サーバーがSTARTTLSコマンドをサポートしているかどうかを確認するために、受信サーバーとネゴシエートします。対応していれば、メールはTLSで暗号化されて配信されます。そうでない場合、配信は失敗します。

TLS-RPTの仕組みのステップ・バイ・ステップの説明

1.TLSハンドシェーク・プロセスを理解する

トランスポート・レイヤー・セキュリティ・ハンドシェイク（TLSハンドシェイク）とは、通信する2つのメール転送エージェント（MTA）間で安全な接続を確立するプロセスのことです。このプロセスには以下のステップが含まれます：

電子メール送信MTAは受信MTAに「Client Hello」メッセージを送信する。このメッセージには、TLSバージョンや暗号スイートなどの有用なパラメータが含まれている。
電子メール受信MTAはこのメッセージを受信し、「Server Hello」メッセージで応答する。これには選択されたTLSバージョンと暗号スイートが含まれる。
TLSハンドシェイクの開始後、受信側MTAは信頼できるCA（認証局）から発行されたSSL/TLS証明書を送信する。この証明書には公開鍵が含まれている。
通信する両MTAは暗号鍵を安全に交換し、TLS暗号化接続を確立する。これにより、両当事者間の安全な電子メール通信が保証される。

2.TLSハンドシェイクの失敗シナリオ

TLSハンドシェイクはさまざまな理由で失敗する可能性がある：

証明書のエラー： 期限切れの証明書や信頼できない認証局から発行された証明書は、TLSハンドシェイクの失敗につながる可能性がある。
バージョンの不一致： 送信側MTAと受信側MTAがサポートするTLSバージョン間に不一致がある場合、ハンドシェイクに失敗する可能性がある。
STARTTLSの失敗： STARTTLSコマンドが正しく実装されていないと、再びTLS暗号化に失敗する可能性がある。
MTA-STSの強制： メール受信者がMTA-STSポリシーモードを "enforce "に設定している場合、TLSハンドシェイクに失敗するとメッセージが拒否される可能性がある。

3.レポートの作成と配信

TLS暗号化の失敗が発生するたびに、送信サーバーはTLS-RPTレポートを生成し、さらなる評価とトラブルシューティングのためにドメイン所有者に送信する。

レポート内容

送信サーバー詳細:送信者のIPアドレスとドメイン名。

受信サーバー詳細:受信者のドメインとメールサーバー情報。

エラー内容:障害の種類と詳細（証明書のエラー、プロトコルの不一致など）。

失敗の時:問題が発生したタイムスタンプ

ポリシーモード：ドメインが "testing "モードか "enforce "モードか。

レポート配信

これらのTLSレポートは、ドメイン所有者のTLS-RPTDNS TXTレコードで指定された電子メールアドレスにJSON形式で送信されます。

SMTPにおける機会的暗号化の役割

SMTPは伝統的に日和見暗号化を使用する。これは、TLSを使用しようとするが、受信MTAがTLSをサポートしていない場合、非暗号化配信にフォールバックすることを意味する。

しかし、日和見暗号化には1つの大きな制限がある。このタイプの暗号化では、TLS暗号化が失敗した場合、電子メールは平文または平文（暗号化されていない形式）で送信される可能性がある。そのような暗号化されていないメッセージは傍受されやすい。

MTA-STSとTLS-RPTの連携方法

Mail Transfer Agent Strict Transport Security（MTA-STS）とTLS-RPTは、電子メール認証エコシステムにおける補完的なプロトコルです。MTA-STSは、送信MTAが配信にTLSを使用し、暗号化に失敗した場合にメールを拒否することを保証します、

TLS-RPTは、ドメイン所有者が失敗したTLSハンドシェイクを監視し、問題をトラブルシューティングすることを可能にします。TLS-RPTを併用することで、転送中のメッセージの傍受を防ぎ、メール配信の問題を最小限に抑えることができます。

DANEとTLS-RPTの関係

DNS-based Authentication of Named Entities（DANE）は、ドメイン所有者がDNSSECで検証されたTLS証明書を指定し、中間者攻撃を防ぐことを可能にするプロトコルである。TLS-RPTがTLSの失敗を監視するのに対して、DANEは信頼できる証明書だけが使用されることを保証します。そうすることで、DANEは攻撃者によるTLSダウングレード攻撃や証明書なりすまし攻撃を積極的に防ぎ、電子メール通信の完全性を維持します。

なぜSMTP TLSレポートが必要なのか？

ドメイン所有者は、MTA-STS対応ドメインから送信されたメールのTLS暗号化の失敗によるメール配信の問題について常に情報を得る必要があります。TLSレポートはこの情報を提供することで、それを可能にします。

メールセキュリティ:暗号化されていない電子メール通信のリスク（傍受、中間者攻撃など）を強調する。
コンプライアンス:TLS-RPTが、データ保護に関する規制要件を満たす上でどのように役立つかを説明する。
配信性:TLS-RPTが暗号化の問題を特定し解決することで、電子メールの配信性をどのように向上させるかを説明します。

TLS-RPTの設定手順

TLS-RPTのTXTレコードを作成し、DNSで公開することで、ドメインのTLSレポートを有効にできます。このレコードは、サブドメイン smtp.tls.yourdomain.comで公開する必要があります。

ステップ1：TLS-RPTレコードを生成する（TLS-RPTレコードジェネレーターを使用する）

あなたはサインアップPowerDMARCに無料でサインアップし、TLS-RPTレコードジェネレーターを使ってレコードを作成してください。

ステップ2：報告用メールアドレスを入力

SMTP TLS レポートを受信するメールアドレスを入力します。

ステップ3：DNSでTLSレコードを公開する

ドメインレジストラに連絡して、TLS-RPTの新しいTXTレコードを作成することができます。自分でDNSを管理している場合は、DNS設定を編集してレコードを含めます。

TLS-RPTレコードの構文と例

構文：v=TLSRPTv1; rua=mailto:[email protected]；

提供されたTLS報告記録の2つの構成要素を分解してみよう：

v=TLSRPTv1：このタグは、使用するTLS-RPTプロトコルのバージョンを指定する。この場合 「TLSRPTv1"はプロトコルの最初のバージョンを示す。
rua=mailto:[email protected]：ruaは "Reporting URI(s) for Aggregate Data "の略である。このタグは、受信者のメールサーバーが集約されたTLSレポートをどこに送るかを指定する。

レポートの受信先は複数設定できます。複数の宛先を指定する場合は、各エントリをカンマ（,）で区切ります。mailto: "を使用してこのステップのメールアドレスを指定するか、rua=フィールドに "https: "を使用してエンドポイントURLへのPOSTでレポートを送信するようにMTAに指示することができます。https:" を使用する場合は、"https:" フィールドがエンドポイント URL を定義していることを確認すること。を使用する場合、フィールドが有効な証明書を持つ HTTPS 対応ウェブサーバーへの URL を定義していることを確認してください。mailto:」と「https:」の両方を、カンマで区切って1つのレコードに使用することもできます。

例：v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com；

注意： 実際には"を" を、これらのレポートを受け取りたい実際のドメイン名に置き換えます。

TLS-RPT JSONレポートを理解する

TLS-RPT JSONレポートの構造

TLSレポートはJSON形式で送信されます。下記はJSON TLSレポートの例です：

{

"組織名"：「株式会社組織

“date-range”: {

"start-datetime"：“2020-10-22T00:00:00Z”,

"end-datetime"：“2020-10-22T23:59:59Z”

「contact-info"："[email protected]"、

"report-id"：“2020-10-22T00:00:00Z_domain.com”,

"ポリシー"：[

{

“policy”: {

"policy-type"："sts"、

"policy-string"：[

「バージョンSTSv1」、

「モード：テスト」、

「mx: mx.domain.com」、

「mx: mx2.domain.com」、

"mx：mx3.domain.com"、

"max_age：604800"

"policy-domain"："domain.com"

“summary”: {

"total-successful-session-count"：15,

"total-failure-session-count"：0

}

キー・フィールドとその意味

このJSON TLSレポートの主なフィールドの内訳は以下の通りです：

フィールド	説明
組織	TLS-RPTレコードを所有するドメイン組織。
電子メール	集計レポートを送信するEメールアドレス。
開始日	報告期間の開始日。
終了日	報告期間の終了日。
政策	報告期間中に適用されたポリシーを記述するポリシーオブジェクトの配列。
方針	適用されたポリシーに関する情報が含まれています。
ポリシータイプ	ポリシーの種類を指定する
ポリシーの文字列	ポリシーに関連するポリシー文字列を指定します。
モード	MTA-STS ポリシーモード (Enforce/Testing) を指定します。
概要	試行されたセッションの概要情報を含む。
合計成功セッション数	正常に確立されたTLSセッションの総カウント。
合計失敗セッション数	TLSセッションの失敗の総カウント。
失敗の詳細	特定の失敗についての詳細を提供するオブジェクトの配列。
理由	失敗の理由を示す文字列（例："certificate_expired"）。
カウント	特定の理由で失敗したセッション数。

TLS-RPT JSONレポートフォーマットとデータ解釈

レポートのメタデータ

{

"組織名"：「送信MTA組織

“date-range”: {

"start-datetime"：“2025-02-25T00:00:00Z”,

"end-datetime"：“2025-02-25T23:59:59Z”

"report-id"：“unique-report-id-12345”

}

JSONレポートのこのセクションには、メール送信者の組織名、開始日時、終了日時、生成されたTLSレポートの一意のIDなどの基本情報の概要が記載されています。

ポリシー詳細

“policy”: {

"policy-type"："sts"、

"policy-string"："mode: enforce; mx: mail.example.com; max_age：604800;"

}

このセクションでは、実装されているMTA-STSポリシーモードの概要を説明します。この場合はEnforceモードですが、Testingモードに設定することもできます。

故障の詳細

"failure-details"：[

{

"result-type"："証明書-期限切れ"、

"sending-mta"："smtp.example.org"、

"receiving-mta"："mail.example.com"、

"failure-reason"："期限切れ証明書のためTLSハンドシェイクに失敗"

}

]

このセクションはTLSレポートの中で最も重要な部分であり、暗号化の根拠や潜在的な配信の失敗を詳述する。この例では、期限切れの証明書が TLS ハンドシェイク失敗の原因であることを示しています。これは、TLS ハンドシェイク失敗時のエラー検出において重要な役割を果たし、安全な TLS 通信の迅速なトラブルシューティングを促進します。

TLS暗号化の失敗理由とトラブルシューティング

TLS暗号化の失敗にはいくつかの理由が考えられる。どちらか一方が暗号化をサポートしていない以外に、SMTPダウングレード攻撃のようなもっと不吉な理由がTLS接続の失敗につながることがある。しかし、ドメイン所有者は失敗した配信について知りたいと思うだろう。TLSレポート（TLS-RPT）は通知するプロトコルである。配信に失敗すると、TLS-RPTレコードで定義されたメールアドレスに、JSONファイル形式でTLSレポートが届きます。以下は、暗号化に失敗する一般的な理由とトラブルシューティングのヒントです：

1.証明書の問題

証明書_期限切れ

リモート・サーバーが提示した証明書は有効期限を過ぎている。このため、暗号化には信頼できません。この場合、証明書を更新する必要があります。

まだ有効でない証明書

リモート・サーバーが提示した証明書がまだ有効でない。これは、サーバーの時刻が正しくないか、証明書の使用時期が早まっている可能性があります。この場合、証明書プロバイダーに問い合わせるのが最善です。

証明書失効

リモートサーバーが提示した証明書が、セキュリティ上の懸念から認証局によって失効された。この場合、証明書プロバイダーに連絡するのが最善です。

no_valid_signature

リモート・サーバーが提示した証明書チェーンが、送信者のメール・サーバーまたはクライアントによって信頼されておらず、潜在的なセキュリティ・リスクがあることを示しています。この場合、証明書プロバイダーに連絡するのが最善です。

未対応証明書

リモートサーバーから提示された証明書が、送信者のメールサーバーでサポートされていない暗号化アルゴリズムまたは鍵長を使用しており、安全な接続を妨げている。この場合、証明書のプロバイダーに連絡するのが最善です。

2.ホスト名とIDの不一致

ホスト名不一致

サーバーの証明書で指定されたホスト名が、送信者のメールサーバーが接続しようとしているサーバーのホスト名と一致しない。これは中間者攻撃の可能性または設定の問題を示しています。

MTA-STSポリシーファイルのMXレコードをチェックして、ドメインのMXレコードと一致していることを確認できます。

3.ハンドシェークとプロトコルの問題

握手失敗

送信者のメールサーバーと受信者のメールサーバー間の最初のTLSハンドシェイク処理中に問題が発生し、セキュアチャネルが確立されませんでした。SMTP STARTTLS接続が確立されているか再確認してください。STARTTLSのサポート不足、またはTLSダウングレード攻撃など、暗号化の失敗にはいくつかの理由が考えられます。

4.MTA-STSの政策課題

MTA_STS_POLICY_NOT_FOUND

この障害は、送信者のメールサーバーが受信者のドメインのMTA-STSポリシーを見つけられない場合に発生します。MTA-STSポリシーファイルを見直してください。MTA-STSレコードが正しく発行されているか確認してください。

MTA_STS_POLICY_INVALID

このエラーは、受信者のドメインのDNSで見つかったMTA-STSポリシーが無効であるか、エラーが含まれているか、MTA-STS仕様に準拠していない場合に発生します。MTA-STSポリシーファイルを確認してください。適切なMTA-STSポリシーモードを指定します。None、Enforce、またはTestingのいずれかを指定します。これは、MTA-STSポリシーの検証に失敗したメールをどのように処理するかを送信サーバーに指示します。

MTA_STS_POLICY_FETCH_ERROR

この障害は、送信者のメールサーバーが受信者のドメインのDNSレコードからMTA-STSポリシーを取得しようとしてエラーが発生した場合に発生します。DNSのMTA-STSレコードを検証し、レコード構文が正しいことを確認する必要があります。

MTA_STS_CONNECTION_FILURE

この失敗は、送信者のメールサーバーがMTA-STSを使用して安全な接続を確立しようとしたが、信頼されていない証明書、サポートされていない暗号スイート、またはその他のTLSの問題などの理由で失敗した場合に発生します。証明書の有効性を確認し、証明書が最新のTLS標準であることを確認する必要があります。

mta_sts_invalid_hostname

この障害は、MTA-STSポリシーで指定された受信者のメールサーバーのホスト名が、サーバーの実際のホスト名と一致しない場合に発生します。MTA-STSポリシーファイルのMXレコードをチェックして、ドメインのMXレコードと一致していることを確認する必要があります。

TLS-RPT実装のベストプラクティス

TLSレポートを定期的に監視する

TLSレポートは定期的に監視し、未配信メッセージを見逃さないようにする必要があります。そのためには、メールボックスのJSONレポートを手動で監視するか、次のようなレポート・アナライザー・ツールを使用します。 PowerTLS-RPT.

MTA-STSポリシーが適切に設定されていることを確認する

TLS-RPTを正しく実装するには、MTA-STSポリシーが正しく設定され、構文エラーがない必要があります。私たちの MTA-STSチェッカーを使用してレコードをチェックできます。

暗号化の失敗に迅速に対処する

TLSレポートで暗号化の失敗を検出したら、今後のメール配信の問題を防ぐために迅速に対応することが重要です。

安全なTLSプロトコルバージョンを使用する

サポートされている最新バージョンのTLSプロトコルのみを使用することは、望ましくない暗号化の失敗を避けるために不可欠です。

PowerDMARCによるSMTP TLSレポートの簡素化

PowerDMARCのSMTP TLSレポート体験は、ホストされたサービスであなたの生活を容易にしながら、セキュリティを向上させることにある。

翻訳されたTLSレポート

複雑なTLS-RPT JSONレポートは、数秒でざっと目を通すことも、詳しく読むこともできるシンプルな情報に変換されます。

オートディテクト問題

PowerDMARCプラットフォームは、あなたが直面している問題をピンポイントで浮き彫りにするので、時間を無駄にすることなく問題を解決することができます。

PowerDMARCプラットフォームについて好きなところは一つもない。使いやすく理解しやすいレイアウトで、ホストされたDMARCコントロールを可能にするフル機能と呼べるものを持っている、 SPFフラット化SPFを簡単に拡張してレコードの詳細を検査したり、MTA-STSやTLS-RPTを完全にサポートすることもできます！

ディラン・B（ビジネスオーナー）

トランスポート層のセキュリティに関するよくある質問

TLSとは何の略ですか？

TLSとは、Transport Layer Securityの略で、日本語では「トランスポート・レイヤー・セキュリティ」と訳されます。

誰がTLS証明書を発行するのか？

認証局（CA）はTLS証明書を発行できる。証明書の発行プロセスには、証明書所有者の身元確認が含まれる。本人確認に成功すると、証明書が発行される。

なぜTLS証明書が必要なのですか？

TLS証明書は、インターネット上の通信を保護する上で極めて重要な役割を果たしている。TLS証明書は機密情報通信するウェブ・サーバー間で交換される機密情報を暗号化する。TLS証明書の最も一般的な使用例としては、電子メール通信の保護やHTTPSなどがあります。

現在のTLS標準は何ですか？

TLS 1.3はトランスポート・レイヤー・セキュリティの最新バージョンである。TLS-RPTはどのバージョンのTLSでも実装できる。これには、プロトコルの古いバージョンや将来のバージョンも含まれる。バージョンは通常、通信するサーバーの能力などの基準によって決定される。

ユネス・タラダ

ドメインとメールセキュリティのエキスパートPowerDMARC

ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。

最新記事 by Yunes Tarada(全て見る)

compauth=fail：Microsoft 複合認証の解説 - 2026年6月1日
Windows Defenderだけで中小企業のセキュリティは十分か？ - 2026年5月14日
DMARCbisの解説 – 変更点と準備方法 - 2026年4月16日

SMTP TLS Reporting（TLS-RPT）とは何ですか？