DKIM2とは？次世代のDKIMの仕組みと標準化の現状【2026年版】

DKIM2とは？次世代のDKIMの仕組みと標準化の現状【2026年版】

転送で壊れない、リプレイを検出できる ― IETFで策定中のDKIM2をInternet-Draftから読み解く

作成
著者: 竹洞 陽一郎

DKIM（RFC 6376）は、2011年にInternet Standard（STD 76）となったメール認証の仕組みです。
しかし、転送やメーリングリストで署名が壊れる、署名済みのメールをそのまま再送するリプレイ攻撃を防げない、といった課題が残っています。
こうした課題を根本から見直すため、IETFのDKIMワーキンググループでは、DKIM2（DomainKeys Identified Mail Signatures v2）の標準化作業が進められています。
ここでは、DKIM2のInternet-Draftの内容に基づいて、DKIM2の仕組みと標準化の現状、ドメイン管理者が今すべきことを解説します。
DKIM自体の仕組みについては、DKIMで解説しています。

この記事の前提
この記事は、2026年10月18日時点のInternet-Draftに基づいています。
DKIM2はRFCとして発行されておらず、標準ではありません。
Internet-Draftは「作業中の文書（work in progress）」であり、内容は今後変更される可能性があります。
この記事で「〜とされています」と書いている内容は、すべてドラフトの記述であり、確定した仕様ではありません。

1. DKIM2とは

要点: DKIM2は、メールが経由するシステムごとに署名を追加して「受け渡しの連鎖」を作り、途中での変更内容を記録できるようにする新しいDKIMです。2026年10月時点では、IETFのワーキンググループ文書（Internet-Draft）の段階です。

DKIM2の基本仕様は、draft-ietf-dkim-dkim2-specとして策定されています。
著者は、Yahoo、Google、Fastmailの技術者です。
ドラフトの冒頭では、DKIM2は署名ドメインの所有者が「そのメールを取り扱ったこと」を記録できる仕組みとして説明されています。
DKIMが「署名ドメインがメールに責任を持つこと」を示すのに対し、DKIM2は送信から配信までにメールを扱った各システムが、それぞれ署名を追加していく点が大きく異なります。

DKIMワーキンググループのDKIM2関連文書（2026年10月18日時点）
文書内容版・日付目指す位置付け
draft-ietf-dkim-dkim2-specDKIM2の基本仕様-06（2026年8月28日）Standards Track
draft-ietf-dkim-dkim2-dns公開鍵のDNSレコードの仕様-01（2026年10月）Standards Track
draft-ietf-dkim-dkim2-bcp導入・運用のベストプラクティス-01（2026年9月9日）Best Current Practice

「目指す位置付け」は各ドラフトの冒頭に記載された予定（Intended status）です。
3つとも、2026年10月18日時点のDatatrackerでの状態は「WG Document」（ワーキンググループで作業中の文書）です。
このほかに、個人が提出した関連ドラフトが複数あります。
最新の状態は、DKIMワーキンググループの文書一覧で確認できます。

2. DKIM2が解決しようとしているDKIMの課題

要点: DKIM2は、DKIMの「転送で署名が壊れる」「リプレイ攻撃を検出できない」「バウンスメールが無関係な第三者に届く（バックスキャッター）」という3つの課題の解決を目指しています。

転送やメーリングリストで署名が壊れる
DKIMでは、メーリングリストが件名にタグを付けたり、本文にフッターを追加したりすると、署名の検証に失敗します。
この問題を補う仕組みとしてARC（RFC 8617）がありますが、ARCはExperimental（実験的）のRFCです。
DKIM2では、途中のシステムが行った変更の内容を記録し、受信側が変更前の状態を復元して元の署名を検証できるようにします。
リプレイ攻撃を検出できない
DKIMの署名は、送信時のSMTPのエンベロープ（MAIL FROMとRCPT TO）を対象にしていません。
そのため、正規の署名が付いたメールを一度受け取った攻撃者が、別の宛先に大量に再送しても、署名は有効なままです（RFC 6376 Section 8.6）。
DKIM2では、エンベロープの情報を署名に含めることで、意図されていない宛先への再送を検出できるようにします。
バックスキャッター
送信元を詐称したメールが配信できなかった場合、そのバウンスメール（配信状況通知、DSN）が、送信元として詐称された無関係な第三者に届くことがあります。
DKIM2では、DSNをメールの受け渡しの連鎖に沿って、直前の送信者にだけ返す仕組みが規定されています。

3. DKIM2の仕組み

要点: DKIM2では、メッセージのハッシュ値を記録するMessage-Instanceヘッダーと、署名を記録するDKIM2-Signatureヘッダーの2種類を使います。各ホップが連番付きで追加することで、送信から配信までの「受け渡しの連鎖（Chain of Custody）」を作ります。

次の図は、送信者（Originator）が最初の署名を作成するまでの流れを、DKIMの署名作成のプロセス（DKIMの「1.1. 送信側での署名生成」）と比べられるように描いたものです。
オレンジの「違い1」〜「違い5」が、DKIMと異なる点です。

DKIM2の署名作成のプロセスとDKIMとの違い
DKIM2の署名作成のプロセスとDKIMとの違い（draft-ietf-dkim-dkim2-spec-06に基づく）
違い1：署名対象ヘッダーを選ばない
DKIMではh=タグで署名対象のヘッダーを選びますが、DKIM2にはh=に相当する仕組みがありません。
Received、Return-Path、Authentication-Results、X-*などの除外対象（Section 4.1）を除く、すべてのヘッダーがハッシュ値の対象になります（Section 4）。
DKIMで問題になる「署名対象ヘッダーが少なすぎる」という設計上の弱点が、仕様の段階でなくなります。
違い2：ハッシュ値と署名を分ける
本文とヘッダーのハッシュ値は、Message-Instanceヘッダーのh=タグに「ハッシュ名:ヘッダーハッシュ:ボディハッシュ」の形で記録されます（Section 7）。
署名の対象は、Message-InstanceヘッダーとDKIM2-Signatureヘッダーだけです（Section 9.6）。
DKIMでbh=を含むDKIM-Signatureヘッダー自体に署名するのと考え方は似ていますが、DKIM2ではハッシュ値を独立したヘッダーに分けることで、転送者が新しいMessage-Instanceヘッダーを追加できるようにしています。
違い3：SMTPエンベロープを署名する
DKIM2-Signatureヘッダーのmf=とrt=に、MAIL FROMとRCPT TOをbase64で記録します（Section 8.5、8.6）。
DKIMでは、エンベロープは署名の対象外です。
違い4：連番で連鎖をつくる
Message-Instanceヘッダーにはm=、DKIM2-Signatureヘッダーにはi=の連番を付けます。
転送者は、メッセージを変更した場合は変更内容（r=のRecipes）を含む新しいMessage-Instanceヘッダーを、変更しない場合も新しいDKIM2-Signatureヘッダーを追加します（ベストプラクティスのドラフトでは、転送者は変更の有無にかかわらず署名しなければならない（MUST）とされています。bcp-01 Section 5.2）。
DKIMの署名は、それぞれが独立しています。
違い5：正規化方式を選ばない
DKIMではc=タグでsimpleとrelaxedを選びますが、DKIM2の正規化方式は固定です。
本文はDKIMのsimple方式と同じ方法でハッシュ値を計算し（Section 6.1）、ヘッダーは名前を小文字にして空白を整え、名前順に並べ替えてから計算します（Section 6.2）。
署名値、セレクタ、署名アルゴリズム名は、DKIM2-Signatureヘッダーのs=タグにまとめて記録されます（Section 8）。

2種類の新しいヘッダー

Message-Instance
メッセージのヘッダーと本文のハッシュ値を記録するヘッダーです（draft-ietf-dkim-dkim2-spec-06 Section 7）。
途中のシステムがメッセージを変更した場合は、変更後のハッシュ値と、変更前の状態に戻すための手順（Recipes）を記録したMessage-Instanceヘッダーを新たに追加します。
連番はm=タグで表し、1から始まります。
DKIM2-Signature
署名を記録するヘッダーです（Section 8）。
署名ドメイン、SMTPのエンベロープ（MAIL FROMとRCPT TO）、タイムスタンプを含みます。
連番はi=タグで表し、1から始まります。
署名の対象は、Message-InstanceヘッダーとDKIM2-Signatureヘッダーです。
本文やその他のヘッダーは、Message-Instanceヘッダーのハッシュ値を通じて保護されます（Section 9.6）。

ドラフトでは、連番に欠番があるメッセージは署名のないメッセージとして扱わなければならない（MUST）とされています（Section 8.1）。
なお、DKIM2-Signatureヘッダーにはバージョン番号がなく、互換性のない変更が必要になった場合は「DKIM3」という名前のヘッダーにするという方針が示されています（Section 8）。

エンベロープ情報の署名とリプレイの検出

DKIM2-Signatureヘッダーには、MAIL FROMを記録するmf=タグと、RCPT TOを記録するrt=タグがあります（Section 8.5、8.6）。
受信側は、実際のSMTPのMAIL FROMとRCPT TOが、最新のDKIM2-Signatureヘッダーのmf=とrt=に完全に一致するかを確認します（Section 9.2）。
この確認では、relaxedなドメイン一致の方法を使ってはならない（MUST NOT）とされています（Section 11.4）。
攻撃者が署名済みのメールを別の宛先に再送すると、RCPT TOがrt=と一致しないため、署名の連鎖が成り立たなくなります。
また、受け渡しの途中で宛先が展開される（1通が複数の宛先に配られる）場合は、そのことを示すフラグ（exploded）を付けます（Section 8.10）。
このフラグがないのに同じメッセージが複数届いた場合、受信側は失敗として扱うとされています（Section 11.9）。

途中の変更の記録（Recipes）

メッセージを変更する転送者（ドラフトでは「Reviser」と呼びます）は、変更前の状態を再現するための手順をJSON形式のRecipesとして記録します（Section 5）。
変更したヘッダーについては、Recipesを必ず記録しなければならない（MUST）とされています（Section 5.1）。
受信側は、Recipesを使って変更前のメッセージを復元し、それぞれの段階のハッシュ値と署名を検証できます。
これにより、メーリングリストがフッターを追加しても、元の送信者の署名を検証でき、どのシステムがどんな変更をしたかも把握できます。
本文を変更前に戻せない場合は、本文のRecipesをnullにして、その旨を示すこともできます（Section 5.2）。

DSN（バウンスメール）の返送先

ドラフトでは、DSNはメッセージを送ってきたMTAに宛てなければならない（MUST）とされています（Section 12）。
返送先は、最新のDKIM2-Signatureヘッダーのmf=から決まります。
失敗の通知が受け渡しの連鎖を一段ずつさかのぼるため、詐称された無関係な第三者にバウンスメールが届くことを防げます。
また、検証に成功しないメールについては、DSNを生成してはならないとされており、拒否する場合はSMTPのやり取りの中で5xxの応答を返すことが推奨されています（Section 10.1）。

タイムスタンプと暗号アルゴリズム

タイムスタンプ
DKIM2-Signatureヘッダーのt=タグに署名時刻を記録します。
検証者は、署名から14日を超えている場合は失敗を返すべき（SHOULD）とされています（Section 11.3）。
DKIMのx=タグ（有効期限）は任意でしたが、DKIM2では署名の古さが検証の判断に組み込まれています。
暗号アルゴリズム
基本仕様（spec-06 Section 3）では、署名アルゴリズムとしてRSA-SHA256とEd25519-SHA256が規定され、検証者はすべてのアルゴリズムを実装しなければならない（MUST）とされています。
DNSの仕様（dns-01 Section 3.3）では、これに加えて、ポスト量子暗号のML-DSAとEd25519を組み合わせたmldsa44-ed25519-sha512を実装すべき（SHOULD）とされています。
rsa-sha1による署名は検証してはならない（MUST NOT）とされています。

4. DKIMとDKIM2の比較

DKIM（RFC 6376）とDKIM2（draft-ietf-dkim-dkim2-spec-06）の主な違い
項目DKIMDKIM2（ドラフト）
仕様の状態Internet Standard（STD 76）Internet-Draft（WG Document）
ヘッダーDKIM-SignatureMessage-Instance、DKIM2-Signature
署名対象ヘッダーh=タグで選ぶ（Fromは必須）除外対象を除くすべてのヘッダー（h=に相当する仕組みはない）
正規化方式c=タグでsimpleとrelaxedを選ぶ固定（本文はsimple方式と同じ）
署名の対象署名対象ヘッダーと、bh=を含むDKIM-SignatureヘッダーMessage-InstanceヘッダーとDKIM2-Signatureヘッダー
署名の付け方各署名は独立。途中のシステムが署名を追加することはできるが、連鎖としては扱わない各ホップが連番付きで署名を追加し、受け渡しの連鎖を作る
途中の変更署名対象が変更されると検証に失敗する変更内容をRecipesとして記録し、変更前の状態を復元して検証できる
SMTPのエンベロープ署名の対象外mf=（MAIL FROM）とrt=（RCPT TO）を署名に含める
リプレイ攻撃検出できない（x=で有効期限を限定する程度）エンベロープの不一致と重複配信で検出する
署名の古さx=は任意（RECOMMENDED）14日を超えた署名は失敗とすべき（SHOULD）
DSNの返送先規定なし直前の送信者（最新のmf=）に返す
公開鍵の置き場所セレクタ._domainkey.ドメインのTXTレコード同じ（DNSレコードの形式も共通）

5. DNSレコード（公開鍵）の扱い

DKIM2の公開鍵は、DKIMと同じく_domainkeyサブドメインのTXTレコードに置きます（draft-ietf-dkim-dkim2-dns-01 Section 3.4.2.1）。
DKIM2ではバージョン番号を上げず、既存の鍵の配置との互換性のために、DKIMのレコード形式をそのまま使うとされています（Section 3.4.1）。
そのため、v=タグを指定する場合の値は、DKIM2でもDKIM1です。
一方、DKIMの鍵レコードにあったh=、n=、s=、t=タグは、DKIM2では廃止され、無視すべき（SHOULD）とされています。

DNSの仕様のドラフトでは、DKIM2の文書はRFC 6376を廃止するものではなく、DKIMとDKIM2は少なくとも当面は共存すると明記されています（Section 1）。
同じセレクタの鍵をDKIMとDKIM2の両方で使えるかどうかは、ドラフトには明記されていません。
レコード形式が共通であることから、既存の鍵を使える可能性はありますが、これは現時点のドラフトからの推測です。

6. DKIMからの移行と共存

要点: ベストプラクティスのドラフトでは、移行期間中はDKIMとDKIM2の両方で署名すること、DKIM2の署名がないことだけを理由に受信を拒否しないことが推奨されています。DMARCでDKIM2をどう扱うかは、まだ決まっていません。

送信側：DKIMとDKIM2の二重署名
署名者は、DKIM2が広く普及するまで、DKIMとDKIM2の両方の鍵で署名すべき（SHOULD）とされています（draft-ietf-dkim-dkim2-bcp-01 Section 3.3）。
また、DKIM2の署名は、メールが自組織の基盤を出る最後のホップで付けなければならない（MUST）とされています（Section 3.4）。
転送者：変更しなくても署名する
転送者は、メッセージを変更するかどうかにかかわらず、扱うすべてのメッセージにDKIM2の署名を付けなければならない（MUST）とされています（Section 5.2）。
メーリングリストなどの転送者には、DKIM2への対応が求められることになります。
受信側：DKIM2の署名がないだけでは拒否しない
移行期間中は、DKIM2の署名がないことだけを、拒否する理由として扱うべきでない（SHOULD NOT）とされています（Section 6.1.3）。
DKIMとDKIM2の両方の署名がある場合は、両方を検証し、DKIM2のpassをより強い判断材料として扱うべき（SHOULD）とされています（Section 7.1）。
DMARCとの関係
2026年5月に発行されたDMARCの仕様（RFC 9989）が認証の仕組みとして扱っているのは、SPFとDKIM（RFC 6376）です（Section 4.3）。
ベストプラクティスのドラフトでも、DKIM2は現時点ではDMARCの認証の仕組みとして挙げられておらず、DMARCとの関係を扱う節（Section 7.2）はワーキンググループの合意前の検討段階であることが明記されています。
SPFとの関係
受信側は、当面はDKIM2の検証とあわせてSPFの確認も続けることが推奨されています（Section 7.8）。
ただし、この節も検討段階の扱いです。

7. 今、ドメイン管理者がすべきこと

DKIM2はまだ標準化の途中であり、ドメイン管理者が今すぐDKIM2を設定する必要はありません。
ドラフトでも、DKIMとDKIM2は当面共存し、DKIMの署名は引き続き必要とされています。
MailDataでは、DKIM2の標準化を待つのではなく、現行のDKIMとDMARCを正しく運用することが、今できる最も効果的な対策だと考えています。

DKIM2の標準化を待たずに今できること
対策内容根拠
自社ドメインでのDKIM署名すべての送信元で、自社ドメイン（d=がFromヘッダーのドメインとアライメントするドメイン）で署名するRFC 9989
署名対象ヘッダーの見直しFrom以外に、Subject、Date、MIME関連ヘッダーなどを署名し、オーバーサインで後からの追加を防ぐRFC 6376 Section 5.4、5.4.2
l=タグを使わない本文全体を署名対象にするRFC 6376 Section 8.2
x=タグの設定署名の有効期限を設定し、リプレイに悪用できる期間を限定するRFC 6376 Section 3.5（RECOMMENDED）
2048ビット以上のRSA鍵新しく鍵を生成する場合は2048ビット以上にするRFC 8301 Section 3.2（SHOULD）
鍵のローテーション少なくとも6か月毎に鍵を更新し、更新を自動化するM3AAWG（2019年）、MailDataの推奨
DMARCをp=rejectで運用自社ドメインを詐称したなりすましメールを受信側で拒否させるRFC 9989
DKIM2の動向の確認利用中のメールサービスやメール配信サービスの対応状況と、ドラフトの更新を確認する―

DKIMの設定と運用上の注意点は、DKIMで詳しく解説しています。
リプレイ攻撃とその防御方法については、DKIMリプレイ攻撃とは？その防御方法をご参照ください。
MailDataでは、DMARCレポートの分析を通じて、送信元ごとのDKIM署名とアライメントの状況を洗い出し、p=rejectへの移行を支援しています。
DKIMの設定の見直しやDMARCの運用でお困りの場合は、お問い合わせフォームからご相談ください。

8. 参考資料

いずれも2026年10月18日に確認した版です。
Internet-Draftは更新されると版数が変わるため、最新の版はDatatrackerで確認してください。