DKIMとは？メール認証標準をわかりやすく解説
要約
DKIMはRSA公開鍵暗号を使用して、送信メールに検証可能な送信元の主張を付与します。送信サーバーは秘密鍵で各メッセージに署名します。受信MTAはセレクターラベルを使用してDNSで公開鍵を検索し、署名を検証して結果を報告します。DKIMは単独では何もブロックしません：DMARCポリシーの適用と評価スコアリングを条件付けるパスまたはフェイルシグナルを生成します。
DKIMとは（DomainKeys Identified Mail）、メール認証のための暗号プロトコルです。DKIMとは何かを実務的に説明すると、メールサーバーが送信するすべての送信メッセージにRSA署名を付与するシステムです。受信側のMTAはDNSから公開鍵を取得し、署名を検証して、結果を dkim=pass または dkim=fail として報告します。この結果はドメインの評価モデルに反映され、DMARCアライメントが維持されるかどうかを決定します。有効な署名がなければ、受信側のMTAはメッセージがあなたのインフラから来たという暗号的な確認を持ちません。
DKIMは署名プロトコルであり、フィルターではない
この名称はよくある誤解を招きます。DKIMはメールをブロックしません。メッセージを隔離したり、独自にポリシーを適用したりすることもありません。DKIMが行うのは、各送信メッセージに検証可能な主張のスタンプを押すことです。このメッセージは d= フィールドのドメインによって、セレクター s= に対応する秘密鍵を使用して署名されました。
受信側のMTAはその主張を取得し、<セレクター>._domainkey.<ドメイン> へのDNSクエリを構築し、公開鍵を含むTXTレコードを取得して、暗号検証を実行します。検証に成功すると、認証結果ヘッダーに dkim=pass が表示されます。失敗すると、dkim=fail または dkim=temperror が表示されます。
いずれの結果もそれ自体では拒否を引き起こしません。このシグナルは受信サーバーの評価モデルに反映され、そして重要なこととして、DMARC評価にも反映されます。DKIMの役割は検証可能な結果を生成することであり、それに基づいて行動することではありません。
DKIMが署名するものと署名が対象とするもの
DKIMは二つのものに署名します：選択されたメッセージヘッダーとメッセージ本文です。署名アルゴリズムは両方をハッシュし、その結果を DKIM-Signature ヘッダーフィールドに格納します。
ヘッダーリストは署名内の h= タグによって制御されます。典型的なプロダクション設定では from:subject:date:message-id:content-type が含まれます。DMARCアライメントに関連するヘッダーは from ヘッダーです。本文ハッシュは、simple または relaxed の正規化によって正規化されたメッセージ本文全体をカバーします。
relaxed 正規化は、ほとんどのプロダクションスタックが使用するものです。ハッシュ前に空白を正規化するため、署名がリレーMTAによる小規模な再フォーマットを乗り越えることができます。simple はより厳格で、末尾の空白が一文字変わるだけで署名が壊れます。適切に設定されたほぼすべてのESPの DKIM-Signature フィールドには c=relaxed/relaxed が表示されます。
DKIMが署名しないもの：SMTPエンベロープ送信者、Received などのルーティングヘッダー、および h= リスト以外のヘッダー。これは意図的な設計です。エンベロープに署名するとフォワーディングシナリオが壊れてしまい、それがSPFに対するDKIMの優位性の根拠です。
セレクター：ラベルとして扱われているアクセス制御メカニズム
セレクターは、ほとんどのチームが圧力下でキーのローテーションを余儀なくされるまで過小評価するDKIMの部分です。
DKIM-Signatureの s= フィールドは、DNS内の特定の公開鍵を指します。ルックアップ形式は <セレクター>._domainkey.<あなたのドメイン.com> です。セレクターが mail2026 でドメインが example.com の場合、リゾルバーは mail2026._domainkey.example.com のTXTレコードを検索します。
一つのドメインは複数のアクティブなセレクターを同時に持つことができます。各送信サービス、各ESP、各内部MTAはそれぞれ独自のセレクターを使用すべきです。これにより三つの具体的な運用上の能力が得られます：
他の送信者に影響を与えずにサービスごとに独立したキーローテーション。
認証ログでの追跡可能な帰属：セレクターは特定のメッセージでどの署名キーが使用されたかを示します。
クリーンなオフボーディング：セレクターのDNSレコードを削除すると、そのESPはあなたのドメインとして署名できなくなります。
トレースで観察されること：すべての送信サービスに共有セレクターを設定したチームは、他のすべてを中断させずに一つの送信者のアクセスを取り消すことができません。セレクターは装飾的なものではありません。アクセス制御メカニズムです。
DKIMとDMARCアライメント：エンフォースメント層の仕組み
DKIMの通過は、DMARCアライメントと呼ばれる特定のタイプのDMARC通過の前提条件です。
DMARCは二つのアライメント条件のうち少なくとも一つを必要とします：SPFアライメントまたはDKIMアライメント。DKIMアライメントとは、From: ヘッダーのドメインがDKIM署名の d= 値と一致し、署名が検証されることを意味します。両方の条件が満たされると、DMARCはメッセージを認証済みとみなします。
これがDKIMがより耐久性のある認証シグナルである理由です。SPFアライメントはフォワーディングで壊れます：メッセージが転送されると、SMTPエンベロープ送信者が変わり、SPF評価は新しい送信IPに対して失敗します。DKIMアライメントはフォワーディングを乗り越えます。なぜなら、署名と From: ヘッダーはメッセージ本文と共に移動し、転送中にメッセージ本文が変更されない限り、リレーMTAによって書き換えられることがないからです。
DMARC ポリシーが p=reject のドメインでは、SPFとDKIMの両方のアライメントに失敗したメッセージは受信MTAによって拒否されます。これがあなたのドメインからの偽装メールが大規模にインボックスに届くのを阻止するメカニズムです。DKIMはここでの最後の防衛線ではありません。しかし、フォワーディングが経路にある場合に持ちこたえる防衛線です。
2024年以降、Google、Yahoo、MicrosoftはMXに1日5,000件以上のメッセージを送信する大量送信者にDKIMを要求しています。未署名のドメインからのメッセージはデフォルトでスパムにルーティングされるか、拒否されます。
これはマーケティング機能ではありません。インフラの制約です。
キー長とローテーション：2026年の実践的な意思決定
ほとんどのDKIM実装はRSA-SHA256を使用しています。核心的な問題はキー長です。
1024ビットのRSAキーはレガシー設定にまだ登場します。NISTは2015年にほとんどのユースケースで1024ビットRSAを廃止しました。2048ビットキーは大幅に強力なマージンを提供し、すべての主要なMTAと受信プロバイダーでサポートされています。今日新しいキーを生成する場合は2048ビットを使用してください。
一部のチームはアクティブな署名キーを2048ビットに移行しましたが、誰も在庫を監査しなかったため、古い1024ビットセレクターをDNSに公開したままにしています。システムの動作を変える三つのシグナル：古いセレクターに k=rsa と1024ビットキーが表示されている場合、現在の署名インフラがすでに移行していても、そのセレクターは脆弱性です。有効だが廃止されたセレクターは悪用可能です。
キーローテーションスケジュール：ほとんどのインフラチームは年に1回ローテーションし、より機密性の高いドメインには四半期に1回ローテーションするチームもあります。順序が重要です：
新しいキーペアを生成する。
DNSの新しいセレクター名の下に新しい公開鍵を公開する。
TTLの伝播を待つ。通常、低いTTLのレコードでは24〜48時間かかります。
MTA設定の署名キーを新しいセレクターに切り替える。
メールテストツールを通じて、または送信テストメッセージの認証結果ヘッダーを検査することで、送信メッセージのDKIMパスを確認する。
新しいキーがライブで正しく署名していることを確認した後、古いDNSレコードを削除する。
順序に従えばローテーションは中断なしに行えます：最初にDNS、次に署名の切り替え、最後に古いレコードの削除。ステップ4と6を逆にすると dkim=fail ウィンドウが発生します。
DKIM設定後に追跡すべき運用シグナル
DKIMは一度きりの設定タスクではありません。以下のシグナルは何かが変化したか、壊れたことを示しています。
受信ヘッダーに dkim=temperror。 一時的な失敗は通常、受信側でのDNSルックアップの問題、またはキーローテーション中のTTLの不一致を示します。キーローテーション直後に送信メッセージでこれが表示された場合は、キー自体の設定ミスと結論付ける前に完全な伝播を待ってください。
送信したメッセージに dkim=fail。 中間リレーによる本文の変更が最も一般的な原因です。配信経路にフォワーディングホップ、メーリングリストプロセッサ、またはフッター挿入リレーがあるかどうかを確認してください。失敗が単一のフローで一貫している場合は、ホップごとにリレーチェーンをマッピングしてください。
DKIM-Signature ヘッダーが完全に欠如。 MTAの署名デーモンが実行されていないか、署名キーのパスが間違っているか、MTA設定でドメインセレクターのマッピングが誤って設定されています。これは影響を受けるメッセージフローに対するDKIMの完全な停止です。
セレクターTXTレコードがDNSにない。 DKIMセレクターレコードを保持せずにDNSゾーンが編集または移行されました。外部リゾルバーから dig TXT <セレクター>._domainkey.<ドメイン> で確認してください。
マルチリージョン送信設定では、ノード間でDKIM結果が一貫していない場合は、異なるノードが異なるセレクター設定を使用していることが原因であることが多いです。ローテーションを展開する前に、すべての送信ノードで署名キー設定が同期されていることを確認してください。
DKIMが保護しないもの
DKIMはスパムフィルターではありません。送信者は新しいドメインを登録し、有効なDKIMを設定して、完全に認証されたスパムを送信することができます。署名はクリーンに検証されます。認証は起源を確認しますが、意図やコンテンツの品質を確認するものではありません。
DKIMは表示名スプーフィングも対処しません。表示名スプーフィングでは、From: ヘッダーに「給与チーム」などの信頼できる名前が表示され、攻撃者が制御するドメインと組み合わされます。暗号検証はドメインで動作し、MUAでの視覚的なプレゼンテーションでは動作しません。MUAレベルのフィッシングのほとんどは、正確なドメインスプーフィングではなく、表示名の欺瞞に依存しています。
DKIMが保護するもの：攻撃者があなたの秘密鍵を持たずにあなたのドメインとして送信しようとする正確なドメインスプーフィング。DKIMアライメントを強制する p=reject DMARCポリシーと組み合わせると、DMARCを適用している受信プロバイダーで偽装メッセージのクラスがインボックスに届くのを防ぎます。
実用的な注意：DKIMだけでは不十分です。保護モデルには受信MTAでのDMARCポリシーの適用が必要です。DKIMはDMARCを意味のあるものにする認証レイヤーです。SPFはもう一つの認証レイヤーで、エンベロープ送信者の検証を処理します。三つすべてが協力して機能します。いずれか一つが欠けていると、エンフォースメントチェーンにギャップが残ります。
DKIMとSPFをすでに設定していてもDMARCレコードをまだ公開していない場合、署名は存在しますが、アクティブなエンフォースメントポリシーはありません。監視モード（rua レポーティングを持つ p=none）は合理的な最初のステップです：p=quarantine または p=reject にコミットする前に、送信ドメイン全体の認証合格率を示す集約レポートを受け取ります。