DKIMとは？電子署名の仕組み・セレクタ・鍵の長さと確認方法

SPF、DMARCと並んでメール認証の柱になるDKIM。署名の仕組みと、設定が正しいかを自分で確かめる方法をまとめます。

公開: 2026年11月13日

DKIMは「メールに付ける電子署名」

DKIM（DomainKeys Identified Mail）は、送信するメールにサーバーが電子署名を付け、受信側がその署名を検証することで、「このメールは確かにそのドメインの管理下で送られ、途中で書き換えられていない」ことを確かめる仕組みです。仕様はRFC 6376で定められています。

SPFが「どのサーバーから送られたか」を見るのに対し、DKIMは「メールの中身そのもの」に署名をかけます。そのため、メールが転送されて送信元のIPアドレスが変わっても、本文や主要なヘッダーが変更されていなければ、署名は有効なまま残ります。この点が、転送に弱いSPFを補う大きな理由です。

署名と検証のながれ

1. 送信側のメールサーバーが、本文と一部のヘッダー（From、Subject、Dateなど）からハッシュ値を作り、秘密鍵で署名します。
2. 署名は、メールの先頭に DKIM-Signature というヘッダーとして付きます。
3. 受信側のサーバーは、そのヘッダーに書かれたドメインとセレクタから、DNSに公開された公開鍵を取得します。
4. 公開鍵で署名を検証し、メールが改ざんされていなければ「pass」、署名が合わなければ「fail」と判定します。

秘密鍵は送信側だけが持ち、DNSに置くのは公開鍵だけです。公開鍵から秘密鍵を逆算することはできないため、公開鍵が誰にでも見えていても問題はありません。

DKIM-Signatureヘッダーの読み方

受信したメールのソースを表示すると、次のようなヘッダーが見つかります（一部を省略した例です）。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.co.jp; s=selector1;
 h=from:to:subject:date:message-id;
 bh=（本文のハッシュ）; b=（署名）

• d=：署名したドメイン（署名ドメイン）。DMARCの判定では、この値が差出人（From）のドメインと一致しているか（アライメント）が重要になります。
• s=：セレクタ。公開鍵を探すときの目印になる名前です。
• h=：署名の対象にしたヘッダーの一覧です。
• bh=：本文のハッシュ値、b=：署名そのものです。
• a=：アルゴリズム。現在はrsa-sha256が一般的です。

セレクタとDNSの公開鍵

公開鍵は、セレクタ._domainkey.ドメイン というDNS名のTXTレコードに置きます。たとえばセレクタが selector1、ドメインが example.co.jp なら、次の名前を引きます。

selector1._domainkey.example.co.jp.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

p= に公開鍵が入っています。セレクタが存在する理由は、ひとつのドメインで複数の鍵を同時に使えるようにするためです。メール配信サービスを複数使っている場合や、鍵を入れ替える場合に、セレクタを分けておけば互いに干渉しません。

鍵の長さとアルゴリズム

RSA鍵は、2048ビットが現在の推奨です。1024ビットも多くの環境で動きますが、強度の面から2048ビットへの移行が勧められています。2048ビットの公開鍵はTXTレコードの長さが255文字を超えるため、DNSの管理画面によっては、文字列を複数に分割して登録する必要があります（分割してもDNSの仕組み上、連結されて1つの値として扱われます）。

長い鍵を登録するとき、入力欄が引用符や改行を自動で処理する場合と、そうでない場合があります。登録後に、実際にDNSから引いた値が途中で切れていないかを必ず確認してください。

DKIMの鍵を入れ替える（ローテーション）

秘密鍵は漏えいのリスクを抱え続けるため、定期的な入れ替えが望ましいとされています。入れ替えの基本手順は次のとおりです。

1. 新しいセレクタ名で、新しい鍵ペアを作ります。
2. 新しい公開鍵を、DNSに追加します（古い鍵はまだ消しません）。
3. 送信側の署名設定を、新しいセレクタに切り替えます。
4. 古い署名のメールが配送中に残る期間（数日ほど）を待ってから、古い公開鍵を削除します。

古い鍵を先に消してしまうと、まだ配送中のメールの検証が失敗します。必ず「追加、切り替え、待機、削除」の順に進めてください。

DKIMだけでは足りない理由

DKIMは「署名したドメイン」を保証しますが、その署名ドメインが、利用者の目に見える差出人（From）のドメインと同じである保証まではしません。攻撃者が自分のドメインで署名したメールに、あなたのドメインの差出人を表示させることもできてしまいます。この食い違いを見抜いて、一致しないメールの扱いを指示するのがDMARCの役割です。DKIMとDMARCは、セットで考えてください。

設定が正しいかを確認する方法

• 実際にメールを送って確かめる：自分のドメインのアドレスから、Gmailなどの別のアドレスへ送り、受信側で「メッセージのソース」を表示して dkim=pass と、header.d= が自分のドメインになっていることを確認します。
• DNSを直接引く：dig TXT selector1._domainkey.example.co.jp のように、セレクタ名を指定して引き、v=DKIM1 と p= があるかを見ます。
• ツールで確認する：DMARC・なりすまし対策チェックでは、よく使われるセレクタ名を順に確認し、見つかったものを表示します。

よくあるつまずき

• メール配信サービスのDKIMは、サービス側が用意したCNAMEレコードを自分のDNSに追加する方式が多くあります。追加を忘れていると、サービス側のドメインで署名されるため、自社ドメインとの一致が取れません。
• 送信経路の途中で、本文の末尾に広告文や免責文を自動で追記する仕組みがあると、署名後に本文が変わり、検証に失敗します。
• 公開鍵のレコードの末尾に余分なスペースや改行が入ると、検証に失敗することがあります。

よくある質問

DKIMだけ設定すれば、なりすましは防げますか？

防げません。DKIMは署名したドメインを示すだけで、利用者に見える差出人（From）のドメインとの一致までは保証しません。差出人との一致を確認し、一致しないメールの扱いを指示するDMARCと、組み合わせて使います。

DKIMの鍵は、どのくらいの頻度で入れ替えるべきですか？

一律の決まりはありませんが、年に1回程度の入れ替えを目安にする運用が多く見られます。鍵が漏えいした疑いがあるときや、担当者が退職したときは、すぐに入れ替えます。

DKIMの署名が、メールの転送で壊れることはありますか？

本文や署名対象のヘッダーが書き換えられなければ、転送しても署名は有効です。ただし、メーリングリストなどが、件名や本文に文言を追加すると、署名が無効になることがあります。