MTA-STS（Mail Transfer Agent Strict Transport Security）

概要

MTA-STS（Mail Transfer Agent Strict Transport Security） は、メールの SMTP 通信で TLS 暗号化を強制し、送信サーバーに対して受信サーバーの証明書検証を要求する仕組みです。RFC 8461（2018年）で定義されています。

SMTP のメール配送はデフォルトで平文通信です。STARTTLS による暗号化は「日和見的」で、サーバー間で TLS をネゴシエーションできなければ平文にフォールバックします。中間者攻撃（MITM）で STARTTLS の応答を除去すると、送信サーバーは平文で配送してしまいます。

MTA-STS はこの脆弱性を塞ぎます。受信ドメインが「TLS を必須とする」ポリシーを HTTPS 経由で公開し、送信サーバーはそのポリシーに従って TLS が確立できない場合はメールを配送しません。Web の HSTS（HTTP Strict Transport Security）に似た考え方をメール配送に適用した仕組みです。

仕組み

MTA-STS はDNS TXT レコードによるポリシー検出と、HTTPS 経由のポリシーファイル取得の 2 段階で動作します。

ポリシーの取得フロー

MTA-STS のポリシー取得は 2 段階で行われます。

1. 送信サーバーが _mta-sts.受信ドメイン の TXT レコードを DNS で引く
2. TXT レコードが存在すれば、https://mta-sts.受信ドメイン/.well-known/mta-sts.txt からポリシーファイルを HTTPS で取得する

DNS レコードはポリシーの存在と更新バージョンを示すだけで、ポリシー本体は HTTPS で配信されます。DNS は暗号化されていないため、ポリシー本体を DNS に置くと改ざんの余地があります。HTTPS を使うことで完全性を確保しています。

DNS TXT レコード

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20240201"

v=STSv1 はバージョン、id= はポリシーの識別子です。ポリシーを更新するたびに id の値を変更します。送信サーバーはキャッシュしたポリシーの id と比較し、変更があれば新しいポリシーを取得します。

ポリシーファイル

ポリシーファイルは https://mta-sts.example.com/.well-known/mta-sts.txt で配信します。

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

mode は 3 種類あります。

testing はポリシー違反を検出してもメールを配送します。TLS-RPT レポートでエラーを収集する段階で使います。

enforce はポリシーに違反する場合（TLS が確立できない、証明書が無効など）メールを配送しません。本番運用で使います。

none はポリシーを無効化します。MTA-STS の運用を停止する場合に使います。

mx は許可する MX ホスト名です。送信サーバーは、MX レコードで取得したホスト名がポリシーの mx に含まれているか、証明書の SAN（Subject Alternative Name）がホスト名と一致するかを検証します。

max_age はポリシーのキャッシュ期間（秒）です。604800 は 7 日間です。

証明書の検証

MTA-STS が有効な場合、送信サーバーは次の検証を行います。

1. STARTTLS で TLS を確立する
2. サーバー証明書がパブリック CA から発行されていることを検証する
3. 証明書の SAN が MX ホスト名と一致することを検証する
4. 証明書の有効期限が切れていないことを検証する

いずれかの検証に失敗し、mode: enforce であれば、メールは配送されません。

設定例

MTA-STS の導入には DNS レコードの追加、ポリシーファイルの配置、段階的なモード移行の 3 ステップが必要です。

DNS レコードの追加

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20240201"

ポリシーファイルの配置

https://mta-sts.example.com/.well-known/mta-sts.txt に以下を配置します。

version: STSv1
mode: enforce
mx: mail.example.com
mx: backup-mx.example.com
max_age: 604800

段階導入（testing モード）

最初は mode: testing で運用し、TLS-RPT レポートでエラーが発生しないことを確認してから mode: enforce に移行します。

version: STSv1
mode: testing
mx: mail.example.com
max_age: 86400

max_age は testing 中は短め（1 日 = 86400 秒）にして、ポリシー変更を素早く反映できるようにします。

確認方法

MTA-STS の DNS レコードは dig で確認できます。

dig TXT _mta-sts.example.com

;; ANSWER SECTION:
_mta-sts.example.com.	3600	IN	TXT	"v=STSv1; id=20240201"

ポリシーファイルは curl で取得できます。

curl "https://mta-sts.example.com/.well-known/mta-sts.txt"

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

ポリシーファイルが HTTPS で正しく配信されていること、証明書が有効であることが前提です。

外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/dns?domain=example.com&type=TXT,MX"

{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "TXT": [["v=spf1 include:_spf.google.com ~all"]],
      "MX": [{ "priority": 10, "exchange": "mail.example.com" }]
    }
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

MX レコードのホスト名がポリシーファイルの mx と一致しているかを確認します。

よくある問題

MTA-STS の運用では、HTTPS 証明書の管理やポリシーファイルの更新漏れがメール配送障害につながります。

ポリシーファイルの HTTPS 証明書が失効する

ポリシーファイルは HTTPS で配信する必要があります。mta-sts.example.com の SSL/TLS 証明書が失効すると、送信サーバーがポリシーを取得できなくなります。キャッシュ済みのポリシーが max_age 以内であれば引き続き使われますが、キャッシュが切れた後は MTA-STS なしの状態になります。証明書の自動更新を設定します。

MX ホスト名がポリシーと一致しない

MX レコードのホスト名を変更した際に、ポリシーファイルの mx を更新し忘れると、送信サーバーがメールを配送できなくなります。MX を変更する前にポリシーファイルを先に更新し、max_age の期間待ってから MX を切り替えます。

testing モードのまま放置する

mode: testing ではポリシー違反があってもメールは配送されます。TLS のダウングレード攻撃を防ぐ効果はありません。TLS-RPT レポートでエラーが発生しないことを確認したら、mode: enforce に移行します。

DANE との関係

DANE（DNS-based Authentication of Named Entities）も SMTP の TLS を強制する仕組みですが、DNSSEC が前提です。DNSSEC を導入していないドメインでは MTA-STS が代替手段になります。両方を設定した場合、送信サーバーの実装によって優先順位が異なります。