MTA-STS 導入の具体的ステップ｜DNS と HTTPS ポリシーを 90 分でセットする手順

この記事でわかること

• MTA-STS が解決する課題（盗聴・ダウングレード攻撃）と、SPF / DKIM / DMARC との違い
• 導入の 5 ステップ（DNS / ポリシー / HTTPS / TLS-RPT / モード切替）
• mode=testing から mode=enforce へ安全に切り替えるための判断材料
• 導入後に DNS / HTTPS のどちらが壊れても致命傷にならないよう運用する勘所

MTA-STS とは（30 秒で要点）

MTA-STS（Mail Transfer Agent Strict Transport Security、RFC 8461）は、送信メールサーバが受信メールサーバに対して必ず TLS で接続することを宣言・要求するための仕組みです。SMTP の STARTTLS は通信路を暗号化する仕組みですが、攻撃者が中間で STARTTLS を剥がしてしまう「ダウングレード攻撃」に弱いという課題がありました。MTA-STS はこの抜け道を塞ぎます。

導入の 5 ステップ

ステップ 1: DNS に _mta-sts TXT を追加

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

id はポリシーファイルを更新するたびに変える ID。タイムスタンプ形式が運用しやすい。

ステップ 2: ポリシーファイルを作成

mta-sts.txt を以下の内容で用意します。

version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: *.googlemail.com
max_age: 86400

mx: には現状で MX レコードに登録されているホスト名をすべて列挙します。1 つでも漏れると、漏れたホスト宛のメールが拒否されます。

ステップ 3: HTTPS で公開

https://mta-sts.example.com/.well-known/mta-sts.txt で配信できるよう、サブドメイン mta-sts.example.com を HTTPS（有効な証明書付き）で立てます。Cloudflare Pages や S3 + CloudFront などの静的ホスティングで十分です。

ステップ 4: TLS-RPT（RFC 8460）を併設

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com" を追加し、TLS 接続失敗のレポートを受け取れるようにします。MTA-STS 単体では問題に気付けないため、TLS-RPT との併設が事実上必須です。

ステップ 5: testing → enforce 切り替え

mode: testing で 2〜4 週間運用し、TLS-RPT で失敗が出ないことを確認してから mode: enforce に切り替えます。同時に id を更新します。

運用上の注意

• DNS と HTTPS の両方が壊れると配送停止: mta-sts.example.com の証明書期限切れに気付かないと受信できなくなる送信者が出るため、SSL 期限監視を必ず仕込む（SSL 証明書の期限切れ確認方法 参照）
• MX 変更時は必ずポリシーも更新: 新 MX を追加してから id を回す。順序を逆にすると新 MX 宛拒否が出る
• DMARC との関係: MTA-STS は「メールが TLS で運ばれることを保証」する仕組みで、DMARC（なりすまし防止）とは別レイヤー。両方を設定する

まずは現状を把握しましょう

MTA-STS は SPF / DKIM / DMARC が整った後の「次の一手」です。まず無料のドメイン診断でメール認証の現状を確認し、判断に迷う場合はお問い合わせからご相談ください。SSL 期限や DNS 設定の単発チェックは無料ツール一覧からどうぞ。

関連記事: MTA-STS と TLS-RPT の基礎 / DMARC とは？ / SSL 証明書の期限切れ確認方法