DKIM（DomainKeys Identified Mail）とは何ですか？

DKIM（DomainKeys Identified Mail）は、受信サーバーが、メッセージが送信元と主張するドメインから実際に送信されたものであること、および転送中に内容が改ざんされていないことを確認できる電子メール認証プロトコルです。このプロトコルは、送信されるすべての電子メールに暗号署名を付加し、受信サーバーが、送信元のドメインのDNSに公開されている公開鍵と照合することで機能します。 

このガイドでは、DKIMレコードの形式、署名と検証のプロセスを段階的に解説し、実際のDKIM-Signatureヘッダーの読み方、および最も頻繁に発生するエラーのトラブルシューティング方法について説明します。

DKIMレコードとは何ですか？

DKIMレコードとは、ドメインのDNSにTXTレコードとして公開される一連の指示のことです。これには、メールサーバーが送信メールに署名する際に使用する秘密鍵に対応する公開鍵が格納されています。受信サーバーが署名を検証する際には、このレコードを参照して公開鍵を取得し、その鍵を用いて、メッセージが改ざんされておらず、実際にそのドメインから送信されたものであることを確認します。

DKIMは、もともと2004年にYahooの「DomainKeys」とCiscoの「Identified Internet Mail」が統合されて誕生し、それ以来、最も広く採用されている電子メール認証規格の一つとなっています。

DKIMレコードの形式と命名規則

DKIMレコードはルートドメインには公開されません。これは、セレクタと固定ラベル「_domainkey」を組み合わせて構成された特定のサブドメイン上に存在します。命名規則は以下の通りです：

[selector]._domainkey.[domain]

したがって、yourdomain.com に対して Google セレクタで署名されたレコードは、以下の場所に公開されます：

google._domainkey.yourdomain.com

そのTXTレコードの値は、次のようになっています：

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

各タグにはそれぞれ特定の役割があります：

当社の DKIMジェネレーター を使用して有効なレコードを生成し、当社の DKIMチェッカー ツールで、正しく公開されているか確認できます。

DKIMセレクタとは何ですか？

DKIMセレクタとは、特定のメッセージの署名に使用された鍵ペアを受信サーバーに伝える一意の識別子です。これは、DKIM-Signatureヘッダーのs=タグで定義される英数字の文字列であり、ドメインが複数の鍵を同時に管理できるようにするものです（例えば、メールプラットフォーム用に1つのセレクタ、マーケティングサービス用に別のセレクタを設定するなど）。送信を行う各ベンダーは、それぞれ区別可能な独自のセレクタを使用する必要があります。

たとえば、Google Workspace では「google」がデフォルトのセレクタとして使用されているため、Google によって署名されたメッセージの完全な DNS 検索は google._domainkey.yourdomain.com となります。レコード名が s1._domainkey.yourdomain.com の場合、s1 がセレクタとなります。

セレクタの詳細や、その見つけ方については、当社の詳細な DKIMセレクタ ガイドをご覧ください。 

DKIMレコードとDKIM署名：その違いとは？

この2つの用語は常に混同されがちなので、明確に説明しておく価値があります。DKIMレコードとは、公開鍵を格納するDNS内の静的なTXTエントリのことで、一度公開すればそのまま残ります。一方、DKIM署名とは、送信される各メールに追加される「DKIM-Signature」ヘッダーのことで、秘密鍵を使って生成されます。一方は固定のDNSエントリであり、もう一方はメッセージごとに新たに作成されるものです。このレコードこそが、署名を検証するためのものです。 以下では、署名ヘッダーをフィールドごとに詳しく解説していきます。

後者については、当社の完全ガイド「 DKIM署名の完全ガイドで詳しく学ぶことができます。 

DKIMはどのように機能するのですか？

DKIM認証は、鍵の生成から受信側での最終的な合否判定に至るまで、4つのステップで実行されます。

ステップ 1：鍵ペアの生成

メールプロバイダ、あるいはユーザー自身が、暗号鍵ペア（ 秘密鍵 （送信側のメールサーバー上で秘密に保持される）と、 公開鍵 は、前述のDKIMレコードとしてDNSに公開されます。この2つは数学的に結びついているため、秘密鍵で署名されたものは、それに対応する公開鍵でのみ検証可能です。

ステップ 2：送信メールへの署名

メッセージを送信する際、送信サーバー（メール転送エージェント）は秘密鍵を使用して、メールの特定の部分（署名の h= タグにリストされているヘッダーとメッセージ本文）のハッシュ値を計算し、その結果を送信メッセージの DKIM-Signature ヘッダーとして付加します。

ステップ3：受信サーバーによるDNS検索

受信サーバーは、DKIM-Signatureヘッダーを読み取り、セレクタ（s=）と署名ドメイン（d=）を抽出した後、[selector]._domainkey.[domain]にある公開鍵をDNSに問い合わせます。これは、前述の「DKIMレコード」のセクションで説明した命名規則とまったく同じです。ここで、メッセージごとの署名と静的なDNSレコードが結びつきます。

ステップ4：検証

受信サーバーは、取得した公開鍵を使用して署名を検証し、実際に受信したメッセージから独自にハッシュ値を再計算します。その後、これら2つの値を比較します。一致すればDKIM検証に合格となり、メッセージは改ざんされておらず、署名ドメインによって承認されたものとみなされます。一致しない場合はDKIM検証に失敗し、ドメインのDMARCポリシーに応じて、メッセージにフラグが立てられたり、隔離されたり、拒否されたりすることがあります。 

上記のリンクから、当社の無料DKIMチェッカーツールを利用して、いつでもご自身の設定を確認することができます。

DKIM-Signatureヘッダーの内容 

受信したメールにおける実際のDKIM-Signatureヘッダーは、次のようなものです：

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=google;
c=relaxed/relaxed; h=from:to:subject:date:message-id;
bh=abc123...; b=xyz789...

各フィールドには、受信者がメッセージを検証するために必要な情報の一部が含まれています：

実際に処理を行う2つのフィールドは、bh（ボディハッシュ）とb（暗号署名）です。DMARCにおいて最も重要なのはd=フィールドです。このフィールドが表示されている「From」ドメインと一致していなくても、DKIMは合格しても、DMARCは不合格となる可能性があります。

「カノニカル化」とはどういう意味か？（緩やかなカノニカル化と厳格なカノニカル化）

c=タグは、転送中に生じた軽微な書式変更に対して、その署名がどの程度許容的であるかを定義します。 

リラックスモード （一般的で推奨される設定）は、メールがサーバーを経由する際にほぼ避けられない、わずかな空白やヘッダーの大文字小文字の違いを許容します。 

厳格モード （シンプルモードとも呼ばれる）は、バイト単位での完全一致を要求し、わずかな変更でもエラーとなります。これは重要な点です。なぜなら、メーリングリストや転送サーバーでは、厳格な正規化ではエラーとなるような微細な変更（フッターの追加や行の書き換えなど）が頻繁に行われる一方で、緩和された正規化では問題なく通過してしまうからです。この値は c=relaxed/relaxed のような形式で表され、前者がヘッダーに、後者が本文に適用されます。

DKIMはなぜ重要なのでしょうか？

メールの完全性を検証（改ざんを防止）

この署名は改ざん防止シールのようなものです。送信中にメッセージが傍受され、改ざんされた場合、受信者が再計算したハッシュ値は署名されたハッシュ値と一致せず、検証に失敗して、そのメールは拒否されるか、警告対象となります。これがDKIMの主な役割であり、届いた内容が送信された内容そのものであることを保証することです。

送信者の評判と配信率を保護します

適切に署名されたメールは、メールボックスプロバイダーからの信頼を得ることができます。検証済みで一貫して認証された送信ドメインは、ISP からの評価を高めます。これにより、正当なメッセージがスパムフォルダではなく受信トレイに届く可能性が高まり、マーケティングメールやトランザクションメールの双方にとって直接的なメリットとなります。

（SPFとは異なり）メールの転送にも耐える

これが、この2つのプロトコル間の最も重要な実用上の違いですが、見落としがちです。DKIM署名は メッセージと共に転送されるためため、メールが転送された後も検証が継続されます。対照的に、SPFは送信サーバーのIPアドレスを元のドメインのSPFレコードと照合するため、メッセージが転送されると、転送サーバーのIPアドレスがそのリストに含まれておらず、SPFの検証に失敗してしまいます。そのため、転送されたメールや間接的なメールフローにおいてDMARCの整合性を維持する点では、DKIMの方が2つのプロトコルの中でより信頼性が高いのです。

Google、Yahoo、Microsoftが大量送信者に義務付けている要件

DKIMは、大量送信者にとってオプションではなくなりました。以下に GoogleおよびYahooの要件 （2024年2月に発効）およびMicrosoftの同等の規則（2025年5月から段階的に導入）により、これらのプロバイダーに対して1日あたり約5,000通以上のメッセージを送信するドメインは、DKIM（SPFおよびDMARCと併せて）による認証を行う必要があります。これを怠ると、メールが拒否されたり、スパムとしてフィルタリングされたりするリスクがあります。この閾値を下回る場合でも、DKIMは現在、良好な配信率を確保するための最低限の要件となっています。

DKIM、SPF、DMARC：これらがどのように連携するか

DKIMは、単独ではなく組み合わせて使用されるように設計された3つの電子メール認証規格のうちの1つです。それぞれの役割分担は以下の通りです：

簡単に言えば： SPF は送信サーバーを検証し、DKIMはメッセージの完全性を検証し、 DMARC は、これら2つを、受信者が「From」フィールドで実際に目にするドメインと結びつけ、チェックに失敗した際に受信者がどう対応すべきかを指示するポリシーを追加します。DKIMとSPFが認証を行い、DMARCが整合性の確保と強制を行います。これら3つすべてを導入することが望ましいです。

DKIMでよく見られるエラーとその対処法

「DKIMとは」という検索ワードで上位に表示されるページには、実際にどのような問題が発生するのかを詳しく解説しているものは一つもありません。ここでは、最も頻繁に遭遇する4つの不具合と、それぞれの解決方法をご紹介します。 

DKIM署名が見つかりません

このエラーの意味：このエラーは、受信サーバーがDKIM署名を確認できなかったことを示しています。通常、これは、使用した送信サービスでDKIMが設定されていないか、DNSレコードが公開されていないことを意味します。 

解決方法：ご自身のドメイン名でメールを送信するすべてのサービスでDKIM署名を有効にし、DNSにレコードが存在することを確認してください。

DKIM署名の検証に失敗しました

これはどういう意味か：署名は存在したが検証に失敗しました。これは、署名後に本文または署名付きヘッダーが変更されたことを意味します。最も一般的な原因は、メーリングリストや転送サーバーがフッターを追加したり、件名を書き換えたり、ヘッダーを削除したりしたことです。 

解決方法: 緩やかな正規化を行うことでこの問題は軽減され、ARC（Authenticated Received Chain）は、転送の各ホップ間で認証結果を保持するために特に存在しています。ただし、ARCはまもなく非推奨となる予定であり、DKIM2が導入されれば、転送に伴う問題は大幅に軽減されるでしょう。 

DNS に公開鍵が見つかりません

これはどういうことか: 受信側が公開鍵を検索しましたが、結果が得られませんでした。これは通常、DKIM-Signatureヘッダーと実際のDNSレコード名との間のセレクタまたはドメインの不一致、最近の変更に伴うDNSの伝播遅延、あるいはレコード名の単純な入力ミス（最も多いのは、_domainkeyのアンダースコアが抜けてしまっている場合）が原因です。

解決方法: ドメインをDKIMチェッカーツールでチェックし、すべてのエラーを確認して、一つずつ修正してください。 

鍵が短すぎる／鍵の強度が不十分

これが意味すること：多くの旧式のメールプラットフォームやホスティングパネルでは、依然としてデフォルトで1024ビットの鍵が生成されています。RFC 8301では1024ビットを最低限の基準として扱っていますが、署名には少なくとも2048ビットを推奨しており、NISTは1024ビットRSAを「レガシー用途限定」と分類しています。 Googleなどの主要な受信側は、依然として1024ビットを最低基準として受け入れていますが、2048ビットを推奨しています。したがって、1024ビットの鍵は現時点では完全に無効というわけではありませんが、単に現在の基準を下回っており、そのセキュリティマージンは縮小し続けています。

解決方法: デフォルトとして、rsa-sha256 を使用した 2048 ビットの RSA 鍵を使用してください。アップグレードの際に注意すべき点が 2 つあります。1 つは、2048 ビットの公開鍵は 255 バイトの DNS TXT 文字列 1 つには長すぎるため、同じレコード内で引用符で囲まれた複数の文字列に分割する必要があることです。もう 1 つは、6～12 ヶ月ごとに鍵をローテーションさせる必要があることです。 

DKIMのベストプラクティス

• 1024ビットではなく、2048ビットの鍵を使用してください： 鍵が長ければ長いほどセキュリティは強固になり、主要なプロバイダーからもその採用がますます求められています。
• 鍵は少なくとも年に1回は入れ替える: 切り替え中に認証の空白期間が生じないよう、古い鍵を無効化する前に、新しい鍵をDNSに公開してください。
• 送信されるすべてのメールの送信元に署名を行う： すべてのサードパーティ製サービス（CRM、メールマーケティングプラットフォーム、ヘルプデスク）については、それぞれのセレクタの下で独自のDKIM署名を設定する必要があります。
• 合格・不合格率の監視: DMARCの集計レポートを確認し、配信率に悪影響が出る前に、破損したセレクタや署名のない送信者を早期に発見しましょう。

DKIMの限界

DKIMは不可欠ですが、それだけでは不十分です。以下に、いくつかの率直な制限点を挙げます：

DKIMだけでは、送信元アドレスのなりすましを防ぐことはできません

DKIMは、署名のd=タグに記載されたドメインを認証し、メッセージが改ざんされていないことを確認しますが、d=の値が受信者に表示される「From」アドレスと一致しているかどうかは確認しません。その整合性の確認はDMARCの役割です。また、攻撃者が正規のアカウントやサーバーへのアクセス権を取得した場合、有効に署名されたメールを送信することが可能になります。

DKIMは、DNSの正しい公開に依存しています

レコードの設定ミス、伝播の遅延、または誤ったセレクタがあると、正当なメールであってもDKIMの検証に失敗してしまいます。

DKIM自体は、それ自体ではポリシーを強制しません

DKIMは合格／不合格の結果を示すだけであり、不合格の場合に受信者がどう対応すべきかについては指示しません。DKIM（および／またはSPF）の結果に基づいて隔離や拒否のポリシーを適用するDMARCと組み合わせることで、認証が実際の保護につながるのです。

鍵管理は運用上の複雑さを増す

複数の送信サービスにわたる鍵の管理、安全な鍵のローテーション、およびすべてのサードパーティ送信業者との連携を維持するには、継続的な注意と定期的な監視が必要です。複数のドメインに対してこれらを手作業で行うことは、時間がかかるだけでなく、リソースも大量に消費します。

PowerDMARCでDKIMを有効にする

PowerDMARC を利用すれば、ドメイン所有者はSPFや DMARCと併せて DKIM を設定でき、実時間での監視とレポート機能により、認証結果を追跡し、手動での介入なしにエラーを発生と同時に検知することができます。 

このプラットフォームは、複数のドメインと大量のメールを処理し、 ホスト型DKIMを を他の認証プロトコルと組み合わせることで、メール詐欺に対する包括的な保護を実現しています。DNS設定を手作業で苦労して行う必要はなく、DKIMとDMARCの設定を数分で完了させることができます。

PowerDMARCのホスト型DKIMを利用すると、以下のメリットがあります：

• CNAMEの設定は一度だけ、その後はDNSの編集は一切不要： ドメインを一度接続すれば、その後のセレクターやキーの変更はすべて、更新のたびにDNSを操作することなく、単一のクラウドダッシュボードから管理できます。
• DNSへのアクセスなしでキーをローテーションする： ダッシュボードからキーのローテーションを即座にスケジュールして適用できるため、伝播の遅延や手動でのレコード編集が不要となり、ダウンタイムが発生せず、構文ミスの余地もありません。
• 鍵長の柔軟性が完全： 1024、2048、または4096ビットの鍵長を選択し、認証を中断することなく鍵の強度を向上させることができます。
• 専用のDKIMアナリティクスダッシュボード： メールの送信量、DKIMの通過率、およびセレクタごとのパフォーマンスをリアルタイムで追跡し、状況を迅速に把握してトラブルシューティングを行います。
• マルチドメインおよびMSP対応の管理機能： 企業やサービスプロバイダー向けに構築されたマルチテナントビューを活用し、1か所から数百のドメインおよびサブドメインにわたるDKIMを一元管理できます。
• 1つのプラットフォームに統合された包括的な認証スタック： DKIMはDMARC、SPF、MTA-STS、BIMIと連携し、Google WorkspaceやMicrosoft 365などのプロバイダーと統合されています。

よくあるご質問

1. DKIMとは何の略ですか？

DKIMは「DomainKeys Identified Mail」の略称です。これは、暗号署名を用いて、メッセージが主張されたドメインから送信されたものであり、転送中に改ざんされていないことを検証する電子メール認証プロトコルです。

2. DKIMとは、簡単に言うと何ですか？

DKIMは、メールに貼られた改ざん防止の封印のようなものだと考えてください。送信側のサーバーは各メッセージに秘密鍵で署名し、受信側のサーバーはその署名を、DNSに登録されている公開鍵と照合して確認します。署名が破損していなければ、そのメールは本物であり、改ざんされていないことになります。

3. 自分のドメインでDKIMを設定するにはどうすればよいですか？

DKIMを設定するには、鍵ペアを生成し（メールプロバイダーまたは当社のDKIMジェネレーターを使用）、送信サーバーを構成して送信メールを秘密鍵で署名させ、公開鍵を selector._domainkey.yourdomain.com のTXTレコードとして公開する必要があります。詳細な手順については、当社の DKIM設定 ガイドで、手順ごとの詳細な説明をご確認いただけます。

4. DKIMだけで十分でしょうか？

いいえ。DKIMはメッセージの完全性を検証しますが、表示される「From」アドレスを確認したり、ポリシーを強制したりすることはありません。なりすましに対する完全な保護を実現するには、SPFおよびDMARCと組み合わせて使用する必要があります。

5. DKIMとSPFの違いは何ですか？

SPFは、どのサーバーがあなたのドメインの代わりにメールを送信できるかを許可する（経路の検証）のに対し、DKIMは、メッセージの内容が改ざんされておらず、そのドメインによって署名されていることを検証します（完全性と発信元の検証）。DKIMの署名は転送後も維持されることが多いのに対し、SPFはメールが転送されると通常無効になります。

6. DKIMが正しく設定されているかどうかを確認するにはどうすればよいですか？

DKIMレコードが正しく設定されているかどうかを確認するには、PowerDMARCの無料DKIMチェッカーをご利用ください。ドメインとセレクターを入力するだけで、DNSにクエリを送信し、レコードが公開されており、形式が正しく、取得可能かどうかを確認します。

7. DKIMの検証に失敗した場合はどうなりますか？

DKIMの検証に失敗したということは、そのメッセージが改ざんされたか、適切に署名されていないことを意味します。受信者はこれをスパムとしてマークする可能性があり、DMARCポリシーが適用されており、かつSPFの検証にも合格していない場合、そのメッセージは隔離されるか、あるいは完全に拒否される可能性があります。

8. DKIMキーはどのくらいの頻度で更新すべきですか？

DKIMキーは、少なくとも年に1回は更新する必要があります。古いキーを無効化する前に、必ず新しいキーをDNSに登録してください。そうすることで、メールの検証ができない期間が生じるのを防ぐことができます。

9. DKIMはフィッシングを防止できますか？

DKIMだけではフィッシングを防止することはできません。DKIMはメールの偽造を困難にし、内容の改ざんを防ぐことはできますが、表示される「差出人」アドレスのなりすましを阻止することはできません。それを阻止できるのはDMARCのアラインメントのみです。DKIMはフィッシング対策の構成要素の一つであり、解決策そのものではありません。

10. DKIMはメールの配信率に影響を与えますか？

DKIMはメールの配信率にプラスの効果をもたらします。適切に署名されたメールは、ISPに対する送信者の評判を高め、受信トレイへの到達率を向上させます。また、Google、Yahoo、Microsoftは現在、大量送信者に対してDKIMを必須としているため、DKIMが欠けていると、メールがスパムフォルダに振り分けられたり、配信拒否されたりする可能性があります。