MTA-STSとTLS-RPT：メールを通信中に暗号化する

SPF、DKIM、DMARCは、メールを誰が送ったかを証明します。MTA-STSとTLS-RPTが守るのは、メールが配送されている最中の通信です。メールを運ぶ接続が本当に暗号化されていることを保証し、そうでない場合は通知してくれます。MTA-STS（SMTP MTA Strict Transport Security、RFC 8461で定義）を使うと、ドメインは、自社のサーバー宛てのメールをTLSと有効な証明書で届けるよう宣言できます。TLS-RPT（SMTP TLS Reporting、RFC 8460）は、その暗号化が成功したか失敗したかを、送信側サーバーに毎日レポートしてもらう仕組みです。どちらもメールの内容を認証するものではありません。ただし2つを組み合わせると、日和見TLSでは無防備なままになる別の穴をふさげます。ここでは、それぞれの役割と、受信メールを止めずに導入する手順を解説します。

結論#

MTA-STSは、他社のメールサーバーが自社宛てのメールを暗号化して送るよう求めるために公開するポリシーです。構成要素は2つあります。1つは、ポリシーの存在を知らせる_mta-sts.yourdomain.comのDNS TXTレコード。もう1つは、https://mta-sts.yourdomain.com/.well-known/mta-sts.txtにHTTPSで置くポリシーファイルで、MXホスト名、モード（none、testing、enforce）、キャッシュ期間を記載します。TLS-RPTは、_smtp._tls.yourdomain.comに置く2つ目のTXTレコードで、TLS接続の結果を毎日受け取るアドレスを指定します。安全な導入手順はDMARCと同じです。まずtestingモードで公開し、すべての接続でTLSが問題なく確立されると確信できるまでTLS-RPTのレポートを確認してから、enforceに切り替えます。ドメイン診断の監視は、毎日のチェックの一部として、SPF、DKIM、DMARC、BIMIと並べて、_mta-stsのTXTレコードが公開されているかどうかを表示します。HTTPSのポリシーファイルの取得やTLS-RPTレポートの読み取りは行わないため、それらはご自身で引き続きテストしてください。

MTA-STSがふさぐ穴#

現在のSMTPは、STARTTLSによって大半のメールを通信中に暗号化しています。送信側サーバーが「TLSに対応していますか」と尋ね、受信側が「はい」と答えると、両者は暗号化チャネルを確立します。ところが、このハンドシェイクは日和見で、認証がありません。どちらかがTLSを提示しなければ、メールは失敗せずに平文へフォールバックします。さらに、2台のサーバーの間にいる攻撃者は、やり取りからSTARTTLSの提示を取り除けます。これがダウングレード攻撃です。TLSが提示されていないと判断した送信側サーバーは、何も言わずにメールを平文で配送してしまいます。証明書も検証されないため、中間者は自前の証明書を提示して接続を傍受できます。

MTA-STSは、この2つの弱点を両方とも解消します。ポリシーを公開すると、対応する送信者に次のことを伝えられます。このドメイン宛てのメールは必ずTLSで送ること。受信サーバーは、有効で、記載したMXホスト名のいずれかに一致する証明書を必ず提示すること。この条件を満たせない場合は配送せず、平文にフォールバックせずに保留して再試行すること。ポリシーはHTTPS経由で取得されるため、そのポリシー自身の証明書が信頼の起点となり、攻撃者による偽造や除去を防げます。その結果、受動的な盗聴者も、能動的なダウングレード攻撃者も、自社の受信メールを強制的に平文で送らせることはできなくなります。

TLS-RPTでできること#

MTA-STSだけでは、可視性のないままポリシーを適用することになります。送信者に安全でない接続を拒否するよう求めても、それがどのくらいの頻度で起きているのか、どの送信者が失敗しているのかは確認できません。そのフィードバックの経路がTLS-RPTです。DMARCの集計レポートとまったく同じ仕組みで動くため、DMARCレポートを読む習慣とも相性がよいでしょう。

TLS-RPTレコードを公開すると、対応する送信者から、MXホストに対して開いたすべてのTLSセッションをまとめたJSONレポートが毎日届きます。成功した件数、失敗した件数、そして重要な点として、失敗した理由が分かります。たとえば、MXサーバーの証明書の期限切れ、ホスト名の不一致、中断されたSTARTTLSのネゴシエーション、ポリシー取得の問題などです。enforceモードでの失敗は、受信メールの保留やバウンスを意味します。そのため、MTA-STSをenforceにする前に、まさにこの情報が必要になります。TLS-RPTがあるからこそ、導入は賭けではなく、安全な手順になります。

MTA-STSの設定：DNSレコードとポリシーファイル#

MTA-STSには、DNSレコード、ポリシーファイル、そのファイルをHTTPSで配信するためのサブドメインの3つが必要です。

1. DNS TXTレコード。 _mta-sts.yourdomain.comにTXTレコードを公開します。役割は小さく、ポリシーが存在することを知らせ、ポリシーの変更を送信者が検知するためのidを載せるだけです。

_mta-sts.example.com.  TXT  "v=STSv1; id=20260725090000"

idは、英数字で最大32文字の任意の文字列です。タイムスタンプを使うのが一般的です。守るべきルールは1つで、ポリシーファイルを編集するたびにidを変更することです。送信者はポリシーをキャッシュしており、新しいidが再取得の合図になります。変更し忘れると、max_ageの期間が終わるまで、変更が反映されないことがあります。

2. ポリシーファイル。 プレーンテキストのファイルを、固定のパスhttps://mta-sts.yourdomain.com/.well-known/mta-sts.txtに置きます。モード、有効なすべてのMXホスト名、キャッシュ期間を記載します。

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.com
max_age: 86400

各mx行は、ドメインのMXレコードにあるホスト名と一致している必要があります。ワイルドカード形式（*.example.com）は、最も左側の1ラベルに一致します。記載するMXホストはすべて、現在有効で、公的なCAにチェーンしており、ホスト名に一致する証明書を提示しなければなりません。そうでなければ、enforceモードの送信者はそのホストを拒否します。max_ageはキャッシュの有効期間（秒）で、RFC 8461では31557600（約1年）までの値が認められています。テスト中は変更をすばやく反映させるため、1日程度の短い値にしておきます。enforceに自信が持てたら値を長くしてください。Googleなどの受信側は本番環境で長いmax_ageを推奨していますが、実際の値は自由に決められます。

3. HTTPSで配信するmta-stsサブドメイン。 ポリシーファイルは、mta-stsサブドメインでHTTPS経由で取得できる必要があり、mta-sts.yourdomain.comに有効な証明書が必要です。実際には、このサブドメインを（A/AAAAレコードまたはCNAMEで）ファイルを配信するもの、たとえば小さな静的ホストやCDNに向け、Content-Type: text/plainで応答させます。最近は、ファイルと証明書を代わりに管理してくれるMTA-STSのマネージドオプションを提供するDNSサービスやホスティングサービスも多くあります。

TLS-RPTの設定#

TLS-RPTは2つのうちでずっと簡単で、TXTレコードが1つだけです。ポリシーファイルは必要ありません。

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

ruaタグは、レポートの送信先を指定します。mailto:アドレス、POSTでレポートを受け取るhttps:エンドポイント、またはその両方をカンマで区切ったリストを指定できます。生のTLS-RPTのJSONは読みにくいため、多くのチームはruaを監視サービスに向け、レポートを読みやすいダッシュボードに変換させています。DMARCレポートが、通常は担当者の受信トレイではなくパーサーに送られるのと同じです。TLS-RPTは単独でも公開でき、MTA-STSの前に公開しておく価値があります。メールフローにリスクを与えずに、現在のTLSの状態を把握できるからです。

MTA-STSとTLS-RPTを安全に導入する手順#

MTA-STSとTLS-RPTでは、レコードそのものよりも作業の順序が重要です。順序を誤ると、自社の受信メールを保留させかねません。優れたDMARCの導入と同じように、まず監視し、そのあとで適用するという方針で進めてください。

1. 最初にTLS-RPTを公開する。 MTA-STSのポリシーがまだない段階では、レポートから、受信メールのうちどのくらいがすでにTLSを使っているか、MXの証明書に設定ミスがないかが分かります。明らかな問題はここで修正します。

2. testingモードでMTA-STSを公開する。 DNSレコードと、mode: testingのポリシーファイルを追加します。このモードでは、送信者はポリシーを評価して失敗をTLS-RPTで報告しますが、メールは通常どおり配送します。メールフローは何も変わらず、データを集めるだけです。普段やり取りのある相手を一通りカバーできる期間、できれば2週間ほど、この状態にしておきます。

3. TLS-RPTのレポートを読み、失敗を修正する。 証明書の問題、ホスト名の不一致、記載し忘れたMXホストに注意してください。testingモードでの失敗はすべて、enforceモードでは自分で引き起こす失敗になります。レポートが問題なくなるまで、証明書とポリシーファイルの改善を繰り返します。

4. mode: enforceに切り替える。 失敗が出なくなったら、ポリシーファイルをenforceに編集し、送信者が再取得するようにDNSレコードのidを変更します。この時点から、対応する送信者は、認証されていない接続やダウングレードされた接続では配送しなくなります。ダウングレードの試みに対する保護を強めるため、ここでmax_ageを長くすることも検討してください。

SPF、DKIM、DMARCとの位置づけ#

MTA-STSとTLS-RPTができることとできないことは、正確に押さえておく必要があります。「到達率」の対策に分類して、誤った効果を期待しがちだからです。

SPF、DKIM、DMARCが答えるのは、「このメールは、名乗っているとおりの送信者から届いたものか」という問いです。送信者とメールの内容を認証します。MTA-STSとTLS-RPTが答えるのは別の問いで、「このメールを運んだ接続は、実際に暗号化され、検証されていたか」です。こちらは、通信中の機密性を守ります。この2つの層は補完的で、互いに独立しています。メールが平文で運ばれてもDMARCに成功することはありますし、強制されたTLSで運ばれてもDMARCに失敗することはあります。完全な設定には、両方が必要です。

注意点が2つあります。1つ目に、MTA-STSとTLS-RPTは、2024年に施行された、GoogleとYahooの大量送信者向けの送信者ガイドラインには含まれていません。そこで義務付けられているのは、SPF、DKIM、DMARC、ワンクリック配信停止、低い迷惑メール率であり、通信経路のセキュリティポリシーではありません。ただし、主要なプロバイダーは受信側としてMTA-STSを公開し、尊重しています。公開したポリシーは、Gmailなどがそのドメイン宛てに配送する際に実際に適用されます。2つ目に、MTA-STSは迷惑メールフォルダー対策ではありません。強化されるのは受信の通信セキュリティで、それだけでは送信するマーケティングメールの届き先は改善しません。受信トレイへの配置は、今も送信者レピュテーション、エンゲージメント、リストの衛生状態で決まります。メールが迷惑メールに振り分けられている場合は、その原因はこれらのシグナルにあり、TLSの設定にはありません。MTA-STSとTLS-RPTは、成熟した送信ドメインに必要な通信経路のセキュリティの一章として位置づけてください。実施する価値はありますが、受信トレイへの配置を実際に左右する、メール到達率ガイドの施策とは別物です。

たとえるなら、MTA-STSはDANEの近い親戚です。DANEは、DNSSECを使ってSMTPのTLSを強制する、より古い方式です。どちらも同じダウングレードの問題の解決を目指していますが、MTA-STSは、DNSSECのないドメインでも保護の大部分を得られるよう、Webの証明書の仕組みを使って設計されました。すでにDANEを運用しているなら、MTA-STSは不要かもしれませんが、両者は共存できます。

MTA-STSとTLS-RPTは、メールが通る経路を強化しますが、受信トレイへの到達はリストの品質で決まります。無料メールチェッカーなら、存在しないドメインや入力ミスをバウンスする前に見つけられます。また、無料プランでも、リストに対して検証の全工程を実行できます。安全で、きちんと認証されたドメインも、背後のリストがクリーンでなければ、受信トレイには届かないからです。