MTA-STSポリシーチェッカー
ドメインの_mta-sts TXTレコードとmta-sts.txtポリシーファイルを取得し、メール転送時のTLS暗号化強制（MTA-STS）が正しく設定されているかを診断します。
メール転送のTLS強制（MTA-STS）を診断する
SMTP の暗号化は本来「できるならする」という任意の仕組みで、途中に割り込んだ攻撃者が STARTTLS の告知を削り取れば、平文へ落とすことができてしまいます。MTA-STS はこれを塞ぐ取り決めで、**「このドメイン宛のメールは必ず TLS で送れ」と送信側へ指示します。** このツールは `_mta-sts` の TXT レコードとポリシーファイルの両方を取得し、設定が揃っているかを診断します。
**構成で紛らわしいのは、DNS にはポリシーそのものが置かれないという点です。** TXT レコードが持つのは版を示す `id` だけで、**実体は `https://mta-sts.ドメイン/.well-known/mta-sts.txt` から HTTPS で配られます。** つまりこの仕組みの信頼は、DNS ではなくウェブの証明書に置かれています。**そして最もよくある行き詰まりが、`mode` を `testing` のままにしていることです。** この状態では TLS に失敗しても配送はそのまま通り、**実際に強制されるのは `enforce` にしたときだけ**です。導入の順序としては、`testing` で TLS-RPT のレポートを見て実害が無いことを確かめてから `enforce` へ進むのが定石になります。
使い方
- ドメインを入力する `example.com` のように、ドメインだけを入れます。
- TXTレコードを確認する **`v=STSv1` と `id=` があるかを見ます。** `id` はポリシーを更新するたびに変えます。
- ポリシーファイルの中身を読む `mx`・`max_age`・`mode` の3つが並んでいます。
- modeを確かめる **`testing` のままなら強制されていません。** 実効を得るには `enforce` が要ります。
使いこなすためのヒント
- MTA-STSはメール「送信側」のサーバーが確認する仕組みです。導入するとメールを送ってくる側が自ドメイン宛の通信でTLSを強制してくれるようになります。
- ポリシーファイルは必ずmode:enforceの前にmode:testingで数週間〜1ヶ月ほど運用し、意図しない配送拒否が起きないか監視してから移行するのが安全です。
- max_age（ポリシーの有効期間）は604800秒（7日）〜31557600秒（1年）の範囲で指定するのが一般的です。短すぎるとキャッシュ切れのたびに再取得コストが発生します。
- mxで指定するホスト名にはワイルドカード（*.example.com）が使えますが、TLS証明書のSAN（Subject Alternative Name）がそのワイルドカードに一致している必要があります。
- DNSレコードとポリシーファイルのどちらか一方だけを設定しても機能しません。両方が揃って初めてMTA-STSとして有効になる点に注意してください。
活用シーン
自社ドメインの設定を点検する
**DNSとHTTPSの両方が揃っていないと機能しないため、片方の抜けを見つけられます。**
enforceへ進む前に確かめる
`testing` の間に設定の誤りを潰しておけます。
MXを追加したとき見直す
**新しいMXホストをポリシーの `mx` に書き足し忘れると、そのホスト宛の配送が拒まれます。**
取引先の対応状況を知る
相手がTLSを強制しているかどうかが分かります。
MTA-STSの用語
- _mta-sts TXT
- **ポリシーの版を示す `id` を置く DNS レコードです。** ポリシー本体はここには入りません。
- ポリシーファイル
- `https://mta-sts.ドメイン/.well-known/mta-sts.txt` に置く本体です。**HTTPS で配るため、証明書が有効である必要があります。**
- mode
- `enforce`・`testing`・`none` のいずれかです。**`testing` では失敗しても配送されます。**
- max_age
- 送信側がポリシーをキャッシュしてよい秒数です。長くすると保護は強まりますが、変更が行き渡るのに時間がかかります。
- mx
- TLSを強制する対象のMXホストの一覧です。**ここに無いホストへは配送されなくなります。**
- STARTTLSダウングレード
- 中間者が STARTTLS の告知を削って平文へ落とす攻撃です。**MTA-STS はこれを防ぐために作られました。**
よくある質問
余談ですが ― STARTTLSの弱点とMTA-STSが生まれた背景
SMTPにおけるメール転送時の暗号化は、1999年に標準化されたSTARTTLSという「平文で接続を開始し、途中で暗号化に切り替える」仕組みが長らく使われてきました。しかし2014年、STARTTLSのネゴシエーション自体が暗号化される前の平文でやり取りされる弱点を突き、中間者攻撃者がSTARTTLSコマンドを含む応答を書き換えて暗号化への切り替えを無効化する「STARTTLSストリッピング攻撃」が実際に確認されました。攻撃を受けたサーバーは暗号化なしで平文のままメールを送受信してしまいます。
この問題の根本原因は、STARTTLSが「相手がTLSに対応していなければ平文にフォールバックする」設計だったことです。攻撃者はこの互換性維持の仕組みを逆手に取り、あたかも相手がTLS非対応であるかのように装うことができました。Googleの調査（2015年前後）では、一部の国・ISPで広範囲にわたりSTARTTLSストリッピングが行われている実態が明らかになっています。
MTA-STS（RFC 8461、2018年公開）はこの弱点への回答として、Google・Microsoft・Yahoo等の主要メールプロバイダが共同で策定した規格です。DNSのTXTレコードで「このドメインはMTA-STSに対応している」ことを宣言し、HTTPSで取得するポリシーファイルで許可されたMXホストとTLS要件を明示します。ポリシーを一度取得すればmax_ageの期間はキャッシュされるため、その後の接続では平文へのダウングレードを試みる中間者攻撃を検知・拒否できます。
よく似た目的のTLS-RPT（TLS Reporting、RFC 8460）と組み合わせることで、TLS接続に失敗した際のレポートを受け取れるようにする運用も広がっています。MTA-STSは「防御」、TLS-RPTは「可観測性」という役割分担で、両者を併用するのが現在のベストプラクティスです。