## この記事でわかること

- MTA-STS と TLS-RPT が何を防ぐ仕組みか
- 設定の段取りとポリシーモードの考え方
- DMARC の次に取り組むべき理由

## なぜ DMARC の次に必要なのか

DMARC・SPF・DKIM は「差出人のなりすまし」を防ぐ仕組みです。一方で、メールサーバー間の **通信経路の盗聴・改ざん** までは保護しません。

メール配送は SMTP に STARTTLS 拡張を載せて TLS 暗号化するのが現代の標準ですが、STARTTLS は「使えるなら使う、使えないなら平文に落とす」という日和見暗号化(opportunistic TLS)です。経路上の攻撃者が `STARTTLS` の応答を書き換えてダウングレード攻撃を仕掛けると、平文のままメールが送られてしまいます。

これを防ぐのが **MTA-STS(RFC 8461)** で、配送状況のレポートを受け取って異常を可視化するのが **TLS-RPT(RFC 8460)** です。簡単な概要は[メール認証の追加機能まとめ](/blog/email-extras-overview)でも触れています。

![STARTTLS ダウングレード攻撃と MTA-STS で防ぐ流れ](/blog/mta-sts-tls-rpt-basics/starttls-downgrade.svg)

## 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:tls-reports@example.com"
```

レポートは JSON 形式で日次配信され、「特定の送信元が証明書検証に失敗して何通配送できなかったか」「TLS のセッションが何件確立できなかったか」が分かります。MTA-STS を `enforce` で運用するときは、TLS-RPT を必ず併設して **配信できなかったメールが闇に消えていないか** を確認できる状態にしておくのが安全です。

レポート受信用のメールアドレスは別ドメインに切る運用が便利で、`tls-reports@example.com` のように専用アドレスを用意すると、DMARC レポートとは別フォルダで集約できます。受信量はメール流量にもよりますが、中小企業なら 1 日 1〜10 件程度が目安です。

## ポリシーモードの段階移行

MTA-STS には `none` / `testing` / `enforce` の 3 モードがあります。いきなり `enforce` にすると、自社向けに送ってくれる取引先のサーバーが古い設定だった場合にメールが届かなくなります。

![MTA-STS ポリシーモードの段階移行](/blog/mta-sts-tls-rpt-basics/mta-sts-modes.svg)

推奨の段取りは次の通りです。

### ステップ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 設定ガイド](/blog/spf-setup-guide)
- **DKIM**: メール内容の改ざん検知
- **DMARC**: SPF/DKIM とアラインメントの統合判定。設定は[DMARC 設定ガイド](/blog/dmarc-setup-guide)
- **MTA-STS / TLS-RPT**: 配送経路そのものの暗号化を強制

DMARC を `p=quarantine` 以上で安定運用できているドメインは、次の一手として MTA-STS の testing 導入を強く推奨します。日本国内の中小企業で MTA-STS まで設定している例はまだ少ないため、取引先からの信頼指標としても有効です。

### まとめ

- MTA-STS は STARTTLS のダウングレード攻撃を防ぐ仕組み
- TLS-RPT で配信失敗をレポートとして受け取れる
- testing → enforce の段階移行が事故を防ぐ鉄則
- DMARC が安定したら次に検討する価値あり

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。MTA-STS は HTTPS 経由で policy ファイルを公開する仕組みなので、SSL 周りの状態を [SSL 証明書 単発チェック](/ssl/check) で先に確認しておくと、設定後の検証で躓きにくくなります。CSP / X-Frame-Options などの Web セキュリティヘッダ全般を単発で見るには [Web セキュリティヘッダ 単発チェック](/security-headers/check) もどうぞ。

棚卸しから自動更新セットアップまでまとめて任せたい場合は、[SSL 棚卸し・自動更新支援](/ssl)もご検討ください。判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。