MTA-STSとは？DNSレコードとポリシーファイルの設定方法・enforce移行・診断基準

MTA-STSとは

MTA-STS（SMTP MTA Strict Transport Security）とは、「このドメイン宛てのメールは、検証済みの証明書を持つ指定のメールサーバーへ、TLSで暗号化して届けること」を送信側のメールサーバー（MTA）に求めるための仕組みです。RFC 8461で定められており、Webにおける HSTS のメール版にあたります。

_mta-sts.city.example.lg.jp. 3600 IN TXT "v=STSv1; id=20261001T0900"

version: STSv1
mode: enforce
mx: mail.city.example.lg.jp
max_age: 604800

サーバー間のSMTP通信は、STARTTLSによる暗号化が「できればする」任意の方式です。そのため、通信経路上の攻撃者がSTARTTLSの提示を消去したり、偽のMXへ誘導したりすると、送信側は平文で、あるいは偽サーバーへメールを届けてしまいます（ダウングレード攻撃）。MTA-STSを enforce モードで公開すると、MTA-STSに対応した送信側（Gmail、Microsoft 365など）は、TLSが成立しない場合や証明書・MX名がポリシーと一致しない場合に配送を中止します。

セキュリティAIチェッカーのこの項目は、自治体のメールドメインにMTA-STSのDNSレコードとHTTPSポリシーが整合した形で公開され、実際に保護が働く enforce モードになっているかを評価します。TLSの失敗を報告してもらう仕組みは「SMTP TLSレポート（TLS-RPT）」で別に評価します。

MTA-STSの仕組み（DNS TXTとポリシーファイル）

2つの構成要素（RFC 8461 §3）

1. DNS TXTレコード：_mta-sts.<ドメイン> に v=STSv1; id=<識別子> を公開します。id は1〜32文字の英数字で、ポリシーを変更するたびに値を変えて送信側に再取得を促します。区切りの ; の前後には空白を入れてもよく（*WSP ";" *WSP）、CNAMEで別名を指すこともできます。v=STSv1; で始まるレコードが1件でない場合、送信側は「ポリシーなし」とみなさなければなりません。
2. HTTPSポリシーファイル：https://mta-sts.<ドメイン>/.well-known/mta-sts.txt に置きます。取得は有効な証明書によるHTTPSで行い、HTTP 3xxリダイレクトは追跡してはならず、HTTPキャッシュも使ってはなりません（MUST NOT）。メディアタイプは text/plain であることを送信側は検証すべき（SHOULD）とされ、推奨される最大サイズは64KB、タイムアウトは1分程度です。

ポリシーファイル（mta-sts.txt）の書き方（§3.2）

version: STSv1
mode: enforce
mx: mail.city.example.lg.jp
mx: *.mail.protection.outlook.com
max_age: 604800

MTA-STSのモード（testing・enforce・none）の意味

初回接続の問題（Trust on First Use）

送信側がポリシーを一度も取得していない状態（初回）や、キャッシュ期限切れの状態では保護されません（Trust on First Use）。max_age を長め（1〜2週間以上）にし、送信側にキャッシュさせておくことが重要です。

MTA-STSでよくある誤解

• 「TXTレコードだけで有効になる」：HTTPSのポリシーファイルが必須です。TXTだけでは送信側は何もしません。
• 「mta-stsサブドメインからwwwへリダイレクトしてもよい」：3xxは追跡されないため、ポリシー取得に失敗します。
• 「Webサイトの証明書があればよい」：mta-sts.<ドメイン> に有効な証明書が必要です。さらに enforce では、MXサーバー自身がMX名に一致する有効な証明書でSTARTTLSを提供している必要があります。

送信ドメイン認証（なりすまし対策）は「SPFの一意性・構文・DNS参照数」や「DMARCレコード」の領域で、MTA-STSは「受信するメールの経路の暗号化」を守る別の仕組みです。

MTA-STSの診断基準（セキュリティAIチェッカー）

取得対象

• 対象ドメイン：最終URLのホスト名から先頭の www. を除いたもの。
• DNS-over-HTTPS（dns.google）で MX と _mta-sts.<ドメイン> のTXTを照会します（タイムアウト5秒）。
• MXがあり、TXTが有効な場合に限り、https://mta-sts.<ドメイン>/.well-known/mta-sts.txt をGETで1回取得します。リダイレクトは追跡しません（3xxはポリシー取得失敗として扱う）。証明書検証は有効、タイムアウト7秒、最大64KB。

判定に使う条件

• TXT有効：v=STSv1 の後に ;（前後の空白可）が続くレコードがちょうど1件あり、id= が1〜32文字の英数字であること。
• ポリシー有効：HTTP 200で、version: STSv1、mode: が enforce／testing／none のいずれか、max_age: が0〜31557600の整数、mode: none 以外では mx: が1つ以上あること。
• MX適合：DNSのMXホスト名（末尾のドットを除く）がすべて、ポリシーの mx: のいずれかに完全一致、またはワイルドカード（左端の1ラベルのみ）で一致すること。

判定条件

• TXTがあるのにポリシーが無効な状態は、送信側から見て設定の不整合であり、導入作業が途中で止まっている可能性が高いため不合格とします。
• MXの不一致を enforce で放置すると、正規のメールが配送拒否されるおそれがあります。
• 重大度はmedium、重みは2です。

自治体サイトでの判定例

判定の限界

MXサーバーが実際にSTARTTLSを提供し、証明書が有効かどうかは接続して確認していません。_mta-sts のTXT照会に失敗した場合は、レコードなしと同じ要確認になります。DANE（TLSA）による保護も評価対象外です。

MTA-STSが無い・不十分だとどんなリスクがあるか

• メールの盗聴：経路上の攻撃者がSTARTTLSを無効化すると、住民や事業者から自治体に届くメール（申請に関する問い合わせ、添付書類など）が平文で流れます（CWE-319）。
• メールの横取り：DNS応答の偽装などで偽のMXへ誘導されると、メールが攻撃者のサーバーに届きます。MTA-STSの enforce はMX名と証明書の一致を求めるため、この種の誘導を防げます。
• 設定不整合による不達：enforce のままMXを変更し、ポリシーの mx: を更新し忘れると、対応送信者からのメールが届かなくなります。導入後の変更管理が重要です。

MTA-STS未導入を直接の原因として公表された自治体の被害事例は確認できていません。

MTA-STSの設定方法（DNS・Apache・nginx・IIS・Next.js）

導入手順

1. MXサーバーが、MX名に一致する有効な証明書でSTARTTLSを提供していることを確認します（クラウドメールサービスは通常対応済み）。
2. mta-sts.<ドメイン> のDNSレコードを作り、有効な証明書でHTTPS配信できる場所を用意します。
3. mode: testing のポリシーを公開し、_mta-sts TXTと _smtp._tls のTLS-RPTレコードを設定します。
4. 2〜4週間、TLS-RPTのレポートで失敗が無いことを確認します。
5. mode: enforce に変更し、TXTの id を更新します。max_age を604800（1週間）以上へ段階的に延ばします。

DNS

_mta-sts.city.example.lg.jp. 3600 IN TXT "v=STSv1; id=20261001T0900"
mta-sts.city.example.lg.jp.  3600 IN CNAME policy-host.example.net.
_smtp._tls.city.example.lg.jp. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@city.example.lg.jp"

Apache（mta-sts用バーチャルホスト）

<VirtualHost *:443>
  ServerName mta-sts.city.example.lg.jp
  DocumentRoot /var/www/mta-sts
  SSLEngine on
  # SSLCertificateFile／SSLCertificateKeyFile にmta-sts用の証明書を指定
  <Location "/.well-known/mta-sts.txt">
    ForceType "text/plain; charset=utf-8"
    Header always set Cache-Control "no-store"
  </Location>
  # ここでwww等へのリダイレクトを設定しない
</VirtualHost>

nginx

server {
    listen 443 ssl;
    server_name mta-sts.city.example.lg.jp;
    # ssl_certificate／ssl_certificate_key にmta-sts用の証明書を指定（必須）
    location = /.well-known/mta-sts.txt {
        default_type text/plain;
        root /var/www/mta-sts;
    }
}

IIS

mta-sts 用サイトを作成し、.txt のMIMEタイプが text/plain であること、HTTP→HTTPSのリダイレクト規則がこのパスに適用されてもHTTPS自体はリダイレクトしないことを確認します。

Next.js（Vercel）

mta-sts.<ドメイン> を独立したプロジェクトとして割り当て、public/.well-known/mta-sts.txt を配置します。ドメイン設定で「wwwへリダイレクト」を有効にしないよう注意します。

設定後の確認方法

dig +short TXT _mta-sts.city.example.lg.jp
dig +short MX city.example.lg.jp
# リダイレクトを追わずに取得（3xxなら設定誤り）
curl -s -o - -w '\n%{http_code} %{content_type}\n' https://mta-sts.city.example.lg.jp/.well-known/mta-sts.txt

最後の行で 200 text/plain が返り、DNSのMXがすべてポリシーの mx: に含まれていることを確認してから、セキュリティAIチェッカーで再診断します。

メールを止めないための注意点（ガードレール）

• MXの追加・変更時は、先にポリシーの mx: を追加して id を更新し、送信側のキャッシュ（max_age）が切り替わる時間を見込んでからMXを変更します。
• 撤回するときはいきなりTXTを消さず、mode: none のポリシーを公開して id を更新し、max_age が経過してから削除します。
• mta-sts サブドメインにも証明書の自動更新と期限監視を設定します。証明書切れはポリシー取得失敗に直結します。

よくある質問（FAQ）

参考資料

• RFC 8461「SMTP MTA Strict Transport Security (MTA-STS)」
• RFC 8460「SMTP TLS Reporting」
• Google Workspace 管理者ヘルプ「About MTA-STS and TLS reporting」
• Microsoft Learn「Enhance mail flow with MTA-STS」

「MTA-STS」と関連する診断項目

• SMTP TLSレポート（TLS-RPT）low
• SPFの一意性・構文・DNS参照数high
• DMARCレコードhigh
• SPFレコードmedium
• SPFの終端ポリシーmedium
• DMARC強制ポリシーmedium
• DMARC集計レポート送信先low
• CAAレコードlow