DKIMセレクタの確認方法｜メールヘッダーのd=・s=と見つからないときの対処
DKIMのセレクタが分からないときの最短の答えは、問題が起きている送信経路から自分宛にテストメールを送り、届いたメールのソースに含まれる DKIM-Signature ヘッダーの d= と s= を確認することです。DNSへの照会先はこの2つの値から決まり、s._domainkey.d という形になります（RFC 6376 §3.6.2.1）。s= だけでは照会先は決まりません。
以降で、この確認の手順と、ヘッダーを見ても分からなかった場合にすることを順に説明します。
まずDKIM-Signatureのd=とs=を確認する
DKIMのセレクタは、DNSに登録された公開鍵を指す識別子です。セレクタ名._domainkey.ドメイン名 という形式でTXTレコードとして公開されており、受信側はこれを引いて署名を検証します。
このセレクタ名を最も確実に確認できる場所は、実際に送られたメールのヘッダーです。
- 問題が起きている送信経路から、自分宛にテストメールを送ります。同じドメインでも、ホームページのフォーム通知、メール配信サービス、日常のメールソフトではDKIMの署名元が別々に設定されていることが珍しくありません。問い合わせフォームからの通知が届かないのであれば、そのフォームから送信して確認してください。日常のメールソフトから送って確認しても、原因の切り分けにはなりません
- 届いたメールの元のメッセージ（ソース）を表示します。Gmailであれば該当メールを開き、右上のその他アイコンから「メッセージのソースを表示」を選びます
DKIM-Signature:で始まる行を探し、d=とs=の値を読み取ります
RFC 6376 §3.5では、d= を「メッセージを送信する責任を持つドメイン（署名ドメイン識別子、SDID）」、s= を「その d= の名前空間を細分化するセレクタ」と定義しています。そして §3.6.2.1 では、d=example.com と s=foo.bar の場合にDNSへの照会先が foo.bar._domainkey.example.com になるという例を示しています。つまりDNSへの照会は s= 単体では成立せず、常に d= と組み合わせて行われます。
セレクタ名だけをメモして「セレクタはこれです」と管理画面や本サイトの入力欄に貼り付けても、対象ドメインが違えば公開鍵は見つかりません。d= と s= は必ず対で扱ってください。
複数のDKIM-Signatureがある場合の読み方
1通のメールに DKIM-Signature が複数含まれることがあります。メーリングリストや転送サービスを経由した場合、送信サービスに加えてリスト側・転送側の署名が追加で付くためです。
この場合、各行の d= と s= は必ず対で読んでください。1行目の d= と2行目の s= を組み合わせるような読み方をすると、存在しないドメインの照会先を作ってしまいます。
もう1つ注意したいのは、Fromアドレスのドメインと d= が同じとは限らない点です。送信サービスによっては、自社のドメイン（例: 配信サービスのドメイン）で署名し、Fromアドレスは利用者の独自ドメインのままという構成があります。この場合、DMARCの判定ではFromドメインと d= が一致しているか（アライメント）が別途問われますが、それは「セレクタが分からない」とは別の論点です。この記事では扱いません。
ヘッダーに署名自体が無い場合
DKIM-Signature の行そのものが見つからないこともあります。これは「セレクタが分からない」より手前の状態です。その送信経路でDKIM署名が有効化されていないか、送信サービス側の設定が済んでいない可能性があります。
ここで注意したいのは、テストに使った1つの経路にDKIM-Signatureが無かったからといって、そのドメイン全体でDKIMが設定されていないと断定はできない点です。分かるのは「そのテストで使った送信経路が、その時点で署名していなかった」ことだけです。別の送信経路（例えばWeb制作会社が別のメール配信サービスを併用している場合など）では署名が付いていることもあります。
送信経路ごとの設定状況を含め、DKIMやSPF、DMARC全体の見え方については独自ドメインのメールが届かない原因は？送信・受信を切り分けるでも整理しています。
診断結果「セレクタを特定できませんでした」の意味
メールヘッダーを確認する手段がない、あるいはこれから確認する前に、まずDNS側からセレクタを推測して調べたい場合もあります。本サイトの診断ツールは、MXレコードとSPFレコードから利用中のメール基盤を推定し、そのサービスでよく使われるセレクタ名を自動で試します。セレクタ名を入力しなくても一定の確認ができるのはこのためです。
ただし、この探索で見つからなかった場合の意味は一律ではありません。診断結果は次の3つに分かれます。
- DKIMセレクタを自動判別できませんでした（参考）。ドメインが
*._domainkeyにワイルドカードを設定しており、存在しないセレクタに対しても応答を返す構成になっています。この場合、推測による探索自体が成立しません - DKIMが設定されていない可能性があります（要修正）。利用中のメール基盤が判明しており、その基盤の既定セレクタを試しても公開鍵が見つからない場合です。この場合は未設定の可能性が高いと判断できます
- DKIMセレクタを特定できませんでした（要確認、この記事が扱う所見）。メール基盤が判明していない、または判明した基盤がドメインごとに固有のセレクタを発行する方式（後述するAmazon SESやHubSpotなど）で、既定のセレクタ候補が存在しない場合です
3つ目に該当する場合、「未設定」とは書きません。DKIMのセレクタは自由な文字列を使えるため、よく使われる候補で見つからないことは、そのドメインにDKIMが存在しないことの証明にはならないからです。日付を使ったセレクタ名を採用しているサービスもあります。
利用しているサービスの、実ドメインで確認できたセレクタ候補
セレクタ名を推測で書くと、間違った値をDNSに登録させてしまう恐れがあります。本サイトでは、対象のサービスを実際に利用しているドメインに問い合わせて、公開鍵が実在することを確認できたものだけを次の表にまとめています。
| サービス | 確認できたセレクタ |
|---|---|
| Google Workspace | google |
| Zendesk | zendesk1 / zendesk2 |
| Microsoft 365 | selector1 / selector2 |
| SendGrid | s1 / s2 |
| Mailchimp | k1 / k2 / k3 / mandrill |
| エックスサーバー | default |
| Postmark | pm |
検証方法は npm run verify:selectors（scripts/verify-selectors.mjs）で対象ドメインに実際にDNS問い合わせを行うというものです。実ドメインでの確認数は、Google Workspace 12件、Zendesk 10件、Microsoft 365 5件、SendGrid 3件、Mailchimp 3件、エックスサーバー 1件、Postmark 1件です。件数は「標準的な値であること」を保証するものではなく、実際に確認できたドメイン数を示しています。
この表は「サービス名からセレクタの候補を引く」片方向の対応表であり、逆方向には使えません。例えばMailchimpの確認済み候補である k1 は、本サイトのセレクタ候補リスト上ではMailgun（こちらは未確認）にも登録されています。同じ文字列が複数のサービスで使われることがあるため、s=k1 という値だけを見て送信サービスを逆引きすることはできません。特定するには、前述のメールヘッダーの d= を確認するか、実際に利用しているサービスの管理画面で確認してください。
表にないサービスをお使いの場合は、まずメールヘッダーで確認するか、そのサービスの管理画面でセレクタ名を確認してください。
Amazon SESやHubSpotなど、セレクタがドメインごとに固有のサービス
一部のサービスは、ドメインごとに異なるセレクタを発行するため、既定のセレクタ候補を用意できません。
Amazon SESのEasy DKIMは、ドメインごとにランダムなトークンを含む3本のCNAMEレコードを発行します。SESコンソールの「Verified identities」で対象のドメインを開き、「Authentication」タブの「View DNS records」から、この3本のCNAMEレコードを確認できます（AWS公式ドキュメント）。
HubSpotもDKIM用に2本のCNAMEレコードを発行します。設定アイコンから「Content」内の「Domains & URLs」を開き、「Email Sending」タブから確認できます（HubSpot公式ドキュメント）。セレクタ名の命名規則については、確認できる公式ドキュメントの範囲では明記されていませんでした。
いずれの場合も、本サイトの診断ツールはこれらの値を推測できません。管理画面で確認したセレクタ名を、次の項で説明する入力欄に指定して再診断してください。
DNSから手当たり次第に探すときの注意
DKIM-Signatureヘッダーが確認できない状況で、よく使われるセレクタ名を1つずつDNSに問い合わせて調べる方法もあります。この方法には見落としやすい注意点があります。
*._domainkeyにワイルドカード応答を設定しているドメインでは、実際には存在しないセレクタ名に問い合わせても、空の公開鍵（p=が空のレコード）が返ってくることがあります。これを「セレクタが見つかったが鍵が失効している」と読み違えると、実際には未定義のセレクタを誤って失効した鍵として報告してしまいます。本サイトの診断ツールは、この構成に衝突しにくい探索用の名称（実在するサービスのセレクタ名としては使われない可能性が高い文字列）で事前に1回問い合わせ、応答が返ってくるかどうかでワイルドカードの有無を先に判定してから、セレクタ候補を試す設計にしています。この判定を入れずに探索していた際、ワイルドカード設定のドメインで試した全セレクタを「鍵が失効している」と誤って報告したことがありました。
自分で
digなどを使って候補を試す場合も、まず存在しないはずのランダムな文字列（例:xyz12345test._domainkey.example.jp）に応答が返るかを確認し、返るようであればこのドメインはワイルドカード設定であると考えてください。その場合、以降にどの候補を試しても「見つかった」という結果は参考になりません。
セレクタを指定して再診断する
管理画面やメールヘッダーでセレクタ名が分かれば、そのセレクタで再診断できます。
DKIMレコードチェックの入力欄には「DKIMのセレクタを指定する（任意）」という折りたたみがあります。ここにセレクタ名を入力すると、そのセレクタに絞って診断します。カンマ区切りで複数指定することもでき、google._domainkey のように _domainkey を含む形で貼り付けても、その手前の部分だけを取り出して解釈します。
すでに診断結果で「DKIMセレクタを特定できませんでした」と表示されている場合は、その所見のすぐ下にも同じ入力欄があります。管理画面で確認したセレクタ名をその場で入力すれば、既に入力したドメイン名を打ち直さずに再診断できます。
まとめ
DKIMのセレクタが分からないときは、次の3つのどこに当てはまるかで対応が変わります。
- メールヘッダーの
DKIM-Signatureにd=とs=が見つかった場合は、その2つを対で読めば照会先が分かります。複数の署名がある場合は行ごとに対で読んでください - ヘッダーに署名が見当たらない、またはDNS側で実ドメインで確認できたセレクタ候補に一致しない場合は、未設定と断定せず、利用しているサービスの管理画面でセレクタ名を確認してください。Amazon SESやHubSpotのようにドメインごとに固有のセレクタを発行するサービスでは、この確認が必須です
- 確認できたセレクタ名は、DKIMレコードチェックの入力欄に指定して再診断できます。「見つからない」という結果のまま止まらず、確認できた値で診断をやり直してください