## この記事でわかること

- DKIM 鍵を定期的にローテーションする必要性
- 新旧鍵を共存させながら切り替える 4 ステップ
- 鍵長(1024 bit / 2048 bit)とセレクタ運用のベストプラクティス

## なぜ DKIM 鍵を定期的にローテーションするのか

DKIM(DomainKeys Identified Mail)は、メールに **電子署名**を付けて改ざんがないことを証明する仕組みです。署名には公開鍵暗号(RSA)を使い、

- **秘密鍵**: 送信側のメールサーバーが署名生成に使う
- **公開鍵**: DNS の TXT レコードで公開、受信側が署名検証に使う

この秘密鍵が長期間使い続けられると、暗号攻撃への耐性が低下します。DMARC.org の「Best Practices for Email Senders」でも **年に 1 回以上の鍵ローテーション**が推奨されています。月数千万通以上の大量送信や機密情報メールを扱う場合は、より頻繁な更新が望ましいとされます。

また、[DKIM リプレイ攻撃](/blog/dkim-replay-attack)の被害発生時には、リプレイされ続けている署名を無効化するために**即時の緊急ローテーション**が応急処置になります。鍵長の問題ではなく「正規署名が再送され続ける」状態を断ち切るための運用上の最後の手段です。

DKIM の基本概念は[DKIM 設定の確認方法](/blog/dkim-verification)も参考になります。

![DKIM 鍵ローテーションが必要な理由](/blog/dkim-key-rotation/why-rotate.svg)

## 鍵長: 1024 bit と 2048 bit のどちらにすべきか

RFC 6376 では署名側が **最低 1024 bit**、推奨 1024〜2048 bit 範囲。RFC 8301(2018 年)で **「1024 bit 以上、2048 bit を推奨」**に明確化されました。

実務的な選択:

- **新規導入**: 迷わず **2048 bit** を選ぶ
- **既存 1024 bit 運用**: ローテーションのタイミングで 2048 bit へ昇格
- **2048 bit が DNS に入らない問題**: TXT レコードの 255 文字制限で、2048 bit 鍵は分割記述が必要(複数の文字列に分けて連結)。レジストラの管理画面で対応している必要あり

中小企業のレンタルサーバーや格安 DNS サービスでは、2048 bit 鍵の登録に不具合が出る場合もあります。事前にレジストラのサポート範囲を確認してから進めるのが安全です。

## ローテーションの 4 ステップ

メール配信を止めずに切り替えるには、**新旧鍵をしばらく共存させる**のが基本です。

![DKIM 鍵ローテーションの 4 ステップ](/blog/dkim-key-rotation/rotation-steps.svg)

### ステップ 1: 新しい鍵ペアを生成

新しいセレクタ名(例: `s2026`)で新しい鍵ペアを生成します。

- Google Workspace の場合: 管理コンソール > Gmail > 「DKIM 認証」で新規セレクタを生成
- Microsoft 365: PowerShell で `Rotate-DkimSigningConfig`(Exchange Online)
- 自前サーバー: `openssl genrsa -out new.key 2048` で生成

### ステップ 2: 公開鍵を DNS に登録

新セレクタ用の DNS レコード(`s2026._domainkey.example.co.jp` の TXT)に公開鍵を登録。**この時点では旧セレクタも DNS に残ったまま**。新旧両方が DNS で配信されている状態を作ります。DNS が Cloudflare の環境では、ダッシュボードの DNS Records 画面で TXT を 1 行貼り付けで追加できます。具体的な手順は [Cloudflare DNS で DKIM を設定する手順](/blog/cloudflare-dkim-setup) を参照。

### ステップ 3: 送信側の署名を新セレクタに切り替え

メールサーバーの署名設定を新セレクタに変更。送信メールの DKIM-Signature ヘッダーが `s=s2026` になることを確認。

最低 **1〜2 週間は新旧両方を DNS に残しておく**のが安全。配信中のメールがバウンスから戻ってきたとき、旧セレクタで検証する受信サーバーが残っているため。

### ステップ 4: 旧セレクタを DNS から削除

新セレクタの運用が安定し、配信に問題がないことを確認したら、旧セレクタの DNS レコードを削除。これでローテーション完了です。

## 切り替え期間中のチェック方法

`mail-tester.com` や `dkimcore.org/tools/keycheck.html` のような無料ツールで、DKIM 検証が新セレクタで通ることを確認できます。

また、`/diagnose` でも対象ドメインの DKIM 状態を一括チェックできます。

DMARC レポート(rua)を受信している場合、レポート内の `dkim_align: pass` が新セレクタで安定して出ていれば成功です。レポートの読み方は[DMARC レポートの見方](/blog/dmarc-report-reading)を参照。

## 失敗パターンと回避

### 失敗 1: 切り替え当日に旧セレクタを即削除した

→ 新セレクタの DNS 伝播完了前に旧を消すと、一部の受信サーバーで DKIM fail が出る可能性。**最低 2 週間は併存**が原則。

### 失敗 2: 鍵ペアの秘密鍵をメールサーバーに反映し忘れた

→ DNS には新公開鍵があるが、送信メールはまだ旧秘密鍵で署名 → 検証 fail。設定変更後の **テスト送信を必ず実施**。

### 失敗 3: 2048 bit 鍵が DNS に入りきらない

→ 文字数制限で公開鍵が切れて記録される。レコード登録後、`dig` で実際の TXT を確認し、Base64 全文が取れているかチェック。

## まとめ

- DKIM 鍵は **年に 1 回以上**ローテーション、新規は 2048 bit
- 新旧鍵を **1〜2 週間共存**させてから旧を削除する 4 ステップが基本
- 切り替え後は DMARC レポートと外部ツールで検証

## DKIM の現状を診断

無料の[ドメイン診断](/diagnose)で、現在の DKIM セレクタ・鍵長・検証状態を 3 分でチェックできます。鍵ローテーションを含む継続運用を専門家に任せたい場合はお気軽にご相談ください。