2026年8月25日

TLS-RPTを使ってMTA-STSをenforceへ移行する手順｜DMARCのp=rejectに当たる段階の進め方と戻し方

DNS・名前解決

TLS-RPTには、DMARCの p=reject のような「拒否」のポリシーはありません。TLS-RPTは配送時の暗号化の成否を報告してもらうだけの仕組みで、受信を断る側の設定はMTA-STSの mode: enforce が担います。つまり「TLS-RPTでp=rejectに移行する」は、実際には「TLS-RPTのレポートを見ながら、MTA-STSを testing から enforce へ移す」作業です。この記事では、レポートの受け取り体制づくり、移行の段取りと判断基準、max_age の伸ばし方、問題が起きたときの戻し方を、運用の手順として説明します。

DMARCとの対応関係を整理する

DMARCの段階移行に慣れている方向けに、対応関係を並べておきます。

DMARCの p=none（監視のみ）に当たるのが、MTA-STSの mode: testing。失敗しても配送は続き、結果はTLS-RPTで報告されます。
DMARCの p=reject（不合格を拒否）に当たるのが、MTA-STSの mode: enforce。ポリシーに合わない相手（証明書が不正、MXが一覧に無いなど）には、送信側が配送を見送ります。
DMARCの集計レポート（rua）に当たるのが、TLS-RPTのレポート。

大きく違うのは向きです。DMARCは「あなたのドメインから送ったメール」の認証、MTA-STSとTLS-RPTは「他社があなたのドメインへ送るメール」の配送経路の暗号化を扱います。enforce の影響を受けるのは受信で、設定を誤ると、あなたのドメイン宛てのメールが届かなくなります。

手順1：TLS-RPTのレポートを受け取れるようにする

まずレポートの宛先をDNSで公開します。

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

rua= にはメールアドレス（mailto:）のほか、HTTPSのURLも指定できます。カンマで区切って複数書くこともできます。

運用面では次の点を決めておきます。

専用の受信箱を用意する：レポートは送信事業者ごとにおおむね1日1通届き、gzip圧縮のJSONが添付されています。どの事業者が送ってくるかや頻度は事業者の判断によります（2026年10月現在）。担当者の個人の受信箱に混ぜると見落とします。
レポート用アドレスが受け取れなくなる事態に備える：レポートの宛先が、MTA-STSの対象である同じドメインのアドレスだと、enforce で配送に失敗したとき、肝心のレポートまで届かなくなる可能性があります（仕様にはレポート配送時の扱いについての定めもありますが、実際の挙動は送信側の実装によります）。別ドメインのアドレスや、HTTPSの受け口を併用しておくと安心です。
集計の仕組みを用意する：届いたJSONを1通ずつ開くのではなく、スクリプトやレポート集計サービスで、送信事業者ごと・MXホストごとの成功数と失敗数を一覧にできるようにします。

dig _smtp._tls.example.com TXT +short

でレコードが引けることを確認したら、受け取りの準備は完了です。

手順2：testing で公開し、max_age は短く始める

MTA-STSのポリシーファイルを mode: testing で公開します。最初は max_age（送信側がポリシーをキャッシュする秒数）を短めにしておくのがポイントです。

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

_mta-sts.example.com.  TXT  "v=STSv1; id=20261018a"

max_age を短くしておくのは、後で設定を直したときに、古いポリシーが送信側に長く残らないようにするためです。testing の間は失敗しても配送は続くので、この段階で長くしておく利点はあまりありません。

手順3：enforce に進む判断基準を決める

testing の期間は、数週間ほどを目安にします。届いたレポートを集計し、次の条件がそろったら enforce を検討します。

主要な送信事業者（取引先がよく使うメールサービスなど）からのレポートが、継続して届いている。
total-failure-session-count がほぼゼロ、または失敗の原因がすべて説明できる。
失敗が特定のMXホストに偏っていない。偏っているなら、そのMXの証明書やSTARTTLSの設定を先に直す。
ポリシーファイルの mx: に、実際に使っているMXがすべて含まれている（dig example.com MX +short の結果と突き合わせる）。
MXの証明書の自動更新が動いていて、更新後にメールサーバーが新しい証明書を読み込み直すことを確認している。

5は見落とされがちですが、enforce 後にもっとも起きやすい事故は、証明書の期限切れや更新の反映漏れです。testing の間に一度でも証明書の更新を経験しておくと、運用の流れを確かめられます。レポートの各項目の意味や失敗の種類（result-type）ごとの対処は、ここでは詳しく扱いません。RFC 8460と、お使いの集計ツールの説明を参照してください。

手順4：enforce へ切り替える

切り替えは、ポリシーファイルとTXTレコードの2か所を変更します。

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

_mta-sts.example.com.  TXT  "v=STSv1; id=20261101a"

id の値を変えないと、送信側はポリシーが更新されたことに気づかず、キャッシュした testing のポリシーを使い続けます。変更前には、現在のポリシーファイルとTXTレコードの内容を控えておきます。

切り替え後の1〜2週間は、TLS-RPTのレポートを毎日確認します。enforce になると、失敗した接続ではメールが配送されなくなるため、失敗件数がそのまま「届かなかったメールの件数」の目安になります。

手順5：問題がなければ max_age を伸ばす

enforce で安定したら、max_age を段階的に伸ばします。たとえば1日から1週間（604800秒）、さらに長い値へ、という具合です。仕様上の上限は約1年（31557600秒）です。

max_age を伸ばすほど、DNSの改ざんなどでポリシーの取得を妨げられても、送信側はキャッシュしたポリシーで守り続けられます。その一方で、設定を誤ったときに直しても古いポリシーが長く残ります。MXの入れ替えなど大きな変更を控えている時期は、伸ばすのを待つのが無難です。

戻し方：mode: none を使う

enforce で問題が起きたら、まず mode: testing に戻して id を更新します。testing なら、失敗しても配送は続きます。

MTA-STSをやめる場合は、TXTレコードやポリシーファイルをいきなり削除してはいけません。送信側には max_age の間、キャッシュした enforce のポリシーが残るためです。RFC 8461では、mode: none のポリシーを公開して id を更新し、それまでの max_age が過ぎてからレコードとファイルを取り除く手順が示されています。

version: STSv1
mode: none
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

MXを別の事業者に移す場合も同じ考え方で、新しいMXをポリシーの mx: に先に追加して id を更新し、送信側に行き渡ってからMXレコードを切り替えます。

まとめ

TLS-RPTに p=reject は無い。拒否の役割はMTA-STSの mode: enforce、TLS-RPTはその判断材料になるレポート。
専用の受信箱と集計の仕組みを用意し、レポートの宛先は同じドメインだけに頼らない。
testing は短い max_age で始め、失敗が説明できる状態と証明書更新の確認がそろってから enforce へ。
切り替え時はポリシーファイルとTXTレコードの id を一緒に更新し、直後はレポートを毎日見る。
戻すときは testing、やめるときは mode: none を公開して max_age を待ってから削除する。