DKIM 鍵: 長さとローテーションの実務ガイド

DKIM 鍵は、送信認証を支える DNS 設定の一部です。弱い鍵、形式の誤り、古い鍵は検証や配送に影響する可能性があります。記事では Gmail の要件が2024 年二月から適用され、2025 年十一月からさらに強化された背景を説明しています。実際には最新の送信者要件を確認してください。DNS の基本を整理中なら、まずビジネスメールを参照してください。

短くまとめると、可能なら 2048 ビットの RSA 鍵を使います。長い TXT は引用符付きの複数文字列として正しく公開し、セレクターを使って計画的に更新します。切り替え後も適切な期間だけ旧レコードを残すことで、運用リスクを減らせます。

新しいドメインでは、独自ドメインのメール作成と TrekMail の必要な DNS レコードを併せて読み、DKIM、SPF、DMARC を一緒に設定してください。

DKIM 鍵とは？

ここでは DKIM 署名の公開鍵を指します。送信サーバーは秘密鍵で署名し、受信側は DNS の公開鍵で署名対象の完全性と署名ドメインの責任を確認します。表示上の From が信頼できることを自動的に証明するわけではありません。

DKIM は DomainKeys Identified Mail の略です。秘密鍵は送信システムに置き、公開鍵をセレクターの下で公開します。例は s1._domainkey.example.com です。

受信側はヘッダーの署名を読み、DNS の鍵を取得し、指定された正規化に従って検証します。成功時に確認できるのは次の点です。

署名対象の本文部分とヘッダーが、検証に影響する形で変更されていない。
署名側が、そのドメインとセレクターに対応する秘密鍵を使えた。

受信トレイへの到達は保証されませんが、フィルターが利用できる暗号学的な検証結果になります。

DKIM 鍵の長さはどれを選ぶ？

2048 ビットの RSA 鍵を、記事が扱う 2025 年と 2026 年の構成でも可能なら使うことを推奨します。標準は 1024 ビットを認めていますが、より強い 2048 ビットを推奨しています。4096 ビットでは DNS 応答が大きくなり、互換性や運用上の問題が増える場合があります。

根拠はRFC 8301です。署名側は最低 1024 ビットの RSA 鍵を使い、少なくとも 2048 ビットを使うことが推奨されています。この推奨を現代の設定に反映してください。

DKIM 鍵の長さ	位置付け	本番環境での意味
512 ビット	使用不可	受信側は有効と扱ってはいけない。交換する。
1024 ビット	従来の最低値	標準で許可されるが、新しい構成の第一候補ではない。
2048 ビット	一般的な推奨	強度と運用負担のバランスがよい。対応は確認する。
4096 ビット	負担が大きい場合が多い	DNS データと失敗要因が増え、実務上の利点は限られる場合がある。

古いメール環境を引き継いだら、鍵も確認します。以前の管理画面は 1024 ビットを既定で生成することがありました。当時許された設定が、今の推奨とは限りません。

Google は一括送信者に DKIM を求め、認証失敗時の制限について FAQ で説明しています。最新の要件はGoogle の送信者ガイドライン FAQを参照してください。

2048 ビット鍵が DNS で問題になる理由

2048 ビットの公開鍵は、TXT の一つの文字列の上限である 255 オクテットを超えます。管理画面が長い値を正しく分割できないと、拒否、切り詰め、誤った保存が起こり得ます。

多くの場合、暗号ではなく DNS の画面が問題です。

2048 ビットの RSA 公開鍵を含む p= は長いため、通常は一つの TXT レコード内で複数の引用符付き文字列に分けます。結合するのは DKIM 検証側やアプリケーションであり、DNS リゾルバーが必ず結合するわけではありません。公開の誤りは検証に影響します。

よくある失敗:

画面が 255 文字で切り詰める。
鍵の中へ不要な空白や改行を追加する。
一つの TXT の複数文字列ではなく、複数の TXT レコードを公開する。
短くしようとして v=DKIM1; k=rsa; p= の一部を削除する。

こうなると弱い鍵ではなく、無効な鍵になります。

2048 ビット DKIM 鍵を正しく公開する

セレクターごとに一意な TXT レコードを作り、その内部だけで文字列を分割します。検証アプリケーションが部分を結合します。構文と実際の DNS 応答をコマンドラインで確認してください。

ゾーンファイルの構文例:

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

多くの Web 画面では同じ値を一行にします。

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

その後、画面のプレビューだけでなく外部から確認します。

dig txt s1._domainkey.example.com +short

完全な TXT 応答が必要です。引用符付きの二つの文字列は正常です。欠落、変なエスケープ、不完全な出力があれば、公開された内容と問い合わせツールを照合してください。

TrekMail では管理された TrekMail SMTPと DNS ウィザードを参照できます。紹介された有料プランには管理された SMTP と、ダッシュボードで示すドメイン固有のDKIM レコードが含まれます。Starter は月額 $3.50 から、有料プランはカードが必要な 14 日間無料試用、Nano は自分の SMTP を使う無料プランと説明されています。最新の機能と条件を確認してください。

例として、2048 ビット鍵を作っても、レジストラが長い TXT を黙って切り詰めることがあります。メールは送信され続け、受信側で認証に失敗して初めて問題が見えます。そのため外部から検証します。

メールへのリスクを抑えて鍵を更新する

新しいセレクターと公開鍵を追加し、署名を切り替え、適切な移行期間は旧レコードを残します。使用中の鍵の直接上書きは避けてください。別名の鍵なら、遅延や再試行された古いメールを検証しやすくなります。

慎重な手順:

新しい 2048 ビット鍵ペアを生成する。
s2 のような新しいセレクターを割り当てる。
s2._domainkey.example.com を DNS に公開する。
送信側の署名を s2 へ切り替える。
s1 を適切な数日間残す。
旧署名メールが鍵を必要としなくなってから s1 を削除する。

移行期間を 7 日とするのは一例で、一般的な保証ではありません。キュー、再試行、DNS キャッシュに応じて決めます。漏えいした鍵では、古いメールの検証より緊急の失効を優先する場合があります。

署名、キャッシュ、遅延メールへの影響を管理できないなら、同じセレクターの鍵を置き換えないでください。鍵を区別するための名前を活用します。

複数の送信システムでは、各セレクターの担当を記録します。同じドメインの CRM、チケット基盤、Web アプリ、メールボックスの障害を調べる際に役立ちます。

DKIM 鍵を更新する時期は？

定期的な更新に加え、秘密鍵の露出、ベンダー変更、送信環境の移行後に対応します。半年ごとの周期は出発点の一つで、高リスク環境では短くすることもあります。場当たり的な変更より予測できる方針が重要です。

秘密鍵が漏れた可能性があれば直ちに対応し、異常がなければ計画どおり更新して検証します。

早めに更新する理由:

送信を別のプロバイダーへ移した。
署名にアクセスできたベンダーを終了した。
安全でない手順で鍵をエクスポートした。
用途の不明な古い共有管理者アカウントを見つけた。

先延ばしにしてはいけない理由:

「時間ができたら後でやる」
「まだ検証を通るから問題ない」
「秘密鍵の場所を覚えていない」

顧客ドメインが多いと、暗号より運用手順の問題になります。だから複数ドメインのメールホスティングが重要です。一つは手作業でも、五十のドメインには明確な流れが必要です。

DKIM に Ed25519 を使うべき？

Ed25519 は鍵が短く、RSA-2048 の長い TXT の問題を減らせます。ただし受信側の対応確認が必要です。DKIM では RFC 8463 で標準化されていますが、幅広い相互運用には RSA-2048 が保守的な出発点になりやすいでしょう。

利点はサイズです。Ed25519 公開鍵は RSA より小さく、DNS で公開しやすくなります。

難点は受信側とツールの実装差です。RSA-2048 は広く使われますが、普遍的な互換性は保証しません。二重署名をサポートする基盤なら、実際の経路で Ed25519 を RSA と併せてテストできます。

多くの運用者には次の方針が適します。

RSA-2048 を優先する基本構成にする。
対応を理解し、十分に検証できる場合に Ed25519 を使う。
DNS が短いという理由だけで Ed25519 のみにしない。

従来と新しい方法: 多数のドメインで DKIM を管理する

従来は各 TXT を手作業で編集し、別々のレジストラ画面へ長い鍵を貼り、更新を忘れないことに頼っていました。新しい方法は、繰り返せる DNS と署名の管理を集約し、鍵のライフサイクルをメール基盤の運用に組み込みます。

従来の方法:

ドメインごとに DNS 画面が違う。
更新は見落とされやすい予定表の通知に頼る。
レジストラの誤記で顧客メールが影響を受け、到達性が下がるまで気づかない。

新しい方法:

多くのドメインで共通の手順を使う。
管理された SMTP で署名設定を揃えやすくする。
長い TXT や認証のずれの繰り返し調査を減らす。

TrekMail はユーザー単位ではない定額の複数ドメインホスティング、共有ストレージ、IMAP、組み込み移行、キャッチオール、転送、Nano の BYO SMTP、有料プランの管理された SMTP を紹介しています。現在の機能は確認してください。転送規則を多数使うなら認証の変化も調べ、ドメインメールを Gmail へ転送も参照します。

チームや代理店にとっての利点は、DNS が必ず成功することではなく、繰り返す作業を標準化できることです。紹介された Starter は月額 $3.50からです。最新の条件を確認してください。