MTA-STS

このガイドはメール認証ガイドの一部です。関連記事: BIMI と DKIM vs DMARC。

MTA-STS（SMTP MTA Strict Transport Security）は、ドメインが着信メールを暗号化・認証された TLS 経由で配信するよう要求できる標準で、ダウングレード攻撃や中間者攻撃を防ぎます。TLS-RPT はその companion となるレポート標準で、配信 TLS の失敗に関する日次レポートを収集します。MTA-STS はトランスポート層を保護し、接続ではなく送信者を認証する SPF、DKIM、DMARC を補完します。

MTA-STS が解決する問題

2 台のメールサーバーが SMTP でメッセージを交換するとき、通常は STARTTLS を使って暗号化をネゴシエートします。問題は、STARTTLS が日和見的だということです。送信サーバーは受信側が TLS に対応しているかを尋ね、答えが「いいえ」なら静かに平文へフォールバックします。その問いと答えは平文でやり取りされるため、2 台のサーバーの間に位置する攻撃者は、会話から STARTTLS コマンドを剥ぎ取ることができます。すると送信サーバーは受信側に TLS 対応がないと信じ込み、メッセージを暗号化せずに配信するか、偽造証明書を提示する成りすましサーバーに接続してしまいます。

これらはダウングレード攻撃および中間者攻撃として知られています。SMTP は相互運用性を第一に、セキュリティを後回しにして設計されたため、受信ドメインが「私宛のメールは常に暗号化し、それができないなら配信を拒否せよ」と表明する方法は、歴史的に存在しませんでした。MTA-STS はまさにその隙間を埋めます。ドメインは、着信メールが必ず TLS 経由で、公開された MX ホストの 1 つに一致する有効な証明書を用いて配信されなければならない、と宣言するポリシーを公開できます。MTA-STS に対応する送信サーバーはそのポリシーを尊重し、メッセージを平文で送るくらいなら遅延させるかバウンスさせます。

MTA-STS はどう機能するか

MTA-STS は、連携して動作する 2 つの要素に依存します。ポリシーを告知する DNS TXT レコードと、それを定義する HTTPS でホストされたポリシーファイルです。

まず、_mta-sts.yourdomain.com に TXT レコードを公開します。このレコードはポリシーが存在することを示し、ポリシーを更新するたびに変わる ID を持つので、送信サーバーはいつ再取得すべきかを知ることができます。

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260910T120000;"

次に、ポリシーファイルを固定された既知の場所 https://mta-sts.yourdomain.com/.well-known/mta-sts.txt で HTTPS 経由で提供します。HTTPS の要件が重要なのは、そのホスト上の証明書が、ポリシーが本物であり転送中に改ざんされていないことを証明するからです。

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800

mx の行は、あなたのメールを受信することを許可されたすべてのホスト名を、MX レコードに一致させて列挙します。max_age は、ポリシーをどれだけの秒数キャッシュするかを送信サーバーに伝えます（604800 は 1 週間です）。キャッシュが長いほど、DNS を一時的に操作できる攻撃者に対する耐性が高まるので、設定に自信が持てたら少なくとも数日の値が推奨されます。

enforce モードとテストモード

ポリシーファイルの mode フィールドは、ポリシーをどれだけ厳格に適用するかを制御し、MTA-STS を展開する際に最も重要なダイヤルです。

mode: testing から始めましょう。テストモードでは、送信サーバーはあなたのポリシーを評価しますが、失敗しても決して配信をブロックしません。代わりに、後述の TLS-RPT と組み合わせて、失敗をあなたに報告します。これにより、正当なメッセージを一通も失うことなく、誤設定された MX ホスト、期限切れの証明書、ホスト名の不一致を発見できます。

レポートが 1〜2 週間クリーンに戻ってきたら、mode: enforce に切り替えます。これで送信サーバーは、列挙された MX ホストへ認証済み TLS で送れないメールの配信を拒否します。3 つ目の値 mode: none は事実上ポリシーを無効化し、MTA-STS を穏やかに廃止するために使われます。テストから enforce へは常に慎重に移行し、決して急いで逆方向に進めないでください。

TLS-RPT: レポート

MTA-STS 単独では、配信がどうなっているかを何も教えてくれません。TLS-RPT（SMTP TLS Reporting）はそのフィードバックチャネルです。_smtp._tls.yourdomain.com に 2 つ目の TXT レコードを公開し、集計レポートを受け取るべきアドレスを指定します。

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

参加している送信サーバーは、あなたのドメインへの成功・失敗した TLS セッションを要約した日次 JSON レポートを送ってきます。証明書が検証されなかった、あるいは STARTTLS ネゴシエーションが剥ぎ取られたといった、各失敗の理由も含まれます。これらのレポートこそがテストモードを有用にするものであり、enforce モードにおいても証明書の期限切れや MX の変更に対する早期警戒システムとして価値を持ち続けます。多くのチームは rua アドレスを人間の受信トレイではなく監視ダッシュボードへとルーティングします。

SPF、DKIM、DMARC の中での位置づけ

MTA-STS を他の頭字語と一緒くたにしがちですが、これは異なる問題を解決します。SPF、DKIM、DMARC は送信者を認証し、「このメッセージは本当にそれが名乗るドメインからのものか？」に答えます。MTA-STS は接続を保護し、「このメッセージはプライベートに、正しいサーバーへ配信されているか？」に答えます。両方が必要です。メッセージは完璧に認証されていてもなお転送中に傍受されうるし、完璧に暗号化された接続でもなおなりすましメッセージを運びうるからです。

送信者認証の全体像については、メール認証ガイドをご覧ください。MTA-STS はトランスポート層の追加としてそれらの標準と自然に組み合わさり、それらを整えたら、対応する受信トレイに検証済みのブランドロゴを表示できる BIMI も、検討に値するもう 1 つの高度な層です。

よくある質問

MTA-STS とは何ですか？

MTA-STS（SMTP MTA Strict Transport Security）は、ドメインが着信メールを暗号化・認証された TLS 経由で配信するよう要求できる標準です。DNS レコードと HTTPS でホストされたポリシーファイルを公開し、送信サーバーに暗号化を強制させ、平文へのフォールバックを拒否させることで、SMTP に対するダウングレード攻撃や中間者攻撃をブロックします。

MTA-STS と TLS-RPT の違いは何ですか？

MTA-STS は強制の標準で、TLS 配信を要求するポリシーを定義します。TLS-RPT はレポートの標準で、送信サーバーが TLS 配信の成功と失敗の日次サマリーを送れるよう、DNS レコードと JSON レポート形式を定義します。両者は一緒にデプロイし、MTA-STS ポリシーを強制する前に安全に検証するために TLS-RPT を使います。

MTA-STS は必須ですか？

いいえ、MTA-STS は必須ではなく、メールはそれなしでも機能します。しかし、SPF、DKIM、DMARC が対処しない実際の隙間を塞ぐため、機密性の高いメールを扱うあらゆるドメインに強く推奨されます。まずテストモードでデプロイすれば配信リスクは伴わないので、採用しない理由はほとんどありません。

MTA-STS は SPF、DKIM、DMARC を置き換えますか？

いいえ。MTA-STS は異なる層で動作します。SPF、DKIM、DMARC は送信者を認証しなりすましを検出しますが、MTA-STS はトランスポート接続を保護し、メールが正しいサーバーへプライベートに配信されるようにします。両者は補完的な制御であり、十分に保護されたドメインはどれか一つを選ぶのではなく、それらすべてを一緒にデプロイします。