MTA-STSとDKIMを併用する設定｜役割の違い・DNSレコードの全体像・メール事業者移行時の順序

MTA-STSとDKIMは、同じドメインで同時に設定しても互いに干渉しません。守っている対象が違うからです。DKIMは「あなたのドメインから送るメール」に署名して改ざんやなりすましを見分けられるようにし、MTA-STSは「他社からあなたのドメインへ届くメール」の配送経路でTLSの暗号化を強制します。この記事では、2つの役割の違いを整理したうえで、併用するときに公開するDNSレコードとファイルの全体像、それぞれの設定と確認の手順、メール事業者を移すときにどの順番で切り替えるかを説明します。

2つの仕組みが守っているもの

まず、よくある誤解を解いておきます。

• DKIMは暗号化ではありません。 メールのヘッダーと本文から作った電子署名を付け、受信側が公開鍵で検証することで、「このドメインが送り、途中で書き換えられていない」ことを確かめられるようにする仕組みです。中身は暗号化されません。
• MTA-STSは送信メールを暗号化する仕組みではありません。 あなたのドメインが公開するMTA-STSは、他社のメールサーバーがあなたのMXへ配送するときに「TLSで、正しい証明書を持つMXにだけ届けてほしい」と伝えるものです。あなたが他社へ送るメールが暗号化されるかどうかは、相手のドメイン側の設定と、あなたの送信サーバーの対応によります。

整理すると、次のような分担になります。

• 送信（あなた → 相手）：DKIMで署名し、SPF・DMARCと組み合わせて認証する。
• 受信（相手 → あなた）：MTA-STSで配送経路の暗号化を強制し、TLS-RPTで結果を報告してもらう。

両方を設定すると、送信の信頼性と受信の安全性を別々に高められます。片方を設定したからもう片方は不要、という関係ではありません。

公開するDNSレコードとファイルの全体像

DKIMとMTA-STSを併用するドメインでは、おおむね次のものを公開します。名前が似ていて取り違えやすいので、一覧にしておくと設定や棚卸しのときに役立ちます。

; 送信側（DKIM と関連する認証）
s1._domainkey.example.com.   TXT  "v=DKIM1; k=rsa; p=（公開鍵）"
example.com.                 TXT  "v=spf1 include:_spf.mail-provider.example ~all"
_dmarc.example.com.          TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

; 受信側（MTA-STS と TLS-RPT）
_mta-sts.example.com.        TXT  "v=STSv1; id=20261018a"
_smtp._tls.example.com.      TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
mta-sts.example.com.         A    （ポリシーファイルを置くWebサーバー）

; ファイル
https://mta-sts.example.com/.well-known/mta-sts.txt

DKIMのセレクター（例の s1）は、送信サービスやメールサーバーごとに決まります。複数の送信元があれば、セレクターも複数になります。一方、MTA-STSのTXTレコードとポリシーファイルはドメインに1組です。

DKIMの設定：送信元ごとに署名を用意する

DKIMは送信元ごとに設定します。代表的な送信元と、設定する場所は次のとおりです。

• Google Workspace や Microsoft 365 などのメールサービス：各サービスの管理画面でDKIMを有効にし、表示されたTXTまたはCNAMEレコードをDNSに追加します。
• 自社運用のPostfixなど：OpenDKIMなどで鍵を作り、署名を設定します。
• WordPressからの通知メール：WordPress本体は署名しません。SMTPプラグインで外部の送信サービスにつなぎ、その送信サービス側で自社ドメインのDKIMを設定します。

設定後は、テストメールを受け取ってヘッダーの Authentication-Results を確認します。dkim=pass で、署名ドメインが差出人アドレスのドメインと一致していれば正しく動いています。DNSに公開した鍵は次のように確認できます。

dig s1._domainkey.example.com TXT +short

MTA-STSの設定：受信側のMXに合わせる

MTA-STSの設定で中心になるのは、ポリシーファイルの mx: に、実際のMXをすべて書くことです。

dig example.com MX +short

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

Google Workspace や Microsoft 365 のように、MXが事業者のホスト名になっている場合は、そのホスト名を書きます。mx: *.mail.example.net のように、先頭のラベルだけをワイルドカードにする書き方も仕様で認められています。事業者がMTA-STS用の推奨値を案内している場合は、それに従ってください。案内の有無や内容、管理画面での設定の可否は事業者ごとに異なり、変わることもあります（2026年10月現在）。

ポリシーファイルは https://mta-sts.example.com/.well-known/mta-sts.txt で配信します。注意点は次のとおりです。

• mta-sts.example.com 用の有効な証明書が必要です。サブドメインのDNSレコードを作り、Webサーバー側にもそのホスト名の設定と証明書を用意します。
• 送信側はリダイレクトをたどりません。WordPressと同じサーバーに置く場合、サイト全体のリダイレクト設定（www 付きへの転送など）がこのサブドメインにも効いていないか確認します。
• Content-Type は text/plain にします。
• 仕様では各行の区切りをCRLFとしています。LFでも読める実装は多いものの、仕様に合わせておくと無難です。

curl -sv https://mta-sts.example.com/.well-known/mta-sts.txt

で、200が返り、中身が意図どおりかを確認します。最初は mode: testing で公開し、TLS-RPTのレポートで失敗が無いことを確かめてから mode: enforce に進みます。

併用で気をつけたい点

設定そのものは独立していますが、運用では次の点で両方に目を配る必要があります。

• 証明書の更新：MTA-STSを enforce にすると、MXの証明書が期限切れになった時点で、他社からのメールが届かなくなります。DKIMには証明書は関係しませんが、鍵の入れ替えを定期的に行うなら、証明書の更新と同じ運用表で管理すると漏れにくくなります。
• レポートの宛先：DMARCの集計レポート（rua）とTLS-RPTのレポートは別物で、宛先も別に指定します。同じ受信箱に集める場合は、件名や送信元で振り分けておきます。
• 宛先が同じドメインであることのリスク：MTA-STSの設定ミスで受信が止まると、同じドメイン宛てのTLS-RPTやDMARCのレポートも届かなくなる可能性があります。レポートの宛先に別ドメインのアドレスを併用しておくと安心です。

メール事業者を移すときの順序

メールサービスを別の事業者に移す場面は、両方の設定がいちばん崩れやすいタイミングです。次の順序で進めると、送信・受信のどちらも途切れにくくなります。

1. 新しい送信元のDKIMを先に公開する。 新しい事業者のセレクターでDKIMレコードを追加します。古いセレクターは残したままにします。SPFにも新しい事業者を追加します。
2. MTA-STSのポリシーに新しいMXを追加する。 mx: に新旧両方のMXを書き、_mta-sts のTXTレコードの id を更新します。enforce で運用中なら、この時点で testing に戻しておくと、移行中の思わぬ失敗で受信が止まるのを避けられます。
3. 送信側のキャッシュが入れ替わるのを待つ。 旧ポリシーの max_age の間は、古いポリシーを持つ送信側が残ります。
4. MXレコードを切り替える。 新しい事業者のMXに向けます。
5. レポートで確認する。 DMARCの集計レポートで新しい送信元が dkim で合格しているか、TLS-RPTで新しいMXへの配送が成功しているかを確認します。
6. 古い設定を片付ける。 古いMXをポリシーから外して id を更新し、旧事業者からの送信が無くなったことを確認してから、古いDKIMセレクターとSPFの記述を削除します。

DNSを変更する前には、各レコードの現在の値を控えておきます。TTLを事前に短くしておくと、切り替えや戻しが早く行き渡ります。

まとめ

• DKIMは送信メールの署名、MTA-STSは受信時の配送経路の暗号化の強制。守る対象が違うので干渉せず、両方設定して意味がある。
• DKIMは送信元ごとのセレクター、MTA-STSはドメインに1組のTXTレコードとポリシーファイル。一覧にして管理すると取り違えにくい。
• MTA-STSの mx: には実際のMXをすべて書き、ポリシーファイルはリダイレクトなしのHTTPSで配信する。
• 証明書の更新とレポートの宛先は、両方の運用にまたがる注意点。
• 事業者の移行時は、新しいDKIMとMTA-STSの mx: を先に追加し、MXの切り替えは最後、古い設定の削除は確認後に行う。

• OpenDKIMでDKIM署名を設定する方法
• メールのSTARTTLSによる暗号化の設定