Skip to main content
New SPF lookups must resolve in milliseconds — why a DMARC tool's add-on isn't enough Learn Why → →

DKIMとは？

DKIM（DomainKeys Identified Mail）は、公開鍵暗号方式を使って、メールメッセージが認可されたサーバーから送信され、その内容が転送中に改変されていないことを検証するメール認証プロトコルです。送信サーバーは送信メッセージを秘密鍵で署名し、受信サーバーは送信者のDNSに公開された公開鍵を使ってその署名を検証します。送信サーバーのIPアドレスのみを検証するSPFとは異なり、DKIMはメッセージの完全性を検証し、メールの転送を経ても維持されます。DKIMはRFC 6376で定義されています。

このガイドは、DKIMに関する完全ガイドの一部です。関連: DKIMレコード、DKIM署名の仕組み。

DKIM（DomainKeys Identified Mail）は、現代のメール認証における第2の柱です。SPFがメッセージが認可されたサーバーから送信されたことを検証するのに対し、DKIMはさらに一歩踏み込みます。すなわち、メッセージ自体を暗号学的に署名することで、その内容が改ざんされておらず、名乗っている送信ドメインが実際にそのメッセージを認可したことを証明します。

RFC 6376は、DKIMをドメイン名とメールメッセージを関連付ける方式として定義しており、それによって個人、役割、または組織がメッセージに対して何らかの責任を主張できるようにします。この署名はメールの転送を経ても維持され、これはSPFに対する決定的な利点です。

DKIMを理解することは、メールインフラを管理する誰にとっても不可欠です。なぜなら、DKIMのアラインメントはDMARC認証を通過するための2つの経路のうちの1つであり、転送されたメールにとってはしばしば唯一の経路だからです。

DKIMの仕組み: 全体像

DKIMはシンプルな暗号学的原理で動作します。送信サーバーはメッセージを秘密鍵で署名し、受信サーバーはDNSに公開された公開鍵でその署名を検証します。

署名プロセス（送信時）

  1. 送信メールサーバーが、特定のメールヘッダーとメッセージ本文のハッシュを生成する
  2. サーバーがこのハッシュを、ドメインのDKIM秘密鍵を使って暗号化する
  3. サーバーが、暗号化されたハッシュ、セレクター名、署名ドメイン、そしてどのヘッダーが署名されたかについてのメタデータを含むDKIM-Signatureヘッダーをメッセージに追加する
  4. メッセージが受信サーバーに送信される

検証プロセス（受信時）

  1. 受信サーバーが、メッセージからDKIM-Signatureヘッダーを抽出する
  2. 署名からd=（ドメイン）とs=（セレクター）の値を読み取る
  3. <selector>._domainkey.<domain>に対してDNSルックアップを実行し、公開鍵を取得する
  4. 公開鍵を使って署名を復号し、元のハッシュを復元する
  5. 指定されたアルゴリズムを使って、同じヘッダーと本文を独立してハッシュ化する
  6. 2つのハッシュが一致すれば、署名は有効であり、メッセージは本物で改変されていない

このプロセスの詳細な技術的解説については、DKIMの仕組み: メール認証の総合ガイドを参照してください。

検証アルゴリズムのRFCレベルの詳細については、RFC 6376の内部: DKIM検証は実際にどのように動作するかを参照してください。

DKIM-Signatureヘッダー

DKIM署名ヘッダーは次のようになります。

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
    c=relaxed/relaxed; q=dns/txt; t=1618884473;
    h=from:to:subject:date:message-id;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
タグ意味
v=1DKIMバージョン（常に1）
a=rsa-sha256署名アルゴリズム
d=example.com署名ドメイン（DMARCアラインメントに使用）
s=selector1セレクター - どの公開鍵を使うかを識別する
c=relaxed/relaxedヘッダー/本文の正規化（カノニカライゼーション）方式
q=dns/txt公開鍵のクエリ方式
t=1618884473署名のタイムスタンプ
h=from:to:subject:...署名に含まれるヘッダーのリスト
bh=...本文ハッシュ
b=...署名そのもの

DKIM鍵: 公開鍵と秘密鍵

DKIMは非対称暗号を使用します。ドメイン所有者が鍵ペアを生成します。

  • 秘密鍵 - 送信メールサーバー上に安全に保管されます。決して共有も公開もされません。送信メッセージの署名に使用されます。
  • 公開鍵 - <selector>._domainkey.<domain>にTXTレコードとしてDNSに公開されます。受信サーバーが署名を検証するために使用します。

DNSレコードの形式

DKIMのDNSレコードは次のようになります。

selector1._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."
タグ意味
v=DKIM1バージョン
k=rsa鍵の種類（RSAが標準。Ed25519が台頭しつつある）
p=...公開鍵、base64エンコードされたもの

任意のドメインのDKIM公開鍵は、DKIMルックアップツールを使って検索できます。

鍵のサイズ

  • 1024ビットRSA - 推奨される最小の鍵サイズ。今でも広く使われていますが、現代の基準では弱いと見なされています。
  • 2048ビットRSA - 現在推奨されている標準。強力なセキュリティを提供しますが、より長いDNSレコードを生成するため、TXTレコードの分割が必要になる場合があります。
  • Ed25519 - より短い署名と鍵を生成する、新しく効率的なアルゴリズム。対応するメールサーバーは増えていますが、まだ普遍的ではありません。

詳細ガイド: DKIMの暗号アルゴリズムを理解する: RS256 vs RS512と台頭する動向

セレクター: 複数の鍵の管理

DKIMセレクターにより、1つのドメインが複数のDKIM鍵を同時に公開できます。各鍵はセレクター文字列で識別され、DKIM-Signatureヘッダー内のs=タグが、検証にどのセレクター（すなわちどの公開鍵）を使うべきかを受信者に伝えます。

セレクターにはいくつかの目的があります。

  • 複数の送信サービス - 主要なメールサーバーと、各サードパーティサービス（SendGrid、Mailchimpなど）は、それぞれ固有のセレクターを持つ独自のDKIM鍵ペアを持てます
  • 鍵のローテーション - 鍵をローテーションする際、移行期間中は古いセレクターを有効なままにしつつ、新しい鍵を新しいセレクターの下で公開できます
  • 部門別の分離 - 追跡や管理の目的で、異なるチームや部署が異なるセレクターを使用できます

一般的なセレクターの命名規則には、s1、s2、google、sendgrid、k1、または202604のような日付ベースの名前があります。

正規化（カノニカライゼーション）: メッセージの改変への対応

メールメッセージは、転送中に頻繁に改変されます。空白が追加・削除されたり、ヘッダーが書き換えられたり、改行が変わったりします。正規化は、署名と検証のプロセスがハッシュ化の前にメッセージをどのように標準化するかを定義し、軽微な改変によって署名が壊れないようにします。

正規化には2つのモードがあり、ヘッダーと本文に独立して適用されます。

  • simple - ほとんど改変を許容しません。ヘッダーは（末尾の空白を除いて）完全に一致しなければなりません。本文は末尾の空行についてのみ標準化されます。配信経路全体を制御していて、いかなる中継機関もメッセージを改変しない場合に使用します。
  • relaxed - より寛容です。ヘッダー名は小文字化され、空白は標準化され、複数のスペースは1つにまとめられます。本文では、各行の末尾の空白が除去されます。実際のほとんどの運用ではこちらを使用します。

c=relaxed/relaxed設定（ヘッダーと本文の両方にrelaxed）が最も一般的で推奨される構成です。

DKIMアラインメント

DKIMアラインメントは、DKIM署名内のドメイン（d=の値）が、可視のFromヘッダー内のドメインと一致するかどうかを判定するDMARCの概念です。これは重要です。なぜなら、DMARCはSPFまたはDKIMの少なくとも一方が有効かつアラインしていることを要求するからです。

緩和（relaxed）アラインメント

組織ドメインが一致していなければなりませんが、サブドメインは許容されます。例えば:

  • From: user@example.com で d=mail.example.com - 緩和アラインメントを通過（同じ組織ドメイン）
  • From: user@example.com で d=example.com - 緩和アラインメントを通過

厳格（strict）アラインメント

ドメインが完全に一致しなければなりません。

  • From: user@example.com で d=example.com - 厳格アラインメントを通過
  • From: user@example.com で d=mail.example.com - 厳格アラインメントに失敗

詳細ガイド: DKIMアラインメントをマスターする: 鍵、署名、そしてメールが検証に失敗する理由

DKIM鍵のローテーション

DKIMの秘密鍵は、鍵が漏洩した場合の被害を抑えるために、定期的にローテーションすべきです。ローテーションのプロセスは次のとおりです。

  1. 新しいセレクターで新しい鍵ペアを生成する
  2. 新しい公開鍵をDNSに公開する
  3. 新しい秘密鍵で署名するよう送信サーバーを設定する
  4. DNSの伝播を待ち、新しい鍵で署名を検証する
  5. 移行期間後に古い公開鍵をDNSから削除する

どのくらいの頻度でローテーションすべきか？ 普遍的な基準はありませんが、一般的な推奨は6か月ごとから年1回の範囲です。高度なセキュリティを要する環境では、より頻繁にローテーションすることもあります。

詳細ガイド: DKIM鍵はいつローテーションすべきか？

DKIMが失敗する理由

DKIMの検証は、いくつかの理由で失敗することがあります。

転送中のメッセージ改変

署名されたヘッダーやメッセージ本文が署名後に改変されると、ハッシュが一致せず、検証は失敗します。よくある原因は次のとおりです。

  • メーリングリスト — フッターを追加したり、Subject行を変更したりするもの
  • メールゲートウェイ — コンプライアンスやセキュリティスキャンのためにヘッダーを書き換えるもの
  • 転送サービス — メッセージヘッダーを改変するもの

DNSの問題

  • DKIM公開鍵レコードが存在しない、または到達できない
  • 署名内のセレクターが、公開されているどの鍵とも一致しない
  • 鍵のローテーション後のDNS伝播の遅延

設定エラー

  • 秘密鍵が、公開されている公開鍵と一致しない
  • 署名で指定された署名アルゴリズムが、鍵の種類と一致しない
  • h=タグに記載されたヘッダーが、実際の署名計算に含まれていなかった

詳細ガイド:

DKIM vs SPF: 競合ではなく補完

DKIMとSPFは異なる目的を果たし、それぞれ異なる強みを持ちます。

特徴SPFDKIM
検証する内容送信サーバーのIPアドレスメッセージの完全性と発信元
仕組み認可されたIPのDNSルックアップ暗号学的署名の検証
転送後も維持されるかいいえ - 転送で送信IPが変わるはい - 署名がメッセージとともに移動する
内容の完全性を保護するかいいえはい - 改ざんを検出する
DNSレコードの種類ドメイン上のTXTselector._domainkey.domainのTXT
DMARCアラインメントの基準Return-Pathドメイン署名内のd=ドメイン

SPFはメールの転送時に壊れる（転送サーバーのIPが元のドメインのSPFレコードにない）ため、DKIMはしばしば転送されたメッセージで通過する唯一の認証方式です。このため、メーリングリスト、転送ルール、あるいは何らかの中継インフラを使用するドメインにとって、DKIMのアラインメントは不可欠です。

詳細ガイド:

転送・中継されるメールのためのDKIM

SPFに対するDKIMの最も重要な実用上の利点の1つは、メール転送時の挙動です。メッセージが中継サーバー（メーリングリスト、自動転送ルール、または中継サービス）を経由して転送されると、転送サーバーのIPアドレスが元のドメインのSPFレコードに記載されていないため、SPFは壊れます。対照的にDKIMは、メッセージの内容が改変されない限り、転送を経ても維持されます。この設定が初めての方は、AutoSPF FAQで最もよくある設定の疑問に答えています。

これが、次のような環境でDKIMがDMARCコンプライアンスにとって重要である理由です。

  • メーリングリスト - 業界のメーリングリストや社内配信グループに参加している組織
  • メール転送 - あるプロバイダーから別のプロバイダーへメールを転送するユーザー（例: 大学のアドレスをGmailに転送）
  • 共有ホスティング - メールが共有中継サーバーを経由する環境
  • メールゲートウェイ - 内容を改変せずにメールを中継するセキュリティアプライアンス

ただし、中継機関がメッセージの署名された部分を改変すると、DKIMは壊れます。DKIMを壊すよくある改変には、フッターの追加、Subject行の書き換え、添付ファイルの除去などがあります。MailmanやLISTSERVのようなメーリングリストソフトウェアは、しばしばリストのヘッダーやフッターを追加するため、本文ベースのDKIM署名を壊すことがあります。

解決策は、c=relaxed/relaxed正規化（軽微な空白の変更を許容する）でDKIMを設定し、運用しているメーリングリストソフトウェアが可能な限りDKIM署名を維持するよう設定されていることを確認することです。

よくあるDKIM設定パターン

メールインフラの構成が異なれば、必要となるDKIM設定のアプローチも異なります。

単一プロバイダー

すべてのメールが単一のプロバイダー（例: Google Workspace）を経由する場合、そのプロバイダーがDKIM署名を自動的に処理します。プロバイダーが提供する公開鍵をDNSに公開するだけで済みます。

別々のセレクターを持つ複数プロバイダー

複数のサービスがあなたに代わってメールを送信する場合、各サービスは固有のセレクターを持つ独自のDKIM鍵ペアを取得します。例えば:

  • google._domainkey.example.com - Google WorkspaceのDKIM鍵
  • s1._domainkey.example.com - SendGridのDKIM鍵
  • k1._domainkey.example.com - MailchimpのDKIM鍵

各サービスは自身の秘密鍵でメッセージを署名し、受信者はDKIM-Signatureヘッダー内のセレクターに基づいて正しい公開鍵を検索します。

オンプレミス署名

自前のメールサーバー（Exchange、Postfix、Exim）を運用する組織は、独自の鍵ペアを生成し、秘密鍵をメールサーバーにインストールし、公開鍵をDNSに公開する必要があります。鍵ペアは無料のDKIMジェネレーターで作成できます。これにより署名プロセスを完全に制御できますが、鍵の生成、ローテーション、保管を自分で管理する必要があります。

DKIMとTLS: 異なるセキュリティの層

DKIMとTLS（トランスポート層セキュリティ）は、どちらもメールセキュリティに貢献しますが、異なる層で動作します。

  • TLS は、送信中のメールサーバー間の接続を暗号化し、転送中の盗聴を防ぎます。送信者の身元を検証したり、なりすましを防いだりはしません。
  • DKIM は、送信者の身元とメッセージの完全性を検証しますが、メッセージの内容を暗号化はしません。

包括的なメールセキュリティには、両方が必要です。

詳細ガイド: TLSとDKIM: 強力なメールセキュリティに両方が必要な理由

プラットフォーム向けのDKIM設定

DKIMの設定はメールプラットフォームによって異なります。一般的なプロセスは次のとおりです。

  1. DKIM鍵ペアを生成する（通常はメールプラットフォームが行う）
  2. 公開鍵を、正しいセレクターの場所にDNS TXTレコードとして公開する
  3. 送信プラットフォームでDKIM署名を有効化する
  4. DKIMルックアップで設定を検証する

プラットフォーム固有の手順については、以下のガイドを参照してください。

認証スタックの中のDKIM

DKIMは、メールを認証するために連携する3つのプロトコルの1つです。

  • SPF - 送信サーバーが認可されていることを検証する
  • DKIM - メッセージの完全性を検証し、ドメインレベルの署名を提供する（このガイド）
  • DMARC - SPFとDKIMをアラインメント要件で結びつけ、強制ポリシーを定義し、レポート機能を可能にする

DMARCは、SPFまたはDKIMの少なくとも一方が通過し、Fromヘッダーのドメインとアラインしていることを要求します。実際には、SPFとDKIMの両方を設定することでDMARC通過の可能性が最大化されます。なぜなら、一方の方式が失敗しても（例: 転送によりSPFが失敗）、もう一方が有効なアラインした結果を提供できるからです。

詳細ガイド:

診断ツール

次のステップ

  1. 現在のDKIM設定を検証する - DKIMルックアップツールを使って、ドメインに有効なDKIM鍵が公開されているか確認する
  2. アラインメントを確認する - DKIM署名内のd=ドメインが、Fromヘッダーのドメインと一致していることを確認する
  3. 鍵の強度を見直す - 少なくとも2048ビットのRSA鍵を使用していることを確認する
  4. 鍵のローテーションを計画する - ローテーションのスケジュールを確立し、プロセスを文書化する
  5. DMARCを展開する - まだであれば、DMARCを設定してSPFとDKIMのアラインメントを強制し、集約レポートを受け取る
  6. DMARCレポートで監視する - DMARC集約レポートを使って、すべての受信サーバーにわたるDKIMの失敗を特定する
Rated 5/5 on G2 · Trusted since 2018

Trusted by 50,000+ domains

"AutoSPF Flattens SPF Records Seamlessly & Keeps Changes Logged - I am quite pleased with the product"

It does what it promises to do, and does it very well. I appreciate that it keeps a log of changes made, which prevents many mistakes. A client's SPF record would have way too many lookups, but AutoSPF makes that problem go away. The length of the SPF record is typically not the issue; it's the amount of lookups in the record that are. AutoSPF "flattens" the record, automatically expanding the defined lookups to IP addresses or ranges. And it auto-updates the record when the un-flattened lookups change.
PJ

Peter J.

President · Small-Business (50 or fewer emp.)

"Helped us go beyond capacity"

AutoSPF did exactly as described, it helped us get past our 10 lookup limit. Afterwards, we hit another limit regarding overall capacity and when contacted, they quickly provided us with a new solution to eliminate capacity issues entirely going forward, so now we can add as many SPF records as needed. They also provided us with a personalized support video explaining their new method in its entirety using our instance as the example.
VU

Verified User

Financial Services · Mid-Market (51-1000 emp.)

"Great service and great support"

AutoSPF was easy to initially set up on our own and a great cost effective entry into spf flattening. Needed our first support assistance today and got great response including a video demonstrating the issue I was trying to solve, a quick fix, and more detailed followup.
GF

Greg F.

Mid-Market (51-1000 emp.)

Read our reviews on G2