解説

MTA-STSとTLS-RPTの設定方法: 受信メールの暗号化を強制する

自社宛てのメールが暗号化されずに届くのを防ぐのが MTA-STS、その結果を受け取るのが TLS-RPT です。TXT レコード、mta-sts サブドメインのポリシーファイル、testing から enforce への切り替え、Google Workspace と Microsoft 365 での注意を説明します。

何が守られていないのか

メールサーバー同士の通信は、多くの場合 STARTTLS という仕組みで暗号化されています。ただし STARTTLS は「相手が対応していれば暗号化する」方式で、暗号化できなければ平文のまま送ってしまいます。途中の経路に入り込んだ攻撃者が「このサーバーは暗号化に対応していない」と見せかければ、送信側はそのまま平文で送ります。証明書が偽物でも、多くの送信サーバーはそれを理由に配送を止めません。

MTA-STS(RFC 8461)は、受信側のドメインが「うちのメールサーバーには必ず TLS で、正しい証明書を確認したうえで送ってください。できなければ送らないでください」と宣言する仕組みです。Gmail や Microsoft 365 の送信サーバーはこの宣言を確認して従います。

守られるのは、他社から自社へ届くメールです。自社から送るメールの暗号化は、送り先のドメインが MTA-STS を設定しているかどうかで決まります。

TLS-RPT(RFC 8460)は、送信側が「あなたのドメインに送ろうとして、TLS の接続に成功した件数と失敗した件数」を毎日レポートで送ってくれる仕組みです。MTA-STS と組み合わせて使います。

必要なもの

設定は3つです。

_mta-sts.example.com の TXT レコード(ポリシーがあることの合図)
https://mta-sts.example.com/.well-known/mta-sts.txt に置くポリシーファイル
_smtp._tls.example.com の TXT レコード(TLS-RPT のレポート送り先)

2番目は Web サーバーが必要です。mta-sts.example.com というサブドメインを作り、そのホスト名で有効な SSL証明書を付けて、HTTPS でファイルを1つ公開します。メールのために Web サーバーを用意するのは手間ですが、ファイルは数行のテキストなので、静的なファイルを置ける場所ならどこでも構いません。

ポリシーファイルの書き方

まず、自社ドメインの MX レコードを確認します。DNSレコード確認で MX を見ると、メールを受け取るサーバーのホスト名が表示されます。

ポリシーファイルは次のような内容です。

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

version は固定値です。mode は testing、enforce、none のどれかを書きます。mx には MX レコードに出てくるホスト名を1行に1つずつ書きます。先頭のラベルだけ *.example.net のようなワイルドカードが使えますが、* が置き換えるのは1段分だけです。max_age は送信側がこのポリシーを覚えておく秒数で、上限は 31557600(約1年)です。

公開時の注意が3つあります。

証明書は mta-sts.example.com で有効なものが必要です。期限切れや名前の不一致があると、送信側はポリシーを取得できません
HTTP のリダイレクトは使えません。送信側はリダイレクトを追いかけない決まりなので、ファイルはそのURLで直接返します
改行コードは CRLF が仕様上の書き方ですが、LF でも読み取る実装がほとんどです。文字コードは ASCII の範囲で書きます

TXT レコードの書き方

ポリシーファイルを公開したら、DNS に TXT レコードを2つ追加します。

_mta-sts.example.com.    TXT  "v=STSv1; id=20261102T0900"
_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

id は、ポリシーの版を表す任意の英数字です(32文字まで)。送信側はこの値が変わったときだけポリシーファイルを取り直します。ポリシーファイルを書き換えたら、id も必ず変えてください。日時を入れておくと、いつ変えたかが分かります。

rua には TLS-RPT のレポートを受け取るアドレスを書きます。届くのは JSON を gzip で圧縮したファイルで、Google などから1日1通程度届きます。共有のメールボックスを1つ作り、そこで受けるのが扱いやすい形です。

testing から enforce へ

最初は必ず mode: testing で始めます。testing では、送信側はポリシーに合わない接続があってもメールを届け、失敗の記録を TLS-RPT で報告するだけです。

1〜2週間レポートを読み、次の点を確認します。

total-failure-session-count(失敗件数)が 0 か、ごくわずかか
失敗の理由に certificate-expired(証明書切れ)や certificate-host-mismatch(ホスト名の不一致)が出ていないか
ポリシーの mx に書き漏れたサーバーがないか

問題がなければ、ポリシーファイルを mode: enforce に書き換え、TXT レコードの id を新しい値に変えます。enforce にすると、送信側は TLS で接続できない場合や証明書が正しくない場合に配送をやめます。メールは送信側のキューに残り、再送が続いたあとで差出人に不達通知が返ります。

enforce にした後で困るのは、メールサーバーの証明書の更新が遅れたときと、メールサービスを乗り換えて MX が変わったときです。どちらも、自社宛てのメールが届かなくなります。乗り換えの予定があるときは、事前に mode: testing に戻し、新しい MX を mx に追加し、id を変えておきます。max_age を長くしていると、送信側は古いポリシーをその期間覚えているため、戻すのにも時間がかかります。運用に慣れるまでは 86400(1日)から 604800(1週間)程度にしておくと安全です。

やめたいときは、mode: none のポリシーを公開して id を変え、max_age が過ぎてからレコードを削除します。いきなり消すと、送信側は覚えている古いポリシーで判定を続けます。

Google Workspace で使う場合

Google Workspace は、管理コンソールで MTA-STS のポリシーをホストしてくれるわけではありません。ポリシーファイルは自社で公開します。

MX の値は契約時期によって異なります。最近の設定では smtp.google.com の1件、以前からの設定では aspmx.l.google.com と alt1.aspmx.l.google.com などの複数件です。複数件の場合は、ポリシーに次のように書きます。

mx: aspmx.l.google.com
mx: *.aspmx.l.google.com

*.google.com と書いても alt1.aspmx.l.google.com には一致しません。ワイルドカードは1段分しか置き換えないためです。

Google の送信サーバーは MTA-STS に従い、TLS-RPT のレポートも送ってきます。Gmail や他社の Google Workspace から自社宛てに送られたメールの結果が、このレポートに入ります。

Microsoft 365 で使う場合

Microsoft 365 の MX は、通常 example-com.mail.protection.outlook.com の形です。ポリシーには次のように書けます。

mx: *.mail.protection.outlook.com

Microsoft 365 でも、ポリシーファイルの公開は自社で行います。Microsoft はこのファイルをホストする方法を手順として案内していますが、どの方法でも mta-sts.example.com の証明書の管理は自社の責任です。

また、Microsoft 365 は受信サーバーのホスト名を新しい形式に移行させる取り組みを進めています。テナントの MX が mail.protection.outlook.com 以外のホスト名に変わった場合は、ポリシーの mx も合わせて直す必要があります。MX を変更したら、ポリシーを確認する作業を手順に入れておいてください。

設定したかを確かめる

最低限、次の3点を確認します。

https://mta-sts.example.com/.well-known/mta-sts.txt をブラウザで開き、証明書の警告なしに4行が表示されるか
DNSレコード確認で _mta-sts と _smtp._tls の TXT レコードが見えるか
数日後に TLS-RPT のレポートが届き始めたか

メールの認証全体の状態は、メールの実測でドメインを入れると外から確認できます。SPF と DMARC が未設定なら、MTA-STS は後回しで構いません。なりすましの被害に直結するのは SPF と DMARC の方です。手順は SPF・DKIM・DMARCの設定方法にあります。

確認に使えるツール

メールの実測: 自社ドメインのメール設定を外から実測します
DNSレコード確認: TXT レコードが登録されているかを確認します
SSL証明書チェック: mta-sts サブドメインとメールサーバーの証明書の期限を確認します