MTA-STSポリシーチェッカー
ドメインの_mta-sts TXTレコードとmta-sts.txtポリシーファイルを取得し、メール転送時のTLS暗号化強制（MTA-STS）が正しく設定されているかを診断します。
Tips
- 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として有効になる点に注意してください。
よくある質問
余談ですが ― 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は「可観測性」という役割分担で、両者を併用するのが現在のベストプラクティスです。