メルマモ

この記事でわかること

DKIM鍵の長さと署名アルゴリズムが配信や互換性にどう影響するかを、初心者にも分かるように例や手順で解説します。結論→理由→例→手順の順で短く説明します。

結論（要点）

推奨鍵長は2048ビット。十分な強度があり、主要メールプロバイダでサポートされています。
署名アルゴリズムはrsa-sha256を選ぶ。rsa-sha1は非推奨です。
互換性に不安がある古い機器では1024ビットを暫定利用するが、可能な限り早く2048に移行してください。

なぜ重要か（理由）

セキュリティ（改ざん耐性）

鍵が短いと総当たり（ブルートフォース）や暗号解析で秘密鍵が破られるリスクが高まります。2048ビットは現時点で実運用に十分な強度と見なされています。

配信と受信の互換性

受信サーバは公開鍵をDNSから取得して署名を検証します。長い鍵や特定アルゴリズムが未対応だと「検証失敗」になり、迷惑メール判定につながる可能性があります。しかし主要クラウド（Google/Microsoft）や一般的なMTAは2048ビットとrsa-sha256をサポートしています。

仕組みの簡単な説明（初心者向け）

例えると、DKIMは封筒の裏に押される捺印のようなものです。送信者はメールに秘密のハンコ（秘密鍵）で押印し、受信者は発行元の公開ハンコ（公開鍵）をDNSで照合して真正性を確認します。鍵長はハンコの複雑さ、アルゴリズムはハンコの作り方です。

推奨設定（実務）

鍵長

初期：2048ビットを推奨。
互換性問題が出る場合：一時的に1024ビットにするが、移行計画を立てる。

アルゴリズム

rsa-sha256（表記例: "rsa-sha256" または DNS上はデフォルトで指定しないことが多い）。
sha1系は非推奨で、RFCやプロバイダで避けるべき。

DNSレコード（公開鍵）

DKIM公開鍵はセレクタを含むTXTレコードとして配置します。形式の基本：

selector._domainkey.example.com. TXT "v=DKIM1; p=公開鍵のBase64;"

長いBase64は複数の""で分割しても構いません。DNSのTXTはスペースで自動連結されます。

実践手順（生成→公開→検証）

1. 鍵ペア生成（例: openssl）

openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.pem

2. 公開鍵をDNS用に変換

# 公開鍵ファイルからヘッダ/フッタを除去しBase64連結
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqh...（省略）...IDAQAB
-----END PUBLIC KEY-----
# DNS用p= に入れる文字列はヘッダ/改行を削ったBase64

3. TXTレコードの例

default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

注: k=rsa はオプション。v=DKIM1 と p= は必須。

4. メールサーバに秘密鍵を登録し署名を有効化

SaaS（Gmail for Business等）なら管理コンソールに公開鍵を登録する手順があるので、それに従ってください。オンプレ/自前MTAでは秘密鍵のパスとセレクタを設定します。

5. 検証

送信後、受信側でヘッダに"DKIM-Signature"が付与され、検証結果が"pass"か確認する。
外部ツール: DKIM validator、openssl s_client ではなく専用チェックサイトやdigでDNSを確認。

互換性チェックのポイント

主要プロバイダ（Gmail, Outlook/Office365, Yahoo）は2048 & rsa-sha256をサポート。
古いアプライアンスや一部のスマートデバイス：2048で問題が出るケースが稀にある。問題が出たらメールヘッダと受信側ログを確認。
DNSの最大長: TXTの1文字列は255バイトだが、複数文字列を連結できるため実運用では公開鍵サイズで困ることはほぼありません。

よくあるトラブルと対処法

1. 検証がfailになる

原因と対処例：

DNSに公開鍵がない/誤記: digでselector._domainkeyを確認しp=が正しいかチェック。
公開鍵が改行やスペースで壊れている: Base64を連結して適切にTXTに入れる。
メールが途中で改変されている: 署名対象ヘッダや本文がMTA中継で変更されていないか確認（例: X-headers追加や本文のMIME変換）。

2. 送信遅延や処理負荷

2048ビット鍵は署名作成に少しCPUを使います。大量送信環境では署名処理の影響をベンチし、必要なら署名オフロードやキュー制御を検討してください。

鍵ローテーションと運用上の注意

定期ローテーションを計画的に実施（例: 年1回または侵害時）。
ローリング方式: 新しいセレクタで鍵を追加→十分運用確認後に旧セレクタを削除。
秘密鍵の保護: ファイル権限、KMS/HSMの利用を検討。

まとめ

推奨は2048ビット鍵＋rsa-sha256。主要プロバイダがサポートしており、安全性と配信の両立が図れます。互換性の懸念がある場合は段階的に移行し、DNS公開鍵の正確さとメール送受信の検証を必ず行ってください。

DKIM鍵長とアルゴリズムの最適設定