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レコードとして、公開されており、受信側は、これを引いて署名を検証します。

このセレクタ名を最も確実に確認できる場所は、実際に送られたメールのヘッダーです。

1. 問題が起きている送信経路から自分宛にテストメールを送ります。同じドメインでもホームページのフォーム通知、メール配信サービス、日常のメールソフトではDKIMの署名元が別々に設定されていることが珍しくありません。問い合わせフォームからの通知が届かないのであれば、そのフォームから送信して確認してください。日常のメールソフトから送って確認しても原因の切り分けにはなりません
2. 届いたメールの元のメッセージ（ソース）を表示します。Gmailであれば該当メールを開き、右上のその他アイコンから「メッセージのソースを表示」を選びます
3. 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に登録させてしまう恐れがあります。本サイトでは対象のサービスを実際に利用しているドメインに問い合わせて、公開鍵が実在することを確認できたものだけを次の表にまとめています。

検証方法は、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セレクタを特定できませんでした」と表示されている場合は、その項目のすぐ下にも同じ入力欄があります。管理画面で確認したセレクタ名をその場で入力すれば、既に入力したドメイン名を打ち直さずに再診断できます。

鍵が見つかった場合、そのレコードに t=y が入っていることがあります。テストモードの表明で、動作確認が済んだら、外すことが前提のフラグです。意味と安全な外し方は、DKIMのt=y（テストモード）とはで扱っています。

鍵が見つかったら、鍵長も確認してください。1024bitのままになっていることがあります。RFCの要件と実際に公開されている鍵の分布は、DKIMの鍵長は1024bitで足りるのかで扱っています。

探しても見つからず、これから設定するかどうかを決める段階であれば、判断の材料は、SPFだけで足りるのかにまとめてあります。転送を経由するか、DMARCを p=reject で運用するか、大量送信かで結論が変わります。

セレクタが分かってレコードも見つかったのに認証が失敗し続ける場合は、レコードの中身に原因があります。構文の誤り・公開鍵の値が空になっている失効・同じセレクタ名にレコードが2本ある状態の3つで、見分け方はDKIM認証に失敗する原因にまとめています。

まとめ

DKIMのセレクタが分からないときは、次の3つのどこに当てはまるかで対応が変わります。

1. メールヘッダーの DKIM-Signature に d= と s= が見つかった場合は、その2つを対で読めば照会先が分かります。複数の署名がある場合は、行ごとに対で読んでください
2. ヘッダーに署名が見当たらない、またはDNS側で実ドメインで確認できたセレクタ候補に一致しない場合は、未設定と断定せず、利用しているサービスの管理画面でセレクタ名を確認してください。Amazon SESやHubSpotのようにドメインごとに固有のセレクタを発行するサービスでは、この確認が必須です
3. 確認できたセレクタ名は、DKIMレコードチェックの入力欄に指定して再診断できます。「見つからない」という結果のまま止まらず、確認できた値で診断をやり直してください

診断が「特定できませんでした」ではなく「DKIMが設定されていない可能性があります」と表示した場合は、利用中のサービスの既定のセレクタを実際に引いたうえで公開鍵が無かったという意味になります。その場合の確かめ方は「DKIMが設定されていない可能性があります」と出たときで扱っています。