DKIM

1. DKIM処理プロセス

要点: DKIMの処理は「送信側での署名生成」と「受信側での署名検証」の2段階で構成されます。
送信側はbodyのハッシュ値（bh=）を含むDKIM-Signatureヘッダーと署名対象ヘッダーに署名し、受信側はDNSから公開鍵を取得して署名とbodyハッシュを検証します。

DKIMは、送信者がメールの一部（bodyとh=タグで指定したヘッダー）に対して署名を行い、受信側がその署名とハッシュ値を検証する仕組みです。
検証に成功すると、署名ドメイン（d=）がメールに責任を持つこと、署名対象のヘッダーとbodyが改竄されていないことを確認できます。
以下は、送信側と受信側のそれぞれの処理の流れです。

1.1. 送信側での署名生成

送信MTAでのDKIMの署名作成プロセスは、bodyのハッシュ値計算と、ヘッダーのハッシュ値計算による署名作成の2つから成り立ちます。
bodyのハッシュ値はbh=としてDKIM-Signatureヘッダーに書き込まれ、そのDKIM-Signatureヘッダー自体も署名対象に含まれます。
そのため、b=の署名値は、署名対象ヘッダーとbodyハッシュの両方を保護します（RFC 6376 Section 3.7）。

1. メール作成とcanonicalization

送信者はメールを作成し、DKIMの署名対象となるヘッダー群（h=タグで指定）とメールbodyを、それぞれ定められたcanonicalization方式（c=タグ、例：simpleまたはrelaxed）に従って整形します。

2. bodyのハッシュ値計算

整形したbody部に対して、指定のハッシュアルゴリズム（SHA-256、a=タグで指定）を用いてハッシュ値を計算し、その値をDKIM-Signatureヘッダーのbh=タグにセットします。

3. ヘッダーのハッシュ値計算と署名

h=タグに列挙した署名対象ヘッダーと、作成中のDKIM-Signatureヘッダー（b=の値は空として扱う）を整形してハッシュ値を計算します。
このハッシュ値に秘密鍵で署名し、その署名値をb=タグにセットします。

4. DKIM-Signatureヘッダーの付加

以下の項目でDKIM-Signatureヘッダーがメールに付加されます。

• ドメイン d=
• セレクタ s=
• canonicalization方式 c=
• 署名アルゴリズム a=
• 署名対象ヘッダーリスト h=
• bodyハッシュ値 bh=
• 署名値 b=

以下は、DKIM署名が付加されたメールヘッダーの一例です。
説明のため署名対象ヘッダーを最小限にしています。
実運用で署名すべきヘッダーは、「1.2. 署名対象ヘッダー（h=）の選び方」で説明します。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector;
  h=From:Date:Subject:To;
  bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
  b=aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456789AbCdEfGhIjKlMnOpQrStUvWxYz;

この例では、以下のような情報が含まれています。

v=1

DKIM署名のバージョンは1です。

a=rsa-sha256

署名に使用されたアルゴリズムはRSA-SHA256です。

c=relaxed/relaxed

ヘッダーとbodyのcanonicalization方式は、両方ともrelaxedです。

d=example.com

DKIM署名を行ったドメイン名はexample.comです。

s=selector

セレクタは"selector"です。

h=From:Date:Subject:To

署名対象のヘッダーフィールドは、From, Date, Subject, Toです。

bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=

メールbodyのハッシュ値（Base64エンコード済み）です。

b=aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456789AbCdEfGhIjKlMnOpQrStUvWxYz

署名値（Base64エンコード済み）です。署名対象ヘッダーとDKIM-Signatureヘッダー自体（b=は空として扱う）のハッシュ値に、秘密鍵で署名した値が格納されています。

1.2. 署名対象ヘッダー（h=）の選び方

RFC 6376では、Fromヘッダーの署名がMUSTとされています（Section 5.4）。
ただし、Fromだけに署名した場合、Subjectや本文の解釈に関わるContent-Typeなどを差し替えられても、署名は有効なままです。
署名対象ヘッダーについて、RFC 6376には次の記述があります。

Section 5.4のINFORMATIVE OPERATIONS NOTE

Date、Subject、Reply-To、Sender、およびすべてのMIMEヘッダー（MIME-Version、Content-Typeなど）について、メッセージに存在する場合は署名することを強く勧めています。

Section 5.4.1（Recommended Signature Content）

From（必須）、Reply-To、Subject、Date、To、Cc、Resent-Date、Resent-From、Resent-To、Resent-Cc、In-Reply-To、References、List-Id、List-Help、List-Unsubscribe、List-Subscribe、List-Post、List-Owner、List-Archiveを、存在する場合に署名すべきヘッダーとして挙げています。
一方、Return-Path、Received、Comments、Keywordsは署名すべきでないヘッダーとして挙げています。

この2つの記述が異なる助言をしているという指摘が、Errata 6254として登録されています（Held for Document Update）。
MailDataでは、両方の記述を踏まえて、From、To、Cc、Subject、Date、Reply-To、Sender、Message-ID、MIME-Version、Content-Type、Content-Transfer-Encodingなど、メッセージの表示や解釈に影響するヘッダーを署名対象に含めることを推奨しています。

オーバーサイン（存在しないヘッダーへの署名）

RFC 6376では、実際のヘッダー数より多くのヘッダー名をh=に列挙できます（Section 5.4.2）。
たとえばh=From:From:Subject:Subjectのように列挙すると、署名後にFromやSubjectを追加されたときに署名検証が失敗します。
この手法はオーバーサインと呼ばれ、ヘッダーを追加して受信者の表示を変える攻撃への対策になります（Section 8.15）。

1.3. DKIM検証プロセス

受信MTAでのDKIMの検証プロセスは、bodyのハッシュ値の検証と署名の検証の2つから成り立ちます。
2つの検証がともに成功すると、署名ドメインがメールに責任を持つこと、署名対象のヘッダーとbodyが署名時から変更されていないことを確認できます。

bodyハッシュ値 (bh=)

受信MTAは、メールbodyを指定のcanonicalizationとハッシュアルゴリズムで処理し、計算結果とbh=の値が一致するかをチェックすることで、body部の改竄がないかを検証します。

署名 (b=)

受信MTAは、d=とs=を使ってDNSから公開鍵を取得し、署名対象のヘッダーとDKIM-Signatureヘッダーを再構築して、b=に記載された署名が公開鍵で正しく検証できるかどうかを確認します。

1. DKIM-Signatureヘッダーの抽出

受信したメールから、DKIM-Signatureヘッダーを見つけ、各タグの値を取得します。

• ドメイン d=
• セレクタ s=
• canonicalization方式 c=
• 署名アルゴリズム a=
• 署名対象ヘッダーリスト h=
• bodyハッシュ値 bh=
• 署名値 b=

2. 公開鍵の取得（DNS ルックアップ）

DKIM-Signatureヘッダーに記載された署名ドメイン（d=）とセレクタ（s=）の値を使って、セレクタ._domainkey.ドメインのTXTレコードを問い合わせます。
このTXTレコードには、送信者が設定した公開鍵が含まれており、これが署名検証に使われます。

3. bodyのハッシュ検証

3.1. Canonicalization

受信したメールbodyを、DKIM-Signatureのc=タグで指定された方式に従い正規化します。

3.2. ハッシュ計算

正規化後のbodyに対して、同じハッシュアルゴリズム（a=タグで指定）を用いてハッシュ値を計算します。

3.3. 比較

この計算結果がDKIM-Signatureのbh=タグに記載されている値と一致するか確認します。
一致すれば、body部が改竄されていないと判断されます。
不一致の場合は、メールbodyが途中で変更された可能性があるため、検証は失敗となります。

4. ヘッダー署名の検証

4.1. 署名対象ヘッダーの再構築

DKIM-Signatureのh=タグにリストされたヘッダー群と、DKIM-Signatureヘッダー自体（b=の値は空として扱う）を、同じcanonicalization方式で再整形し、署名生成時と同じ形に再構築します。

4.2. 署名検証

取得した公開鍵を使い、DKIM-Signatureのb=タグにある署名を検証します。
署名が正しければ、署名対象ヘッダーとbh=の値が署名時から変更されていないと判断されます。

5. 検証結果の利用

bodyのハッシュ検証とヘッダー署名検証がともに成功した場合、その署名はpassとなります。
これは「d=のドメインがこのメールに責任を持ち、署名対象のヘッダーとbodyは署名時から変更されていない」ことを意味します。
DKIM単体では、d=のドメインとFromヘッダーのドメインの関係は検証しません。
この関係は、DMARCのアライメントで検証されます。

1.4. 受信側メールサーバーの処理

RFC 6376は、署名の検証に失敗してもメッセージの拒否を強制しないとしています（Section 1）。
また、検証に失敗した署名（PERMFAIL）は、メッセージに存在しないものとして無視すべき（SHOULD）とされています（Section 4.2）。
つまり、DKIM単体の仕様では、検証に失敗したメールは署名のないメールと同じ扱いになり、受信可否の判断は受信側のポリシーに委ねられています。

送信ドメインにDMARCポリシーが設定されている場合、受信側はDMARCの評価結果とポリシーを踏まえて処理を決定します。

2. DKIMの動作例

要点: Google Workspaceを例に、DKIM署名の設定から検証までの流れを解説します。第三者署名ではDMARCアライメントに失敗するため、自社ドメインの鍵を発行してDNSに登録する必要があります。

ここでは、Google Workspace を例に、DKIMの動作を説明します。
例として、example.com の正しいメールサーバーが Gmail であると仮定します。

Google Workspaceはデフォルトで、第三者署名（例：d=*.gappssmtp.com）の鍵を使用して署名します。
しかし、DMARCのアライメントでは署名ドメインとFromヘッダーのドメインが一致しないと判断されるため、d=example.com の DKIM 鍵を発行します。
この公開鍵は、DNSにTXTレコードとして登録され、レコード名は google._domainkeyとなります。

_domainkey

DKIMレコードであることを示す固定のラベルです。
DNSでDKIMの公開鍵を検索する際に使用されます。

google

これは「セレクタ」と呼ばれ、同一ドメインで複数のDKIM鍵を区別するための識別子です。
メール送信時、使用されたセレクタ情報がヘッダーに含まれ、受信側はこの情報を基に適切な公開鍵をDNSから取得し署名を検証します。
同じドメイン内で重複しない値にする必要があり、たとえば、Google Workspace では「google」、Microsoft 365 では「selector1/selector2」、SendGrid では「s1/s2」などが使われます。

DNS に公開鍵を登録後、Google 管理コンソールにログインし、「認証を開始」ボタンをクリックして DKIM を有効化します。
詳しい手順については、以下のリンクをご参照ください。
ドメインでDKIMを有効にする - Google Workspace 管理者ヘルプ

例えば、悪意のあるユーザーが、自分で用意したメールサーバーやメールサービスからFromヘッダーをsupport@example.comと詐称してメールを送信する場合を考えます。
攻撃者はexample.comの秘密鍵を持っていないため、d=example.comの有効なDKIM署名を付けることはできません。
メールに付くのは、攻撃者が利用したサービスや攻撃者自身のドメインの署名か、署名なしのどちらかです。
攻撃者側ドメインの署名はDKIMとしてはpassする場合がありますが、Fromヘッダーのドメインとは一致しません。
なお、SPFも評価するのはエンベロープFrom（MAIL FROM）のドメインであり、SPFが通過してもFromヘッダーのドメインが正当であるとは限りません。
この不一致を検出してなりすましと判定するのが、DMARCのアライメントです。

3. DKIMの構文

要点: DKIM-Signatureヘッダーには署名アルゴリズム（a=）、ドメイン（d=）、セレクタ（s=）、bodyハッシュ（bh=）、署名値（b=）などのタグが含まれます。DNSのTXTレコードには公開鍵（p=）や鍵の種類（k=）が格納されます。

DKIM署名は、メールのヘッダーにDKIM-Signatureというフィールドとして追加されます。
このフィールドには、いくつかのタグが含まれており、それぞれ異なる情報を持ちます。
以下に、主要なタグを示します（RFC 6376 Section 3.5）。

署名に使われるタグ

v

DKIMのバージョン。現在の仕様では1のみであり、他の値は無効です。

a

署名に使用されたアルゴリズム。
RFC 8301により、署名者はrsa-sha256で署名しなければならず（MUST）、rsa-sha1は署名にも検証にも使用してはならない（MUST NOT）とされています（RFC 8301 Section 3.1）。
RFC 8463でed25519-sha256が追加されています。

d

DKIM署名を行ったドメイン名（SDID）。

s

セレクタ。署名に使用された公開鍵を特定するために使用されます。

c

ヘッダーとbodyのcanonicalization方式。"relaxed/relaxed" や "simple/simple" などの組み合わせがあります。
省略時は"simple/simple"です。

q

公開鍵取得のクエリ方法。通常、"dns/txt" が使用されます。

h

署名対象のヘッダーフィールドのリスト。Fromを必ず含みます。

bh

メールbodyのハッシュ値（Base64エンコード済み）。bodyの改竄検知に使用されます。

b

署名値。署名対象ヘッダーとDKIM-Signatureヘッダー自体（b=は空として扱う）のハッシュ値に対する署名です。

i

署名の主体を示す識別子（AUID）。省略時は「@」とd=のドメインです。
ドメイン部分は、d=と同じか、そのサブドメインでなければなりません（MUST）。

t

署名の作成時刻（UNIX時間）。

x

署名の有効期限（UNIX時間）。RFC 6376ではRECOMMENDEDとされており、省略時は有効期限なしです。
t=がある場合は、t=より大きい値でなければなりません（MUST）。
有効期限を短くすると、署名済みメールを再送するリプレイ攻撃に悪用できる期間を限定できます。

l

署名対象とするbodyの長さ（オクテット数）。省略時はbody全体です。
l=を指定すると、指定した長さより後ろに追加された内容は署名で保護されません（Section 8.2）。
Section 5.4.1では、l=0にすると署名を無効にせずに本文を完全に書き換えられることが説明されています。
MailDataでは、l=は使用しないことを推奨しています。

z

署名時のヘッダーの写し。診断用です。

DNSに使われるタグ

DKIM では、メール送信者が自身のドメインに DNS TXT レコード を作成し、公開鍵などの情報を提供します。
このレコードには、次のようなタグ（パラメータ）が含まれます（RFC 6376 Section 3.6.1）。

v

DKIM鍵レコードのバージョン。指定する場合はDKIM1でなければならず（MUST）、レコードの先頭に置かなければなりません（MUST）。
それ以外の値で始まるレコードは破棄されます。

p

DKIM署名の検証に使用する公開鍵。
p= の値が空の場合、その公開鍵は失効（revoked）したことを意味し、その鍵による署名は検証に失敗します。
p= を削除するのではなく、空にすることで、鍵の失効を明示できます。

k

鍵の種類を指定します。
デフォルトではrsaです。
RFC 8463でed25519が追加されました。
RFC 8463では、検証者はEd25519-SHA256を実装しなければならない（MUST）、署名者は実装すべき（SHOULD）とされています（Section 5）。
また、後方互換性のために、新旧のアルゴリズムで複数の署名を付けることができ、その場合は異なるセレクタを使用する必要があるとされています（Section 6）。
Ed25519に対応していない受信側でも検証できるよう、Ed25519を使う場合はRSA署名と併用するのが実務的です。

t

DKIMの動作を変更するためのフラグ。

y

このドメインがDKIMをテスト中であることを示します。
検証者は、テストモードの署名者からのメールを、署名のないメールと異なる扱いをしてはなりません（MUST NOT）。

s（ドメイン制限）

i=タグ（AUID）のドメインが、d=タグ（SDID）のサブドメインであってはならない（MUST NOT）ことを示します。
サブドメインでの署名が必要な場合を除き、このフラグの使用はRECOMMENDEDとされています。
t=y:s のように複数のフラグを組み合わせることも可能です。

h

署名に使用できるハッシュ関数を指定します。

n

管理者向けのメモや説明文を記載できますが、DKIM の動作には影響しません。

4. SMTPリレーで経由したMTA毎の署名について

要点: メールが複数のMTAを経由する場合、各MTAが独自のDKIM署名を追加できます。受信側は各署名を独立して評価します。DMARCでは、Fromヘッダーのドメインとアライメントする署名が1つ以上passしている必要があります。

メールは複数のMTAを経由して配信される場合があります。
通常、DKIM署名は送信元のMTAで付与され、受信側で検証されることで、メール内容の改竄が行われていないことを保証します。
しかし、各SMTPリレーに関与したMTAも独自のDKIM署名を追加することも可能です。

ここでは、1つのメールに複数のDKIM署名が付く理由とその注意点について説明します。

複数の組織が関与する場合

多くの企業は、Amazon SES、SendGrid、MailChimp、SalesForce、Zoho などのメール配信サービスやSaaSを利用しています。
これらのサービスは、独自のDKIM署名を付与することで、サービス経由で送信されたことを示し、各組織のメール配信に対する責任を明確にします。

複数の送信システムを経由する場合

同一ドメインから送信されるメールが、複数のシステム（例：Secure Mail Gateway、誤送信防止システム、PPAP対策ツール）を経由すると、各システムが独自にDKIM署名を追加することができます。
たとえば、古い送信元MTAがDKIMに未対応であっても、途中のリレーで適切な署名が追加されれば、それ以降の経路での改竄は検証できます。

複数のDKIM署名を付与する際の注意点は以下の通りです。

署名の検証

RFC 6376では、検証者は各署名を独立して評価すべき（SHOULD）とされています（Section 4.2）。
複数の署名の結果をまとめて「DKIMとして成功」とみなすかどうかは、RFC 6376では定義されておらず、受信側の実装に依存します。
DMARCでは、Fromヘッダーのドメインとアライメントする署名が1つ以上passしている必要があります。

既存の署名の扱い

RFC 6376では、署名者は検証できないとわかっている場合でも、既存のDKIM-Signatureヘッダーを削除すべきでない（SHOULD NOT）とされています（Section 4.2）。
途中のシステムが署名対象のヘッダーやbodyを書き換えると、それより前に付与された署名は検証に失敗します。

DMARC運用時の署名

各サービス独自のドメインの鍵ではなく、自社ドメインの鍵で署名する必要があります。
多くの主要サービスは、カスタムドメイン向けの鍵生成や設定手続きを提供しており、これによりDMARCアライメントが実現できます。

異なる送信システムや組織が関与していても、自社ドメインの鍵で署名された署名が受信側まで壊れずに届けば、DMARCの認証は維持されます。
なお、複数のDKIM署名を付与する場合は、それぞれ異なるセレクタ（署名に関連付けられた識別子）と鍵ペアを使用することが重要です。
これにより、署名ごとに対応する公開鍵を特定でき、問題が起きたときの切り分けも容易になります。

補足：転送時にDKIM認証が成功するケース

一般的に、メール転送はDKIM署名を破損させる原因となりますが、特定の条件下では署名が維持される場合があります。

成功する条件

DKIM認証が成功するのは、転送プロセスにおいて署名対象となったヘッダーとメールbodyが一切変更されない場合に限られます。
具体的には、次のような転送方法が該当します。

リダイレクト（内容を改変しない再配送）

メールサーバーが受信したメールを、内容を改変せずにそのまま別の宛先へ再配送するケース。
この場合、元のDKIM-Signatureヘッダー、署名対象ヘッダー、bodyが維持されるため、DKIM検証は成功します。
一方、SPFは転送元のサーバーのIPアドレスで評価されるため、失敗する場合があります。

元の署名が引き継がれないケース

メールクライアントの「転送」機能や「添付ファイルとして転送」機能では、転送者が差出人となる新しいメールが作成されます。
受信側が認証するのはこの新しいメールであり、転送者のドメインのSPF・DKIM・DMARCで評価されます。
添付された元のメール（.eml）の中のDKIM署名は、届いたメールの認証には使われません。
元のメールの署名は、調査のために個別に検証することはできます。

失敗する一般的なケース

メーリングリストが件名にタグを付けたり、本文にフッターを追加したりする場合や、セキュリティゲートウェイがURLを書き換えたり本文に警告を挿入したりする場合は、署名対象のヘッダーやbodyが変更されるため、DKIM検証は失敗します。

この問題を解決し、転送経路全体での認証情報を維持するために、ARC (Authenticated Received Chain)という仕組みが導入されています。

5. DKIM運用上の注意点

要点: M3AAWG（2019年版）は少なくとも6か月毎のキーローテーションを推奨しています。MailDataでは、鍵の更新を自動化して、より短い周期で実施することを推奨しています。RSA鍵は2048ビット以上を使用し、リプレイ攻撃への備えとしてx=タグと署名対象ヘッダーの設計も重要です。また、DKIMレコードはサブドメインに自動継承されないため、サブドメインごとに個別設定が必要です。

DKIMのキーローテーション

DKIMのキーローテーションは、定期的に秘密鍵と公開鍵のペアを更新するプロセスで、セキュリティのベストプラクティスとして推奨されます。
キーローテーションが重要な理由は以下のとおりです。

セキュリティ向上

万が一秘密鍵が漏洩しても、定期的に更新することでその鍵の有効期間が短縮され、悪用リスクを低減できます。

鍵の強度維持

暗号技術は日々進化しており、古い鍵では新しい攻撃手法に対抗できない可能性があります。
最新の技術に基づいた鍵に更新することで、セキュリティレベルを維持できます。

運用上の問題対処

鍵の管理や運用に問題が生じた場合でも、新しい鍵ペアへの切り替えが容易になります。

暗号アジリティ（Crypto Agility）の確保

ポスト量子コンピューティング時代への備えとして、暗号アルゴリズムや鍵を迅速に切り替えられる体制を構築できます。

SSL/TLS証明書の有効期間短縮とDKIMキーローテーションの関係

2025年4月、CA/Browser ForumはSSL/TLS証明書の最大有効期間を段階的に短縮し、2029年3月までに47日とする決定を承認しました（Ballot SC-081v3）。

DKIMの鍵とSSL/TLS証明書は別の仕組みであり、証明書の有効期間短縮がDKIM鍵の更新周期を直接求めるものではありません。
一方で、鍵や証明書の更新を自動化し、短い周期で回すことでリスクを抑えるという考え方は共通しています。
MailDataでは、この業界の流れを踏まえて、以下の間隔をDKIMキーローテーションの目安として推奨しています。
下表の「MailDataの推奨」は、標準仕様や業界団体の文書で定められたものではなく、MailData独自の推奨です。

実務上の推奨: SSL/TLS証明書の自動更新（ACME等）を導入している環境では、同じ自動化基盤を活用してDKIMキーローテーションも自動化することを推奨します。
これにより、運用負荷を増やすことなく、より短い間隔でのローテーションが実現できます。

キーローテーションの手順

M3AAWGの文書に基づく、キーローテーションの一般的な手順は以下の通りです。

1. 新しい秘密鍵と公開鍵のペアを生成する。
2. 新しい公開鍵をDNSに登録する。
3. メールサーバーが新しい秘密鍵で署名を開始する。
4. 古い公開鍵は最低7日間、最長30日間DNSに残し、配送中のメールの署名の検証をサポートする。その後、p=（空）として無効化し、セレクタのレコードは削除しない。

具体例として、Google Workspaceでは、管理者が管理コンソールで新しい鍵を生成し、DNSに登録する必要があります。
Microsoft 365では、selector1とselector2の2つのCNAMEレコードをDNSに登録しておくことで、公開鍵の管理はMicrosoft側で行われます。
カスタムドメインのローテーションは、管理者がMicrosoft DefenderポータルまたはPowerShell（Rotate-DkimSigningConfig）で実行し、新しい鍵での署名が始まるまで4日（96時間）かかります。
鍵長の既定値は1024ビットのため、2048ビットへの変更を推奨します（Microsoft Learn）。

出典:M3AAWG DKIM Key Rotation Best Common Practices（2019年3月改訂版）

RSA鍵の長さ

RFC 8301では、署名者はすべての鍵で1024ビット以上のRSA鍵を使用しなければならず（MUST）、2048ビット以上のRSA鍵を使用すべき（SHOULD）とされています（RFC 8301 Section 3.2）。
また、検証者は1024ビット未満のRSA鍵による署名を有効な署名とみなしてはなりません（MUST NOT）。
新しく鍵を生成する場合は、2048ビットを選択してください。

DKIMリプレイ攻撃への備え

有効なDKIM署名が付いたメールは、署名対象のヘッダーとbodyを変更しない限り、別の宛先に再送しても署名が有効なままです。
攻撃者が正規のメールを一度受け取り、それを大量に再送する手法はDKIMリプレイ攻撃と呼ばれ、RFC 6376でも想定されています（Section 8.6）。
リプレイは、署名を取得してから数時間から数日のうちに行われることが多いため、数か月単位のキーローテーションだけでは十分な対策になりません。
送信側では、次の対策を組み合わせてください。

x=タグで署名の有効期限を設定する

署名を再利用できる期間を限定します。

署名対象ヘッダーを十分に含める

「1.2. 署名対象ヘッダー（h=）の選び方」で説明したヘッダーを署名し、オーバーサインで後からのヘッダー追加を防ぎます。

l=タグを使わない

body全体を署名対象にします。

リプレイ攻撃の詳細と防御方法は、「DKIMリプレイ攻撃とは？その防御方法」をご参照ください。

DKIMはサブドメインに自動継承されない

DKIMレコードは設定されたドメインにのみ適用され、サブドメインには自動的に継承されません。
したがって、サブドメインからメール送信する場合は、個別にDKIM設定を行う必要があります。

例えば、example.comにDKIM設定があっても、subdomain.example.comでメールを送信する場合は、以下の対応が必要です。

1. サブドメイン用の公開鍵・秘密鍵ペアを生成する。
2. DNSに対応するTXTレコードを登録する。

Type: TXT
Host: mail202610._domainkey.subdomain
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...（2048ビットの公開鍵。以下省略）

同一メールサーバーから複数のドメインやサブドメインでメールを送信する場合、運用を簡略化するために同じセレクタと鍵ペアを再利用することも可能です。
ただし、以下の点に注意してください。

鍵の漏洩リスク

同一鍵を複数のドメインで共有すると、鍵が漏洩した場合の影響範囲が広がります。

管理の複雑化

セレクタ名が同じだと、管理が煩雑になる可能性があります。
問題が発生した際に、切り分けが難しくなります。

運用効率を高めるためには、必要に応じて各サブドメインに個別の鍵を設定するか、DKIM自動設定をサポートするツールやサービス（例：メール配信サービス、DNS管理ツール）の利用が推奨されます。

6. DKIMの限界

要点: DKIMには「転送・メーリングリストでの署名破損」「DNSの遅延」「Fromヘッダーとの関係を検証しない」「署名範囲が狭いと改竄やリプレイに悪用される」という限界があります。これらを補完するためにARC・DMARCの導入と、署名設計の見直しが有効です。

DKIMはメール認証システムとして広く利用されていますが、いくつかの制限事項があります。
以下に、主要な制限事項とその対策について説明します。

転送やメーリングリストによる変更に弱い

DKIM署名は、署名対象のヘッダーやbodyが変更されるとハッシュ値が変化し、署名が無効となります。
転送やメーリングリストでメール内容が加工されると、DKIM検証に失敗する可能性があるため、この問題の軽減にはARC（Authenticated Received Chain）の導入が有効です。

DNSの遅延に弱い

SPFについては、RFC 7208で、MTAはcheck_host()の評価にかかる時間に上限を設けるべき（SHOULD）であり、その上限は少なくとも20秒を許容すべき（SHOULD）とされています（RFC 7208 Section 4.6.4）。
一方、DKIMの公開鍵取得には、RFCで示されたタイムアウト値がありません。
各MTAが独自にタイムアウト値を設定しており、例えば、Microsoft 365ではDKIMのタイムアウト値が500msであるという報告があります（Microsoftの公式ドキュメントでは確認できていません）。
MailDataのDMARCレポート分析では、応答の遅いDNSを利用している場合、公開鍵の取得に失敗し、Microsoft 365で数%〜10%程度のTemperror（一時エラー）が発生する事例を確認しています。
また、Gmailでも2024年11月頃から、リゾルバの遅延が原因と考えられる同様のエラーを観測しています。

Fromヘッダーのドメインとの関係を検証しない

DKIMの署名ドメイン（d=）は、Fromヘッダーのドメインと一致している必要がありません。
そのため、攻撃者が自分のドメインの鍵で署名したメールでも、DKIMとしてはpassします。
Fromヘッダーのドメインと署名ドメインの一致は、DMARCのアライメントで検証します。
自社ドメインのDMARCポリシーを「p=reject」にすることで、自社ドメインをそのままFromヘッダーに使うなりすましを防げます。
ただし、攻撃者が類似ドメイン（例: 本物に似た～.xyzのドメイン）を取得し、SPFやDKIMを正規の送信者のように設定した場合は、DKIMもDMARCも合格します。
類似ドメインによるなりすましには、類似ドメインの監視、防衛的なドメイン取得、利用者への注意喚起などの対策が必要です。
BIMIは、DMARCを強いポリシーで運用している正規ドメインのメールにロゴを表示する仕組みであり、類似ドメインのメールを拒否するものではありません。

署名範囲が狭いと改竄やリプレイに悪用される

DKIMが保護するのは、h=に列挙したヘッダーと、l=で指定した範囲のbodyだけです。
署名対象が狭いと、署名を壊さずにヘッダーの追加や差し替え、本文の追記ができてしまいます。
また、有効な署名の付いたメールは、そのまま再送されても署名が有効なままです。
対策は「5. DKIM運用上の注意点」の「DKIMリプレイ攻撃への備え」をご参照ください。

次世代のDKIM「DKIM2」

IETFのDKIMワーキンググループでは、転送による署名の破損やリプレイ攻撃といった、ここで挙げたDKIMの限界の解決を目指すDKIM2の標準化作業が進められています。
2026年10月時点では、DKIM2はInternet-Draftの段階であり、RFCとして発行された標準ではありません。
DKIM2の仕組みと標準化の現状は、「DKIM2とは？次世代のDKIMの仕組みと標準化の現状【2026年版】」で解説しています。

よくある質問（FAQ）

要点: DKIMの導入・運用に関してよく寄せられる質問と回答をまとめました。

Q1. DKIMが複数ついている時があります。

DKIMは、メールの送信や中継に関与したシステムが、それぞれ署名を付けることができます。
ですから、往々にして、複数のDKIM署名がついていることがあります。
受信側は各署名を独立して評価し、DMARCではFromヘッダーのドメインとアライメントする署名がpassしているかを確認します。

Q2. DKIMの署名はどのように検証されますか？

受信側MTAは、以下の2段階で検証します。

1. メールbodyのハッシュ値を再計算し、bh=タグの値と比較
2. DNSから公開鍵を取得し、署名対象ヘッダーとDKIM-Signatureヘッダー（bh=を含む）に対するb=タグの署名を検証

両方が成功すれば、署名対象のヘッダーとbodyは改竄されていないと判断されます。

Q3. DKIMのキーローテーションはどのくらいの頻度で行うべきですか？

M3AAWG（2019年版）は、少なくとも6か月毎のローテーションを推奨しています。
MailDataでは、SSL/TLS証明書の有効期間短縮の流れを踏まえ、独自の推奨として、2026年3月以降は3〜6か月毎、2029年以降は1〜2か月毎を目安としています。
自動化基盤の導入を推奨します。

Q4. サブドメインでもDKIM設定は必要ですか？

はい、必要です。
DKIMレコードは設定されたドメインにのみ適用され、サブドメインには自動的に継承されません。
サブドメインからメール送信する場合は、個別にDKIM設定（公開鍵・秘密鍵ペアの生成とDNS登録）を行う必要があります。

Q5. DKIMだけでなりすましメールを防げますか？

いいえ、DKIMだけでは不十分です。
DKIMは署名ドメインとFromヘッダーのドメインの関係を検証しないため、攻撃者が自分のドメインで署名したメールもDKIMとしてはpassします。
自社ドメインをFromヘッダーに使うなりすましを防ぐには、DMARCポリシー（p=reject）の設定が必要です。
類似ドメインを使ったなりすましは、DMARCでも防げないため、類似ドメインの監視などの対策を組み合わせてください。

Q6. メールを転送するとDKIMは失敗しますか？

転送の方法によります。

リダイレクト（内容を改変しない再配送）

メールサーバーが受信したメールを、内容を改変せずにそのまま別の宛先へ再配送するケース。
元のDKIM-Signatureヘッダー、署名対象ヘッダー、bodyが維持されるため、DKIM検証は成功します。

メーリングリストやセキュリティゲートウェイを経由する場合

件名へのタグ付け、フッターの追加、URLの書き換えなどで署名対象が変更されると、DKIM検証は失敗します。

メールクライアントの「転送」「添付ファイルとして転送」

転送者が差出人となる新しいメールが作成されるため、元のDKIM署名は引き継がれず、転送者のドメインで認証されます。