DKIMの鍵長は1024bitで足りるのか｜RFCの要件と実際に公開されている鍵の分布

DKIMを診断すると「セレクタ ○○ の鍵長が 1024 bit です」と表示されることがあります。これは設定が壊れているという意味ではありません。ただ、そのままにしておく理由もありません。

この記事では、RFCが実際に何を要求しているのかを原文で確認し、そのうえで実際にDNSに公開されている鍵がどうなっているかを調べた結果を示します。最後に、2048bitへ切り替える手順を扱います。

鍵長はDNSに公開されている値から測れます

DKIMの公開鍵は、DNSのTXTレコードに p= タグの値として置かれています。この値はRSA公開鍵をBase64にしたもので、そこからRSAのモジュラス（法）のビット長を取り出せます。これが「鍵長」です。

本サイトの診断は、k=rsa の鍵のうちSubjectPublicKeyInfo形式として解析できるものについて、このビット長を表示します。Ed25519（RFC 8463で追加された署名方式）や、それ以外のエンコード形式は鍵長の判定対象外です。

ドメインを診断する

RFCが定めているのは「1024以上、できれば2048」

鍵長の要件はRFC 8301 §3.2に書かれています。RFC 8301はDKIMの基礎仕様（RFC 6376）を更新する文書です。

Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits. Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits, and they MAY be able to validate signatures with larger keys. Verifier policies can use the length of the signing key as one metric for determining whether a signature is acceptable. Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures.

整理すると次のようになります。

注目すべきは、引用の中ほどにある一文です。「Verifier policies can use the length of the signing key as one metric for determining whether a signature is acceptable」とあり、受信側が鍵長を受理判断の材料に使うことも認められています。つまり1024bitは仕様違反ではないものの、受信側の扱いは一律ではありません。

実際に公開されている鍵の分布

Majestic Millionに掲載されている.jpドメイン19,065件について、2026年7月27日にDNSを調べました。診断と同じ手順でメール基盤を判定し、そこから組み立てたセレクタで公開鍵を取得しています（再現用のスクリプトは scripts/measure-dkim-keys.mjs）。

結果は9,571件でメール基盤を判定でき、5,304ドメインから合計9,937件の鍵レコードを取得できました。

数え方で見え方が変わるため、3通りの単位で示します。

取得したレコード単位（9,937件）

公開鍵の重複を除いたあと（8,321件）

事業者が同じ鍵を多数の顧客に配っている場合、レコード単位で数えるとその事業者の顧客数がそのまま反映されます。同じ p= の値を1つと数え直すと次のようになります。

ドメイン単位（5,304ドメイン）

1つのドメインが複数のセレクタを持ち、鍵長が混在していることがあります。そのため合計は100%を超えます。

• 2048bitの鍵を持つ: 4,328ドメイン（81.6%）
• 1024bitの鍵を持つ: 2,265ドメイン（42.7%）

2048bitと1024bitの両方を持つドメインが相当あることになります。鍵の入れ替え中である場合と、古いセレクタが残ったままの場合の両方が考えられます。

この数字について注意すること

• DKIMを使う全ドメインの割合ではありません。 セレクタを判定できた事業者に偏っており、無作為抽出ではありません
• DNSに公開されている鍵の分布であって、いま送信に使われている鍵の分布ではありません。 RFC 6376 §3.1 は、鍵を入れ替える期間に旧鍵と新鍵の両方を公開しておく手順を認めています
• 事業者ごとの内訳では、Google Workspaceを判定した4,656レコードのうち1,325件、Microsoft 365を判定した4,198レコードのうち1,316件が1024bitでした。特定の事業者だけの傾向ではありません

1024bitのままだと何が起きるか

まず、鍵長だけを理由にただちに配送が止まることはありません。RFC 8301 §3.2 は1024bitを署名側の必須要件として認めており、検証側には1024bitから4096bitまでの検証能力を求めています。

一方で、同じ節は受信側が鍵長を受理判断の材料に使うことも認めています。特定のメールサービスが1024bitの署名を拒否したり、迷惑メール判定で不利に扱ったりするかどうかは、この調査では確認していません。

したがって、次のように考えるのが妥当です。鍵を再発行できる環境であれば2048bitへ移す。すぐに動かせない事情があるなら、仕様違反ではないので慌てて壊す必要はない。ただし放置する理由も特にありません。

1024bit未満は無効として扱われます

1024bitを下回ると話が変わります。RFC 8301 §3.2 は「Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures」と定めており、検証側は有効な署名と見なしてはなりません。

今回の調査では、512bitの鍵が1件、768bitの鍵が1件見つかりました。9,937件中の2件なので稀ですが、実在します。この状態だとDKIMの署名は検証されず、DKIMを設定しているつもりでも認証は通りません。診断では警告ではなく「要修正」として表示します。

心当たりがある場合は、鍵長を確認したうえで再発行してください。

2048bitへ切り替える手順

鍵の入れ替えは、既存のレコードを上書きするのではなく、新しいセレクタを追加して並行運用します。RFC 6376 §3.1 がこの手順を説明しています。

it merely makes sure that both public keys are advertised in the public-key repository concurrently for the transition period during which email may be in transit prior to verification

送信済みでまだ受信側に届いていないメールがあるため、切り替えの瞬間に旧鍵を消すと、そのメールの検証が失敗します。

手順は次のようになります。

1. 新しいセレクタ名で2048bitの鍵ペアを生成します。多くのサービスでは管理画面から発行できます
2. 新しいセレクタの公開鍵をDNSに追加します。この時点では旧セレクタのレコードも残しておきます
3. 送信側の署名設定を新しいセレクタに切り替えます
4. しばらく（配送中のメールが届き切るまで）両方を残します
5. 旧セレクタのレコードを削除します

TXTレコードの文字数について

2048bitの公開鍵はBase64で約400文字になります。DNSのTXTレコードは複数の文字列から構成でき、1つの文字列のデータ部分は最大255オクテットです（RFC 1035 §3.3、§3.3.14）。そのため、2048bitの鍵は複数の文字列に分割されて格納されます。

検証する側は、これらの文字列を空白を挟まずに連結してから使います（RFC 6376 §3.6.2.2）。したがって、p= の値の途中に文字としての空白や改行を入れてはいけません。

管理画面で分割を自分で行う必要があるかどうかは、DNSを管理している事業者によって異なります。自動で分割する事業者もあり、引用符で区切った形式の入力を求める事業者もあります。事業者の公式手順に従ってください。事業者ごとの画面については事業者別ガイドにまとめています。

なお、RFC 6376 §3.6.2.2 は「TXT RRs MUST be unique for a particular selector name」とも定めています。同じセレクタ名に複数のレコードがある状態は結果が未定義になるため、追加の際は既存のレコードと重複していないか確認してください。

切り替えたあとに確認する

1. 新しいセレクタの公開鍵が外から引けるかを確認します。診断でセレクタを指定すれば確認できます
2. テストメールを送り、届いたメールの DKIM-Signature ヘッダーで s= が新しいセレクタになっているかを見ます
3. Authentication-Results ヘッダーで dkim=pass が出ているかを確認します
4. 確認できてから旧セレクタのレコードを削除します

セレクタの調べ方はDKIMセレクタの確認方法で扱っています。公開鍵に t=y が付いている場合の扱いはDKIMのt=y（テストモード）とはを参照してください。

ドメインを診断する