MTA-STSとTLS-RPT｜DMARCの次の一手
目次
この記事でわかること
- MTA-STS と TLS-RPT が何を防ぐ仕組みか
- 設定の段取りとポリシーモードの考え方
- DMARC の次に取り組むべき理由
なぜ DMARC の次に必要なのか
DMARC・SPF・DKIM は「差出人のなりすまし」を防ぐ仕組みです。一方で、メールサーバー間の 通信経路の盗聴・改ざん までは保護しません。
メール配送は SMTP に STARTTLS 拡張を載せて TLS 暗号化するのが現代の標準ですが、STARTTLS は「使えるなら使う、使えないなら平文に落とす」という日和見暗号化(opportunistic TLS)です。経路上の攻撃者が STARTTLS の応答を書き換えてダウングレード攻撃を仕掛けると、平文のままメールが送られてしまいます。
これを防ぐのが MTA-STS(RFC 8461) で、配送状況のレポートを受け取って異常を可視化するのが TLS-RPT(RFC 8460) です。簡単な概要はメール認証の追加機能まとめでも触れています。
MTA-STS の仕組み
MTA-STS は受信側ドメインが「うちは TLS でしか受け取りません、証明書は正しいものだけ受け付けます」と宣言するための規格です。送信側 MTA はこの宣言を取得し、平文配送やオレオレ証明書を拒否します。
宣言は次の 2 つで構成されます。
- DNS TXT レコード
_mta-sts.example.com(ポリシー ID とバージョンの告知) - HTTPS 配信のポリシーファイル
https://mta-sts.example.com/.well-known/mta-sts.txt
ポリシーファイルの中身はテキスト数行で、対象 MX・有効期間・モードを記述します。
version: STSv1
mode: testing
mx: mail.example.com
mx: *.googlemail.com
max_age: 604800
DNS と HTTPS の両方を揃える理由は、DNSSEC が導入できなくても HTTPS の証明書検証で改ざんを検知できるからです。
TLS-RPT の仕組み
TLS-RPT は MTA-STS や DANE による TLS 強制の 失敗状況をレポートで受け取るための仕組みです。DMARC の rua/ruf がメール認証の結果を集約するように、TLS-RPT は配送経路の TLS ハンドシェイク失敗を集約します。設定は DNS TXT 1 行で済みます。
_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:[email protected]"
レポートは JSON 形式で日次配信され、「特定の送信元が証明書検証に失敗して何通配送できなかったか」「TLS のセッションが何件確立できなかったか」が分かります。MTA-STS を enforce で運用するときは、TLS-RPT を必ず併設して 配信できなかったメールが闇に消えていないか を確認できる状態にしておくのが安全です。
レポート受信用のメールアドレスは別ドメインに切る運用が便利で、[email protected] のように専用アドレスを用意すると、DMARC レポートとは別フォルダで集約できます。受信量はメール流量にもよりますが、中小企業なら 1 日 1〜10 件程度が目安です。
ポリシーモードの段階移行
MTA-STS には none / testing / enforce の 3 モードがあります。いきなり enforce にすると、自社向けに送ってくれる取引先のサーバーが古い設定だった場合にメールが届かなくなります。
推奨の段取りは次の通りです。
ステップ1: TLS-RPT の単独導入(2 週間)
まずは TLS-RPT だけ設定し、現状の TLS 配送状況を観察します。MTA-STS の宣言なしでも、対応している大手送信側(Google, Microsoft 等)はレポートを返してくれます。
ステップ2: MTA-STS を testing モードで(2〜4 週間)
ポリシーを mode: testing で公開します。送信側の MTA はポリシーを解釈しますが、検証失敗してもメールはそのまま配送します。代わりに TLS-RPT で「ここで検証失敗が起きている」が見える状態になります。
ステップ3: enforce へ昇格
testing で 2〜4 週間レポートを観察し、自社 MX の証明書 / SAN / 配信経路に問題がないことを確認したら mode: enforce に切り替えます。max_age は最低 604800 秒(7 日)が推奨で、安定したら 2,592,000 秒(30 日)程度まで伸ばします。
設定後の検証
ポリシーが正しく公開できたかは、外部の検証ツールでチェックできます。代表的なツールには以下があります。
- mxtoolbox の MTA-STS Lookup
- hardenize.com のドメインスコア
- aykira.jp など国内の検証ツール
dig +short TXT _mta-sts.example.com で TXT レコードが取れること、curl https://mta-sts.example.com/.well-known/mta-sts.txt で正しい Content-Type(text/plain)とポリシー本文が返ることを確認します。HTTPS の証明書は当然有効である必要があり、SAN に mta-sts.example.com を含めます。Cloudflare Pages や CDN を使うとここの管理が楽です。
SPF / DKIM / DMARC との位置づけ
メール認証は層が違うので、片方だけでは弱点が残ります。
- SPF: 送信元 IP の正当性を保証。設定はSPF 設定ガイド
- DKIM: メール内容の改ざん検知
- DMARC: SPF/DKIM とアラインメントの統合判定。設定はDMARC 設定ガイド
- MTA-STS / TLS-RPT: 配送経路そのものの暗号化を強制
DMARC を p=quarantine 以上で安定運用できているドメインは、次の一手として MTA-STS の testing 導入を強く推奨します。日本国内の中小企業で MTA-STS まで設定している例はまだ少ないため、取引先からの信頼指標としても有効です。
まとめ
- MTA-STS は STARTTLS のダウングレード攻撃を防ぐ仕組み
- TLS-RPT で配信失敗をレポートとして受け取れる
- testing → enforce の段階移行が事故を防ぐ鉄則
- DMARC が安定したら次に検討する価値あり
自社の状況を確認してみませんか
設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。MTA-STS は HTTPS 経由で policy ファイルを公開する仕組みなので、SSL 周りの状態を SSL 証明書 単発チェック で先に確認しておくと、設定後の検証で躓きにくくなります。CSP / X-Frame-Options などの Web セキュリティヘッダ全般を単発で見るには Web セキュリティヘッダ 単発チェック もどうぞ。
棚卸しから自動更新セットアップまでまとめて任せたい場合は、SSL 棚卸し・自動更新支援もご検討ください。判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。