DKIM セレクタ（DKIM Selector）

概要

DKIM セレクタ（DKIM Selector） は、DKIM 署名の検証に必要な公開鍵を DNS から取得する際に使うラベルです。RFC 6376 の Section 3.6.2.1 で定義されており、セレクタ._domainkey.ドメイン の形式で TXT レコードを参照します。

メールの DKIM-Signature ヘッダーには s= タグとしてセレクタが記録されています。受信サーバーはこの値を読み取り、d= タグのドメインと組み合わせて DNS を引きます。たとえば s=google かつ d=example.com であれば、受信サーバーは google._domainkey.example.com の TXT レコードから公開鍵を取得します。

セレクタが存在する理由は、1 つのドメインで複数の DKIM 鍵を同時に運用する必要があるからです。Google Workspace、SendGrid、Amazon SES といった複数のメール送信サービスを併用する場合、それぞれが異なるセレクタで署名し、対応する公開鍵をそれぞれの DNS レコードに配置します。鍵のローテーションでも、旧セレクタを残したまま新セレクタを追加することで、移行中のメール検証を中断せずに済みます。

仕組み

受信サーバーがセレクタを使って DNS から公開鍵を取得するフロー、セレクタの構文規則、および公開鍵レコードのタグを解説します。

DNS 参照のフロー

受信サーバーが DKIM 署名を検証する流れは次の通りです。

1. 受信メールの DKIM-Signature ヘッダーから s=（セレクタ）と d=（ドメイン）を読み取る
2. s= の値と d= の値を セレクタ._domainkey.ドメイン の形式で結合する
3. その FQDN に対して DNS TXT レコードを問い合わせる
4. TXT レコードから p= タグの値（Base64 エンコードされた公開鍵）を取得する
5. 公開鍵を使って DKIM-Signature ヘッダーの署名を検証する

この一連の流れで、セレクタは「どの公開鍵で検証すべきか」を指定するインデックスの役割を果たします。

セレクタの構文規則

RFC 6376 はセレクタの ABNF を selector = sub-domain *( "." sub-domain ) と定義しています。英数字とハイフンで構成され、ピリオドを含めることもできます。ピリオドを含む場合、DNS ラベルの区切りとして扱われます。たとえば mail.2026 というセレクタは mail.2026._domainkey.example.com として DNS に問い合わせられます。

実用上、セレクタの長さは1〜63 文字で、先頭と末尾にハイフンは使えません。

DKIM 公開鍵レコードのタグ

セレクタで特定される TXT レコードには、以下のタグが含まれます。

タグ	必須	説明
v=	推奨	バージョン。DKIM1 のみ有効
k=	任意	鍵の種別。省略時は rsa。ed25519 も指定可能（RFC 8463）
p=	必須	Base64 エンコードされた公開鍵。空文字の場合は鍵の失効を意味する
t=	任意	フラグ。t=y はテストモード、t=s はドメイン完全一致を要求

p= タグが空（p=）のレコードは、そのセレクタの鍵が失効したことを示します。鍵ローテーション後に旧セレクタを即座に削除するのではなく、p= を空にして失効を宣言する方法もあります。

設定例

主要メール送信サービスのデフォルトセレクタ名と、鍵ローテーション時のセレクタ管理方法を示します。

主要サービスのデフォルトセレクタ

メール送信サービスごとにデフォルトのセレクタ名が異なります。

サービス	デフォルトセレクタ	DNS レコード例
Google Workspace	google	google._domainkey.example.com
SendGrid	s1, s2	s1._domainkey.example.com
Amazon SES	selector1〜selector3（CNAME）	selector1._domainkey.example.com
Microsoft 365	selector1, selector2	selector1._domainkey.example.com

Google Workspace で DKIM を有効にした場合、DNS には次のような TXT レコードを追加します。

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

SendGrid は 2 つの CNAME レコードをセットで設定します。

s1._domainkey.example.com.  IN  CNAME  s1.domainkey.uXXXX.wl.sendgrid.net.
s2._domainkey.example.com.  IN  CNAME  s2.domainkey.uXXXX.wl.sendgrid.net.

鍵ローテーション時のセレクタ管理

M3AAWG は年 2 回以上（約 180 日以内の間隔）での鍵ローテーションを推奨しています。ローテーションではセレクタ名を変更し、新旧を並行稼働させます。

# 新セレクタ（運用中）
s20260401._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=新しい公開鍵"

# 旧セレクタ（移行期間中は残す）
s20251001._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=古い公開鍵"

旧セレクタのレコードは、切り替え後も少なくとも 1 週間は残します。メーリングリストやキューに残っている古いメールが再検証される可能性があるためです。移行完了後は p= を空にして失効を宣言するか、レコード自体を削除します。

日付ベースのセレクタ名（s20260401 など）にすると、鍵の発行時期を追跡しやすくなります。

確認方法

特定のセレクタの DKIM レコードが正しく設定されているかは dig で確認できます。

dig TXT google._domainkey.example.com

;; ANSWER SECTION:
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

v=DKIM1 で始まるレコードが返れば、そのセレクタの公開鍵が DNS に公開されています。p= タグの値が送信サービスの管理画面で表示される公開鍵と一致するかを確認します。

複数のセレクタを使い分けている場合は、セレクタごとに問い合わせます。

dig TXT s1._domainkey.example.com

dig TXT selector1._domainkey.example.com

外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/mail-auth?domain=example.com&selector=google"

{
  "success": true,
  "data": {
    "spf": { "record": "v=spf1 include:_spf.google.com ~all", "exists": true },
    "dkim": {
      "mode": "explicit",
      "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...",
      "exists": true,
      "selector": "google"
    },
    "dmarc": { "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com", "exists": true },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

レスポンスの data.dkim.exists が true であれば、指定したセレクタの DKIM レコードが外部から参照可能な状態です。data.dkim.record にレコードの内容、data.dkim.selector にリクエストで指定したセレクタ名が返ります。selector パラメーターを省略した場合、API は一般的なセレクター候補（google, selector1, s1 など）を自動検出します。特定のセレクターを確認したい場合は明示的に指定してください。

よくある問題

セレクタの設定ではネーミングの不一致や DNS 伝搬の待機不足が原因で dkim=fail になるケースが頻出します。

セレクタ名の不一致

最も多いトラブルは、送信サービスが使うセレクタと DNS に登録したレコードのサブドメイン名が一致していないことです。Google Workspace のセレクタは google ですが、DNS に gmail._domainkey や mail._domainkey として登録してしまうと、受信サーバーは google._domainkey を問い合わせるためレコードが見つかりません。

送信サービスの管理画面でセレクタ名を確認し、DNS レコードのサブドメイン部分と完全に一致させます。

セレクタの存在確認ができない

DKIM レコードを追加した直後は、DNS の伝搬に時間がかかります。TTL の設定にもよりますが、最大 48 時間程度を見込む必要があります。dig で NXDOMAIN が返る場合は、伝搬の完了を待ってから再度確認します。

CNAME で設定するサービス（SendGrid、Amazon SES など）では、CNAME の参照先が正しいかも確認します。CNAME 先のホスト名を間違えると、レコード自体が存在しない扱いになります。

同一ドメインで複数サービスのセレクタが競合する

セレクタの仕組み上、同一ドメインで複数のサービスを併用しても DNS レコードは競合しません。各サービスが異なるセレクタ名を使うため、google._domainkey と s1._domainkey は独立したレコードとして共存できます。

問題が起きるのは、2 つのサービスに同じセレクタ名を割り当てた場合です。後から登録したレコードが前のレコードを上書きし、片方のサービスで dkim=fail になります。サービスごとにセレクタ名が重複していないかを確認します。

鍵ローテーション時に旧セレクタを早く消してしまう

新セレクタへの切り替え直後に旧セレクタの DNS レコードを削除すると、キューに残っている古いメールや、受信者がまだ検証していないメールが dkim=fail になります。切り替え後も旧レコードは一定期間残し、十分な時間が経ってから削除します。