主なポイント
- DKIMキーの長さは、RSA署名キーのビット数です。キーが長いほど偽造に対する耐性は高くなりますが、公開するDNSレコードのサイズも大きくなります。
- 1024ビットのRSAはRFC 8301により非推奨とされており、NISTの最低基準を下回っていますが、cPanelなどのホスティングパネルでは依然としてデフォルトで生成されています。
- 2048ビットのRSAは、2026年における適切なデフォルト設定であり、RFC 8301、NIST、およびGoogleやYahoo!の大量送信者向け要件を満たしています。
- 2048ビットの公開鍵は、DNS TXTレコードの255バイトという制限を超えるため、これをチャンク化された文字列に分割する必要があります。そうしないと、検証が失敗してもエラーメッセージは表示されません。
- チャンキングのステップを省略すると、目に見えないDKIMエラーが発生します。メールは送信され、ログにも異常は記録されませんが、受信側では署名が拒否されます。
- 6~12か月ごとにパラレルセレクタを使用して鍵をローテーションし、Ed25519はRSA-2048と併用して二重署名を行う場合にのみ採用し、決して単独では使用しないこと。
DKIMキーを更新すれば、メールのセキュリティが強化されるはずです。しかし実際には、DNSの設定ミスが原因で認証エラーが発生することがよくあります。
多くの組織では、自覚のないまま1024ビットのDKIM鍵を使い続けている。また、最新のセキュリティ推奨事項に準拠するために2048ビットに移行した組織もあるが、鍵の長さが長くなると新たな公開要件が生じることが判明している。DNSに公開鍵を追加する際にたった一つのミスがあれば、メールの送信自体は正常に行われているにもかかわらず、DKIMの検証に失敗してしまう可能性がある。
課題は、適切な鍵長を選択し、それを正しく公開し、電子メールの認証に支障をきたすことなく、長期にわたって維持管理することである。
このガイドでは、2026年においてDKIMキーの長さがセキュリティ、配信率、コンプライアンスにどのような影響を与えるかについて解説します。1024ビット、2048ビット、4096ビット、およびEd25519キーの違い、現在の設定状況の確認方法、DNS公開におけるよくあるミスの回避方法、そしてキーを安全にローテーションする方法について学ぶことができます。
DKIMキーの長さとは何ですか?
DKIMキーの長さとは、 DKIM規格 (RFC 6376)に基づき、電子メールに署名および検証を行うRSA鍵ペアのサイズ(ビット単位)を指します。秘密鍵はメールサーバー上で送信される各メッセージに署名を行い、それに対応する公開鍵はDNSのTXTレコードに格納されるため、受信サーバーは署名を検証することができます。
鍵が長ければ長いほど、解読は困難になります。2048ビットの鍵は、1024ビットの鍵よりもはるかに偽造に対して強固です。しかし、鍵の長さにはトレードオフがあり、暗号強度、DNSレコードのサイズ、受信側との互換性のすべてに同時に影響を及ぼします。
公開鍵は セレクタというラベル(例: selector1._domainkey.example.comなど)として公開されます。これは、1つのドメインで複数の鍵を同時に運用できるため、受信者にどの鍵を使用すべきかを伝えるためのラベルです。
DKIM 鍵長のオプション比較
DKIMキーはすべて同じというわけではありません。時代遅れのものもあれば、現在の標準となっているものもあり、ある問題を解決する一方で別の問題を引き起こすものもあります。ここでは、1024ビット、2048ビット、4096ビット、およびEd25519を、実際の運用において比較してみます。
1024ビットRSA
1024ビットRSAは当初のDKIM標準でしたが、現在では依然として許可されている選択肢の中で最も脆弱なものとなっています。標準はすでにこれを超えて進化しています。 RFC 8301 (2018)では、許容される鍵サイズの最小値を1024ビットと定めていますが、署名には少なくとも2048ビットを推奨しています。また、検証者は1024ビット未満の鍵を無効として扱うことが求められています。
NIST SP 800-131A Rev. 2 はさらに踏み込み、デジタル署名の生成において2048ビット未満のRSA鍵の使用を禁止し、1024ビットのRSAをレガシー用途の暗号技術として分類している。 Googleの送信者ガイドライン では、Gmail への配信における最低要件として 1024 ビットの DKIM 鍵を依然として認めていますが、セキュリティを強化するため、2048 ビットの鍵を推奨しています。
さまざまな推奨事項があるにもかかわらず、1024ビットの鍵は依然として広く使われています。多くの ホスティングパネルや旧式のメールプラットフォームの多くは、依然としてデフォルトで1024ビット鍵を生成しており、その結果、組織は気づかないうちに1024ビットのRSAを使い続けています。
1024ビットのRSA鍵は、現在の暗号化に関する推奨基準よりもセキュリティが脆弱であるため、標準化団体やメールボックスプロバイダーは2048ビットへの移行を進めています。しかし、依然として1024ビットのDKIMを運用している組織にとっては、認証エラーを招くような性急な変更を行うよりも、計画的な移行を策定・検証する方が、概して望ましいと言えます。
2048ビットRSA
2048ビットのRSAは、現在のDKIM標準です。 RFC 8301では、署名用に少なくとも2048ビットのRSA鍵を使用することを推奨しており、NIST SP 800-131A Rev. 2では、2048ビット以上のRSA鍵をデジタル署名の生成に許容されるものとして分類しています。また、Googleの送信者ガイドラインでも、セキュリティ上の理由から2048ビットの鍵を推奨しています。2048ビットの鍵は、現在の業界、プロバイダー、およびコンプライアンスの要件を満たしています。
2048ビットの鍵に関連するDKIMの失敗のほとんどは、暗号上の問題によるものではありません。これらはDNSの公開に関する問題です。2048ビットの公開鍵の長さは、おおよそ392文字(Base64エンコード)ですが、1つのDNS TXTレコードに記述できる文字列は255バイトに制限されています。そのため、鍵を1つの文字列として公開することはできません。鍵を 同じTXTレコード内で、引用符で囲まれた複数の文字列に分割する必要があり、DNSはルックアップ時にこれらを自動的に再構成します。
鍵が誤って公開された場合、 DKIMの検証に失敗します レコードは存在しているように見え、メールサーバーも通常通りメッセージへの署名を継続しているにもかかわらず、検証に失敗します。
4096ビットRSA
4096ビットのRSAは、ほとんどの受信者が検証可能な最大の鍵長です。RFC 8301では、検証者は1024ビットから4096ビットまでの鍵を検証することが義務付けられており、それ以上の鍵長については任意とされているため、4096ビットを超える鍵はまったく検証されないリスクがあります。PowerDMARCのホステッドDKIMは、最大4096ビットの鍵長に対応しています。
ほとんどの組織にとって、4096ビットは不要です。2048ビットはすでにNIST SP 800-131A Rev. 2の最低要件およびGoogleの送信者ガイドラインを満たしており、4096ビットはこれに比べてセキュリティ上の実質的な利点をもたらさない一方で、DNSレコードのサイズが大きくなり、署名検証時にわずかなオーバーヘッドが生じます。
4096ビットは、社内ポリシーや監査機関によって特にその使用が求められている、高度なセキュリティが求められる環境や規制の厳しい環境でのみ使用してください。
Ed25519(今後の方向性)
Ed25519 は、RFC 8463 (2018) によって標準化された DKIM 署名アルゴリズムです。その最大の利点は鍵の長さです。Ed25519 の公開鍵は 44 オクテットの Base64 文字列にエンコードされるため、DNS キーレコード全体を 1 つの TXT 文字列に収めることができます。 RSA-2048 や RSA-4096 とは異なり、DNS レコードのチャンキングを必要とせず、複数の文字列からなる TXT レコードを公開できないシステムでも動作します。また、RFC 8463 では、Ed25519 は RSA よりも大幅に短い鍵長でありながら、強力な暗号セキュリティを提供すると説明されています。
課題は普及です。RFC 8463 では、検証者が Ed25519-SHA256 をサポートすることが求められていますが、これによる署名のサポートは推奨にとどまっています。実際には、メールプラットフォーム、MTA、メールプロバイダー間でのサポート状況は依然として一貫していません。Ed25519 のみを採用した導入では、このアルゴリズムをサポートしていない受信側において、DKIM 検証に不備が生じる可能性があります。
そのため、Ed25519はRSA-2048と併用するのが最適です。 RFC 8463はデュアル署名を明示的にサポートしており、1つのメッセージにRSA-SHA256とEd25519-SHA256の両方の署名を含めることが可能です。セレクタは1つの公開鍵しか公開できないため、各署名は同じ署名ドメインを共有しつつ、異なるセレクタを使用する必要があります。受信者は、自身がサポートする署名を検証することで互換性を確保しつつ、組織がEd25519を採用できるようにします。
| キーの長さ | セキュリティレベル | DNSレコードのサイズ | コンプライアンス状況(2026年) | 推奨用途 |
|---|---|---|---|---|
| 1024ビットRSA | 脆弱、非推奨 | 1つのTXT文字列に収まる | NISTの最低基準を下回っている。NISTの規定により、レガシー用途に限定される。Googleはこれを最低限の基準として認めている。 | レガシー環境のみ。2048ビットへの計画的な移行を策定してください。 |
| 2048ビットRSA | 強力;現行の標準 | ~392 文字(Base64 エンコード);複数の文字列に分割する必要があります | RFC 8301、NIST、およびGoogleの推奨事項に準拠しています | ほぼすべての組織におけるデフォルト設定 |
| 4096ビットRSA | 非常に強い | 大きい;分割が必要;ほとんどの受信機が確認できる最大サイズ | 現行の要件を上回る | 厳重なセキュリティが求められる環境、または規制対象の環境に限る |
| Ed25519 | 強力なアルゴリズムであり、RSAよりも鍵長が短い | 44オクテット。TXT文字列1つ分が収まり、チャンキングは行われない | RFC 8463 で標準化されている。検証者はこれをサポートしなければならない(MUST)、署名者はサポートすべきである(SHOULD)。受信者側のサポート状況は依然としてまちまちである。 | RSA-2048と併用するデュアル署名 |
現在のDKIMキーの長さを確認する方法
DKIM キーのアップグレードを計画する前に、DNS に現在公開されているキーのサイズを確認してください。
1. DKIMセレクタを特定する
署名付きメールのヘッダーを開き、 DKIM-Signature フィールドを探します。 s= タグの値がセレクタとなります。また、メールプロバイダのDKIM設定画面でもセレクタを確認できます。
2. DKIMレコードを確認する
クエリ selector._domainkey.yourdomain.com DKIM検索ツールまたはDNSクエリツールを使用して、公開されているTXTレコードを取得します。
3. 公開鍵を確認する
次の場所を探してください p= タグを探してください。ここにはDKIM公開鍵が含まれています。ほとんどのDKIM検索ツールは、鍵の長さを自動的に識別し、1024ビット、2048ビット、またはその他のサイズであるかを報告します。
4. 結果を評価する
そのドメインで依然として1024ビットの鍵が使用されている場合は、2048ビットのRSAへの移行を計画してください。2048ビットの鍵がすでに導入され、正常に機能している場合は、通常、直ちに対処する必要はありません。
PowerDMARCのDKIMチェッカーは、公開済みのレコードを取得し、主要プロバイダーのセレクタを自動検出するため、手動でBase64をデコードする手間をかけずに、数秒で鍵の長さを確認できます。 無料でお試しください
2048ビットのDNSチャンキング問題(およびその回避方法)
2048ビット鍵へのアップグレード後にDKIMエラーが発生する最も一般的な原因の一つは、DNSレコードの公開設定が不正確であることです。
この問題は、 DNSのTXTレコードの の制限に起因しています。1つのTXT文字列に含まれることができる最大サイズは255バイトですが、base64でエンコードされた2048ビットのRSA公開鍵は通常、約392文字の長さになります。その結果、鍵を単一の文字列として公開することができません。DNSプロバイダーがレコードを切り捨てたり、エントリを拒否したりすると、DKIMの検証に失敗します。
| コンポーネント | 制限 |
|---|---|
| 単一のDNS TXT文字列 | 最大255バイト |
| 典型的な2048ビットのRSA公開鍵 | 約392文字のBase64文字列 |
| 誤って公開された場合の結果 | DKIM 検証に失敗しました |
2048ビットの鍵を正しく公開するには、公開鍵を同じTXTレコード内の複数の引用符で囲まれた文字列に分割してください。DNSは、検索時にこれらの文字列を自動的に連結します。
selector1._domainkey.example.com. IN TXT (
“v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1xN8s9k2”
“Qp7Yv3RwL0fHmZ2bKct5oXn8eW4uV1aA9dGqB6sT0pJrN3mC2hF7lYxoZ4kP1wIDAQAB”
)
長いTXTレコードのサポート状況は、DNSプロバイダーによって異なります。プラットフォームによっては、管理者が引用符で囲まれた文字列を複数手動で入力する必要がある場合もあれば、長い値が自動的に分割・再構成される場合もあります。DKIMキーを公開する前に、必ずご利用のプロバイダーのDNSレコードのフォーマット要件を確認してください。
以下の点に留意してください:
| 必要条件 | 説明 |
|---|---|
| 複数の拠点 | キーは任意の箇所で分割することができます。DNSは、これらの文字列を自動的に1つの値に再構成します。 |
| 文字列の長さ | 個々の文字列は、DNSの255バイトという制限を超えてはなりません。 |
| バリデーション | DNSの伝播が完了した後、公開されているDKIMレコードを照会し、完全な公開鍵が返されることを確認してください。 |
| トラブルシューティング | メールの署名が正常に行われているにもかかわらず、受信者からDKIM検証の失敗が報告される場合は、公開されている公開鍵に切り捨てや形式上の問題がないか確認してください。 |
新しいDKIMキーを公開した後、DNSレコードを検証し、受信サーバーがエラーなく完全な公開鍵を取得できることを確認してください。
DKIMキーのローテーションを行う時期と方法
DKIM 鍵のローテーションは、鍵が長期間公開され続けることによるリスクを軽減するものであり、セキュリティおよびコンプライアンスプログラムにおいて一般的な要件となっています。DKIM 規格で定義された普遍的なローテーションスケジュールはありませんが、多くの組織では、日常的なセキュリティメンテナンスの一環として、6~12 ヶ月ごとに署名鍵をローテーションしています。
安全なDKIMローテーションプロセスでは、既存のセレクタを廃止する前に、新しいセレクタを導入します。これにより、移行期間中もDKIMの検証が継続的に行われることが保証されます。
- 手順 1: 新しいDKIM鍵ペアを生成し、新しいセレクタを割り当てます。多くの組織では、追跡や監査を簡素化するために、日付に基づくセレクタ名を使用しています。
- ステップ 2: 新しいセレクタの下で、新しい公開鍵をDNSに公開します。2048ビットのRSA鍵を使用する場合は、DNSレコードが正しく公開されていることを確認してください。
- ステップ 3: レコードのTTLに基づいて、DNSの伝播が完了するまで待ちます。
- ステップ 4: メールサーバーまたはメールサービスプロバイダーの設定を更新し、新しいセレクタを使用してメッセージに署名するようにします。
- 手順 5: 古い鍵で署名されたメッセージが通常の配信経路を通過し、DNSキャッシュの有効期限が切れるまで、前のセレクタを有効なままにしておきます。
- 手順 6: 使用しなくなった古いセレクターおよびそれに関連するDNSレコードを削除してください。
このアプローチにより、遷移期間中も両方のセレクタが共存できるようになり、DNSの伝播遅延やキャッシュされたレコードに起因するDKIM検証の失敗を防ぐことができます。
複数のドメイン、セレクター、またはメールサービスを管理している組織では、手動によるローテーションを一貫して維持することが困難になる場合があります。
プラットフォームおよびコンプライアンス・フレームワークごとのDKIM鍵の長さに関する要件
DKIMキーの長さに関する要件は、メールプロバイダー、セキュリティ基準、およびコンプライアンスの枠組みによって異なります。一部の枠組みでは具体的な暗号化要件が定義されている一方、他の枠組みでは、より広範な業界の指針やベストプラクティスに準拠しています。
コンプライアンスおよびプロバイダーの要件
| フレームワーク / プロバイダー | DKIM 鍵の長さに関する要件 |
|---|---|
| Googleの一括送信に関する要件 | 最低1024ビット、2048ビットを推奨 |
| Yahoo!の送信者要件 | 概ねGoogleの送信者要件に準拠しています |
| NIST SP 800-131A 第2版 | 2048ビット未満のRSA鍵は、デジタル署名の生成には承認されていません。 |
| HIPAAの規制対象となる環境 | 通常はNISTの暗号ガイドラインに従い、2048ビットのRSAを実用上の最低基準とする |
| FedRAMP環境 | NISTの暗号規格および承認された鍵長に準拠する |
| PCI DSS環境 | DKIM固有の鍵長に関する要件はありませんが、組織では一般的にNISTに準拠した暗号化慣行に従っています。 |
プラットフォームのサポートとデフォルト設定
| プラットフォーム | DKIM 鍵の長さに関する考慮事項 |
|---|---|
| cPanel | 一部の設定では、デフォルトで1024ビットのDKIM鍵が展開されることがよくあります。準拠していると判断する前に、公開されている鍵の長さを確認してください。 |
| Microsoft Exchange 2013/2016 | 鍵長のサポート状況やデフォルト設定は、導入方法やDKIMの実装によって異なる場合があります。 |
| Googleワークスペース | 2048ビットのDKIM鍵をネイティブでサポートしています。 |
| Microsoft 365 | 2048ビットのDKIM鍵をネイティブでサポートしています。 |
| 最新のクラウドメールプラットフォーム | 通常、追加の設定を必要とせずに、2048ビットのDKIMの導入に対応しています。 |
主要なメールボックスプロバイダー、セキュリティフレームワーク、および企業環境を問わず、2048ビットのRSAは依然として推奨されるDKIM鍵の長さです。これは、現在のセキュリティガイダンス、幅広い互換性要件、およびコンプライアンスの要件を満たしつつ、より長いRSA鍵に伴う導入上の課題を回避することができます。
2048ビットのDKIMキーを生成する方法
2048ビットのDKIM鍵ペアの生成は、DKIM鍵生成ツールを使用するか、コマンドラインから直接行うことができます。
方法 1:DKIM キー生成ツールを使用する
PowerDMARCのDKIMジェネレーターは、2048ビットのDKIM鍵ペアを生成し、メールサーバーやメールプラットフォーム用に、DNS対応形式の公開鍵とそれに対応する秘密鍵を提供します。
方法 2:OpenSSL を使用して鍵ペアを生成する
# 2048ビットの秘密鍵を生成する
openssl genrsa -out dkim_private.key 2048
# 一致する公開鍵を抽出する
openssl rsa -in dkim_private.key -pubout -out dkim_public.key
鍵ペアを生成した後は、以下のベストプラクティスに従ってください:
| 推奨事項 | 詳細 |
|---|---|
| 記述的なセレクタを使用する | 20260101 や jan2026 といった日付ベースのセレクタを使用することで、鍵の管理やローテーションの追跡が簡素化されます。 |
| 秘密鍵を保護する | 秘密鍵は、DKIM署名を行うシステムにのみ保存してください。DNSに登録したり、公に共有したりしてはなりません。 |
| DNSに公開鍵を登録する | 公開鍵を、該当する selector._domainkey TXT レコードに追加してください。 |
| DNSの書式を確認する | 2048ビットのRSA鍵を使用する場合は、公開鍵が正しく公開されており、DNSのTXTレコードの長さ制限に準拠していることを確認してください。 |
| 本番環境への展開前にテストを行う | DKIMレコードが一般に公開されていること、および新しいセレクタで署名されたメッセージがDKIM検証に合格することを確認してください。 |
鍵が公開され、DNSの伝播が完了したら、メールプラットフォームを更新して、新しいセレクタを使用してメッセージの署名を開始してください。
2026年にDKIM鍵の長さを適切に管理する
正しく生成、公開、および管理された2048ビットの鍵は、配信上の問題を引き起こすことなく、偽造に対するより強力な保護を提供します。しかし、誤って公開された鍵は、その暗号強度にかかわらず、DKIM検証を無効にしてしまう可能性があります。
変更を行う前に、現在のDKIMの導入状況を確認してください。もしまだ1024ビットの鍵を使用している場合は、2048ビットのRSAへの計画的な移行を策定してください。すでに2048ビットに移行済みの場合は、DNSレコードの設定を確認し、鍵のローテーションプロセスを確立し、認証結果を定期的に監視してください。
強力な電子メール認証は、適切な鍵長を選択するだけでは不十分です。鍵の生成やDNSへの公開から、鍵のローテーション、継続的な検証に至るまで、DKIMのライフサイクル全体を適切に管理することが不可欠です。
よくあるご質問
Googleは2026年に2048ビットのDKIMを義務付けるのでしょうか?
Googleの一括送信に関するルールでは、1024ビット以上が最低要件として認められていますが、2048ビットの使用が強く推奨されています。NISTはデジタル署名の生成に1024ビットのRSAを使用することを認めていないため、Googleの制限にかかわらず、2048ビットが事実上の標準となっています。
1024ビットのDKIM鍵を使用するとどうなりますか?
Gmailを含め、1024ビットを受け入れる受信側では、引き続きメールの認証は行われます。しかし、これはNISTが定める2048ビットという最低基準を下回っており、コンプライアンス監査に合格できない可能性があり、十分なリソースを持つ攻撃者によって破られる恐れがあります。
DNSで2048ビットのDKIM鍵を分割するにはどうすればよいですか?
2048ビットの公開鍵(約392文字)は、TXTレコードの文字列制限である255バイトを超えるため、同じTXTレコード内で引用符で囲んだ文字列に分割します。DNSはこれらを自動的に連結します。公開後は、DKIM検索ツールを使用して検証を行ってください。
GmailやOutlookでは、Ed25519 DKIMがサポートされていますか?
2026年現在、サポート状況は改善されているものの、受信側やESPによって対応状況にばらつきがあります。Ed25519のみでの署名は避けてください。RSA-2048とEd25519を併用して署名を行い、Ed25519に対応していない受信側でもRSAに切り替わるようにしてください。
DKIMキーはどのくらいの頻度で更新すべきですか?
6~12か月ごとに更新するのが、広く推奨されているベストプラクティスです。並列セレクタ方式を採用することで、新しい鍵が全システムに反映されるまで古い鍵の有効性を維持し、鍵の切り替え期間中もメールへの署名を継続できるようにします。
- DKIM 鍵の長さ:1024、2048、4096の選び方 - 2026年7月9日
- ClickFix(およびFileFix)とは? - 2026年7月8日
- メールサービスプロバイダーの選び方:セキュリティを最優先とした評価フレームワーク - 2026年7月1日

