目次
1. DKIMとは？
DKIM（DomainKeys Identified Mail）は、メール送信者のドメイン認証技術の一つです。
送信側メールサーバが「電子署名」をメールに付与し、受信側がその署名を公開鍵で検証することで「改ざんがない」ことを確認できます。
2. チェックフロー（全体の流れ）
(1) 送信者側（署名の付与）
- 送信者のメールサーバは、メール本文と一部のヘッダー（From, Subject, Dateなど）をハッシュ化。
- 秘密鍵でハッシュ値を電子署名。
- 署名情報を
DKIM-Signatureヘッダーとしてメールに追加。- 例：
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ... d=→ 署名ドメインs=→ セレクタ（DNSの公開鍵を特定するための識別子）
- 例：
(2) 受信者側（署名の検証）
- メールサーバは
DKIM-Signatureヘッダーを読み取り、d=ドメイン（例: example.com）s=セレクタ（例: selector1）
を取得。
- DNSから公開鍵を取得。
- DNSレコードの問い合わせ例：
selector1._domainkey.example.com - ここにTXTレコードとして公開鍵が格納されている。
- DNSレコードの問い合わせ例：
- 署名の検証。
- メール本文＋対象ヘッダーを再度ハッシュ化。
- DKIM署名（電子署名部分）を公開鍵で復号。
- 両者のハッシュ値が一致すれば「改ざんなし」と判定。
(3) 認証結果の判定
受信サーバは検証結果を Authentication-Results ヘッダーに付加します。
例：
Authentication-Results: example.net;
dkim=pass header.i=@example.com
- dkim=pass → 正しく署名されており、改ざんなし
- dkim=fail → 署名が不正または改ざんの可能性
- dkim=neutral → 署名が付与されていない
3. DKIMの特徴
- 改ざん防止に有効（本文や重要ヘッダーが変えられていないか確認できる）
- 送信元の「ドメイン」レベルでの信頼性を保証
- ただし、「誰が送ったか（人物レベル）」は保証しない
- SPFやDMARCと併用して初めて強力な判定が可能
📊 DKIMチェックフロー図解
┌──────────────┐
│ 送信者 (example.com) │
└───────┬──────┘
│ 秘密鍵で署名
▼
メールにDKIM-Signature追加
│
▼
┌──────────────┐
│ インターネット経由 │
└───────┬──────┘
│
▼
┌──────────────┐
│ 受信者のメールサーバ │
└───────┬──────┘
│ DNSに問い合わせ
▼
selector1._domainkey.example.com → 公開鍵取得
│
▼
署名を検証（本文＋ヘッダーのハッシュ）
│
▼
一致 → DKIM=PASS
不一致 → DKIM=FAIL
✅ まとめ：
DKIMは「改ざんがないか」を保証する仕組みで、受信者は公開鍵をDNSから取得して署名を検証します。
ただし、表示されるFromとDKIMドメインが一致するとは限らないため、DMARCと組み合わせて送信者ドメインの正当性を担保するのが実務上のポイントです。
次は電子署名について深堀りします 👍
ここからは 公開鍵暗号方式（公開鍵と秘密鍵の関係） を整理しつつ、なぜDNSに公開鍵があるのか・なぜそれで署名検証できるのか を解説します。
🔑 秘密鍵と公開鍵の関係
1. 公開鍵暗号方式とは
- 1つのペアの鍵（秘密鍵と公開鍵）を使います。
- 秘密鍵 → 絶対に外部に漏らさない。署名や復号に使う。
- 公開鍵 → 誰でも見れるように公開。暗号化や署名検証に使う。
👉 秘密鍵と公開鍵は 数学的にペア になっており、片方で暗号化／署名したものは、もう片方でしか復号／検証できません。
2. 電子署名の仕組み
(1) 署名（送信側）
- 送信者は本文やヘッダーをハッシュ化。
例:HASH = SHA256(本文) - そのハッシュ値を 秘密鍵で暗号化 する。
これが「電子署名」。
(2) 検証（受信側）
- 受信者はメール本文から同じようにハッシュを計算。
例:HASH2 = SHA256(本文)
メールのヘッダーに含まれるDKIM-Signatureヘッダー に、使われたアルゴリズムなどの情報が入っています。
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
h=From:Subject:Date;
bh=xxxxxxxxxxxxxxxxxxxxxx;
b=yyyyyyyyyyyyyyyyyyyyyy;ここで重要なのは a= と h=。
a=rsa-sha256- 署名アルゴリズム（RSA署名＋SHA-256ハッシュ）を指定
- → 受信者は「SHA-256でハッシュ化してRSAで署名してある」と理解できる
h=From:Subject:Date- どのヘッダーをハッシュ対象にしたかを示す
- 受信者は同じヘッダーを順序通りに取り出してハッシュ化
2. 受信者の動作（検証プロセス）
DKIM-Signatureのa=を読む → 「sha256 でハッシュ化されている」と分かるh=を読む → 「From, Subject, Date ヘッダーを含めて本文と一緒にハッシュ化する」と分かる- 同じ方法でハッシュ計算 → HASH2 を作る
- 署名本体（
b=）を公開鍵で復号 → HASH1 を得る HASH1 == HASH2なら「改ざんなし」
👉 ポイント：秘密鍵を持っている人しか署名できない。公開鍵で検証できるのは「その秘密鍵で作られた署名」だけ。
✅ DKIM 公開鍵取得と検証フロー（正しい手順）
① 受信者のメールサーバはメールを受け取った直後、DNSへ問い合わせる
- DKIM-Signature ヘッダーを読み取り、
d=（ドメイン）とs=（セレクタ）を使って DNS を問い合わせる。
例:selector1._domainkey.example.com
② 受信サーバが DNS へ問い合わせる
- 「このドメインの公開鍵を教えてください」とクエリを投げる。
- （DNSサーバが DKIM-Signature を“読む”のではなく、受信サーバが必要な情報を指定して問い合わせる という点がポイントです）
③ 権威DNSサーバは公開鍵を返す
- TXT レコードとして、公開鍵が返される。 （権威DNSサーバは、そのTXTレコードの内容を返します。）
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..." - v=DKIM1 → DKIMバージョン
- k=rsa → 鍵の種類
- p=… → 公開鍵（Base64エンコード）
④ 受信サーバは公開鍵を使って署名を検証する
- 公開鍵を「自分のDNSキャッシュに保持」することはありますが、TXTレコードに追加するわけではありません。
- 公開鍵を一時的に利用し、署名を復号して、本文のハッシュと照合します。
❌ 誤解しやすいポイント
- DNSサーバが勝手にDKIM-Signatureを解釈するわけではない
- 受信サーバが自分で「selector._domainkey.ドメイン」に問い合わせる
- 受信サーバは公開鍵を「DNSに追加」するのではなく「自分で検証処理に使う」
✅ 正しい理解のまとめ
- 受信サーバ → DNS問い合わせ
- DNS → 公開鍵を返す
- 受信サーバ → 公開鍵で署名を検証する
👉 この流れを 「受信サーバ ↔ DNS ↔ 公開鍵」 の矢印付き図で整理したほうがイメージつきやすいと思います。
図解にしてみましょうか？
🌐 なぜDNSに公開鍵を置くのか？
- DKIMでは「送信者のドメイン管理者」が秘密鍵を持っています。
- 受信側はその署名が正しいか検証するために「対応する公開鍵」が必要です。
- このとき公開鍵を配布する仕組みとして使われるのが DNS。
理由：
- DNSはドメイン所有者が管理する仕組みなので、そのドメインの正規公開情報を安全に伝えられる。
- 受信者は「Fromに書かれたドメインのDNSに問い合わせれば、その公開鍵を必ず取得できる」 → 検証が自動化できる。
- 追加の専用サーバを立てる必要がなく、メール認証の世界標準として普及している。
👉 例えば selector1._domainkey.example.com に公開鍵をTXTレコードで入れておく。
✅ まとめ
- 秘密鍵 → 署名を生成（外部には公開しない）
- 公開鍵 → DNSで誰でも取得可能
- 受信者 → 公開鍵で署名を検証（改ざんの有無を確認）
- 安全性の根拠
- 公開鍵から秘密鍵を逆算するのは現実的に不可能（数学的に一方向性）
- だから「署名できるのは秘密鍵を持つ正規の送信者だけ」と保証できる
💡イメージすると：
- 秘密鍵 → 鍵穴に合う「ハンコ」
- 公開鍵 → 誰でも見れる「印鑑照合機」
- 本物の印鑑で押した印影しか、照合機では「正」と出ない
👉
コメント