DKIM鍵のローテーションとは、メールに署名する鍵ペアを、定期的に、またはセキュリティ上の懸念が生じたときに、認証を壊さずに置き換えることです。操作を誤ると正当なメールが失敗するため危険に思えますが、DKIMの設計上、手順は単純です。セレクターを使えば、古い鍵の隣に新しい鍵を公開し、署名を切り替え、古い鍵はあとで廃止できます。本ガイドではその仕組みを説明し、手順を順を追って示します。
DKIM署名とセレクターの仕組み
プラットフォームがメッセージを送信する際、秘密鍵で署名を作成してヘッダーに追加します。署名には、署名ドメイン(d=)とセレクター(s=)が記載されます。受信側はこれらから selector._domainkey.domain というDNS名を組み立て、そこに公開されている公開鍵を取得して署名を検証します。鍵が一致し、署名対象の部分が変更されていなければ、DKIMは通過します。
DKIM-Signature: v=1; a=rsa-sha256; d=mail.example.com; s=2026a;
h=from:to:subject:date:message-id; bh=...; b=...この例ではセレクターは2026aなので、受信側は 2026a._domainkey.mail.example.com を参照します。セレクターはお客様が自由に選べるラベルにすぎないため、複数を同時に公開できます。これがローテーションの要点です。古いセレクターは古いメールの検証を続け、新しいセレクターが新しいメールに署名します。
なぜローテーションするのか
- 露出を抑える。何年も存在している秘密鍵は、より多くのシステムや人の目に触れています。ローテーションにより、過去の漏えいの影響を限定できます。
- 人事異動に対応する。鍵にアクセスできた管理者が退職した場合、鍵を置き換えることで残存するリスクを取り除けます。
- より強い鍵へ移行する。古いドメインの多くは、今も1024ビットの鍵を公開しています。ローテーションはアップグレードに最適な機会です。
- ポリシーを満たす。セキュリティレビューや一部のお客様のアンケートでは、鍵の更新頻度が問われます。
- 手順に慣れておく。年に2回ローテーションしているチームは、緊急時のローテーションにも落ち着いて対応できます。
ローテーションは到達率向上の手段ではありません。鍵を変えるだけでは、受信箱への配信率は上がりません。目的はセキュリティと衛生管理です。配信に悪影響が出ないよう慎重に行い、評価の向上は期待しないでください。
鍵長の選び方
DKIMの標準は、署名側の最低限として1024ビットを定め、2048ビットを推奨しています。検証側は、1024ビット未満の鍵を受け入れる必要はありません。ほとんどの送信者にとって、現在妥当な選択は2048ビットのRSAであり、大きな性能コストをかけずに十分な余裕が得られます。
| 鍵長 | 位置づけ | 実務上の注意 |
|---|---|---|
| 512ビット | 不可 | 破られているとみなされ、最近の受信側は拒否する |
| 1024ビット | 最低限は許容、現在も一般的 | 動作するが、次回のローテーションでアップグレードする |
| 2048ビット | 推奨 | TXT値を複数の文字列に分割するか、CNAMEが必要 |
| 4096ビット | 標準では許容 | 必要になることはまれで、レコードが実用的なDNSサイズの上限を超える可能性がある |
255文字の制限
TXTレコード内の1つの文字列には最大255文字しか入らず、2048ビットの公開鍵はそれより長くなります。そのためレコードには複数の引用符付き文字列が含まれ、受信側がそれらを連結します。ほとんどのDNSプロバイダーは、長い値を貼り付けるとこれを処理してくれます。そうでない場合は、手動で分割するか、送信プラットフォームにCNAMEのオプションを問い合わせてください。
2026a._domainkey.mail.example.com. TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
"...rest of the public key..." )開始前に:鍵管理の2つのモデル
| モデル | 仕組み | ローテーションのためにすること |
|---|---|---|
| プラットフォーム管理(CNAME) | セレクターからプラットフォームが管理する名前へのCNAMEを公開し、その先の鍵はプラットフォームが変更する | ほぼ不要。スケジュールを確認し、CNAMEが維持されていることを確かめる |
| お客様管理(TXT) | お客様が公開鍵を自分で公開し、プラットフォームは提供された、または生成した秘密鍵で署名する | 以下の手順をすべて実施する |
| 自社運用の署名 | 自社のメールサーバーが署名し、秘密鍵はお客様が保持する | 鍵を生成し、サーバー設定とDNSを更新する |
安全なローテーションの手順
- セレクターを洗い出す。ドメインの _domainkey 配下に公開されているすべてのセレクターを一覧にし、それぞれをどのシステムが使っているかを特定します。不明なセレクターは、それ自体が調査対象です。何が署名に使っているか分かるまで削除しないでください。
- 命名規則を決める。2026aや2027aのように日付や連番を含むセレクターを使うと、鍵を一目で区別できます。
- 新しい鍵を生成する。2048ビットの鍵ペアを作成するか、プラットフォームに発行を依頼します。秘密鍵は、署名システムが必要とする場所にのみ保管してください。
- 新しい公開鍵を公開する。新しいセレクターのレコードを追加します。古いレコードには手を触れないでください。ネットワークの外部から名前解決できることを確認します。
- 切り替える前にテストする。新しいセレクターでテストメッセージに署名し、受信したヘッダーでDKIMが通過していることを確認します。
- 署名を切り替える。署名の設定を変更し、すべての新しいメッセージで新しいセレクターを使うようにします。この時点から、古い鍵は新規には何も署名しません。
- 監視する。その後数日間、DMARC集計レポートとバウンスのデータで、DKIM失敗の急増がないか確認します。
- 残りのメールを待つ。古いレコードは少なくとも数日間は公開したままにします。キュー内、再送中、転送中のメッセージは、送信時ではなく処理時に検証されます。
- 古い鍵を廃止する。古いセレクターのレコードを削除し、保持しているすべてのシステムから古い秘密鍵を削除します。
- ローテーションを記録する。日付、新しいセレクター、次回のローテーション日を運用手順書に記録します。
古い鍵をどれくらい残すか
古い公開鍵は、その鍵で署名されたメールが配送中または検証待ちの状態でなくなるまで、DNSに残す必要があります。通常のトランザクションメールやマーケティングメールであれば、数日で十分です。メーリングリストやメッセージを保留する転送サービスを経由する場合や、再送スケジュールが長い場合は、より長く待ってください。古い鍵を少し長く公開しておいても、コストはかかりません。早く削除しすぎると、原因の特定が難しい失敗を招きます。
起こりうる問題と見つけ方
| 問題 | 兆候 | 対処 |
|---|---|---|
| セレクターの不一致 | DKIMが「鍵が見つからない」で失敗する | 署名の s= の値とDNS名を比較する |
| 公開鍵の切り詰め | DKIMが「不正な鍵」または署名の不一致で失敗する | 鍵を貼り直し、すべての文字列パーツがそろっているか確認する |
| 古い鍵を早く削除した | 遅延したメールでのみ失敗する | 古いレコードを復元し、次回はより長く待つ |
| 署名が切り替わっていない | 新しいセレクターがヘッダーに現れない | 署名の設定とキャッシュされた設定を確認する |
| 2つのシステムが同じセレクターを共有している | 一方のシステムがローテーションしたあと、断続的に失敗する | システムごとに専用のセレクターを割り当てる |
| クリーンアップ中にCNAMEを削除した | プラットフォーム管理の鍵で、突然あらゆる場所でDKIMが失敗する | 提供されたとおりにCNAMEを復元する |
レポートで成功を確認する
DMARC集計レポートでは、送信元ごとに、DKIMとSPFを通過した件数と失敗した件数が分かります。ローテーションの数日後に確認してください。うまくいった場合は、新しいセレクターが現れ、失敗件数が横ばいのままになります。特定の送信元で失敗が増える場合は、すでに公開されていない鍵でまだ署名している可能性があります。読み方はDMARC集計レポートのガイドで解説しています。
緊急時のローテーション
秘密鍵が露出した疑いがある場合は、ただちにローテーションし、重複期間を短くしてください。安全に可能な限り素早く新しい鍵を公開して切り替え、遅延したメールの一部が失敗するとしても、侵害された鍵を削除します。古い秘密鍵を持つ攻撃者は、公開鍵が公開されている限り、お客様のドメインでDKIMを通過する偽造メールに署名できてしまいます。そのため、少数の遅延メールが失われることよりも、露出している期間のほうが重要です。DMARCの強制適用とrejectポリシーは、そうした偽造メールによる被害を抑えますが、それでも鍵は速やかに廃止すべきです。
ローテーションを定常業務にする
- ローテーションの日付を、担当者名とともに共有カレンダーに登録します。
- セレクター、それを使うシステム、作成日の一覧表を保管します。
- 送信システムごとに専用のセレクターを使います。
- DKIMの失敗率にアラートを設定し、不適切なローテーションを数時間以内に検知できるようにします。
- チームにとって初めての手順であれば、まずリスクの低いサブドメインで練習します。
ローテーションの計画でお困りですか?お使いのドメインと送信システムをお知らせください。安全な進め方をご提案します。
参考資料と出典
よくある質問
DKIMセレクターとは何ですか?
セレクターは、受信側にどの公開鍵を取得すべきかを伝えるラベルです。署名にはセレクターとドメインが記載され、受信側は selector._domainkey.domain のDNSレコードを参照します。セレクターが名前の一部であるため、1つのドメインで複数の鍵を同時に公開でき、これがローテーションを安全にしています。
DKIM鍵はどれくらいの頻度でローテーションすべきですか?
必須とされる単一の間隔はありません。多くの組織は年に1〜2回、または秘密鍵にアクセスできる担当者が退職したときや、漏えいが疑われるときにローテーションします。実際に守れるスケジュールを選び、鍵が露出した疑いがある場合はそれより早く行ってください。
どのDKIM鍵長を使うべきですか?
DNSプロバイダーと送信システムが対応している場合は、2048ビットのRSAを使用してください。DKIMの標準では、署名側に最低1024ビットの使用を求め、2048ビットを推奨しており、検証側は1024ビット未満の鍵を受け入れてはならないとされています。鍵が長いほど、計算能力が向上しても余裕を保てます。
2048ビットの鍵がDNSプロバイダーに拒否されるのはなぜですか?
2048ビットの公開鍵は255文字を超えますが、これはTXTレコード内の1つの文字列の上限です。鍵は複数の引用符付き文字列に分割する必要があり、受信側がそれらを連結します。多くのプロバイダーは自動で分割しますが、そうでない場合は手動で分割するか、プラットフォームがホストするレコードへのCNAMEを使用してください。
切り替え直後に古い鍵を削除しても大丈夫ですか?
安全ではありません。メッセージはキューで遅延したり、数日間再送されたりすることがあり、受信側はメッセージを処理する時点で署名を検証します。古いレコードは少なくとも数日間は公開したままにし、転送経路が遅い場合はさらに長く維持してください。
使用中の鍵を削除するとどうなりますか?
そのセレクターで署名されたメッセージは、DKIM検証に失敗します。SPFがアラインしていればDMARCは通過できますが、SPFがアラインしていない場合、DMARCポリシーが適用されていると、メッセージが隔離または拒否される可能性があります。そのため、先に署名を切り替え、古い鍵はあとで削除します。
送信プラットフォームが鍵のローテーションを代行してくれますか?
プラットフォームの中には、DKIM鍵を管理し、お客様が一度設定するCNAME経由で公開するものがあり、その場合はプラットフォーム側でローテーションが行われます。それ以外は、お客様が置き換える必要のある固定レコードを提供します。ローテーションを計画する前に、お使いのプラットフォームがどちらのモデルかを確認してください。
メールストリームごとに異なるセレクターを使うべきですか?
はい、推奨される運用です。トランザクション、マーケティング、社内システムごとにセレクターを分けると、他に影響を与えずに1つだけローテーションや無効化ができ、ヘッダーの分析も分かりやすくなります。
切り替える前に鍵をテストできますか?
はい。まず新しいレコードを公開して名前解決できることを確認し、新しいセレクターで署名したテストメッセージを管理下の受信箱に送り、ヘッダーでDKIMが通過していることを確認してから、すべてのトラフィックを切り替えてください。