DKIM セレクターに気づくのは、認証が失敗したり、Gmail が迷惑メールに振り分けたり、tm1._domainkey.example.com のような TXT レコードを求められたりしたときかもしれません。小さな名前でも、誤っていれば DKIM を検証できません。整合した SPF も成功していなければ DMARC が失敗し、配送に影響する可能性があります。
同じドメインで複数の送信サービスを使うと、管理はさらに複雑です。メールボックス、マーケティング、CRM がそれぞれ別の鍵で署名します。セレクターを理解しないと、署名の担当、ローテーションする DNS レコード、経路ごとに結果が異なる理由を判断しにくくなります。全体の構成はビジネスメールから確認できます。
セレクターを DKIM 鍵の検索用ラベルと考えてください。DNS との対応がわかれば、設定や調査を手順どおりに進められます。
DKIM セレクターとは？
受信サーバーに、DNS からどの公開鍵を取得するか伝える署名内の名前です。同じドメインで複数の鍵を公開し、システム、メールの種類、ローテーションごとに使い分けられます。
セレクターは鍵そのものではなく、検索の手掛かりです。DKIM-Signature ヘッダーの s= がセレクター、d= が署名ドメインです。受信側はこれを selector._domainkey.example.com のように組み合わせ、TXT から公開鍵を取得します。
RFC 6376は、d= のドメインと s= のセレクターで鍵のレコードを探すと定義しています。セレクターの欠落や誤りは、その署名の検証を妨げます。
d=example.comとs=tm1なら、受信側はtm1._domainkey.example.comを調べます。
DKIM セレクターの役割は？
特定のメッセージに使う公開鍵を指定し、同じドメインで複数の鍵を衝突なく扱えるようにします。
運用上、主に三つの利点があります。
- 送信元を分離できます。ヘルプデスクとトランザクションメールのアプリで別のセレクターを使えます。
- 鍵をローテーションできます。新しい名前を公開し、署名を切り替え、配送途中の古いメールが処理されてから旧鍵を終了します。
- 影響を限定できます。一つのサービスの鍵が漏えいまたは失効しても、他の送信元まで変更する必要は必ずしもありません。
よく管理された環境では、一つの鍵を永久に使うより、個別のセレクターを持つ複数のDKIM レコードを、他の認証情報と同じように管理します。
| 用語 | 意味 | 例 | 重要性 |
|---|---|---|---|
| セレクター | 署名内の検索ラベル | tm1 | 問い合わせるレコードを指定する |
| 署名ドメイン | d= のドメイン | example.com | DKIM のドメイン識別情報を定める |
| DNS ホスト名 | セレクター、._domainkey、ドメインの組み合わせ | tm1._domainkey.example.com | 公開鍵の所在 |
| 公開鍵レコード | DNS が返す TXT | v=DKIM1; p=... | 受信側の署名検証に使われる |
セレクターはどこで確認する？
メールヘッダーや送信プロバイダーの DNS 手順で確認できます。実際のメールでは DKIM-Signature の s= の値です。
受信したメールの元のヘッダーを開き、DKIM-Signature: を探します。次のタグを確認してください。
d=は署名ドメインです。s=は DKIM セレクターです。
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=tm1;
c=relaxed/relaxed; h=from:to:subject:date:message-id;
bh=...; b=...この場合は tm1 です。確認する DNS レコード:
tm1._domainkey.example.com TXT新しい送信元では、プロバイダーがセレクターと TXT の値または CNAME の参照先を提供します。TrekMail はドメイン設定で必要な DNS レコードと状態確認を示すと説明しています。必要な DNS レコードとDNS ステータスの確認の文書が入力欄の確認に役立ちます。
DNS にセレクターを公開するには？
selector._domainkey.yourdomain.com にレコードを作成します。通常は DKIM TXT ですが、管理された鍵への CNAME を使うプロバイダーもあります。
一般的な二つの形式:
TXT 型 DKIM:
Host: tm1._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...CNAME 型 DKIM:
Host: tm1._domainkey
Type: CNAME
Value: tm1.example-com.dkim.vendor.net.指定されたセレクターを勝手に変えないでください。s1 なら s1._domainkey を公開します。実際の送信経路用として TrekMail が dkim._domainkey を表示するなら、その名前と値を使います。Nano の外部送信はカスタム SMTP（BYO）を参照できますが、実際に署名するプロバイダーの値が基準です。
セレクターをテストするには？
DNS が解決できることを確認し、実際のメールが同じセレクターで署名され、DKIM を通過するか検証します。
まず DNS を直接問い合わせます。
dig +short TXT tm1._domainkey.example.com
nslookup -type=TXT tm1._domainkey.example.com空の応答は、レコードの欠落、名前の誤り、未更新のキャッシュ、その他の DNS 問題でも起きます。それだけでは原因を確定できません。
続いて送信し、ヘッダーを確認します。
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=tm1 header.b=...
spf=pass smtp.mailfrom=example.com;
dmarc=pass header.from=example.com確認する点:
dkim=passheader.s=tm1が公開したセレクターと一致するheader.iは DMARC の DKIM 整合性の基準ではないため、d=と From ドメインの整合を確認する
転送を多用するなら、メール転送も参照してください。転送は SPF を失敗させることがあります。署名対象が検証に影響する形で変更されなければ、有効で整合した DKIM が DMARC を支える場合がありますが、配送の保証ではありません。
セレクターによる検証が失敗する理由は？
主な原因は、DNS 名の誤り、不正な鍵、送信側が別のセレクターを使っていること、署名後にリレーが内容を変えることです。
運用中によくある例:
- ホスト名が違う。
_domainkey.tm1を公開しており、正しいtm1._domainkeyになっていない。 - ドメインが違う。署名は
d=mg.example.comなのに、レコードはexample.comにある。 - DNS ゾーンの不一致。権威サーバーではない場所にだけレコードがある。
- 鍵の切り詰め。DNS 管理画面で TXT が短くなっている。
- 旧セレクターが使われる。鍵をローテーションしても、送信側は以前の名前で署名している。
- 署名後の変更。転送やゲートウェイが保護されたヘッダーや本文を変える。
Google の送信者向け文書は、認証要件を満たさないメールが制限またはブロックされる可能性を説明しています。転送による SPF の問題も示されています。正しいセレクターは重要ですが、署名検証全体の一部です。
セレクターはどう命名する？
単純でわかりやすく、運用上の役割に結び付いた名前にします。担当が見える名前なら、複数の画面を調べずに障害対応を進めやすくなります。
default、key1、test は機能しますが、後から背景を理解しにくくなります。より具体的な例:
tm1: TrekMail 管理の送信ses2026q1: Amazon SES のローテーションcrm1: CRM 基盤mktg2026a: マーケティング送信
プロバイダーが自由な命名を許すなら、鍵の担当と導入時期がわかる名前にします。特に複数ドメインのメールホスティングでは監査しやすくなります。
リスクを抑えてセレクターをローテーションするには？
新しい名前で鍵を公開し、署名を切り替え、古いメールが旧鍵を必要としなくなるまで待ってから旧レコードを削除します。
プロバイダーが明示的に求めない限り、使用中の鍵を上書きしないでください。より慎重な手順:
- 新しいセレクターを作り、たとえば
tm1からtm2に移す。 - 新しい DNS レコードを公開する。
- DNS 更新を待ち、確認する。
- 送信側を新しいセレクターへ切り替える。
- テスト送信して、新しい名前で
dkim=passを確認する。 - 適切な移行期間中は旧レコードを残す。
- 旧名で署名するシステムがなく、古いメールにも旧鍵が不要になってから削除する。
複数の送信システムでは特に重要です。一つの長期鍵を共有する代わりに、送信元ごとに別のセレクターを割り当て、計画的にローテーションして変更の影響を限定します。
TrekMail はセレクターをどう扱う？
TrekMail は DNS の値と状態確認、有料プランの管理された送信、Nano の BYO SMTP を紹介しています。セレクターの配置と DNS の確認を整理しやすくなりますが、現在の提供内容は確認してください。
メールボックス管理では、ドメインの共通画面、共有ストレージ、招待による作成、転送、組み込み IMAP 移行が説明されています。送信モデルは次のとおりです。
- 有料プランでは、独自ドメインの DKIM 鍵で署名すると説明される TrekMail 管理の SMTP を使える。
- Nano は BYO SMTP を使い、外部プロバイダーが有効なセレクターと署名を管理する。
外部プロバイダーが署名するなら、その DNS 手順にあるセレクターを使います。TrekMail 管理の SMTP なら、その経路向けに表示されたレコードが対象です。Starter は月額 $3.50 から、有料プランはカードが必要な 14 日間の試用、Nano は試用期間のない無料プランと紹介されています。最新の条件とユーザーごとの課金ではない定額モデルはTrekMail の料金ページで確認してください。
セレクターのトラブルシューティングチェックリスト
固定した順序で確認します。ヘッダーのセレクター、正確な DNS 名、送信側の設定、途中で署名対象が変化していないかを調べます。
- 実際のメールで
s=とd=を記録する。 selector._domainkey.domainを直接 DNS で調べる。- レジストラ画面だけでなく権威サーバーを確認する。
- TXT と CNAME のどちらが必要か確認する。
- From と署名ドメインを比較し、DMARC の整合性を見る。
- 転送、ゲートウェイ、メーリングリストで変更があれば再テストする。
直接送信は成功して転送後だけ失敗するなら、セレクターではなく転送側の署名破損が原因かもしれません。Google の転送文書もこの状況を説明しています。必要ならドメインメールを Gmail へ転送する方法も参照してください。
まとめ: セレクターについて覚えておくこと
DKIM セレクターは、受信側が DNS から取得する公開鍵を指定する名前です。この対応を理解すると、調査が進めやすくなります。
正しい名前と DNS ホスト、対応した署名設定は必要ですが、それだけで DKIM 成功や配送は保証されません。まずヘッダー、次に DNS、最後に途中の内容変更を確認してください。送信元ごとに分け、直接上書きせず新しい名前で鍵を更新します。TrekMail は複数ドメイン向けにホスティング、DNS 確認、移行ツール、ユーザー単位ではない定額料金を紹介しています。利用前に最新の条件を確認してください。
