送信するメールには、そのメールがお使いのドメインから送られたことを証明する、目に見えない署名が付いています。DKIMセレクターは、この署名を検証するための鍵がどこにあるかを受信メールサーバーに伝える短い名前です。セレクターはすべてのメッセージに含まれているため、受信トレイに届いた、お使いのドメインからのメッセージのヘッダー、メール送信サービスの設定画面、DNSレコード、DMARCレポートの4か所で確認できます。
このガイドでは、最も手早い確認方法から、ドメインで使われているすべてのセレクターを把握できる方法まで、4つの方法を順に解説します。最後に、見つけたセレクターが正しく機能しているかを確かめる2つのチェックを紹介します。
DKIM（DomainKeys Identified Mail）は、この目に見えないメール署名を実現する標準規格です。お使いのドメインを送信元としてメールを送るサービスは、各メッセージに秘密鍵で署名し、受信サーバーはDNSで公開されている公開鍵を使ってその署名を検証します。1つのドメインは複数の鍵を公開できるため、どの鍵で検証するかを指定する必要があります。この指定に使うラベルがDKIMセレクターです。
セレクターは、DKIM-Signatureヘッダーのs=タグに記載されています。以下は一部を省略した例です。
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2025; ...
この例では、セレクターはmail2025です。受信サーバーはこのセレクターをドメインと組み合わせ、mail2025._domainkey.example.comにあるDNSレコードを参照して公開鍵を取得します。
セレクター名は英字と数字からなる単純なラベルで、署名を設定した人が決めます。実際のセレクターには、mail、k1、s1、selector1、googleのほか、mail2025のように年を含むものがあります。セレクター名は署名のs=タグとDNSレコードの名前の2か所に現れ、この2つは完全に一致している必要があります。
セレクターを最も手早く確認するには、お使いのドメインから送信され、すでに相手に届いたメッセージから読み取ります。メッセージは「送信済み」フォルダからではなく、受信した側の受信トレイから開いてください。「送信済み」フォルダのコピーは、通常、送信メールサーバーがDKIM署名を付ける前に保存されるため、読み取るべきDKIM-Signatureヘッダーが含まれていません。受信したコピーが手元にない場合は、お使いのドメインから別のサービスのメールボックス（個人のGmailアカウントなど）宛てにメッセージを送り、そちらで開きます。続いて、次の手順でメッセージのソースを表示します。
DKIM-Signatureを検索し、s=の後ろにある値を読み取ります。メール送信サービスはお使いのドメインに加えて、サービス自身のドメインでも署名するため、1通のメッセージに複数のDKIM-Signatureヘッダーが付いていることがよくあります。その場合は、d=タグにお使いのドメインが記載されているヘッダーを読んでください。そのヘッダーのs=が、DMARCのアライメント（整合性）の判定に使われるセレクターです。
メールを送信しているサービスでも、認証設定の画面でセレクターを確認できます。
googleです。selector1とselector2という名前の2つのCNAMEレコードを公開します。Microsoft 365は鍵のローテーション（定期的な鍵の交換）を行うたびに、この2つを交互に使います。._domainkeyの前にある部分がセレクターです。オンラインストアでは、2つか3つのセレクターを同時に使っていることがよくあります（たとえば、ECプラットフォームが注文確認メールに署名し、ニュースレターの配信サービスがキャンペーンメールに署名し、それぞれが独自のセレクターを使う構成です）。
DMARCeyeの無料DKIMチェッカーが、DNSでの検索を代わりに行います。下の欄にドメインを入力すると、主要なプラットフォームでよく使われているセレクターをチェッカーが順に調べます。
ここまでの3つの確認方法には共通の限界があり、どの方法でも確認できるのは1通のメッセージか1つのサービスだけです。すべてのセレクターがまとめて表示されるのは、DMARC集約レポートです。DMARC集約レポートは、お使いのドメインを名乗るメールについて、受信メールサーバーが毎日送ってくる要約です。各レポートには、その受信サーバーが確認した送信サービスと、それぞれの認証チェックの結果がセレクターも含めて記載されています。
DMARCeyeはこれらのレポートを代わりに読み解き、どの鍵が有効か、どのサービスがその鍵を使っているか、どこでアライメントの問題が起きているかを表示します。レポートに見覚えのないセレクターがある場合は、確認が必要です。誰かが断りなく連携したサービスか、お使いのドメインになりすました送信者のどちらかだからです。
DMARCeyeの無料プランでは、1つのドメインについてDMARC集約レポートのモニタリングを利用できます。
DKIMが失敗する原因は、次の4つです。
d=にサービス自身のドメインを指定して署名しているため、署名の検証には合格しても、DMARCで求められるお使いのドメインとのアライメントが取れません。こうした設定の問題は、最大手のプロバイダーでもよく見られます。DMARCeyeの2026年第1四半期のデータセットでは、上位10社のESP（メール配信プロバイダー）のDKIM失敗率は、Google LLCが11.1%、Microsoft Corporationが19.6%、Mailgunが22.9%、Proofpointが26.3%です。Proofpointの26.3%は、DMARCeyeが計測した上位10社のESPの中で最も高い値です。
第1四半期レポート自体が指摘しているとおり、主要ESPでコンプライアンスが低い場合、その原因はほぼ常に送信側の設定の問題であり、プロバイダー自体の欠陥ではありません。具体的には、顧客が正しいDKIM鍵をDNSに追加していない、忘れられたツールが誤ったセレクターで署名している、鍵を交換した際に送信サービス側とDNS側の一方しか更新されなかった、といったケースです。
コンプライアンスの数値は、DMARCeyeがモニタリングしている顧客の構成も反映しており、各プラットフォーム全体の顧客ベースとは異なる可能性があります。
セレクターを見つけ、DNSでレコードを参照できることを確認したら、署名から検証までの一連の流れを次のテストでまとめて確かめます。
Authentication-Resultsヘッダーを探し、dkim=passがあるかを確認します。Gmailが付けるこのヘッダーには、検証に使われたセレクターもheader.s=として記載されます。テストに1回合格しても、証明できるのは、そのセレクターがある日に1つのサービスで機能したことだけです。すべてのサービスが正しく署名し続けているかどうかは、DMARCレポートで毎日、全サービス分をまとめて確認できます。
はい、使えます。複数のサービスからメールを送信しているドメインの多くは、複数のセレクターを使っています。各送信サービスはそれぞれ独自のセレクターと独自の鍵で署名するため、たとえばオンラインストアであれば、領収書メール用、ニュースレター用、ヘルプデスク用にそれぞれ1つずつセレクターを持つことがあります。これらのセレクターはDNS上で共存でき、互いに競合することはありません。
いいえ。セレクターはラベルにすぎず、英字と数字からなる短い名前であれば何でも使えます。重要なのは、署名のs=タグにある名前と、公開鍵を格納しているDNSレコードの名前が一致していることです。2つの名前が異なると、鍵そのものが正しくても検証は失敗します。
Microsoft 365がメールに署名する際に、ドメインごとに使う2つのセレクターです。DKIMを設定する際に両方をCNAMEレコードとして公開しておくと、Microsoftは鍵をローテーションするときにこの2つを交互に切り替えます。そのため、ローテーションの最中もメールは認証に合格し続けます。
DKIMセレクターを見つけるのは、調べるだけで済む作業です。配信済みのメッセージでs=タグを読むか、メール送信サービスの認証設定を確認するか、DNSを直接照会します。継続的に必要なのは、すべてのセレクターを機能させ続けることです。サービスが追加されたり、鍵がローテーションされたり、_domainkeyの意味を知らない担当者がDNSレコードを整理してしまったりすることがあるからです。DMARCレポートにはこうした変化がすべて記録されます。DMARCeyeはそのレポートをもとに、お使いのドメインの署名に使われているセレクターと、認証に合格しなくなったセレクターを常に最新の一覧で表示します。