![DKIMセレクタはDNSの公開鍵を切り替えるための識別子](/blog/dkim-selector-explained/service-selectors.svg)

## この記事でわかること

- DKIMセレクタが「1ドメインに複数の公開鍵を共存させる」ための識別子であること
- 主要メールサービス（Google Workspace、Microsoft 365、SendGrid、Mailchimp、Resend）のデフォルトセレクタ名
- 鍵ローテーションやサービス変更でセレクタを切り替えるときの考え方とハマりどころ

「Microsoft 365 のマニュアルに `selector1` `selector2` と書いてあるけれど、これは何ですか？」「DKIMの鍵を更新したいのに、既存の名前で上書きしていいのか分からない」という相談はよくいただきます。DKIM の概念や確認方法は[DKIM設定の確認方法](/blog/dkim-verification)でまとめていますが、本記事ではその中でも一番つまずきやすい「セレクタ」に絞って整理します。

## 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 のメール認証設定](/blog/microsoft-365-email-auth)を参照してください。

SendGrid と Mailchimp はカスタマイズされたセレクタを CNAME で発行します。Resend と Amazon SES のように、認証ウィザードに表示された値をそのまま貼ることが基本です。DNS が Cloudflare の場合のセレクタ TXT/CNAME 入力の画面手順は [Cloudflare DNS で DKIM を設定する手順](/blog/cloudflare-dkim-setup) を参照してください。

## セレクタを「切り替える」シナリオ

セレクタを意識的に切り替える場面は、おおまかに2つです。

![DKIMセレクタ切替シーケンス](/blog/dkim-selector-explained/rotation-sequence.svg)

### シナリオ1｜鍵のローテーション

DKIM 鍵は数か月から1年単位で更新するのが望ましいとされています。短期的には強い暗号でも、長期間使い続けると漏えいリスクが上がるためです。鍵長を 1024bit から 2048bit へ引き上げる移行も同じ流れで行います。鍵長の引き上げ手順は[DKIM鍵を2048ビットへ引き上げる手順](/blog/dkim-key-2048-upgrade)に詳しくまとめています。

ローテーションの典型的な手順は次のようになります。

1. 新しいセレクタ名（例: `google2026`）を決め、新しい鍵ペアを生成
2. 新しい公開鍵を `google2026._domainkey.<ドメイン>` の TXT として DNS 登録
3. 送信側の DKIM 署名設定で、使用するセレクタを `google` から `google2026` へ切替
4. 数日〜2週間ほど、配送中の古いメールが検証失敗しないよう古いセレクタの DNS レコードを残す
5. 十分な経過後、古いセレクタの DNS レコードを削除

途中で **古いセレクタの DNS レコードを早期に消すと、配送遅延中のメールが `dkim=fail` を起こす**ため、移行期間を最低でも数日は確保します。詳細な手順とチェックリストは[DKIMキーローテーションの完全ガイド](/blog/dkim-key-rotation)を参照してください。

### シナリオ2｜送信サービスの変更・追加

送信ベンダーを乗り換える場合、旧サービスの DKIM レコードは即座に消さず、新サービスのセレクタを追加した上でしばらく並走させます。たとえば Mailchimp から SendGrid に移行する場合、`k1._domainkey` と `s1._domainkey` を一定期間共存させ、配信ログで「新サービスから送ったメールが `dkim=pass` になっているか」を確認してから旧レコードを撤去します。

複数サービス並行運用は SPF と違って DKIM では問題になりません。SPF はレコードを1つにまとめる必要があり、include 数の上限（10個）でハマりやすいですが、DKIM はセレクタが分かれているため**何個でも共存可能**です。用途やサブドメインごとに鍵とセレクタを分ける設計の考え方は[DKIM鍵をサブドメインで分ける設計](/blog/dkim-subdomain-key-strategy)で整理しています。

## ハマりどころ：セレクタ名は推測しない

DKIM 設定で最も多い失敗が「セレクタ名を推測して書いてしまう」ことです。

- 「たぶん `default` だろう」→ ほぼ確実に検証失敗
- 「他社の記事に `dkim` と書いてあった」→ サービスが違えば該当しない
- 「ドメインの一部を含めた名前にすれば動く気がする」→ 公開鍵のホスト先と一致しなければ無意味

セレクタ名は送信サービスのマニュアル・管理画面・ウィザードに表示された **正規の値をそのまま使う** のが原則です。サービス側が動的なホスト名を発行する場合（Microsoft 365 の新形式、Amazon SES、SendGrid のカスタム値など）、表示された値を1文字違わず DNS に登録してください。

セレクタが何かわからないメールを受け取ったときは、`Authentication-Results` ヘッダの `header.s=` 値を見ると逆引きできます。具体的なコマンドとヘッダー解析手順は[DKIM確認コマンド集](/blog/dkim-check-commands)で解説しています。

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。「現在の DKIM レコードの中身（`v=DKIM1; k=rsa; p=...`）を日本語で読み解きたい」場合は、独自セレクタも指定できる[SPF / DKIM / DMARC 設定確認・日本語解説ツール](/tools/dns-auth-explainer)が便利です。判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。