DKIM セレクタは何個まで持てる？主要 5 サービスで整理
目次
この記事でわかること
- DKIMセレクタが「1ドメインに複数の公開鍵を共存させる」ための識別子であること
- 主要メールサービス（Google Workspace、Microsoft 365、SendGrid、Mailchimp、Resend）のデフォルトセレクタ名
- 鍵ローテーションやサービス変更でセレクタを切り替えるときの考え方とハマりどころ
「Microsoft 365 のマニュアルに selector1 selector2 と書いてあるけれど、これは何ですか？」「DKIMの鍵を更新したいのに、既存の名前で上書きしていいのか分からない」という相談はよくいただきます。DKIM の概念や確認方法はDKIM設定の確認方法でまとめていますが、本記事ではその中でも一番つまずきやすい「セレクタ」に絞って整理します。
DKIMセレクタとは何か
DKIM（DomainKeys Identified Mail、RFC 6376）は、メール送信時に電子署名を付け、受信側が DNS 上の公開鍵で検証する仕組みです。このとき公開鍵は次の場所に登録されます。
<セレクタ>._domainkey.<ドメイン名> TXT "v=DKIM1; k=rsa; p=..."
たとえばドメインが example.co.jp、セレクタが google なら、google._domainkey.example.co.jp の TXT レコードに公開鍵が載ります。
セレクタ（selector）の役割は、1つのドメインに複数の DKIM 公開鍵を同時に共存させることです。送信側はメールヘッダーに s= タグでセレクタ名を書き込み、受信側はその名前を頼りに DNS から対応する公開鍵を引きます。これにより、同じドメインから Google Workspace と SendGrid と Mailchimp で別々に署名する、といった運用が成立します。
RFC 6376 は「鍵をローテーションするとき、同じセレクタ名で値を上書きするのではなく、新しいセレクタを別途立てる」ことを推奨しています。古い鍵で署名されたメールが配送中に検証失敗するのを避けるためです。
主要サービスのデフォルトセレクタ一覧
セレクタ名は送信サービスが決めます。自分で命名できるのは、自社で DKIM 署名を行うサーバーを運用している場合だけです。よく使われるサービスのデフォルト値を整理します。
| サービス | デフォルトセレクタ | レコード種別 |
|---|---|---|
| Google Workspace | google |
TXT |
| Microsoft 365 | selector1 / selector2 |
CNAME |
| SendGrid | s1._domainkey / s2._domainkey（旧）または独自名 |
CNAME |
| Mailchimp | k1._domainkey / k2._domainkey |
CNAME |
| Resend | resend._domainkey |
TXT |
| Amazon SES | <token>._domainkey（自動発行） |
CNAME |
Google Workspace は管理コンソールの「メール認証」で鍵を生成すると、デフォルトで google がセレクタとして表示されます。任意の名前に変更することもできますが、変更後は DNS への登録もセレクタ名を合わせる必要があります。
Microsoft 365 は他社と異なり CNAME レコードで2本同時に運用するのが標準です。selector1 と selector2 の2系統があるため、鍵切替もダウンタイムなしで行えます。詳細はMicrosoft 365 のメール認証設定を参照してください。
SendGrid と Mailchimp はカスタマイズされたセレクタを CNAME で発行します。Resend と Amazon SES のように、認証ウィザードに表示された値をそのまま貼ることが基本です。DNS が Cloudflare の場合のセレクタ TXT/CNAME 入力の画面手順は Cloudflare DNS で DKIM を設定する手順 を参照してください。
セレクタを「切り替える」シナリオ
セレクタを意識的に切り替える場面は、おおまかに2つです。
シナリオ1｜鍵のローテーション
DKIM 鍵は数か月から1年単位で更新するのが望ましいとされています。短期的には強い暗号でも、長期間使い続けると漏えいリスクが上がるためです。鍵長を 1024bit から 2048bit へ引き上げる移行も同じ流れで行います。鍵長の引き上げ手順はDKIM鍵を2048ビットへ引き上げる手順に詳しくまとめています。
ローテーションの典型的な手順は次のようになります。
- 新しいセレクタ名（例:
google2026）を決め、新しい鍵ペアを生成 - 新しい公開鍵を
google2026._domainkey.<ドメイン>の TXT として DNS 登録 - 送信側の DKIM 署名設定で、使用するセレクタを
googleからgoogle2026へ切替 - 数日〜2週間ほど、配送中の古いメールが検証失敗しないよう古いセレクタの DNS レコードを残す
- 十分な経過後、古いセレクタの DNS レコードを削除
途中で 古いセレクタの DNS レコードを早期に消すと、配送遅延中のメールが dkim=fail を起こすため、移行期間を最低でも数日は確保します。詳細な手順とチェックリストはDKIMキーローテーションの完全ガイドを参照してください。
シナリオ2｜送信サービスの変更・追加
送信ベンダーを乗り換える場合、旧サービスの DKIM レコードは即座に消さず、新サービスのセレクタを追加した上でしばらく並走させます。たとえば Mailchimp から SendGrid に移行する場合、k1._domainkey と s1._domainkey を一定期間共存させ、配信ログで「新サービスから送ったメールが dkim=pass になっているか」を確認してから旧レコードを撤去します。
複数サービス並行運用は SPF と違って DKIM では問題になりません。SPF はレコードを1つにまとめる必要があり、include 数の上限（10個）でハマりやすいですが、DKIM はセレクタが分かれているため何個でも共存可能です。用途やサブドメインごとに鍵とセレクタを分ける設計の考え方はDKIM鍵をサブドメインで分ける設計で整理しています。
ハマりどころ：セレクタ名は推測しない
DKIM 設定で最も多い失敗が「セレクタ名を推測して書いてしまう」ことです。
- 「たぶん
defaultだろう」→ ほぼ確実に検証失敗 - 「他社の記事に
dkimと書いてあった」→ サービスが違えば該当しない - 「ドメインの一部を含めた名前にすれば動く気がする」→ 公開鍵のホスト先と一致しなければ無意味
セレクタ名は送信サービスのマニュアル・管理画面・ウィザードに表示された 正規の値をそのまま使う のが原則です。サービス側が動的なホスト名を発行する場合（Microsoft 365 の新形式、Amazon SES、SendGrid のカスタム値など）、表示された値を1文字違わず DNS に登録してください。
セレクタが何かわからないメールを受け取ったときは、Authentication-Results ヘッダの header.s= 値を見ると逆引きできます。具体的なコマンドとヘッダー解析手順はDKIM確認コマンド集で解説しています。
自社の状況を確認してみませんか
設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。「現在の DKIM レコードの中身（v=DKIM1; k=rsa; p=...）を日本語で読み解きたい」場合は、独自セレクタも指定できるSPF / DKIM / DMARC 設定確認・日本語解説ツールが便利です。判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。