誰もが頭を悩ませるDKIMセレクタ問題#

ドメインのメール認証を設定したばかりだとしましょう。SPFは設定済み(これは簡単でした)。DMARCも設定しました(1時間かかりましたが、無事完了)。次はDKIMを追加する番です。

メールプロバイダーは「セレクタ[何か]のDKIMレコードを追加してください」と指示します。しかし、そのセレクタが具体的に何なのかは明示してくれません。あなたは次のような作業を強いられます。

プロバイダーのドキュメントを掘り起こす(そもそも存在しないこともある)
管理パネルを確認する(表示されないこともある)
Googleで「自分のDKIMセレクタは何?」と検索する
よくある候補を手当たり次第に試す: default、google、selector1、s1、k1、mandrill...
各候補についてDNSをチェック: default._domainkey.yourdomain.com、google._domainkey.yourdomain.comなど
諦める前に正解を引き当てられることを祈る

このプロセスに3〜8時間かかるユーザーもいます。中には最後まで分からず、DKIMが未設定のままになる人もいます。

たった1つのDNSレコードを見つけるのに3時間。 こんなに難しいはずがありません。

このガイドでは、DKIMセレクタとは何か、なぜメールプロバイダーがこれを分かりにくくしているのか、Nova UptimeのDKIMスキャナーのような最新ツールがどのように数秒でレコードを発見するのかを解説します。

DKIMセレクタとは何か、なぜ存在するのか#

DKIMセレクタを簡単に説明#

DKIMセレクタとは、どのDKIM署名鍵を使うかを識別するためのラベルです。

こう考えてみてください。1つのドメインが複数のメールサービスを利用していて、それぞれが独自の署名鍵を持っている場合があります。DKIMセレクタを使えば、複数の鍵を同時にアクティブにしておけます。

default._domainkey.yourdomain.com  → 鍵A (自前のメールサーバー)
google._domainkey.yourdomain.com   → 鍵B (Google Workspace)
sendgrid._domainkey.yourdomain.com → 鍵C (SendGrid)
mailgun._domainkey.yourdomain.com  → 鍵D (Mailgun)

各サービスは自身の秘密鍵でメールに署名します。受信サーバーは、DNS上の対応する公開鍵を使って各署名を検証します。

なぜ複数のセレクタが必要なのか?

例えばSendGridからMailgunに移行したいとします。SendGridのDKIMセレクタをすぐに削除してしまうと、SendGridの鍵で署名された配信中のメールは検証に失敗します。移行期間中は両方のセレクタをアクティブにしておくことで、古いメールも新しいメールも正しく認証されます。

DKIMセレクタの仕組み: 全体の流れ#

メールプロバイダーが鍵ペアを生成します:
- 秘密鍵 (プロバイダーのサーバー上で秘匿)
- 公開鍵 (DNSに公開)
セレクタ名を伝える (理想的には明確に。実際にはそうでないことも多い)
公開鍵をDNSに公開する: selector._domainkey.yourdomain.comに登録
メールを送信するとき:
- プロバイダーのサーバーが秘密鍵でメールに署名
- 署名がメールヘッダーに追加: DKIM-Signature: v=1; a=rsa-sha256; s=google; d=yourdomain.com; bh=...
- メールが送信される
受信サーバーがメールを受け取ったとき:
- 署名ヘッダーからセレクタを抽出: s=google
- 公開鍵を検索: google._domainkey.yourdomain.com
- その公開鍵で署名を検証
- 署名が有効ならDKIMはパスする

最も重要なポイント: メールヘッダー内のセレクタ(s=google)は、DNS上のセレクタ(google._domainkey.yourdomain.com)と完全に一致しなければなりません。たった1文字違うだけで認証は失敗します。

なぜメールプロバイダーはこれを分かりにくくするのか

「あなたのDKIMセレクタはsendgridです」と明確に伝えてくれればよいのですが、たいていそうしてくれません。その理由は次の通りです。

理由1: 状況によって異なるセレクタ#

プロバイダーによっては、設定状況に応じて異なるセレクタを使います。

SendGrid:

デフォルトセレクタ: sendgrid
ただし、ブランド送信ドメインを使う場合: s1234567890のようなランダム生成セレクタ
ユーザーは1つのセレクタを設定し、その後別の送信ドメインを追加すると、それが異なるセレクタを持つことに気付かない

Google Workspace:

セレクタは固定: google
ただし、セットアップ方法によってはs0、s1、s2が表示されることもある

Zoho Mail:

セットアップに応じてセレクタが決まる: zl1234567 (数字はドメインごとにユニーク)
分かりやすい場所に明記されていない

Mailgun:

DKIMレコード作成時に自分でセレクタを選択する
デフォルトはk1だが、mail、bounce、my-custom-keyなど好きな名前にできる
ユーザーは何を選んだか忘れがち

理由2: ドキュメントが見つからないか古い#

「SendGrid DKIM selector」と検索すると、次のような結果が並びます。

2015年のドキュメントページ (UIスクリーンショットが古い)
DKIMセレクタではなく「ブランドリンク」に関するヘルプ記事
異なる回答が並ぶ2018年のフォーラム投稿
「Settings > API Keys > DKIMに行く」と書かれた公式ドキュメント (実際はそこにはない)

理由3: 管理パネルが明確に表示しない#

Gmail管理パネルにログインしてDKIMを探すと、こう表示されます。

ステータス: 未設定
[DKIMをセットアップ]

「DKIMをセットアップ」をクリックすると、こうなります。

DKIMはこのドメインで有効です。
[DNSレコードを表示]

セレクタは表示されたDNSレコードの中に埋もれており、自分で読み取らなければなりません。ほとんどのユーザーはここで挫折します。

理由4: 複数のセレクタがさらに混乱を招く#

これまでに複数のメールプロバイダーを使ったことがある場合:

古いSendGridセレクタ: sendgrid (DNSにあるが、現在は未使用)
現在のMailgunセレクタ: k1 (アクティブ)
バックアップメールボックスのセレクタ: mail (災害復旧用にDNSに残してある)

ユーザーはどれがどれか覚えていません。DKIMチェックを実行して3つのセレクタを目にすると、何かおかしいと思い込んでしまいます。

従来のDKIMセレクタ発見プロセス (時間がかかって辛い)#

手動の方法: 試行錯誤

ほとんどの人は次のようにDKIMセレクタを探します。

ステップ1: ドキュメントを読む

プロバイダーのドキュメントを検索: 「DKIM selector」
30分かけて読む
ようやく1文を発見: 「DKIMレコードはs._domainkey.domain.comに保存されます」
sが実際に何なのかは書かれていない

ステップ2: 管理パネルをチェック

メールプロバイダーの設定に移動
「DKIM」または「DNS records」を探す
DNSレコードが見つかったらスクリーンショットを撮る
そこからセレクタを見つけようとする

ステップ3: よくあるセレクタを手動で試す

DNSをチェック: default._domainkey.yourdomain.com
DNSをチェック: selector1._domainkey.yourdomain.com
DNSをチェック: google._domainkey.yourdomain.com
DNSをチェック: s1._domainkey.yourdomain.com
DNSをチェック: mail._domainkey.yourdomain.com

ステップ4: フォーラムで質問する

StackOverflowで検索: 「How do I find my DKIM selector?」
矛盾する回答が見つかる
さらに2時間かけて1つずつ試す

合計時間: 本来30秒で済むはずの作業に3〜8時間。

この手動プロセスが失敗する理由

タイプミス: スペルを間違えてセレクタを見逃す
DNSキャッシュ: TTLが切れていないため結果が見えない
複数のセレクタ: セレクタ1を見つけてそれで終わりだと思い込み、セレクタ2を見落とす
間違ったドメインレベル: selector._domainkey.yourdomain.comではなく_domainkey.yourdomain.comをチェックしてしまう
プロバイダーがセレクタを変更した: 古いドキュメントを見つけて、廃止されたセレクタを参照してしまう

現代の解決策: DKIMセレクタの自動検出#

Nova UptimeのEmail Health Checkerは、DKIMセレクタの自動検出でこの問題を解決します。

Nova UptimeがどのようにDKIMセレクタを検出するか#

50個のセレクタを1つずつ推測する代わりに、Nova Uptimeは次のように動作します。

50個のよくあるセレクタを並列スキャン
- 主要プロバイダーで一般的なもの: default、google、selector1、s1、k1、mandrill、dkim、mail、sendgrid、mailgunなど
- 結果は2〜3秒で返ってくる (並列DNSクエリは逐次処理よりはるかに高速)
RFC 6376準拠を検証
- v=DKIM1 (推奨だが任意) とp= (公開鍵の存在) の両方をチェック
- 理由: 一部のプロバイダー(Zohoなど)はv=DKIM1なしでセレクタを自動生成しても動作する
DKIMが設定されているかを報告
- 有効なセレクタが1つでも見つかれば「設定済み」と表示
- 50個のうちどれにも該当しなければ「見つかりません」と表示
誤検出を防ぐ
- DNSのフォーマットをチェック
- 鍵の存在を検証
- 実際の公開鍵があるセレクタのみを報告

結果: 何が表示されるか

Nova Uptimeのメールヘルスチェッカーを実行すると、次のように表示されます。

DKIMが見つかった場合:

DKIMステータス: 設定済み
ステータス: 有効

見つからなかった場合:

DKIMステータス: 未設定

50個のよくあるセレクタをスキャンしました。DKIMレコードは見つかりませんでした。

次のステップ:
1. メールプロバイダーのドキュメントで正確なセレクタを確認
2. プロバイダーにDKIMレコードを生成してもらう
3. DNSプロバイダーにレコードを追加
4. 24時間後に再度チェックを実行 (DNSの伝播には時間がかかる)

Nova Uptimeがスキャンする50個のセレクタを理解する#

主要メールプロバイダーのセレクタ

最もよく使われているセレクタは次の通りです。

Google Workspace

セレクタ: google
理由: Googleは全顧客で一貫した命名を採用

SendGrid

セレクタ: sendgrid、s1234567890 (ブランドドメインの場合)
理由: デフォルトはsendgridだが、カスタム送信ドメインには自動生成セレクタが付与される

Mailgun

セレクタ: k1、k2、またはカスタム (自分で選択)
理由: セレクタは自分で設定する。デフォルトはk1とk2

Klaviyo

セレクタ: mailgun-key
理由: KlaviyoはMailgunをバックエンドに使用

HubSpot

セレクタ: hubspot
理由: Googleと同様に一貫している

Zendesk

セレクタ: zendesk1、zendesk2
理由: Zendeskは複数の送信ドメインを許可

Amazon SES

セレクタ: 様々 (リージョンとセットアップによる)
よくあるもの: amazonses、またはランダム生成

Postmark

セレクタ: postmark
理由: 命名は固定

Mandrill

セレクタ: mandrill
理由: 命名は固定

Zoho Mail

セレクタ: zl1234567 (ドメインごとにユニーク)
理由: 自動生成識別子

Microsoft 365 / Outlook

セレクタ: selector1、selector2
理由: 鍵ローテーション用に2つのデフォルトセレクタ

Brevo (旧Sendinblue)

セレクタ: brevo、brevo1
理由: 鍵ローテーション用に複数

自前のメールサーバー

メールを自己ホストしている場合:

セレクタ: 自分で設定したもの
よくあるもの: default、mail、dkim、main、またはカスタム名

50個のセレクタ完全リスト#

Nova Uptimeは次の50個のセレクタをスキャンします。

default、google、selector1、selector2、s1、s2、k1、k2、k3、mandrill、dkim、mail、email、smtp、sendgrid、s、sig1、selector、key1、key2、zoho、protonmail、protonmail2、protonmail3、cm、turbo-smtp、amazonses、ses、mailjet、mxvault、fm1、fm2、fm3、smtpcom、postmark、mailgun、resend、brevo、hubspot、hs1、hs2、zendesk1、zendesk2、freshdesk、smtp2go、mesmtp、krs、everlytickey1、everlytickey2、mailo、mimecast、pp1、sparkpost、barracuda

このリストにセレクタがない場合でも、DNSを直接チェックすることで確認できます。

ステップ・バイ・ステップ: DKIM自動検出の使い方#

ステップ1: Email Health Checkerにアクセス#

Nova Uptime Email Health Checkerを開きます。

ステップ2: ドメインを入力#

プロトコルやサブドメインなしで、ドメインを入力します(例: yourdomain.com)。

ステップ3: DKIM結果を確認#

数秒で、ドメインのDKIMが設定されているかどうかが表示されます。

ステップ4: 結果に応じた次のアクション#

見つかった場合: 何もする必要はありません。DKIMは正しく設定されています。次はDMARCのアラインメントチェックに進みましょう。

見つからなかった場合:

メールプロバイダーのドキュメントで正確なセレクタ名を確認
プロバイダーのサポートに連絡: 「このドメインのDKIMセレクタは何ですか?」
セレクタ名が分かったら、DNSレコードを提供してもらう
DNSプロバイダーに追加
24時間後にチェックを再実行 (DNS伝播のため)

よくあるDKIMセレクタの間違い#

間違い1: 間違ったドメインレベルをチェック#

間違い:

チェック対象: dkim._domainkey.com (自分のドメインがない!)
正しくは: dkim._domainkey.yourdomain.com

DKIMレコードは各ドメイン固有のものです。.comや.orgをチェックしても自分のものは見つかりません。

間違い2: セレクタ名のタイプミス#

プロバイダーの指定: selector チェックしたもの: selectors (余分なs) 結果: 見つからない、DKIMが存在しないと判断

Nova Uptimeは主要プロバイダーの正しいスペルをチェックするので、この問題を回避できます。

間違い3: `._domainkey`サフィックスを忘れる

間違い:

DNSをチェック: sendgrid.yourdomain.com
正しくは: sendgrid._domainkey.yourdomain.com

DKIMレコードは名前に必ず._domainkeyを含む必要があります。これがないとDNSルックアップは何も返しません。

間違い4: DNS伝播を待たない#

DKIMレコードをDNSに追加した直後にチェックして「見つからない」と表示される。

DNSの変更は伝播に時間がかかります(通常1〜2時間、最大24〜48時間)。後で再確認しましょう。

間違い5: 間違ったDNSツールを使う#

一部のDNSツール(基本的なMXチェッカーなど)はTXTレコードのルックアップに対応していません。DKIM TXTレコードを専門にチェックするNova Uptimeを使いましょう。

Nova UptimeのDKIM検出が手動チェックより優れている理由#

比較項目	手動チェック	Nova Uptime自動検出
所要時間	3〜8時間	2〜3秒
正確性	タイプミスや誤解の影響を受ける	50個のよくあるセレクタを正確にチェック
カバレッジ	あまり知られていないセレクタを見落とす可能性	主要プロバイダーをすべてカバー
誤検出	結果を誤解しやすい	明確な合否と説明
継続的な監視	必要なときに手動で実行	四半期ごとに変更をチェック
ドキュメント	プロバイダーのドキュメントを読む必要あり	明確で分かりやすい説明

DKIMセレクタが50個のスキャン対象に含まれていない場合は?#

ニッチなメールプロバイダーや、カスタムセレクタを使う自己ホストメールを利用している場合:

セレクタ名が分かっている → Nova Uptimeで動作確認可能 (結果付きでメインのヘルスチェッカーを使用)
セレクタ名が分からない → プロバイダーに問い合わせるか、ドキュメントを確認

完全に未知のプロバイダーであっても、50個のよくあるセレクタでカバーできるはずです (ほとんどのプロバイダーがこれらの標準のいずれかを使用)。

それでも見つからない場合:

DNSツールで直接チェック: dig selector._domainkey.yourdomain.com TXT
メールプロバイダーのサポートに連絡: 「私のDKIMセレクタは何ですか?」
分かったらNova Uptimeのヘルスチェックを再実行して正しさを確認

DKIM自動検出のビジネスインパクト#

以前(手動チェック):

3時間: DKIMセレクタを調査・推測
30分: 各推測をDNSルックアップで検証
セットアップが面倒すぎてメール配信ヘルスが壊れたまま
結果: 数週間にわたってメールが迷惑メールフォルダに

現在(Nova Uptime自動検出):

2分: Nova Uptimeのヘルスチェックを実行
30秒: 結果を読み、何が設定されているかを正確に把握
5分: 明確なガイダンスに基づいてプロバイダーに連絡、または不足レコードを追加
結果: メールの問題を当日中に特定・解決

組織への影響:

新しいドメインのメール認証セットアップが高速化
「なぜメールが届かないのか」という問い合わせが減少
メール認証が正しく設定されているという安心感
四半期ごとの監査でDNS変更やプロバイダー移行を把握

DKIMの維持: 継続的なベストプラクティス#

月次

特に何も必要ありません。DKIMは正しく設定されれば安定しています。

四半期ごと

Nova Uptime Email Health Checkerを実行して、次を確認しましょう。

DKIMセレクタが引き続きアクティブか
想定外のセレクタ追加がないか (誤設定や攻撃の兆候)

メールプロバイダーを変更したとき

次のような変更を行った場合:

SendGridからMailgunに切り替え
2つ目のメールサービスを追加
メールサーバーを移行

すぐにヘルスチェッカーを実行しましょう。

古いセレクタがまだ機能しているかを確認 (移行中に必要なら)
新しいセレクタがアクティブになっていることを確認
移行完了後に古いセレクタを削除

注意すべき危険信号

四半期チェックで次のような結果が出た場合:

セレクタが消えた: DNS設定ミスやプロバイダー側の問題の可能性
未知の新しいセレクタ: アカウント侵害の可能性 (誰かがDKIM鍵を追加した)
想定していない複数セレクタ: 古いプロバイダーの残骸の可能性 (整理する)

まとめ: DKIMセレクタの謎を解く#

DKIMセレクタは、異なる署名鍵に付けられたただのラベルです。混乱の原因は次の点にあります。

メールプロバイダーが使うべきセレクタを明確に文書化していない
ユーザーが50以上の候補から手動で推測しなければならない
セレクタがプロバイダーや設定によって異なる

Nova Uptimeの自動DKIM検出はこれを次の方法で解決します:

50個のよくあるセレクタを並列スキャン
2〜3秒で結果を返す
RFC準拠を検証
明確な次のステップを提示

3〜8時間かけて手動でチェックする代わりに、即座に明確な結果が得られます。

「DKIMは設定済み、完璧に動作中」 → 何もする必要なし
「DKIMが見つかりません」 → 次にすべきことはこれです

Email Health Checkerの完全ガイド — メール認証設定全体(SPF、DKIM、DMARC、ブラックリスト)を1回のスキャンでチェック。
DKIM徹底解説: 完全ガイド — DKIMの仕組み、鍵ローテーション、トラブルシューティングを深掘り。
SPFレコードの設定方法 — DKIMと並行してSPFを設定し、完全なメール認可を実現。
DMARCポリシー設定ガイド — DMARCの強制でSPFとDKIMを連携させる。
メール配信ヘルスのチェックリスト — 最大限の到達性のためにメールスタック全体が正しく設定されているかを確認。

今すぐ始める: DKIM設定を無料でチェック →