MTA-STS — メール転送エージェント厳密トランスポートセキュリティ

Standards Track Transport Security Published March 2026

ELI5: 施錠されたメールボックスに手紙を送ることを想像してください。ただし、誰かが本物の鍵を偽物と入れ替えてあなたのメールを読むことができます。MTA-STSは「私は常に本物の鍵を使用しています。鍵がおかしく見える場合は配信しないでください」という看板を発表するようなものです。これは攻撃者がメールサーバーを騙して暗号化なしでメールを送信させるのを防ぎます。

これが存在する理由

SMTPは電子メールが平文で送信されていた時代に設計されました。STARTTLS (RFC 3207)はオプションの暗号化を追加しましたが、致命的な欠陥があります。それは機会主義的です。送信サーバーが「TLSをサポートしていますか?」と尋ね、アクティブなネットワーク攻撃者はその応答を単に削除し、平文へのダウングレードを強制できます。送信サーバーは「このサーバーはTLSをサポートしていない」と「攻撃者がTLSオファーを削除した」の違いを知る方法がありません。

MTA-STSはドメイン所有者がポリシーをパブリッシュすることで這い問題を解決します — DNSではなくHTTPSで — 「私のメールサーバーは常に有効な証明書を持つTLSをサポートしています。安全な接続を確立できない場合は、配信を拒否してください」と宣言します。ポリシーはHTTPS(それ自体が独自の証明書信頼チェーンを持つ)を経由して取得されるため、アクティブな攻撃者はそれを偽造または抑制することはできません。

動作方法

MTA-STSは受け取るドメインから2つのことを要求します:

DNSTXTレコード _mta-sts.example.comでポリシーが存在することを通知し、キャッシュバスティング用のバージョン識別子を含みます。
HTTPS で配信されるポリシーファイル https://mta-sts.example.com/.well-known/mta-sts.txtで実際のポリシーを宣言します。

ステップ1: DNSレコード

MTA-STSポリシーをアドバタイズするためにTXTレコードをパブリッシュします:

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

idフィールドは不透明な文字列です。送信サーバーはポリシーをキャッシュし、idが変わると再取得します。タイムスタンプまたは増加するカウンターを使用してください。

ステップ2: ポリシーファイル

https://mta-sts.example.com/.well-known/mta-sts.txtでポリシーをホストします。HTTPSの証明書はmta-sts.example.comに対して有効である必要があります。

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

ポリシーフィールド

フィールド	説明
`version`	`STSv1`である必要があります。
`mode`	`enforce`(失敗時に拒否)、`testing`(配信しますがレポート)、または`none`(無効化)。
`mx`	許可されたMXホスト名。最左ラベルのみワイルドカード許可(例:`*.example.com`)。
`max_age`	送信者がこのポリシーをキャッシュすべき期間(秒)。推奨:604800(1週間)以上。

送信サーバーが行うこと

受信者ドメインのMXレコードを検索します。
キャッシュされたMTA-STSポリシーを確認するか、DNS _mta-sts TXTレコードが新規または変更された場合は取得します。
MXホストに接続してSTARTTLSを開始します。
MXサーバーのTLS証明書をポリシーのmxパターンに対して検証します。
モードがenforceでTLSが失敗または証明書が一致しない場合:配信しないでください。メッセージをキューに入れて後で再試行します。

主要な技術的詳細

DNSSECの代わりにHTTPSを使う理由

DNSSECのデプロイメントは限定的なままです。HTTPSは広く展開されているWeb PKI(認証局インフラストラクチャ)を活用します。Webの証明書を取得できるすべてのドメインはMTA-STSを使用できます — DNSSECは不要です。これは、DNSSECを必要とするDANE (RFC 7672)とMTA-STSの主要な違いです。

最初の使用を信頼する(TOFU)

MTA-STSはTOFUモデルに従います。送信者が初めてポリシーに遭遇するとき、DNS と HTTPS応答を信頼する必要があります。その後、キャッシュされたポリシーはmax_ageが期限切れになるまでダウングレードから保護します。攻撃者は初期フェッチ中にHTTPSとDNSの両方を同時に危険にさらす必要があります — はるかに難しい攻撃です。

テストモード

mode: testingで開始してください。このモードでは、送信サーバーはTLS検証が失敗してもメールを配信しますが、enforceに切り替える前に問題を特定できるようにTLS-RPT (RFC 8460)レポートを生成します。

デプロイメントの例

example.comの完全なMTA-STS設定:

DNSレコード

; MTA-STSポリシーシグナル _mta-sts.example.com. 300 IN TXT "v=STSv1; id=2024061501" ; TLSレポートエンドポイント(RFC 8460) _smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com" ; MXレコード(ポリシーmxラインと一致する必要があります) example.com. 300 IN MX 10 mail.example.com. example.com. 300 IN MX 20 backup.example.com.

ポリシーファイル

# https://mta-sts.example.com/.well-known/mta-sts.txt で配信
version: STSv1
mode: testing
mx: mail.example.com
mx: backup.example.com
max_age: 86400

TLS-RPTレポートが問題がないことを確認したら、modeをenforceに変更し、max_ageを604800以上に増やします。

一般的なミス

証明書の不一致。ポリシーのMXホスト名はそのサーバー上のTLS証明書と一致する必要があります。MXがmail.example.comだが証明書が*.mailprovider.comである場合、強制は配信エラーを引き起こします。
DNS idの更新を忘れる。送信者はポリシーをidでキーイングしてキャッシュします。ポリシーファイルを変更してもidを変更しない場合、送信者はmax_ageが期限切れになるまで再取得しません。
mta-sts.example.comでの無効なHTTPS証明書。ポリシーホスティングサイトは有効で公開されている信頼された証明書を持つ必要があります。自己署名または期限切れの証明書は送信者がポリシーを無視させます。
直接enforceにジャンプする。常にtestingで開始し、少なくとも2週間TLS-RPTレポートを監視してください。設定が間違っているMXサーバーはenforceモードでサイレントにメールを失います。
enforceモードでの短いmax_age。短いTTLは送信者が頻繁に再取得することを意味し、TOFUウィンドウを拡大します。本番環境では少なくとも604800秒(1週間)を使用してください。
ワイルドカードMXの誤用。mx: *は有効ではありません。ワイルドカードは最左DNSラベルのみに適用されます:mx: *.example.comはa.example.comと一致しますが、a.b.example.comとは一致しません。

配信可能性への影響

MTA-STSは直接受信箱の配置を改善しません — 受信者のメールを傍受から保護します。しかし、それには間接的な配信可能性の利点があります:

ドメイン信頼を構築します。Google、Microsoft、およびYahooはすべてMTA-STSをサポートしています。ポリシーをパブリッシュすることは、セキュリティを真摯に受け取り、よく保守されたドメインを実行していることを示します。
コンプライアンスに必要。機密データを処理する業界(金融、医療)は電子メールのTLS強制をますます必要としています。MTA-STSは標準的なメカニズムです。
サイレントダウングレードを防止します。MTA-STSがなければ、ネットワークパス上の攻撃者はSTARTTLSを削除してメールを傍受できます。どちらの側も知ることなく。これは文書化された現実世界の攻撃です。
TLS-RPTと組み合わせます。RFC 8460レポートは、すべての送信者のTLSエラーの可視性を提供します — 配信に影響する前に証明書または構成の問題を診断するために非常に貴重です。