DKIMとは｜必須要件化の背景からSPF・DMARCとの関係まで解説

最終更新日：2026.05.22

DKIM（DomainKeys Identified Mail）は、電子署名を用いてメール送信者のドメイン正当性を検証する送信ドメイン認証技術です。Gmailをはじめとする主要なメールプロバイダの送信者ガイドラインにより、大量配信者に限らずビジネスメールを送信するドメインにおいて、DKIMの導入が必須要件となりました。

本記事では、DKIMが必須条件となった経緯や技術的な仕組み、SPF・DMARCとの関係性を整理します。

※本記事は最新の情報をもとに、2026/5/22に内容を更新いたしました。

DKIMとは？

DKIM（DomainKeys Identified Mail）とは、電子メールの安全性を高めるための送信ドメイン認証技術の一つです。メール送信時に送信元が暗号技術を用いた電子署名を付与し、受信側がそれを検証する仕組みを採用しています。DKIMを導入する目的は、この電子署名によって以下の2つの不正を検知・防止することにあります。

• なりすましの防止： 送信元ドメインが第三者によって偽装されていないかを確認する
• 改ざんの検知： 送信途中でメール本文やヘッダーが書き換えられていないかを保証する

このように、DKIMはメールの送信元の正当性と、内容が改ざんされていないことを同時に証明できる非常に信頼性の高い技術です。そのため、これまで任意とされていたこのDKIM認証が、昨今のセキュリティ環境の変化によって企業にとって対応必須の要件となりました。なぜ今、これほどまでにDKIMの必要性が高まっているのか、その背景を次章で詳しく見ていきましょう。

なぜ今DKIMが必要なのか？ ｜Gmail送信者ガイドラインによる設定の義務化

電子メールがビジネスにおいて不可欠なコミュニケーション手段である一方で、送信元を偽装したフィッシング詐欺や個人情報の盗難といった犯罪が世界的に急増しています。このような脅威から受信者を守り、安全なメール環境を維持するために、主要なメールプロバイダは送信者に対してより厳格な認証を求めるようになりました。その代表的な例がGmail送信者ガイドラインの改定です。 

Google社は、Gmailアカウント宛てに1日あたり5,000件を超えるメールを送信する送信者に対し、SPF、DKIM、DMARCのすべての送信ドメイン認証を設定することを義務付けました。これまで推奨や任意とされていたセキュリティ設定が、明確な必須要件へと変わっています。

未対応によるメール未達・受信拒否のリスク

もしこのガイドラインの要件を満たさないままメールを送信し続けた場合、次のようなペナルティが課されることが明言されています。 

• 迷惑メールへの振り分け： 送信したメールが正当なものとみなされず、受信者のスパムフォルダに強制的に隔離されるリスクが高まります。 
• 受信拒否： 要件を満たさないメールは、Gmailのサーバー側によって段階的に配信を拒否されてしまいます。 

これにより、自社からの重要な通知やメルマガ、商談メールなどが顧客に届かなくなるリスクが生じます。自社メールの到達率を維持するためには、DKIMの導入が必要不可欠です。

DMARC対応を見据えた作成者署名の検討

このガイドラインでは単にDKIMを設定するだけでなく、SPFとDKIMの認証結果をベースに動作するDMARCの認証にも成功することが求められています。DMARC認証をパスするためには、メールの差出人（ヘッダFrom）のドメインと、DKIM認証を行うドメインを一致させる作成者署名での運用が必要となります。そのため、企業がDKIM対応を進める際は、のちに詳しく解説する作成者署名での設定を前提として検討を進める必要があります。

DKIMの仕組みと認証の流れ

DKIM認証は、送信者がメールに付与した電子署名を、受信者が公開鍵暗号方式を用いて検証することで成り立ちます。具体的な認証の流れは、以下の図のステップ（1〜4）の通り、システム間で自動的に実行されます。

ステップ1：送信メールサーバーに秘密鍵を登録  

あらかじめ、メールを送信するサーバー内に署名を行うための秘密鍵が保管・登録されている状態を作ります。この鍵は送信者側だけが厳重に管理し、外部には非公開とします。

ステップ2：公開鍵は送信ドメインのDNSサーバに登録  

秘密鍵とペアになる、暗号を解除するための公開鍵（DKIMレコード）を、送信元ドメインのDNSサーバーにTXTレコードとして登録・公開しておきます。これにより、世界中の受信サーバーがこの公開鍵をいつでも参照できるようになります。

ステップ3：秘密鍵を使って送信メールに電子署名を付与

送信者がメールを送信すると、送信メールサーバーは送り出す直前に、メールのヘッダーや本文などのデータからハッシュ値を計算します。そのハッシュ値を秘密鍵で暗号化して電子署名を作成し、メールヘッダー（DKIM-Signature）に付加して受信者側へ送信します。

ステップ4-1：ドメインの公開鍵情報を要求／返答  

署名付きメールを受け取った受信側のメールサーバーは、メールの差出人ドメインを確認し、そのドメインを管理しているDNSサーバーへ問い合わせて公開鍵情報（DKIMレコード）を要求し、返答を得ます。

ステップ4-2：公開鍵を用いて受信メールの電子署名を検証  

受信サーバーは、DNSから取得した公開鍵を使ってメールに付いていた電子署名を復号し、送信側が作成した元のハッシュ値を取り出します。同時に、受信サーバーは届いたメールのデータから自分自身で新しくハッシュ値を計算し、取り出した元のハッシュ値と照合します。 

• 一致した場合（認証成功）： 2つのハッシュ値が一致すれば、正当なドメイン所有者から送られた本物のメールであること、かつ送信途中で内容が書き換えられていないことが証明され、認証成功となります。 
• 一致しない場合（認証失敗）： 鍵のペアが正しくない場合や、途中でメール本文が書き換えられていた場合はハッシュ値が一致せず、認証失敗（不正なメール）として検知されます。

DKIMと他のメール認証技術（SPF・DMARC）の違い

主要な送信ドメイン認証技術には、DKIMのほかにSPFとDMARCがあります。これらはどれか一つを選んで導入するものではなく、それぞれの弱点を補い合い、組み合わせて使用することで初めて強固なメールセキュリティを実現できる補完関係にあります。各技術の認証アプローチと役割の違いは以下の通りです。

DKIMとSPFの違い

SPFとDKIMは、どちらもメールの送信元が正当であることを証明する送信ドメイン認証技術ですが、認証の仕組みと検証対象が異なります。メール転送によってSPFの認証が失敗判定となった場合でも、データの改ざんがない限りDKIMの認証は成功するため、ドメインの正当性を維持できます。また、SPFでは不可能なメール本文の改ざん検知をDKIMが補完します。

認証技術	認証方法 （何をチェックするか）	メールの転送への耐性	メールの改ざん検知
DKIM	メールに付与された電子署名	強い （サーバーを経由しても署名は不変）	可能 （ハッシュ値で検証）
SPF	送信元のIPアドレス	弱い （転送サーバーのIPに変わるため）	不可 （サーバーの正当性のみ確認）

認証プロセスの違い

• SPF： 送信元のIPアドレスを検証します。ドメイン管理者が、あらかじめ送信を許可するSPFレコードをDNSサーバーに登録しておき、受信側メールサーバーが接続元IPアドレスと照合して正当性を判定します。
• DKIM： メールのデータに付与された電子署名を検証します。送信元ドメインのDNSサーバーに公開されている公開鍵を取得して署名を復号し、データの正当性を判定します。

それぞれの弱点

• SPF：メールの転送が行われると、受信側から見た送信元IPアドレスが転送サーバーのIPアドレスに変わるため、SPFレコードの登録値と一致せず、認証失敗となります。また、送信元サーバーの正当性は確認できますが、送信途中でメール本文やヘッダーが書き換えられた場合にそれを検知する仕様はありません。
• DKIM：電子署名によってメールの内容が送信時のままであることは証明できますが、差出人（ヘッダーFrom）のドメイン自体が詐称されていないかをDKIM単体で検証することはできません。たとえば、第三者のドメインで署名されたメール（第三者署名）であってもDKIMの技術的な認証自体は成功するため、差出人ドメインの偽装を判別できない仕様上の限界があります。

このように、異なる検証方法を組み合わせることで認証の穴を埋めることができるため、両方を併用して設定することが送信ドメイン認証の前提となります。

DKIMとDMARCの違い

DKIMとDMARC（Domain-based Message Authentication, Reporting, and Conformance）も、なりすましメール対策として連携して機能する技術ですが、その役割の次元は根本的に異なります。DKIMが認証を行う技術であるのに対し、DMARCは認証結果に基づいてメールの取り扱いを指示するポリシーです。

認証技術	役割	認証失敗時の動作
DKIM	電子署名を用いて、メールの正当性を認証する技術	規定しない（認証結果を受信側に通知するのみ）
DMARC	SPF/DKIMの認証結果に基づき、メールの取り扱いを指示するポリシー	送信側が指定する（受信拒否、隔離など）

役割の違い

• DKIM： 電子署名によって、メールが正当なドメインから送信され、内容が改ざんされていないかを検証・認証する役割を担います。ただし、認証に失敗したメールを受信側サーバーがどのように扱うべきかについては関与せず、あくまで結果を提示するだけにとどまります。
• DMARC： DKIMやSPFによる認証が失敗した場合に、そのメールを「拒否する」「迷惑メールフォルダに隔離する」「何もしないで受信する」といった具体的な処理方針を、送信側ドメインが受信側サーバーに対して明確に指示するための仕組みです。

DMARCによる差出人の偽装の検証

さらにDMARCは、ユーザがメール画面に表示される差出人（ヘッダーFrom）のドメインと、SPFやDKIMで認証ドメインが一致しているかを検証します。このドメインの一致（整合性）をアライメントと呼び、アライメントを検証することで、SPFやDKIMの単体運用では防ぎきれなかった差出人ドメインの偽装を遮断します。DMARCの判定基準やアライメントについては次の記事を参考にしてください。

DMARCのアライメントとは？ SPF・DKIMアライメントをPassするためのポイント – ベアメールブログ

このように、DKIMやSPFが認証の合否を判定する技術であるのに対し、DMARCはその認証結果に基づいて受信側の挙動を送信側から制御する仕組みです。3つの技術を統合して運用することで、強力ななりすましメール対策が実現します。

DKIMがメール送信において重要な理由

DKIMがメール送信において極めて重要な役割を担う理由は、次のとおりです。

電子署名によるデータの完全性担保（改ざん検知）

DKIMの本質的な役割は、送信側で付与した電子署名を受信側で検証し、メールの送信ドメインの真正性とデータの完全性を証明することです。これにより、メールが送信されてから受信側に届くまでの配送途中で、本文や添付ファイル、重要なヘッダー情報が第三者によって書き換えられていないかを確実に検知するシステムを確立できます。

スパム誤判定による受信ブロックリスクの抑制

DKIM認証の成否はスパム判定の重要な判断材料です。認証を成功させることで、スパムフィルターの判定による迷惑メールフォルダへの隔離や受信拒否のリスクを最小限に抑えます。DKIMの導入は到達率の向上を保証するものではありませんが、正常な配信環境を維持するために不可欠な役割を担います。スパム判定の仕組みの詳細は次の記事をご確認ください。

送信メールの件名に[spam]と付く原因は？ スパム判定の仕組みと改善方法を解説｜ベアメールブログ

共有IP環境におけるドメイン評価の独立

主要なメールプロバイダは、送信元ドメインごとの過去の配信実績を元に、ドメインレピュテーションを独自に算出・更新しています。メール配信サービスなどの共有IPアドレス環境を利用している場合、自社ドメインによるDKIMの作成者署名を運用することで、同じIPを共有する他者の影響を受けることなく、自社の正規な配信実績のみを受信側プロバイダに正しく評価させることが可能になります。ドメインレピュテーションの詳細については次の記事をご確認ください。

IPレピュテーションとドメインレピュテーションとは？ レピュテーション向上のポイントを解説｜ベアメールブログ

DKIM署名の種類

DKIMの電子署名には、署名に利用するドメインによって「作成者署名」と「第三者署名」の2種類が存在します。どちらを選択するかは、利用しているメール送信環境や、DMARCへの対応方針によって異なります。それぞれの特徴を理解し、自社に適した方式を選びましょう。

作成者署名

作成者署名（Author Domain Signatures）は、メールの送信者自身のドメインを用いて電子署名を付与する方式です。

仕組みと特徴

自社のメールサーバー、またはカスタマイズした外部メール配信システムで署名処理を行い、自社ドメインのDNSサーバーにDKIMの公開鍵（TXTレコード）を設定します。受信サーバーは、メールの差出人ドメインのDNSから公開鍵を参照して検証を行います。 

メリットと導入の必要性

メールソフト上で表示される差出人（ヘッダFrom）のドメインと、DKIM認証を行うドメインを完全に一致させることで送信者の真正性を証明できるため、DKIM単体としての認証強度が強くなります。さらに、ドメインが一致していることが必須要件となるDMARC認証にも成功します。セキュリティと自社ブランドの信頼性を担保する観点から、企業においては基本的にこの作成者署名での運用が推奨されます。

第三者署名

第三者署名（Third-Party Signatures）は、メール送信者自身のドメインではなく、利用しているメール配信サービスなど、送信者以外の外部サービスのドメインを利用して電子署名を付与する方式です。

仕組みと特徴

図に「第三者署名の場合、対応の必要なし」とある通り、メールへの署名付与や公開鍵の設定などはすべてサービス事業者側の設備で行われます。自社ドメインのDNSサーバーに手を加える必要がありません。 

デメリットと運用の限界

利用者は個別のDNS設定を行う必要がないため導入のハードルは極めて低いですが 、検証されるドメインが外部システムのものになるため、本当にその作成者のドメインから送られたメールなのかを直接証明することができず、認証の強度は弱まります。また、ユーザが目にする差出人（ヘッダFrom）とDKIM認証ドメインが不一致となるため、DMARC認証は失敗してしまいます。 

外部メール配信サービス利用時の解決策

マーケティング用のメルマガ配信などで外部のSaaSを利用する場合、デフォルトの初期設定では第三者署名になっているケースが少なくありません。しかし、多くの主要サービスでは、管理画面から自社ドメイン専用の鍵を生成し、自社のDNSサーバーに登録することで作成者署名へ切り替える機能が用意されています。自社の環境でDMARC対応を進める場合は、必ずこの設定を行い、作成者署名での認証を通すように設定しましょう。

DKIMのセレクタとは

DKIMを実務で運用する上で、あわせて知っておくべき重要な概念がセレクタ（Selector）です。セレクタとは、DNSサーバーに公開された公開鍵を識別するための名前のことです。DKIMでは、1つのドメインに対して複数の公開鍵・秘密鍵のペアを同時に登録・運用することができますが、受信サーバーがどの鍵を使って検証すればよいか迷わないよう、メールヘッダーとDNSレコードの双方に同じセレクタ名を記載して紐付けを行います。

主に以下のようなケースで、複数のセレクタを使い分ける必要があります。

• 自社の基幹システムからの通知メールと、外部のマーケティング用メルマガ配信サービスで、それぞれ異なる鍵を発行して運用するケース。
• セキュリティ向上のために古い鍵から新しい鍵へ移行する際、新旧の鍵を一時的に並行稼働させるケース。

なお、自社に最適なセレクタの決め方や、詳細な仕組み、実際の確認方法などについては、以下の記事で詳しく解説しています。

DKIMセレクタとは？ 仕組みや命名規則、メールヘッダからの確認方法を解説｜ベアメールブログ

DKIM認証結果の確認方法

自社の環境にDKIMを設定した後、正常に機能しているかを検証する最も確実な手法は、テストメールを送信して受信ヘッダーを直接確認することです。なお、DNSレコードの変更が世界中のサーバーに反映されるまでに、数分から最大24時間程度のタイムラグが生じる場合があるため、レコードの反映を確認してから検証を開始しましょう。

受信ヘッダー情報の確認手順

• 署名を有効化した送信環境から、Gmailなどの検証用受信アドレスへテストメールを送信します。
• 受信したメールのメニューから、メッセージのソース表示（またはメールヘッダーの全表示）を選択します。 
• ヘッダー情報内に記述されている Authentication-Results の行を確認します。 
• 同項目内の dkim= のステータスが pass と記録されていれば、受信側での公開鍵取得と電子署名の検証が正常に成立しています。 

もし結果が pass 以外のステータスの場合は、設定の修正が必要です。各ステータスが持つ技術的な意味の解説や、詳細な認証結果の確認方法については、以下の記事を参照してください。 

DKIM認証が失敗する原因は？認証結果の見方とDKIM fail時の確認ポイントを解説 – ベアメールブログ

DKIMレコードの設定手順

DKIMの有効化は、暗号鍵ペアの生成、DNSサーバーへの公開鍵レコード登録、送信システムでの署名有効化という共通のプロセスを経て行われます。実際の作業手順は、利用している配信環境によって異なります。

メール配信サービス（SaaS）を利用している場合

外部のメール配信サービスを利用する場合、システム側のインフラで署名処理が行われるため、設定負荷は低くなります。デフォルト状態では第三者署名に設定されているケースが多いため、作成者署名での運用が必要な場合は、以下のカスタムDKIM設定を実行します。

対応の流れ

• メール配信サービスの管理画面で、対象ドメインのDKIM（ドメイン認証）機能を有効化する
• 画面に提示されたDNSレコード（TXT形式またはCNAME形式）を確認する
• 自社ドメインを管理するDNSサーバーのゾーン構成に、提示されたレコードを追加する
• DNSへのレコード反映完了後、管理画面上の認証ステータスが成功に変わったことを確認する

外部サービス側の仕様に応じて、セレクタ名の指定や、ベンダー側による鍵の定期ローテーション（自動更新）機能の有無を確認しておく必要があります。

自社でメールサーバーを運用している場合

Postfixなどのメールサーバーを自社で構築・運用している場合、電子署名を行うための専用ミドルウェア（OpenDKIMなど）の導入、秘密鍵・公開鍵の作成、およびMTAとの紐付けをすべて手動で行う必要があります。

対応の流れ

• 送信メールサーバーにOpenDKIMなどの署名用ソフトウェアをインストールする  
• 秘密鍵と公開鍵のペアを生成し、秘密鍵はサーバー内の指定ディレクトリに保管する  
• ペアとなる公開鍵のデータを、自社ドメインのDNSサーバーにTXTレコードとして登録する  
• メールサーバーの設定ファイルを編集し、送信メールへの署名付与を有効化する  

セキュリティ強度を維持するため、秘密鍵および公開鍵は定期的に手動で更新（ローテーション）する計画を策定して運用します。 

DKIMレコードの具体的な書き方と設定手順

DNSに登録するTXTレコードのホスト名の仕様（[セレクタ名]._domainkey.[ドメイン名]）や、レコードの値に記述する各タグ（v=, k=, p= など）の詳細な意味については、以下の解説記事を参照してください。また、同記事では「お名前.com」や「Amazon Route 53」といった具体的なDNSサービス別の設定手順や、2048ビットの長い公開鍵を登録する際の文字数制限対策（レコードの分割登録手順）についても詳しく解説しています。 

DKIMレコードの書き方は？設定・確認方法や失敗例も解説 – ベアメールブログ

PostfixとOpenDKIMを組み合わせた具体的な設定パラメーターやコマンドの詳細については、以下の記事を参照してください。

OpenDKIM×Postfixを使ってDKIMを設定する – ベアメールブログ

DKIM設定における代表的なエラーと対処法

DKIMの確認時、および導入後の運用において発生頻度の高いエラー事象とその解決策です。

署名の整合性が取れません（DKIM Verification Failed）

• 原因：メール送信時に付与された電子署名と、受信側が受け取ったメールデータから再計算したハッシュ値が一致しない場合に発生します。主に、メールが転送サーバーを経由する過程で、メーリングリストのフッター追加やヘッダーの書き換えなどが起きたことが原因です。
• 対処法：署名対象とするヘッダー項目を必要最小限に限定する、または転送システムの配送仕様を見直すことで、ハッシュ値の不一致を回避します。

DNS設定が反映されません（公開鍵が検出できない）

• 原因：受信側サーバーがDNSから公開鍵レコードを取得できない状態です。DNSサーバーへの入力ミスや、DNSのTTLによる反映遅延が考えられます。
• 対処法：外部のレコード検証ツールを使用し、登録したホスト名と値が正確に応答を返すか確認します。記述に誤りがない場合は、設定したTTLの時間が経過するまでテスト送信を待ち、キャッシュがクリアされた後に再検証を行います。

DKIM認証結果や迷惑メール判定リスクをまとめて確認するには

ベアメールの「迷惑メールスコアリング」では、テストメールを送信するだけで、DKIMをはじめSPF・DMARCの認証結果を確認できます。

さらに、送信元IPアドレスの評価、ブラックリストの登録状況、メール本文の内容、キャリアごとの到達度なども総合的に分析し、迷惑メールと判定されるリスクを可視化することが可能です。

メールの認証状況や配信環境の状態をひと目で確認できるため、認証エラーの原因特定や改善ポイントの把握に役立ちます。

「DKIM認証がエラーになる原因を知りたい」「メールの配信状況を確認したい」といった場合は、ぜひお気軽にご相談ください。

まとめ

本記事では、DKIMの仕組み、SPFやDMARCとの違い、導入方法などについて解説してきました。スパム対策が強化されている昨今では、DKIMに対応できていないメールは迷惑メールとして扱われるリスクが高まっています。迷惑メールと判定されず、メールをより確実に相手に届けるためにも、DKIMの導入を検討してみてはいかがでしょうか。