DKIMセレクターの見つけ方（と、鍵を安全にローテーションする方法）

DKIMキーを確認したい、ローテーションしたい、あるいは署名が失敗する理由を調べたい。そんなとき、どのツールでも最初に求められるのがセレクターですが、この短い名前は誰も書き留めていません。セレクターは、公開鍵がどのDNSレコードに入っているかを決めるため、これがないとレコードを引くことができません。このガイドでは、実際のメールからセレクターを読み取る方法、メールが手元にないときの手段、鍵の長さの目安、そして署名が途切れないように鍵をローテーションする方法を説明します。

結論#

セレクターとは、ドメインから送信されたメールのDKIM-Signatureヘッダーにあるs=タグの値です。メールを1通選んで完全なヘッダーを開き、DKIM-Signature:を探して、s=でセレクター、d=で署名ドメインを読み取ります。公開鍵が入っているTXTレコードの名前はselector._domainkey.dで、たとえばmail._domainkey.example.comのようになります。手元にメールがない場合は、送信プロバイダーから公開するよう案内されたDNSレコードを確認してください。セレクターは、その名前の先頭部分にあたります。鍵は2048ビットのRSAにしてください。RFC 8301では、最低でも1024ビットが必須で、署名側は2048ビット以上を使うべきとされています。メールヘッダー解析では、DKIMが成功したか、署名があるかを確認できますが、s=とd=はDKIM-Signatureの行から自分で読み取ってください。そのうえで、DNS側の確認にはSPF、DKIM、DMARCチェッカーを使ってください。

メールヘッダーからセレクターを読み取る#

あなたのドメインを名乗って送信するシステムごとに、自分宛てにメールを送ってみてください。メールボックスプロバイダー、マーケティングプラットフォーム、トランザクションメール用サービス、ヘルプデスクなどです。受信したメールの元のソースまたはヘッダーを開きます。Gmailなら、メッセージのメニューから「メッセージのソースを表示」を選びます。DKIM-Signature:で始まる行を探してください。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=mail2026; t=1730700000;
  h=from:to:subject:date; bh=...; b=...

この例では、d=example.comが署名したドメイン、s=mail2026がセレクターです。したがって、鍵は次の場所にあります。

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

直接問い合わせて確認します。

dig +short TXT mail2026._domainkey.example.com

注意点が2つあります。1つのメールに、DKIM-Signatureが複数付いていることがあります。たとえば、お使いのドメインのものと、送信サービスのドメインのものです。d=の値をそれぞれ確認してください。もう1つは、d=がそもそもお使いのドメインかどうかです。多くのプラットフォームは、初期設定ではプラットフォーム自身のドメインで署名します。DKIM自体は通りますが、DMARCではFromアドレスとアライメントが一致しません。d=があなたのドメインでなければ、その送信元はまだお使いのドメインに対応していません。その結果起きるアライメントの失敗は、DNSの問題と間違えやすいので注意してください。

メールが手元にないとき#

開けるメールがない場合もあります。ドメインを引き継いだ、送信元が休眠している、送信前に監査したい、などです。方法は3つあります。

1. プロバイダーのセットアップ画面を確認する。 送信元でドメイン認証をしたとき、CNAMEまたはTXTレコードを公開するよう案内されたはずです。その名前はセレクターで始まります。たとえばselector._domainkeyです。そのレコードがDNSゾーンに残っていれば、それが答えです。
2. DNSゾーンを読む。 ._domainkeyで終わる名前を探します。その手前のラベルがセレクターです。DNSホストのレコード一覧やゾーンのエクスポートで、すべてを確認できます。実在するものを列挙できるのは、ここだけです。
3. よくある名前から推測する。 プロバイダーは予測しやすい初期値を使っており、ツールが代わりに試すことができます。Qualisendのドメイン診断の監視は、セレクターを何も設定していない場合に、次の25個のよくある名前を試します。google、selector1、selector2、k1、k2、s1、s2、dkim、default、mail、smtp、mandrill、sendgrid、krs、protonmail、zendesk1、zendesk2、mxvault、everlytickey1、hs1、hs2、pm、fm1、fm2、fm3です。見つかれば、鍵があることがわかります。見つからなくても何もわかりません。mail2026のようなカスタムのセレクターは、推測では見つからないからです。

推測はあくまで最後の手段です。頼りにしているものはすべて、セレクターとあわせて書き留めておくべきです。ドメイン診断のルーティンの最初の手順が、すべての送信元とそのセレクターを一覧にすることなのは、そのためです。

DKIMキーレコードの構造#

DNSのレコードはタグの並びで、それぞれの役割を知っておくと役立ちます。

多くのプロバイダーは、セレクター名にCNAMEを公開し、プロバイダーが管理する鍵を指すようにしています。そのため、目にするレコードはエイリアスかもしれません。これは正常な状態で、プロバイダーが代わりに鍵をローテーションできるようにするためです。一方で、プロバイダーが参照先を削除すると、あなたのセレクターが知らないうちに名前解決できなくなる、ということでもあります。

鍵の長さ：1024ビットか2048ビットか#

ルールを定めているのはRFC 8301です。署名側は、1024ビット以上のRSA鍵を使わなければならず、2048ビット以上を使うべきとされています。検証側は、1024ビット未満の鍵を有効とみなしてはなりません。Googleの送信者ガイドラインも同じで、1024ビットが最小、2048ビットが推奨です。つまり1024ビットの鍵でも動作しますが、だからこそ何年も残りがちで、最初にアップグレードすべき対象になります。

実務上、1つ注意点があります。2048ビットの公開鍵は、DNSの1つの文字列が保持できる255文字より長くなります。レコードは、1つのTXTレコード内に引用符で囲んだ複数の文字列として公開する必要があり、DNSがそれらを結合して元に戻します。

mail2026._domainkey.example.com.  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
                                          "...rest-of-the-key..." )

ほとんどのDNSホストは、値全体を貼り付ければ自動でこの処理をしてくれますが、そうでないホストもあり、失敗は静かに起こります。途中で切れた鍵や、余計な文字が混じった鍵は、レコードが存在していても検証に失敗します。公開したら問い合わせて、長さを比較してください。ホストごとの長い値の扱いは、DNSプロバイダー別ガイドで紹介しています。

サービス側が鍵を生成する場合、長さは通常、作成時の設定画面で選びます。変更するには新しい鍵と新しいセレクターを作る必要があり、それがローテーションにあたります。

途切れさせずに鍵をローテーションする#

ローテーションとは、鍵を新しいセレクターの新しい鍵に置き換えることです。頻度について決まりはありません。私たちが自信を持って言えるのは、次のタイミングでローテーションすることです。鍵が2048ビット未満のとき、秘密鍵にアクセスできる人が退職したとき、漏えいの疑いがあるとき。それ以外は、チームが実際に守れるスケジュール（年に1〜2回など）で行います。頻度よりも、手順のほうが重要です。

1. 新しい鍵を生成する。 プロバイダー側、または自前のメールサーバーで、mail2027のような新しいセレクター名を付けて作ります。古い名前を使い回してはいけません。
2. 新しいレコードをDNSに公開し、 パブリックなリゾルバーが返すようになるまで待ちます。ほかの作業の前に、digで確認してください。
3. 送信システムの署名を新しいセレクターに切り替える。 これ以降のメールはs=mail2027になります。
4. 古いレコードはしばらく残す。 古い鍵で署名されたメールが、まだ配送中やキューに残っている可能性があります。受信側が検証するのは、送信時ではなく受信時です。慎重を期すなら、1週間ほどが一般的です。
5. 古い鍵を廃止する。 レコードを削除するか、p=を空にして公開し、意図的に失効させたことを示します。
6. 確認する。 テストメールを送り、s=が新しいセレクターになっていて、DKIMが通ることを確かめます。

最もよくある間違いは、手順3より先に手順5を行うこと、あるいは手順2を完全に飛ばすことです。その結果、鍵が存在しないセレクターで署名されたメールが送られてしまいます。

セレクターを継続的に見守る#

DKIMレコードは壊れやすく、しかも誰も気づきません。古い鍵を早く消しすぎた、参照先が消えたCNAME、張り切りすぎた整理で失効した鍵。いずれも、名前解決できなくなったセレクターで署名されたままメールが送られる状態を招きます。ドメイン診断の監視では、ドメインごとに最大10個のDKIMセレクターを登録でき、毎日チェックします。それぞれについて、鍵があることを確認し、RSA鍵のサイズを読み取り、鍵がない、または失効している場合はbadの問題、1024ビットの鍵はwarn、それより短い鍵はbad、t=yのテスト用フラグはwarnとして報告します。1つも登録していなければ、上記の25個のよくある名前を試し、どれからも鍵が見つからなければ警告します。

ローテーションへの影響にも注意してください。古いセレクターを廃止したら、監視対象のリストからも削除してください。そうしないと、鍵がないと報告され続けます。また、これにも限界があります。読み取るのはDNSなので、メールが実際にどのセレクターで署名されているかは見えず、鍵の経過年数についてもアラートは出しません。SPFやDMARCを含む全体像はメールドメイン診断の監視で、同じチェックのSPF側はSPFのDNSルックアップが多すぎる場合で説明しています。

アライメントがd=のドメインをどう使うかは、DMARCの設定手順で説明しています。

DKIMが証明するのは、メールが確かにあなたのドメインから送られたことであり、相手のアドレスが実在することではありません。無料のメールチェッカーは、1回に1アドレスずつ、構文、MXレコード、入力ミスをテストします。リスト全体をクリーンにするには、無料プランの料金ページにある100クレジットで、フル検証を実行できます。正しく署名されたメールでも、受信箱にたどり着くには健全なリストが必要です。