MTA-STSとは？STARTTLSだけでは不十分な理由と安全なメール送信の方法を解説

更新日：2025年2月14日メール配信

近年メールのセキュリティに関する問題がますます深刻化しています。特にSMTP（Simple Mail Transfer Protocol）によるメール送信はデフォルトでは暗号化が必須ではなく、送信途中で盗聴や改ざんのリスクがあるため安全な通信を確保することが重要になっています。その中でSMTPの暗号化を強制するための技術として「MTA-STS（Message Transfer Agent Strict Transport Security）」が注目されています。

従来SMTPの暗号化にはSTARTTLSが利用されてきましたが、この仕組みにはいくつかの弱点があります。例えば、STARTTLSは「オポチュニスティック（機会ベース）」な暗号化であり、サーバーが対応していない場合は平文で通信してしまうリスクがあります。また、中間者攻撃（MITM攻撃）によってTLSの使用が妨害されることもあり安全性に課題が残る仕組みでした。

MTA-STSはこうしたSTARTTLSの弱点を補完するために設計されました。この技術を導入することで送信者のメールサーバーは事前に受信者のサーバーのTLS対応状況を確認し、安全な通信が可能な場合のみメールを送信するようになります。さらに、DNSレコードとHTTPS経由のポリシーファイルを活用しポリシーの改ざんや偽装を防ぐ仕組みも備えています。

本記事ではMTA-STSの基本的な仕組みから設定方法、ポリシーファイルの具体的な内容、さらにはMTA-STSでも対応できないリスクについても詳しく解説していきます。

MTA-STSとは

MTA-STSはSMTP通信のセキュリティを向上させるために設計されたプロトコルです。SMTP通信においてTLSを強制しメールの送信者と受信者が確実に暗号化された接続を利用するようにします。

SMTPの問題点

SMTP（Simple Mail Transfer Protocol）は電子メールを送受信する標準的なプロトコルですが、いくつかのセキュリティ上の問題を抱えています。

通信の暗号化が必須ではない（STARTTLSは推奨されるが強制ではない）
中間者攻撃によってTLSがダウングレードされる可能性がある
偽の証明書を用いた攻撃が行われる可能性がある

MTA-STSはこれらの問題を解決するために導入されました。具体的には受信サーバー側がTLSを強制し、ポリシーファイルを通じて送信サーバーに対してセキュアな通信を求めることができます。

MTA-STSの設定方法

MTA-STSを導入するには以下の3つのステップが必要です。

前提条件の確認
DNSの設定
ポリシーの作成と公開

前提条件

MTA-STSを設定する前に以下の環境が整っていることを確認してください。

登録済みドメイン
HTTPS対応のWebサーバー（MTA-STSポリシーファイルを公開するため）
有効なTLS証明書
TLS 1.2以上の対応
MTA-STSに対応したメールサーバー
DNS TXTレコードの設定が可能な環境

また、ポリシーファイルで指定する mx（受信サーバーのホスト名）は実際に運用しているメールサーバーと一致する必要があります。

DNSの設定

DNSの設定ではMTA-STSポリシーを有効化するためのTXTレコードを追加します。例としてドメインが example.jp の場合、以下のTXTレコードを追加します。

_mta-sts.example.jp. IN TXT "v=STSv1; id=2024021401"

v=STSv1 は固定値
id はポリシーが更新されるたびに変更する

この設定により、送信サーバーはこのポリシーの更新状況を監視し新しいポリシーを適用します。

ポリシーの設定

MTA-STSのポリシーはDNSではなくWeb上に配置します。具体的には https://mta-sts.example.jp/.well-known/mta-sts.txt のような場所にポリシーファイルを設置します。

ポリシーファイルの基本構造は以下のとおりです。

version: STSv1
mode: enforce
max_age: 604800
mx: mail.example.jp

version：固定値 STSv1
mode：
- none：ポリシーを適用しない（テスト用）
- testing：TLSレポートを収集しつつ、強制はしない
- enforce：TLSを強制し、暗号化されていないメールを拒否
max_age：ポリシーのキャッシュ期間（単位：秒）
mx：許可する受信サーバー

このポリシーファイルをWebサーバーに設置しHTTPS経由でアクセスできるように設定する必要があります。

STARTTLSだけでは不十分な理由

STARTTLSは暗号化されていない通信をSSLやTLSを利用して暗号化する技術です。1999年にSMTPに実装されたことで電子メールの送信が暗号化され、SMTPのセキュリティを補強する役割を果たしてきました。

しかし、STARTTLSにはいくつかの弱点があり暗号化の強制力がないため、攻撃者による介入のリスクがあります。そのため、これを補完しより強力なセキュリティを提供する仕組みとしてMTA-STSが登場しました。

ただし、MTA-STSを導入してもSTARTTLSの問題点を理解していないと適切に運用できません。ここでは、なぜSTARTTLSだけでは不十分なのかを詳しく解説します。

STARTTLSがOpportunistic（機会ベース）であるため

「Opportunistic（オポチュニスティック）」という言葉には「便宜主義的な」や「状況に応じて変わる」という意味があります。つまり、STARTTLSは「利用できるときだけ暗号化する」という仕組みになっており暗号化が必ずしも保証されるわけではありません。STARTTLSの動作の流れは以下の通り。

メール送信を開始（この時点では暗号化なし）
送信先のサーバーがSTARTTLSをサポートしているか確認
対応していれば暗号化（TLS）を開始
対応していなければ平文のまま送信

このようにSTARTTLSは送信側と受信側両方が対応している場合にのみ有効となります。もし受信側のサーバーがSTARTTLSをサポートしていなければメールは暗号化されず、そのまま平文で送信されてしまいます。

MTA-STSを設定することで送信サーバーは「このドメインではTLSを必須にする」というポリシーを確認できるため、対応していない場合はメールを送信しないという動作が可能になります。これにより、意図しない平文送信を防ぐことができます。

中間者攻撃に弱いため

「中間者攻撃（MITM: Man-In-The-Middle Attack）」とはユーザーと通信相手の間に攻撃者が割り込み、通信内容を盗み見たり改ざんしたりする攻撃のことです。

STARTTLSには通信の最初の部分が暗号化されていないという欠点があります。そのため、攻撃者が途中で介入しSTARTTLSを無効化して最初から最後まで平文のまま送信させることが可能です。これを「SMTPストリップダウングレード攻撃」と呼びます。

MTA-STSでは受信サーバーがTLSを強制しなければならないため攻撃者がSTARTTLSのコマンドを削除しても、送信サーバーは「TLSがないなら送信しない」という動作を取ることができます。これにより、中間者攻撃のリスクを大幅に低減できます。

偽の証明書でも通信してしまう可能性があるため

メールの暗号化にはTLS証明書を利用します。しかし、STARTTLSだけでは証明書の検証が厳密でないため、偽の証明書を使っても通信が成立してしまう可能性があります。STARTTLSの証明書検証が不十分な理由は以下の通り。

証明書が有効期限切れでも通信が続行されるケースがある
ルート証明書とトラストチェーンの整合性が確認されないことがある
ホスト名が一致していなくても通信が成立することがある

このような問題があると攻撃者が偽の証明書を使って通信を盗聴することが可能になってしまいます。

MTA-STSではTLS証明書が適切に検証される仕組みが整っています。具体的には、以下のようなポイントをチェックします。

証明書が有効期限内であるか
ホスト名と一致しているか
ルート証明書とトラストチェーンが適切に連携しているか

これにより信頼できるサーバーとのみ安全な通信を確立できるようになります。

MTA-STSポリシーファイルとは

MTA-STSポリシーファイルはメールサーバー間のTLS暗号化を強制するためのルールを定めたファイルです。SMTP通信ではTLSが使われていない、あるいは中間者攻撃によって暗号化が回避されるリスクがありますが、MTA-STSを導入することで安全な接続を確保できます。

このポリシーファイルはHTTPS経由で取得され、受信サーバーのリストと証明書を元に認証されます。送信側のメールサーバーはこのポリシーファイルを参照し、TLSを強制するかどうかの判断を行います。

MTA-STSポリシーファイルの構造

MTA-STSポリシーファイルには以下のようなフィールドが含まれます。

version
MTA-STSのバージョン。現在の仕様では STSv1 に固定。
mode
ポリシーの動作モードを指定。「none」「testing」「enforce」の3種類がある。
mx
ドメインの有効なMX（メール交換）サーバーのリストを指定。
max_age
ポリシーのキャッシュ期間（秒単位）。この期間中は新しいポリシーを取得せず、キャッシュされたポリシーを適用する。

MTA-STSポリシーの例

MTA-STSポリシーファイルは以下のような形式で記述されます。

version: STSv1
mode: enforce
max_age: 86400
mx: mail.example.com

設定はケースによって異なりますが基本的なフォーマットは下記のようになります。

mode: enforce を指定すると、TLS暗号化が必須となり、暗号化されていないメールは拒否される。
max_age: 86400 は、ポリシーを1日（86400秒）キャッシュすることを意味する。
mx: mail.example.com は、指定されたメールサーバーを受信サーバーとして許可する。

MTA-STSでも守れないケース

MTA-STSを導入しても以下のようなケースでは完全に保護できない可能性があります。

DNSキャッシュポイズニング
攻撃者がDNSのキャッシュを改ざんし、送信サーバーが誤ったMTA-STSレコードを参照する可能性がある。
不正なCAによる証明書の発行
正規の認証局（CA）でない第三者が不正に証明書を発行した場合、攻撃者が暗号化された通信を解読できてしまう恐れがある。
ポリシーのキャッシュ期間の影響
max_age の期間中は新しいポリシーが適用されないため、古い設定のままになってしまうリスクがある。

これらのリスクを軽減するため以下のような対策を講じるのが望ましいです。

max_age の値を適切に設定し、頻繁にポリシーを更新する
DANE（DNS-based Authentication of Named Entities） を導入し、DNS経由で証明書の真正性を検証する

MTA-STSの導入が推奨されるケース

MTA-STSはすべてのメール環境で必須というわけではありませんが特にセキュリティが求められる環境では導入が推奨されます。ここでは、MTA-STSの導入が有効なケースについて解説します。

企業メールのセキュリティ強化

企業が運用するメールシステムでは機密情報を含むメールを送信することが多いため、セキュリティの強化が求められます。特に以下のような企業ではMTA-STSの導入が効果的です。

金融機関や医療機関など、高いセキュリティ基準を求められる企業
顧客情報や機密データを扱う企業
フィッシングやなりすまし攻撃のリスクを減らしたい企業

MTA-STSを導入することで送信メールがTLSによって確実に暗号化され、第三者による盗聴や改ざんのリスクを軽減できます。

大量のメールを送信するサービス

ECサイトやSaaSサービスなど大量のメールを送信するビジネスでは、メールの安全性と到達率が重要です。特に以下のようなサービスではMTA-STSの導入が推奨されます。

ECサイトの購入確認メール
会員制サービスのパスワードリセットメール
SaaSやWebアプリの通知メール

MTA-STSを導入することでメールの到達率が向上し、スパムフィルタによる誤判定を防ぐことができます。

MTA-STS導入時の注意点

MTA-STSを導入することでメールのセキュリティは向上しますが、導入にあたってはいくつかの注意点もあります。設定ミスが発生するとメールが正しく送信されない可能性があるため、慎重に導入する必要があります。

DNSレコードとHTTPSの設定ミス

MTA-STSはDNSレコードとHTTPS経由で配信されるポリシーファイルを利用します。設定ミスがあると送信サーバーがポリシーを適用できず、メールが送信できなくなる可能性があります。特に注意すべきポイントは以下の通りです。

_mta-sts.example.com のDNS TXTレコードが正しく設定されているか確認する
https://mta-sts.example.com/.well-known/mta-sts.txt にポリシーファイルが配置されているか確認する
ポリシーファイルがHTTPSで正しく提供されているか（有効なTLS証明書が必要）

これらの設定が正しく行われているか事前にテスト環境で検証することが重要です。

ポリシーモードの選択

MTA-STSには、none、testing、enforce の3つのモードがあります。最初から enforce モードを適用すると、誤設定があった場合にメールが届かなくなるリスクがあるため、導入時は testing モードから始めるのが推奨されます。推奨される導入手順は以下の通りです。

none モードで運用し、影響を確認
testing モードを適用し、TLS-RPTを利用してエラーレポートを収集
問題がないことを確認した後、enforce モードに切り替える

このように段階的に適用することでメール送信のトラブルを防ぎながら安全な運用が可能になります。

MTA-STSとTLS-RPTの関係

MTA-STSを適切に運用するためにはTLS-RPT（TLS Reporting）と併用することが推奨されます。TLS-RPTはMTA-STSのポリシー適用状況を監視し、暗号化通信に関する問題を可視化する仕組みです。MTA-STS単体ではSMTP通信が暗号化されているかどうかを制御できますが、ポリシーの適用状況やエラーの発生原因を把握するためにはTLS-RPTが不可欠です。

TLS-RPTを設定することで送信メールサーバーの管理者は、暗号化に失敗した場合の詳細なレポートを受け取り、問題の特定と改善が可能になります。以下ではTLS-RPTの基本的な仕組みや設定方法について詳しく解説します。

TLS-RPTとは？

TLS-RPT（Transport Layer Security Reporting）はメールのTLS暗号化に関する問題をレポートとして受け取るための仕組みです。送信者側のサーバーがMTA-STSポリシーに従ってTLS接続を試みた際にエラーが発生すると、その詳細が受信者側の管理者に通知されます。TLS-RPTの主な役割は以下の通りです。

TLS暗号化が正しく適用されているかの監視
暗号化に失敗した場合の詳細レポートの取得
MTA-STSの設定ミスや証明書エラーの早期発見

この仕組みによりメール通信のセキュリティを向上させるとともに、問題が発生した際の迅速な対応が可能になります。

TLS-RPTの設定方法

TLS-RPTを設定するにはDNSにTLS-RPT専用のTXTレコードを追加します。

例として、example.com のドメインでTLS-RPTを設定する場合、以下のようなDNSレコードを追加します。

_tlsrpt.example.com. IN TXT "v=TLSRPTv1; rua=mailto:report@example.com"

v=TLSRPTv1 はバージョン指定（固定）
rua はレポート送信先のメールアドレス

この設定により送信サーバーはTLSに関する問題が発生した際に、指定されたメールアドレスにレポートを送信するようになります。レポートを分析することでTLS設定の問題を特定し、改善に役立てることができます。

まとめ

MTA-STSはSMTP通信の暗号化を確実にするための重要な仕組みです。従来のSTARTTLSでは暗号化が保証されないケースがありましたがMTA-STSを導入することで、TLSを強制し、安全なメール送信を実現できます。MTA-STSを適切に設定することで以下のようなメリットが得られます。

メール送信時の暗号化を確実にし、盗聴や改ざんのリスクを軽減できる
中間者攻撃（MITM攻撃）によるTLSのダウングレードを防ぐ
DNSとHTTPSを活用したポリシー設定により、セキュリティポリシーの改ざんを防止できる

ただし、MTA-STSにも限界がありDNSキャッシュポイズニングや不正なCAによる証明書発行などのリスクには対応できません。そのため、DANE（DNS-based Authentication of Named Entities）などの追加対策を組み合わせることで、より強固なメールセキュリティを確保することが推奨されます。

メールのセキュリティ対策は年々進化していますがMTA-STSのような仕組みを導入することで、より安全なメール送信環境を構築できます。今後メールの安全性を向上させるために、ぜひMTA-STSの設定を検討してみてください。

Blog一覧