DKIMメール認証運用Web 担当者

DKIM鍵を2048ビットへ更新する手順

2026年5月6日ドメイン番人約 5 分で読めます

この記事でわかること

DKIM 鍵を 1024 ビットから 2048 ビットへアップグレードする必要性
主要メールサービス別のアップグレード手順
2048 ビット鍵の TXT レコード分割記述と切り替え時の注意

なぜ 1024 ビット鍵では不十分なのか

DKIM(DomainKeys Identified Mail)は RSA 鍵による電子署名でメールの改ざんを防ぐ仕組みです。鍵長は短いほど計算負荷が軽い一方、暗号解読への耐性も弱くなります。

NIST Special Publication 800-57 では、RSA 1024 ビットは 2030 年まで「レガシー扱い」とされ、新規導入では 2048 ビット以上が推奨されています。RFC 8301(2018 年)も DKIM について 「1024 ビット以上、2048 ビットを推奨」と明記しました。

さらに Google は 2024 年以降、Gmail 受信側で 1024 ビット鍵を「弱い署名」として段階的に警告対象に含めると公表しています。Microsoft 365 でも新規テナントは 2048 ビット既定で生成される仕様に変更されました。

DKIM の基本的な仕組みはDKIM 設定の確認方法、DMARC との関連はDMARC とは何かも参考にしてください。

1024 ビット鍵と 2048 ビット鍵の比較

鑑査対応の文脈での 2048 ビット要件

ISMS(ISO/IEC 27001)や SOC 2 Type II の鑑査では、暗号アルゴリズムの選定基準が問われます。NIST や CRYPTREC の推奨に沿った構成かを確認されるため、1024 ビット鍵が残ったままだと指摘事項になりやすい領域です。

特に 2026 年以降は「金融機関向け取引基準」「業界共通のセキュリティチェックシート」でも 2048 ビット必須化が進んでおり、取引先からのセキュリティ質問票に「DKIM 鍵長を回答してください」という項目が増えています。先回りで 2048 ビット化を済ませておくと、後からの差し替え工数を削減できます。

サービス別アップグレード手順

主要メールサービスでの再生成手順は以下の通りです。

サービス別 DKIM 鍵アップグレード 4 ステップ

Google Workspace

管理コンソール > アプリ > Google Workspace > Gmail > 「メールの認証」を開く
対象ドメインを選択し「新しいレコードを生成」をクリック
「DKIM 鍵のビット長」で 2048 を選択(既定が 1024 のままになっていることがあるため確認必須)
表示された TXT レコードをドメインの DNS に登録 → 反映後「認証を開始」

セレクタは Google の場合 google 固定です。再生成しても同じセレクタ名で公開鍵が更新される設計のため、既存セレクタの管理に悩まなくて済みます。

Microsoft 365(Exchange Online)

PowerShell の Exchange Online module から以下を実行します。

# 既存の DKIM 設定を確認
Get-DkimSigningConfig -Identity "example.co.jp"

# 2048 ビットへローテーション
Rotate-DkimSigningConfig -Identity "example.co.jp" -KeySize 2048

Rotate-DkimSigningConfig は内部で新セレクタ(selector1 → selector2 等)へ切り替え、古いセレクタも一定期間 DNS に残す挙動です。CNAME レコードを Microsoft 側のホスト名に向ける構成なので、DNS の TXT 文字数制限を意識せずに済むのが利点です。

SendGrid

管理画面 Settings > Sender Authentication > 対象ドメインの「Edit」
「Use a custom DKIM selector」と「Use a 2048-bit DKIM key」にチェック
表示された CNAME レコード(s1._domainkey、s2._domainkey)を DNS に登録
「Verify」を実行 → 検証完了後、SendGrid 側で自動的に新鍵での署名へ切り替わる

旧設定が残っている場合は新規 Domain Authentication を作成し、確認後に旧設定を Delete する流れが安全です。

TXT レコードの 255 文字問題

2048 ビット鍵の公開鍵を Base64 エンコードすると約 380〜420 文字になります。一方、DNS の TXT レコードは 1 文字列あたり 255 文字制限があるため、そのままでは入りきりません。

解決策は、TXT を 複数の文字列に分割して登録する方式です。BIND ゾーンファイルでは以下のような書式になります。

selector._domainkey IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhk..."
                              "...続きの Base64 文字列..." )

DNS 側がこれらを連結して 1 つの TXT として配信するのが RFC 7208 / 6376 の定める動作です。ただし DNS プロバイダによっては入力フォームが分割記述に対応していないことがあります。

プロバイダ	分割対応	備考
Cloudflare DNS	自動分割	1 行貼り付けで OK
AWS Route 53	手動分割	`"..." "..."` の書式で入力
Google Cloud DNS	自動分割	単一フィールド入力
お名前.com	制限あり	255 文字超で切られる事例あり
Xserver Domain	自動分割	管理画面で連結処理

設定後は dig TXT selector._domainkey.example.co.jp で実際の応答を確認し、Base64 全文が連結されて取得できるかをチェックしてください。

切り替え時の安全な進め方

新鍵への切り替えは、配信中のメールを止めないよう 新旧セレクタの併存期間を必ず設けます。

新セレクタ(例: s2026)で 2048 ビット鍵ペアを生成
新セレクタの公開鍵を DNS に登録(旧セレクタはそのまま残す)
メールサーバーの署名設定を新セレクタに切り替え
1〜2 週間新旧両方を DNS に残し、DMARC レポートで dkim_align: pass が安定することを確認
旧セレクタの DNS レコードを削除

通常のローテーション全般の手順はDKIM 鍵ローテーションの手順も併読してください。本記事は鍵長の強化に特化していますが、運用フローは共通です。

自社の状況を確認してみませんか

設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。