DKIM

DKIM（DomainKeys Identified Mail）とは、メールの送信元ドメインの正当性とメール本文の改ざんがないことを暗号学的に検証するための電子メール認証技術です。送信サーバーがメールに電子署名を付与し、受信サーバーがDNSに公開された公開鍵を使って署名を検証することで、メールの真正性と完全性を確認します。

DKIMの動作原理は公開鍵暗号方式に基づいています。送信サーバーは秘密鍵を使ってメールヘッダーと本文のハッシュ値に署名し、その署名をDKIM-Signatureヘッダーとしてメールに追加します。受信サーバーは、署名に含まれるドメインとセレクター情報をもとにDNS TXTレコードから公開鍵を取得し、署名を検証します。

SPFがIPアドレスベースの送信元認証であるのに対し、DKIMは暗号署名ベースの認証であるため、メール転送時にも認証が維持されるという大きな利点があります。メールの内容が転送途中で改ざんされない限り、署名は有効なままです。DKIMはSPFおよびDMARCと組み合わせることで、包括的なメール認証体制を構築できます。

DKIM-Signatureヘッダーの構造

DKIM-Signatureヘッダーは、メールに付与される電子署名の情報を含むヘッダーフィールドです。主要なタグには以下のものがあります。

• v：DKIMのバージョン（現在は「1」固定）
• a：署名アルゴリズム（rsa-sha256やed25519-sha256など）
• d：署名ドメイン（メール送信者のドメイン）
• s：セレクター（DNS上の公開鍵を特定するための識別子）
• h：署名対象のヘッダーフィールド一覧（From, To, Subject, Dateなど）
• bh：メール本文のハッシュ値
• b：署名データ（Base64エンコード）
• c：正規化方式（ヘッダー/本文の正規化ルール）

RSA署名とEd25519署名

DKIMでは従来からRSA-SHA256が標準的な署名アルゴリズムとして使用されてきました。RSA鍵は1024ビット以上が必須であり、現在は2048ビットが推奨されています。1024ビットの鍵は計算能力の向上により安全性が低下しており、近い将来破られるリスクがあります。

近年では、より高速で鍵サイズが小さいEd25519-SHA256が新たな署名アルゴリズムとして導入されています（RFC 8463）。Ed25519は楕円曲線暗号に基づき、256ビットの鍵で高いセキュリティを提供します。ただし、すべてのメールサーバーがEd25519をサポートしているわけではないため、RSAとEd25519のデュアルサイニング（二重署名）を行うことが推奨されています。

セレクター管理と鍵ローテーション

セレクター（Selector）は、同一ドメインで複数のDKIM鍵を使い分けるための仕組みです。セレクター名はDKIM-Signatureヘッダーの「s」タグに指定され、公開鍵はDNSの「セレクター._domainkey.ドメイン名」というTXTレコードに格納されます。例えば、セレクターが「google」でドメインが「example.com」の場合、公開鍵は「google._domainkey.example.com」に配置されます。

鍵ローテーションは、セキュリティを維持するために定期的にDKIM鍵ペアを更新する運用です。新しいセレクターで新しい鍵ペアを生成し、DNSに公開鍵を登録した後、送信サーバーの設定を新しい秘密鍵に切り替えます。旧セレクターの公開鍵は、検証中のメールのために一定期間残しておく必要があります。推奨されるローテーション間隔は6ヶ月〜1年です。

正規化方式（Canonicalization）

メールがインターネットを経由する際、メールサーバーやMTA（Mail Transfer Agent）によってヘッダーや本文にわずかな変更が加えられることがあります（空白の追加・削除、ヘッダーの折り返し変更など）。正規化方式は、これらの無害な変更による署名検証の失敗を防ぐための仕組みです。

DKIMではsimpleとrelaxedの2つの正規化方式が定義されています。simple方式はメールをほぼそのまま扱うため厳格ですが、中継サーバーによる変更に弱い特徴があります。relaxed方式は連続する空白の統一やヘッダー名の小文字変換などの正規化を行い、中継時の変更に対する耐性が高くなります。一般的には「relaxed/relaxed」（ヘッダー・本文ともにrelaxed）が推奨されます。

DKIMの検証プロセス

受信サーバーがDKIM署名を検証する手順は次の通りです。まず、メールのDKIM-Signatureヘッダーからドメイン（d=）とセレクター（s=）を抽出し、対応するDNS TXTレコードから公開鍵を取得します。次に、指定された正規化方式でメールヘッダーと本文を正規化し、本文のハッシュ値を計算してbhタグの値と比較します。

本文ハッシュが一致したら、署名対象ヘッダーフィールドのハッシュを計算し、公開鍵を使ってbタグの署名を検証します。すべてが一致すればDKIM Pass、不一致であればDKIM Failと判定されます。この結果はAuthentication-Resultsヘッダーに記録され、DMARCの判定やスパムフィルタリングに利用されます。

• 01
  2048ビット以上のRSA鍵を使用：DKIM署名には最低でも2048ビットのRSA鍵を使用してください。1024ビット鍵は現在の計算能力では脆弱であり、攻撃者が秘密鍵を推測できるリスクがあります。可能であればEd25519との二重署名も検討してください。
• 02
  定期的な鍵ローテーションの実施：DKIM鍵は6ヶ月〜1年ごとにローテーションしてください。新しいセレクターで新しい鍵ペアを生成し、旧鍵の公開レコードは検証期間を考慮して一定期間（2〜4週間）保持した後に削除しましょう。
• 03
  署名対象ヘッダーの適切な選択：DKIM署名の対象ヘッダー（h=タグ）には、From、To、Subject、Date、Message-ID、MIME-Versionなどの重要なヘッダーを含めてください。特にFromヘッダーは必須であり、DMARCアライメントにも必要です。
• 04
  relaxed正規化方式の採用：正規化方式は「relaxed/relaxed」を使用することで、中継サーバーによる無害な変更による署名検証の失敗を最小限に抑えられます。simple方式は厳格すぎて、正当なメールの署名が不正に失敗するリスクがあります。
• 05
  秘密鍵の厳格な管理：DKIM秘密鍵はメール送信サーバー上で安全に保管し、アクセスを最小限の権限者に制限してください。秘密鍵が漏洩すると、攻撃者が正規のDKIM署名を持つなりすましメールを送信できるようになります。
• 06
  DKIM検証結果の継続的な監視：DMARCレポートやメールログを通じてDKIM検証の成功率を定期的に確認してください。検証失敗率が上昇している場合は、鍵の不整合、DNSレコードの誤設定、中継サーバーによるメール改変などの原因を調査し、速やかに対処しましょう。