MTA-STSチェック

MTA-STS（Mail Transfer Agent Strict Transport Security、RFC 8461）は、自ドメインへのメール配信に、暗号化され認証されたTLSの使用を他のメールサーバーに求める仕組みです。これがないとSMTPの暗号化は任意で、接続を傍受できる攻撃者はTLSを外し、メールを読んだり改ざんしたりできます（ダウングレード攻撃）。MTA-STSは、送信サーバーが従うべきポリシーを公開して、この穴をふさぎます。

2つの要素が両方とも必要です。1つは_mta-sts.yourdomain.co.jpのDNS TXTレコードで、v=STSv1とidを含みます。もう1つはhttps://mta-sts.yourdomain.co.jp/.well-known/mta-sts.txtでHTTPS配信するポリシーファイルで、モード（testingかenforce）、許可するメールサーバー（mx）、max_ageを記載します。DNSレコードはポリシーの存在と最終更新を送信側に伝え、HTTPSのファイルがポリシー本体です。どちらかが欠けるか、mta-stsホストの証明書が無効なら、MTA-STSは機能しません。

ドメインを入力すると、_mta-stsのTXTレコードを照会し、mta-stsホストからHTTPSでポリシーファイルを取得し、TLS-RPT用の_smtp._tlsのTXTレコードを読み取ります。そのうえで適用モード、ポリシーで許可したメールサーバー、max_age、レポートの設定有無を表示します。送信サーバーから見たとおりに設定全体が機能するか確認できます。

testingモードでは、有効なTLSを確立できない送信サーバーもメールを配信し、（TLS-RPTを設定していれば）失敗を報告します。enforceモードでは、同じサーバーは記載されたMXと認証済みのTLS接続ができるまで配信しません。必ずtestingから始め、失敗の原因がわかるまでTLS-RPTレポートを確認してから、enforceへ切り替えます。MXの記載に誤りがあるままいきなりenforceにすると、正規のメールが不達になることがあります。

TLS-RPT（RFC 8460）は、_smtp._tls.yourdomain.co.jpに置く対のTXTレコードです。TLS接続の成功と失敗について、日次レポートを送るよう受信側に求めます。強く推奨します。enforceに移る前にMTA-STSポリシーが問題を起こしていないかを知る手段であり、その後も続く配信トラブルに気づく手段になります。

どちらも受信メールにTLSを強制しますが、信頼の根拠が違います。DANEは証明書のフィンガープリントをDNSで公開し、ドメインへのDNSSEC導入が前提です。MTA-STSはWeb PKI（mta-stsホストの有効な証明書）に依拠し、DNSSECは不要なため、はるかに導入しやすくなっています。そのためGoogle、Microsoft、YahooはMTA-STSに対応しています。DNSSECを運用済みのドメインは、両方を公開していることもよくあります。

場所は標準で決まっており、送信側はhttps://mta-sts.yourdomain.co.jp/.well-known/mta-sts.txtを取得します。mta-stsサブドメインには、専用のA/AAAA（またはCNAME）レコードと、そのホスト名を含む有効なTLS証明書が必要です。よくある失敗は、DNS TXTレコードだけ公開してmta-stsホストを用意しない、または証明書を失効させることです。上のツールはこのケースを検出します。

はい。Palisadeはポリシーファイルを冗長化した基盤でホストし、DNSレコードの案を作成して承認を求めます。ポリシーの変更時にはidを同期し、TLS-RPTレポートを表示するので、testingからenforceへ切り替える時期を判断できます。管理する全ドメインで、SPF、DKIM、DMARC、BIMIとあわせて対応します。