DKIMセレクタと署名鍵のローテーション手順｜旧鍵を止めずに公開鍵を切り替える方法

自社ドメインからメールを送る仕組みは、Google WorkspaceやMicrosoft 365だけとは限りません。MA、CRM、問い合わせフォーム、採用管理、請求、サポートなどがそれぞれDKIM署名を付けていると、どの送信元がどのセレクタと秘密鍵を使っているか分からないまま鍵の更新日を迎えやすくなります。

DKIMの計画的なローテーションは、新しい鍵を生成してすぐ旧鍵を消す作業ではありません。 新しいセレクタの公開鍵をDNSへ先に登録し、DNSから取得できることを確認してから署名元を切り替え、全送信元の実メールで新しいs=とdkim=passを確かめます。旧公開鍵は、移行前のメールを受信側が検証できる期間を残したうえで削除します。

旧公開鍵を削除する合図は、新しいセレクタを設定した時ではなく、すべての正規送信元が新しい署名へ切り替わり、旧鍵の検証が不要だと確認できた時です。

---

本記事のポイント

1. DKIM鍵の更新では、既存セレクタを上書きせず、新しい鍵に新しいセレクタを割り当てて新旧公開鍵を並行公開します。
2. 切替確認は管理画面の表示だけで終えず、全送信元の外部受信メールでd=、s=、dkim=passを照合します。
3. 旧公開鍵は旧秘密鍵の利用停止後も合理的な検証期間を残し、未切替送信元と遅延メールがないことを確認してから削除します。

---

DKIMセレクタと署名鍵をローテーションする理由

DKIMは、送信側が秘密鍵でメールへ署名し、受信側がDNSに公開された公開鍵で署名を検証する仕組みです。メールヘッダーのDKIM-Signatureには、署名ドメインを示すd=と、公開鍵を探す名前を示すs=が入ります。受信側は通常、<selector>._domainkey.<domain>のDNSレコードから公開鍵を取得します。

RFC 6376は、同じ署名ドメインで複数の公開鍵を同時に扱えるようにセレクタを定義しています。新しい鍵へ切り替えるときは、新旧の公開鍵を移行期間中に並行公開し、送信側を新しい秘密鍵へ切り替えた後、旧公開鍵を合理的な検証期間だけ残す考え方です。既存セレクタの公開鍵を別の鍵で上書きすると、過去メールが旧鍵だから検証できないのか、改ざんされたのかを区別しにくくなるため、新しい鍵には新しいセレクタを割り当てます。

RFC 5863も、鍵素材を定期的に更新し、鍵ペアの生成、DNS公開、登録確認、署名開始、旧秘密鍵の利用停止、旧公開鍵の将来日削除までをライフサイクルとして管理するよう示しています。更新日だけを決めても、送信元台帳、DNS権限、実メール検証、切り戻しがなければ安全なローテーションにはなりません。

要素	ローテーション時の扱い	避けたい変更
秘密鍵	新しい鍵を署名基盤で生成・保護し、段階切替後に旧鍵の利用を止める	秘密鍵をDNS、チケット、メール、共有文書へ貼り付ける
公開鍵	新しいセレクタ名でDNSへ先に公開し、取得確認後に署名を切り替える	旧セレクタの値をその場で上書きする
セレクタ	鍵ごとに一意な名前を使い、送信元台帳と対応付ける	同じセレクタ名を別の鍵へ再利用する
鍵長・方式	利用サービスとDNS事業者の対応を確認し、RSAなら2048ビットを優先する	受信側・DNS側の対応を見ずに方式や長さだけ変更する

RFC 8301は、RSA鍵について署名側に最低1024ビットを要求し、少なくとも2048ビットを推奨しています。したがって1024ビットから2048ビットへの移行には意味がありますが、鍵長だけを伸ばしても、所有者不明の秘密鍵や未確認の送信経路が残れば運用リスクは解消しません。

変更前にそろえる送信元台帳と判断表

最初に、表示Fromだけでなく、実際にDKIM署名を付けるすべての送信元を洗い出します。対象には、従業員メール、メール配信、MA、CRM、問い合わせ通知、電子契約、請求、採用、監視通知、委託先の配信基盤を含めます。外部受信箱で各経路のメール原文を保存し、d=、s=、Authentication-Results、送信サービス、管理者、DNS管理者を一行で結び付けます。

DKIMの鍵更新は、送信サービスごとに操作方法が異なります。自社MTAで秘密鍵を持つ場合、Google Workspaceの管理画面で鍵を生成する場合、Microsoft 365が二つのセレクタを交互に使う場合、配信サービスがCNAME先で鍵を管理する場合を同じ手順書へ混ぜないことが重要です。

確認項目	進めてよい状態	保留する状態
送信元の範囲	正規送信元ごとにd=、s=、管理者、用途が分かる	現在のセレクタを一つのテストメールだけで推測している
DNSの管理	登録先、権限者、TTL、変更前値、反映確認方法が決まっている	委託先と自社のどちらが公開鍵を管理するか不明
新旧併用	新しいセレクタを追加し、旧公開鍵を残したまま切り替えられる	同じ名前のTXTを即時置換する手順しかない
確認経路	複数の外部受信先と送信元ごとのテストが用意されている	管理画面の「有効」表示だけを合格条件にしている
切り戻し	旧秘密鍵が安全な計画更新であり、戻す条件と責任者を記録済み	漏えいが疑われる旧秘密鍵へ戻す想定になっている

鍵の漏えい・不正利用が疑われる緊急更新と、期限・方針に基づく計画更新も分けます。計画更新なら旧鍵を短期間の切り戻しに使える場合があります。一方、侵害が疑われる旧秘密鍵は安全な復旧先ではありません。影響する送信を止め、鍵の失効・公開鍵の扱い、受信側での拒否影響をインシデント対応として判断します。

新旧セレクタを安全に切り替える7段階

1. 変更範囲と合格条件を固定する。 対象ドメイン、送信サービス、現在のd=とs=、DNS値、鍵の作成日、担当者を保存します。合格条件は「新しいDNSレコードが見える」ではなく、すべての正規送信元で新しいセレクタの署名が検証されることにします。
2. 新しい鍵ペアと新しいセレクタを作る。 秘密鍵は署名サービスまたは保護された鍵管理領域で生成し、担当者の端末や共有文書へ配布しません。日付だけに依存しない一意なセレクタ名を使い、旧セレクタを再利用しません。
3. 新しい公開鍵をDNSへ先に登録する。 TXTまたはベンダー指定のCNAMEを追加し、旧公開鍵は残します。権威DNSと複数の外部DNSリゾルバから、新しい名前・値・レコード種別を確認します。
4. 署名開始前の取得確認を行う。 セレクタ名の入力ミス、改行・引用符、CNAMEの向き、DNSSECエラー、委任先の不一致を確認します。公開鍵を取得できない状態で新しい秘密鍵を使い始めると、受信側では署名を検証できません。
5. 一つの送信元から新しい署名へ切り替える。 可能なら低リスクな送信経路またはテスト対象から始め、外部受信箱でDKIM-Signatureのd=とs=、Authentication-Resultsのdkim=pass、DMARCのalignmentを確認します。本文変更を行う中継ゲートウェイがある場合は、通過後の結果を見ます。
6. 全送信元へ展開して未切替を監視する。 業務メール、MA、CRM、通知サービスなどから代表メールを送り、送信ログと受信ヘッダーを照合します。DMARC集計レポートでも、旧セレクタ、新セレクタ、認証失敗、未知の送信元が残っていないかを継続確認します。
7. 旧秘密鍵を止め、検証期間後に旧公開鍵を削除する。 まず旧秘密鍵での署名を停止し、送信キュー、遅延メール、再送、全送信元の切替を確認します。旧公開鍵はすぐ消さず、移行前メールを受信側が検証できる合理的な期間を残します。削除後も旧セレクタが新しいメールへ現れないこと、新セレクタがpassしていることを確認します。

DNSのTTLが切れたことだけを旧公開鍵の削除条件にしないでください。RFC 6376は、受信側がメールを後から検証する可能性を考慮し、旧公開鍵を合理的な検証期間だけ保持するよう示しています。組織では、最大送信遅延、キューの再送期間、メールセキュリティ製品の保留、検証ログの観測周期を踏まえて保持期間を決めます。

配信経路が多い場合は、トランザクションメールとマーケティングメールの分離設計に沿って、用途ごとに送信責任と監視を分けると、未切替の経路を見つけやすくなります。SPFを含む送信元全体の依存はSPFのDNSルックアップ監視と同じ送信元台帳で管理できます。

Google Workspace・Microsoft 365での確認点と切り戻し

Google Workspaceは別のプレフィックスセレクタを使う

Google Workspace管理者ヘルプでは、管理コンソールで新しいDKIMレコードを生成し、DNSへ公開した後に認証を開始します。既に既定のgoogleセレクタを使っている場合は別のプレフィックスを入力できます。DNS事業者が対応するなら2048ビットを選び、公開鍵が取得できることを確認してから「認証を開始」へ進みます。

確認は自組織内だけの自己送信で終えず、外部のGmailまたはGoogle Workspace受信先へ送り、メッセージ原文でdkim=passと新しいs=を見ます。管理画面の状態反映には時間がかかる場合があるため、表示と実メールの両方を記録します。旧セレクタのDNSレコードは、切替後の検証期間が終わるまで残します。

Microsoft 365は二つのCNAMEと交互のセレクタを確認する

Microsoft LearnのDKIM設定ガイドでは、カスタムドメインに二つのCNAMEを用意し、selector1とselector2を交互に使います。管理画面またはRotate-DkimSigningConfigでローテーションし、Get-DkimSigningConfigのSelectorBeforeRotateOnDate、SelectorAfterRotateOnDate、RotateOnDate、鍵長を確認します。

2026年8月時点の同ガイドでは、ローテーション開始から新しい秘密鍵で署名するまで96時間かかり、その間は旧秘密鍵が使われると説明されています。処理中にもう一度ローテーションせず、表示された切替日時を基準に前後のメールヘッダーを保存します。1024ビットから2048ビットへ変更する場合は、最初のローテーションで次のアクティブ側だけが2048ビットになり、もう一方は次回のローテーションで更新される点も確認します。

問題が出たときの切り戻し

計画更新で新しい鍵の署名に失敗した場合は、旧公開鍵を削除せず、旧秘密鍵が安全で利用可能なら署名側を旧セレクタへ戻します。同時に、新しい公開鍵のDNS登録は原因調査が終わるまで残して構いません。DNS削除と署名切替を同時に戻すと、どちらが原因だったか分かりにくくなります。

観測した問題	最初に確認すること	切り戻し判断
新セレクタが見つからない	DNS名、TXT/CNAME、委任、DNSSEC、外部リゾルバの応答	新鍵での署名開始前なら開始を延期する
新セレクタだがDKIM fail	公開鍵と秘密鍵の組、署名後の本文・ヘッダー変更、鍵方式	旧鍵が安全なら署名を旧側へ戻す
一部サービスだけ旧セレクタ	サービス別設定、キュー、送信ノード、委託先の切替状況	旧公開鍵を残し、未切替経路を止めずに修正する
DMARCだけfail	DKIMのd=と表示Fromのalignment、SPF結果	鍵を戻す前に署名ドメインの設定を確認する

旧鍵の利用停止後も、メール到達率の監視で認証失敗、拒否、迷惑メール率を追います。ローテーションと同時にFromドメイン、Return-Path、配信IP、送信量を変えると原因を切り分けにくいため、可能な限り別の変更として実施します。

DKIM鍵ローテーションでよくある質問

関連ページと関連記事

• メールマーケティングの全体像
• メール到達率を改善する方法
• DMARC集計レポートの読み方
• SPFのDNSルックアップ監視
• トランザクションメールとマーケティングメールの分離設計