MTA-STS

メール受信時のTLSの強制化でメール配送経路上の暗号化を完成させる

更新日 2026年1月15日

MTA-STSエムティーエーエスティ―エス(SMTP MTA Strict Transport Security)は、メールサービスプロバイダがTLS（Transport Layer Security）を使用した安全なSMTP接続のサポートを宣言する仕組みです。
この機能により、受信側のSMTPサーバは、信頼できるサーバ証明書を持つTLS接続を提供しないMXホストへのメール配信を拒否することができます。
結果として、SMTPによるメール配送経路の暗号化が保証され、メールのセキュリティが向上します。

MTA-STSの仕様は、2018年に公開されたRFC8461に記載されています。

従来のSTARTTLSの問題点

要点：従来のSTARTTLSは、攻撃者による「250 STARTTLS」応答の削除やMXレコードの改ざんにより、暗号化をバイパス（ダウングレード攻撃）される脆弱性がありました。S/MIMEやPPAPは代替策として使用されますが、それぞれ運用上の課題があります。

メールの通信経路の暗号化は、企業にとって長い間課題でありました。
送信にSTARTTLS(SMTP over TLS)を、受信にPOP/IMAP over TLSを用いることで暗号化は可能です。

しかし、STARTTLSの通信配信経路上での暗号化は、

• SMTPセッションの一部を削除できる攻撃者（「250 STARTTLS」応答など）
• SMTP全体をリダイレクトできる攻撃者（配信ドメインの解決されたMXレコードを上書き）

が、ダウングレードまたはインターセプト攻撃を実行できるという問題がありました。

そこで、この問題を解決するために、国内では、主に以下の2つの手法が使用されています。

S/MIME

S/MIMEは、メールの内容と添付ファイルを公開鍵暗号方式で暗号化およびデジタル署名する標準規格です。
この手法を採用する場合、組織内認証局（CA: Certificate Authority）または公的な認証局（パブリックCA）から、各ユーザに鍵ペアと証明書を発行し、インストールする必要があります。
エンドツーエンドの暗号化を実現する一方で、マルウェアも暗号化される可能性があり、これが一定のリスクとなります。

PPAP

PPAPは、特に添付ファイルを暗号化する目的で使用されます。この手法では、添付ファイルをパスワード付きのZIPファイルにして送信し、その後でパスワードを別途送ります。
しかし、このアプローチには以下のような欠点があります。

1. もし添付ファイルが含まれるメールを不正アクセスできるのであれば、パスワードが記載されたメールも同様にリスクがあります。
2. パスワード付きのZIPファイルは、アンチウィルスソフトによるスキャンが困難であり、添付ファイルがマルウェアに感染している可能性が未検出のまま残ります。

総じて、これらの手法にはそれぞれ長所と短所があり、堅牢なセキュリティ対策を整えるためには多角的なアプローチが必要です。

MTA-STSの仕組み

要点：MTA-STSは、(1) HTTPSでのポリシーファイル検証、(2) MXレコードとポリシー内MXホストのマッチング検証、(3) 受信MTAの証明書検証、(4) ポリシーに基づく送信制御、(5) 結果のレポーティング、という5つの機能でSTARTTLSを強化します。

MTA-STSは、STARTTLSを強化するための仕様です。
以下の機能が提供されます。

• 受信側のDNSでの名前解決とは別に、HTTPSでのポリシーファイルの検証を行う
• 受信側ドメインのDNSのMXレコードと、ポリシーファイルに記載されているMXホストをマッチング検証する
• 受信側MTAの証明書について、有効期限が切れていないか、信頼されているルートCAにチェーンされているかを検証する
• 受信側が指定したポリシーに従う
• 結果をレポーティングする

MTA-STSのプロセス

要点：MTA-STSは7段階のプロセスで動作します。受信側がポリシー公開とDNS設定を行い、送信側がポリシーを取得・検証・適用し、必要に応じてレポートを送信します。ポリシーはキャッシュされ、再利用されます。

1. ポリシーの公開

メールサーバのオーナーは、MTA-STSポリシーを特定の場所に配置します。
通常、このポリシーはWebサーバに置かれ、予め定められたURL(_mta-sts.example.comというように、_mta-sts.ドメイン名)でアクセス可能になります。
ポリシーファイルは、RFC5785の規定に沿って、「.well-known」というフォルダに「mta-sts.txt」というファイル名で保存します。
https://_mta-sts.example.com/.well-known/mta-sts.txt というようなURLになります。

2. DNSレコードの設定

メールサーバのオーナーは、MTA-STSを使用する旨を示すDNS TXTレコードを設定します。

設定例

DNS TXTレコード（_mta-sts.example.com）の例

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

ポリシーファイル（https://mta-sts.example.com/.well-known/mta-sts.txt）の例

version: STSv1
mode: enforce
mx: mail.example.com
mx: backup-mail.example.com
max_age: 604800

パラメータの説明

version

プロトコルバージョン（現在はSTSv1のみ）

mode

ポリシーモード（testing / enforce / none）

mx

許可するMXホスト名（複数指定可、ワイルドカード可）

max_age

ポリシーのキャッシュ有効期間（秒単位、最大31557600秒=1年）

3. メール送信

外部のメールサーバがメールを送信しようとすると、まず対象のドメインのMTA-STSポリシーを確認します。

4. ポリシーの検索

送信サーバはDNSレコードを調べてMTA-STSポリシーのURLを見つけ、そのポリシーをダウンロードします。

5. ポリシーの適用

ダウンロードしたポリシーに基づき、送信サーバはTLSを使用して受信サーバと通信します。
ポリシーに違反する場合（例：無効な証明書、TLSが無効等）は、メールの送信が拒否される場合があります。

6. レポート

オプションで、送信サーバはポリシー違反やその他の問題を報告することができます。

7. キャッシュ

一度ダウンロードしたMTA-STSポリシーは、一定期間キャッシュされることが多いです。
これにより、同じ送信サーバが再度同じドメインに対してメールを送信する際に、MTA-STSポリシーの再ダウンロードを省略できます。

以上が基本的なMTA-STSの処理プロセスです。
この標準により、メールのトランスポートセキュリティが強化され、中間者攻撃などからより安全になります。

MTA-STSが受信側の設定になっている理由

要点：MTA-STSが受信側の設定である理由は、受信側が自身のセキュリティポリシーを制御し、送信側による一方的なセキュリティレベル低下を防止するためです。受信側がポリシーを設定することで、TLS暗号化を強制できます。

メールを送信する際には、自社の設定が適切であれば基本的に問題は少ないですが、受信側が適切なセキュリティ設定をしていない場合、リスクが生じる可能性があります。
SMTP over TLSは、仕様が策定されてからもう20年近く経っており、多くのMTAが対応しています。
しかし、対応しているからと言って必ずしもセキュアな設定が施されているわけではありません。

このような状況で特に問題となるのが受信時です。
MTA-STSは、受信側が自分自身に対するセキュリティポリシーを制御できるようにしています。
この制御により、送信側が一方的にセキュリティレベルを下げることが防がれます。

具体的には、受信側がMTA-STSでポリシーを設定することで、送信側はそのポリシーに従わざるを得ません。
その結果、受信時もTLSによる暗号化通信が強制され、全体として高いセキュリティが確保されます。

以上のような理由から、MTA-STSは受信側がポリシーファイルを用意するという仕組みになっています。
これにより、メール通信のセキュリティがより強固に、そして効率的に確保されるのです。

SPF/DKIM/DMARCのドメイン認証を補助

要点：MTA-STSは、HTTPSという別プロトコルでMXホストの正当性を検証するため、DNSのみに依存するSPF/DKIM/DMARCを補完し、ドメイン認証の信頼性を向上させます。

MTA-STSは、Webサーバにアップロードしたポリシーファイルに、自社のMXレコードを記載して参照します。
DNSのMXレコードや、SPFレコードだけではなく、正しいMTAをHTTPSという別プロトコルによって担保し、ドメイン認証を補助する効果もあります。