DKIMセレクターとは何か、また複数のESP間でどのように管理すればよいのか？

DKIMセレクタとは何ですか？

DKIMセレクタとは、DKIM署名付きメールのヘッダーに含まれる短い文字列のことで、受信メールサーバーに対し、DNS上で対応する公開鍵がどこにあるかを示すものです。これは、DKIM-Signatureヘッダーの `s=` タグで定義されます。

すべてのDKIM署名には、セレクタ値が含まれています。このセレクタは、`d=`タグの署名ドメインと組み合わさることで、署名の検証に使用される公開鍵を含む特定のTXTレコードを指すDNSクエリパスを形成します。

メールのヘッダー内にあるセレクタは、以下のようになっています：

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
c=relaxed/relaxed; q=dns/txt; h=from:to:subject:date;
bh=abc123…=; b=xyz789…=

この例では、`selector1` が DKIM セレクタです。受信サーバーは、公開鍵を取得するために `selector1._domainkey.example.com` にクエリを送信します。

組織では、メール送信の要件に応じて、複数の署名鍵を同時に運用することがよくあります。各鍵には固有のセレクタが割り当てられるため、同じドメイン内で両方が競合することなく共存できます。

セレクタを使用すれば、ダウンタイムなしでキーのローテーションを行うことも可能です。古いセレクタを稼働させたまま、新しいセレクタの下に新しいキーを公開し、伝播が完了した時点で切り替えることができます。

DKIMセレクタはどのように機能するのでしょうか？

受信メールサーバーがDKIM署名付きのメールを受信すると、メールヘッダーからセレクタ（`s=`）とドメイン（`d=`）を読み取り、`{selector}._domainkey.{domain}` でDNSクエリを実行し、返されたTXTレコードから公開鍵を取得して、その鍵を使用してメッセージの暗号署名を検証します。

手順は以下の通りです：

ステップ1：送信サーバーがメールに署名する

メールが送信メールサーバー（またはESP）から送信される前に、サーバーは秘密鍵を使用して、指定されたヘッダーフィールドとメッセージ本文に対して暗号署名を生成します。この署名は、セレクタ値および署名ドメインとともに、`DKIM-Signature`ヘッダーとしてメールに追加されます。

ステップ 2：受信サーバーがセレクタとドメインを抽出します

メールが受信トレイに届くと、受信サーバーは `DKIM-Signature` ヘッダーを解析し、2つの値を抽出します：

1. `s=` からのセレクタ 
2. `d=` からのドメイン。

ステップ3：受信サーバーがDNSに問い合わせる

The server constructs a DNS query by combining the selector, the fixed string `_domainkey`, and the domain: {selector}._domainkey.{domain} → TXT record

たとえば、`s=google` で `d=example.com` の場合、DNS クエリは次のようになります：google._domainkey.example.com

ステップ4：DNSが公開鍵を返す

そのDNSパスにあるTXTレコードには、公開鍵と関連するパラメータが含まれています：

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAO…

ステップ5：受信サーバーが署名を検証します

サーバーは公開鍵を使用して、メールヘッダー内の暗号署名を検証します。 

1. 署名が一致すれば、DKIMは通過します。 
2. キーが存在しない場合、レコードは不正な形式となります。
3. 署名が一致しない場合、DKIMは失敗します。

このセレクタは、メールヘッダーを DNSレコード 。なぜなら、DNSレコードがなければ、受信サーバーは正しい公開鍵を見つける手段を持たないからです。特に、ドメインが異なるサービス向けに複数のDKIMキーを公開している場合はなおさらです。

DKIMセレクタの構文と形式 

DKIMセレクタは、 RFC 6376に定義された特定の構文規則に準拠しなければなりません。

使用可能な文字：

• 英数字（a–z、A–Z、0–9）
• ハイフン（-）
• サブドメイン形式のセレクタにおけるピリオド (.)

制約条件：

• DNSの解決において、セレクタは大文字と小文字を区別しませんが、小文字を使用するのが一般的な慣習です。
• RFC 6376には明確な最大文字数の規定はありませんが、DNSの実用上の制限が適用されます。ほとんどの実装では、セレクタを63文字以内（DNSラベルの最大長）に抑えています。
• セレクタはハイフンで始まったり終わったりしてはなりません。
• セレクタ内のピリオドは、DNSクエリにおいてサブドメインの階層構造を生成します。たとえば、セレクタが `2024.jan` の場合、`2024.jan._domainkey.example.com` は有効なクエリパスとなります。

セレクタのパスにあるDNS TXTレコードのフォーマットには、以下のタグが含まれます：

注： 2048ビットのRSA鍵は、単一のDNS TXTレコードの文字数制限である255文字を超える公開鍵文字列を生成します。DNSでは、RFC 6376に従い、値が複数の引用符で囲まれた文字列に分割され、リゾルバーがそれらを連結するマルチストリングTXTレコードによってこれを処理します。しかし、すべてのDNS管理インターフェースがこれを効率的に処理できるわけではなく、これがDKIM失敗の一般的な原因となっています

DKIMセレクタの見つけ方 

特定のドメインで使用されているDKIMセレクタを確認するには、4つの確実な方法があります。これらの方法は、そのドメインを管理しているか、メールヘッダーにアクセスできるか、あるいは外部から監査を行っているかによって、それぞれ異なる利点があります。

方法 1：メールのヘッダーを確認する

メールのヘッダーを確認するのが最も直接的な方法です。問題のドメインから送信されたメッセージを開き、メールのヘッダー全体を表示してください。

• Gmailの場合：メールを開く → 3つの点のメニューをクリック → 「元のメールを表示」を選択します。
• Outlookの場合：メッセージを開く → [ファイル] → [プロパティ] → 「インターネットヘッダー」
• Apple Mailの場合：「表示」→「メッセージ」→「すべてのヘッダー」を選択します。

`DKIM-Signature`ヘッダーを探し、`s=`タグを見つけます。その値がセレクタです。

メールが複数の署名サービスを経由した場合、それぞれ異なるセレクタを持つ複数の `DKIM-Signature` ヘッダーが表示されることがあります。

方法 2：DKIM 照会ツールを使用する

セレクタ名がわかっている場合は、 selector._domainkey.example.com PowerDMARCのDKIMレコード検索、MXToolbox、またはdigやnslookupなどのコマンドラインDNSクエリ、または dig や nslookup などのコマンドライン DNS クエリそのセレクターに対して公開されているTXTレコードを取得できます。

使用 dig:

bash

dig TXT selector1._domainkey.example.com +short

 

nslookup を使用して nslookup:

bash

nslookup -q=TXT selector1._domainkey.example.com

この方法では、セレクタ名をあらかじめ知っているか、一般的なデフォルト値を試す必要があります。

PowerDMARCのDKIM検索機能 また、多くのドメインのセレクタを自動検出したり、DKIMの構文を検証したり、欠落または不正なレコードを特定したり、一般的なDKIM設定の問題のトラブルシューティングを支援したりすることも可能です。 

方法 3：ESP の管理コンソールを確認する

ほとんどのメールサービスプロバイダーは、認証設定にDKIMセレクタと公開鍵を表示しています。例えば：

• Google Workspace: 管理コンソール → アプリ → Google Workspace → Gmail → メールアドレスの認証
• Microsoft 365: Defender ポータル → ポリシーとルール → 脅威ポリシー → メール認証 → DKIM
• Mailchimp: ウェブサイト → ドメイン → 認証 → DKIM設定

方法 4: DMARC 集計レポート

これは、ご自身のドメインのメールに署名を行っているすべてのセレクター（ご自身が把握していないものも含む）を特定するための、最も効果的な方法です。

DMARC集計レポート （RUAレポート）には、レポート送信メールサーバーが受信したすべてのメッセージに対するDKIM認証結果が含まれます。各結果には、使用されたセレクタ、署名ドメイン、および合格/不合格のステータスが含まれます。

組織内で複数のESPを運用している場合や、サードパーティのサービスが組織に代わってメール送信を行っている場合、DMARCレポートでは、ヘッダーの確認だけでは見つけられないセレクタが明らかになります。これは、かつて承認されたものの、その後廃止されずに残っている「シャドーIT」のメールサービスを発見する上で、特に有用です。

PowerDMARCの DMARCアナライザー は、これらの集計レポートを自動的に解析し、ドメインごとのすべてのアクティブなDKIMセレクタを単一のダッシュボードに表示します。これにより、複数のレポートソースからXMLデータを手動で抽出して照合する手間が省けます。

Note: There is no DNS wildcard or enumeration method to discover all selectors under `_domainkey.{domain}`. DNS does not support listing all subrecords of a zone from the outside. You cannot brute-force all possible selectors. The four methods above are the practical options.

5. ESPのデフォルトDKIMセレクタ：2026年版参照表 

DKIM管理において最も一般的な作業の一つは、どのセレクタがどのメールサービスに属するかを特定することです。以下の表は、2026年初頭時点で主要な14社のESPが使用しているデフォルトのDKIMセレクタを一覧にしたものです。

重要： ESPはいつでもデフォルトのセレクターを変更する可能性があり、一部のプラットフォームではアカウント固有のセレクターやランダムなセレクターが割り当てられる場合があります。必ず、ご自身のESP管理コンソールに表示されているセレクターを、この表と照らし合わせて確認してください。

もし、あるドメインがこれらのプラットフォームのうち3つまたは4つを通じて同時にメールを送信している場合、そのDNSには3つまたは4つのアクティブなDKIMセレクタが存在することになり、それぞれを個別に追跡、検証、およびローテーションする必要があります。 

複数のメール配信事業者（ESP）にまたがる多数のDKIMセレクターを管理することは、規模が大きくなると困難になります。特に、各プラットフォームごとにローテーションのスケジュール、セレクターの形式、DNS要件が異なる場合はなおさらです。 

PowerDMARC ホステッド DKIM 単一のダッシュボードを通じてセレクター管理を一元化し、DNSレコードを手動で繰り返し変更することなく、DKIMセレクターの追加、ローテーション、検証、監視を容易に行えるようにします。

無料トライアルを開始する

命名規則とベストプラクティス

DKIMセレクタには、構文規則の範囲内であればほぼどのような名前でも付けることができます。一貫した命名規則がなければ、サービスの追加や鍵のローテーションが行われるにつれて、セレクタの管理は急速に困難になります。

推奨される命名規則

体系的な命名規則を採用することで、責任の所在を明確にし、ローテーションを管理し、障害のトラブルシューティングを行い、将来的な運用上の混乱を防ぐことが格段に容易になります。 

パターン1：ESP + 日付

例を挙げよう：

• google-2026年第1四半期
• sendgrid-202601
• hubspot-2025年第4四半期

これは運用上最も有用なパターンです。一目で、どのサービスがキーを管理しているか、また最後にキーが更新された時期を確認できます。監査の際には、12ヶ月以上経過した日付のセレクタを即座に特定することができます。

パターン2：サービス関数 + シーケンス

例を挙げよう：

• マーケティング-01
• トランザクション-01
• corporate-01

複数のESPが同じドメインを扱っており、ベンダー別ではなくメールストリーム別にセレクターを整理したい場合に便利です。

パターン 3: ESP のデフォルト設定（カスタム命名なし）

多くのESPでは、セレクタの名前を自由に設定することができません。Google Workspaceでは常に`google`が使用されます。Microsoft 365では`selector1`と`selector2`が使用されます。このような場合、プラットフォームが提供する設定を利用し、対応関係を外部で管理する必要があります。

避けるべき命名規則

構造が不適切だったり、あまりにも一般的すぎる名前は、監査、トラブルシューティング、鍵のローテーションの際に混乱を招く恐れがあります。特に、複数のESPが存在し、アクティブなセレクタが多数ある環境ではその傾向が強まります。以下の命名慣行は避けてください： 

• 文脈のない一般的な名称： `key1`、`test`、`dkim` は、ESP やローテーションの状態に関する情報を一切提供しません。
• 機密情報を含むセレクタ: セレクタ名には、内部インフラの詳細、サーバーのホスト名、または従業員の識別子を埋め込まないでください。セレクタ名はDNSを通じて一般に公開されます。
• 長すぎるセレクタ： 技術的には最大63文字まで許可されていますが、30文字を超えるセレクタは、DNSレコードや検索コマンドに不必要な複雑さを加えることになります。

単一ドメイン・単一ESPの構成は簡単です。鍵ペアを生成し、ESPのセレクタの下に公開鍵を公開すれば、設定は完了です。しかし、その同じドメインから複数のプラットフォームを通じてメールを送信するようになると、運用上の課題が生じ始めます。

実用的なマネジメント・フレームワーク

以下の5段階のライフサイクルは、セレクタ管理のための体系的なアプローチを提供します：

第1段階：現状把握

すべてのアクティブなものを記録する DKIMセレクタ をすべて記録してください。これには、ESP、鍵の長さ、公開日、および担当する担当者またはチームを含めます。DMARCの集計レポートは、この一覧を作成する最も迅速な方法です。なぜなら、誰も設定したことを覚えていないものも含め、現在そのドメインのメールに署名しているすべてのセレクタを明らかにしてくれるからです。

ステージ2：検証

インベントリ内の各セレクタについて、DNSを照会して公開鍵が公開されており、形式が正しいことを確認してください。各ESPでテストメールを送信し、DKIMが通過することを確認してください。鍵の長さを確認し、1024ビットの鍵を使用しているセレクタにはフラグを立ててください。

第3段階：標準化

命名規則を定め、管理するすべてのセレクタに適用してください。固定のセレクタ名を使用するESPについては、その対応関係を明確に文書化してください。ローテーションのスケジュールを決定し、担当者を割り当ててください。

ステージ4：モニタリング。

DMARCの集計レポートを使用して、セレクタごとのDKIMの合格率・不合格率を継続的に監視します。特定のセレクタで不合格率が急激に上昇した場合は、通常、DNSの変更、鍵の有効期限切れ、またはESP側での設定変更が原因であると考えられます。

第5段階：廃止措置

ESPの利用を終了する際は、セレクタのDNSレコードに空の `p=` 値を指定して公開することで、そのDKIMキーを無効化してください。単にDNSレコードを削除するだけではいけません。空の `p=` 値を指定することで、受信サーバーに対してキーが無効化されたことを明確に伝えることができます。レコードを完全に削除するとDNS検索が失敗することになり、その意味が曖昧になるため、受信者によって解釈が分かれる可能性があります。

PowerDMARC は、DMARC集計レポートとDNSモニタリングから同時にデータを取得し、アカウント内の全ドメインにわたるすべてのアクティブなDKIMセレクタを一元的に表示するダッシュボードを提供します。多数のクライアントを管理するMSPにとって、これは数十ドメインを超えると管理が困難になるスプレッドシートによる追跡に代わるソリューションとなります。

DKIM キーのローテーションとセレクター戦略

DKIMキーのローテーションとは、新しい鍵ペアを生成し、新しい（または更新された）セレクタの下で新しい公開鍵を公開した後、送信サービスが新しい秘密鍵を使用して署名するように設定することを指します。

何年も同じままのDKIM秘密鍵は、リスクを高める要因となります。サーバーへの不正侵入、内部関係者による脅威、あるいは鍵保管システムの脆弱性によって鍵が漏洩した場合、攻撃者はあなたのドメインを装ってDKIM認証を通過するメールに署名することが可能になります。定期的に鍵を更新することで、リスクにさらされる期間を最小限に抑えることができます。

ダウンタイムなしでDKIMキーを更新する方法

標準的なローテーション処理では、2つのセレクタを順次使用します：

1. 新しい鍵ペアを生成します： 新しい 2048 ビットの RSA (または Ed25519) 鍵ペアを作成します。
2. 新しい公開鍵を新しいセレクタの下に公開します: たとえば、現在のセレクタが `google-2025q3` の場合、新しいキーを `google-2026q1` で公開します。
3. DNSの反映を待つ: 新しいTXTレコードが世界中に反映されるまで、24～48時間ほどかかります。特にMicrosoft 365の場合、完全に反映されるまで最大96時間かかることがあります。
4. 署名設定を更新します： ESPまたはメールサーバーを設定し、新しい秘密鍵と新しいセレクタを使用して送信メッセージに署名するようにします。
5. 確認： テストメッセージを送信し、新しいセレクタでDKIMが通過することを確認してください。
6. 古い鍵を無効化します: 移行期間（通常7～14日間。これは、古い鍵で署名された送信中のメッセージが確実に配信されるようにするため）を経た後、古いセレクタに対して空の `p=` 値を公開します。

複数のESP環境におけるDKIMキーのローテーション

各ESPには独自の回転機構が備わっています：

• Microsoft 365: `selector1` と `selector2` 間のセレクターローテーション機能が組み込まれています。Defender ポータルからローテーションを開始してください。
• SendGrid: `s1`と`s2`の間で自動的に切り替わります。
• Google Workspace： 管理コンソールから手動でキーを再生成する必要があります。
• ほとんどのマーケティングプラットフォームでは： ドメイン認証設定を通じて手動でローテーションを行う必要があります。

すべてのセレクターを同じ日にローテーションすると、リスクが集中する期間が生じ、万が一不具合が発生した場合のトラブルシューティングが困難になります。ローテーションは、異なる週や月に分散させて実施してください。

PowerDMARCのホスト型DKIM 機能は、アカウント内のすべてのドメインについて、鍵の生成、DNSへの公開、セレクタのローテーションを処理します。ドメインごと、およびESPごとにローテーションスケジュールを設定可能です。

無料トライアルを開始する

DKIMセレクターのよくあるエラーとその解決方法 

DKIMが失敗する場合、その原因はほぼ例外なく、いくつかのセレクタ設定またはDNS設定の誤りに起因しています。以下の表では、最も一般的な失敗事例、その症状、および解決方法について解説しています。

2048ビットの切り捨て問題の詳細

組織がDKIMキーを1024ビットから2048ビットにアップグレードする場合（DKIMの用途においては1024ビットRSAは脆弱と見なされるため）、Base64エンコードされた公開鍵の長さはおよそ2倍になります。その結果、生成される文字列は通常400文字を超えます。

DNSのTXTレコードでは、1つのレコード内の文字列につき255文字という制限があります。RFC 6376で定義されている解決策は、1つのTXTレコード内で値を複数の文字列に分割することです。受信メールサーバーは、これらの文字列を自動的に連結します。

一般的なDNS管理インターフェースの多くは、これを効率的に処理できません：

• 一部のインターフェースでは、警告なしに値を255文字で切り捨てることがあります。
• 一部のインターフェースでは、曖昧なエラーメッセージを表示して、入力そのものを拒否することがあります。
• インターフェースによっては、管理者が手動で文字列を分割し、各セグメントを引用符で囲む必要があります。

2048ビットの鍵を公開した直後にDKIMの検証に失敗し始めた場合は、`dig`や`nslookup`を使用して実際のDNS応答を確認してください。返された`p=`の値を、ご自身の鍵ペアに含まれる完全な公開鍵と比較してください。返された値が短い場合は、DNSプロバイダーによって切り捨てられている可能性があります。

これを避けるには： 

• 長いTXTレコードをネイティブでサポートしているDNSプロバイダーを利用してください（Cloudflare、AWS Route 53、およびほとんどのエンタープライズ向けDNSプラットフォームでは、これに対応しています）。
• CNAMEベースのDKIMを使用し、セレクタのDNSパスがESPがホストするCNAMEを指すように設定します。ESPが自社のインフラ上でTXTレコードを管理するため、この問題は完全に回避されます。
• 手動での分割が必要なプロバイダーを使用せざるを得ない場合は、1つのTXTレコード内で、キーを250文字以下の文字列に分割し、それぞれを引用符で囲んでください。

DKIMセレクタとDMARCの整合性 

DKIMとDMARCは別々のプロトコルですが、その相互作用の仕方は多くの管理者を不意を突くものです。DKIMは通過しても、DMARCは依然として失敗することがあります。そのような場合、その原因はほぼ間違いなく、セレクタの署名ドメインと`From:`ヘッダーのドメインとの関係に起因するドメインの不一致です。

DMARCアラインメントとDKIMの連携方法

DMARCでは、少なくとも1つの認証メカニズム（SPFまたはDKIM）が検証に合格し、かつ`From:`ヘッダーのドメインと一致していることが求められます。

宛先 DKIMのアライメント に関しては、DKIM-Signatureヘッダー内の `d=` ドメインが `From:` ヘッダー内のドメインと一致している必要があります。セレクタ自体は整合性の判定対象とはなりません。整合性の判定は、`d=` ドメインのみに基づいて行われます。

DMARCは2つのアラインメントモードをサポートしています：

DKIMは通過するがDMARCは失敗する2つのケース

メール認証の結果において、最も理解に苦しむケースの一つは、DKIMが合格しているにもかかわらず、DMARCが依然として不合格となる場合です。これは通常、署名自体は有効であるものの、署名ドメインがメッセージで使用されている「From:」ドメインと正しく一致していない場合に発生します。

シナリオ 1：サードパーティのESPが独自のドメインで契約を結ぶ

一部のメール配信サービス（ESP）では、ドメインに対してDKIMが明示的に設定されていない場合、送信メッセージの`d=`部分にそのESP自身のドメインを使用して署名することがあります。たとえば、`[email protected]`を名乗って送信されたメールには、`d=esp-provider.com`というDKIM署名が付与されることがあります。

DKIMの検証は成功しました（署名は有効です）が、`esp-provider.com` が `example.com` と一致しないため、DMARCの検証に失敗しました。

メール配信サービス（ESP）で、`d=`タグに独自のドメインを使用するようにDKIM署名を設定します。これには通常、ESPのDKIMセレクタをドメイン下のDNSレコードとして追加し、ESPの設定でカスタムDKIM署名を有効にする必要があります。

シナリオ 2：厳格な DMARC アラインメントによるサブドメインの署名

DMARCポリシーで厳格な整合性（`adkim=s`）が設定されており、ESPが`d=sub.example.com`で署名している一方で、`From:`アドレスが`example.com`となっている場合、DKIMは通過してもDMARCは失敗します。

「relaxed」アライメント（`adkim=r`、これがデフォルト設定です）に切り替えるか、DKIM署名内の`d=`ドメインが`From:`ドメインと完全に一致するようにしてください。

複数のESPにわたる整合性の監査

複数のESPが存在する環境では、送信元プラットフォームごとに異なる`d=`ドメインを使用して署名を行う場合があります。あるESPはルートドメインで署名し、別のESPはサブドメインで署名し、さらに別のESPはカスタム署名を設定するまで自身のドメインをデフォルトとして使用する場合があります。

DMARCの集計レポートには、DKIM署名された各メッセージについて、`d=`ドメインと整合性の結果が表示されます。これらのレポートを確認し、ドメインの整合性が取れていない状態で署名を行っているESPを特定してください。PowerDMARCのDMARCレポートでは、送信元ごとに整合性の不一致が強調表示されるため、設定の変更が必要なESPを簡単に特定できます。

結論

セレクター管理を単発の設定作業ではなく、継続的な運用業務として位置づけている組織こそが、安定した配信実績を維持し、監査を問題なく通過し、インシデントに迅速に対応できるのです。

管理しているドメインが数個以上ある場合や、複数のメール配信業者（ESP）を利用している場合は、DKIMセレクタの可視性を一元化することには、そのための投資に見合う価値があります。

PowerDMARCは、DMARC集計レポートの分析、DNSモニタリング、およびホスト型DKIM管理を、まさにこのような運用上の複雑さに対応するよう設計された単一のインターフェースに統合し、一元的な管理画面を提供します。

複数のメール配信業者（ESP）にわたるDKIMセレクターを簡単に管理できます。 無料トライアルにお申し込みください DKIMレコードの監視、DMARCの整合性向上、メール配信率の保護を実現しましょう。

よくあるご質問

DKIMセレクターを確認するにはどうすればよいですか？

メールの完全なヘッダーを表示し、 DKIM-Signature フィールドを探します。 s= の後の値がセレクタです。例えば、 s=googleの場合、セレクタは googleとなります。

1つのドメインに設定できるDKIMセレクタの数はいくつですか？

ドメインが持つことができるDKIMセレクタの数に、技術的な制限はありません。組織では通常、異なるメールプロバイダ、部署、または鍵の更新期間に応じて、複数のセレクタを同時に使用しています。

同じドメインに対して、複数のESPが異なるDKIMセレクターを使用することは可能ですか？

はい。通常、各メールサービスプロバイダーは独自のDKIMセレクターを使用しています。例えば、Google Workspace、SendGrid、Mailchimpは、同じドメイン内で互いに競合することなく、それぞれ別のセレクターを持つことができます。

DKIMセレクタとDKIMキーの違いは何ですか？

セレクタとは、DNS内でDKIMレコードを特定するために使用されるラベルのことであり、一方、DKIMキーとは、電子メールの署名および検証に使用される実際の暗号用公開鍵・秘密鍵ペアのことです。

なぜDKIMは通過するのに、DMARCは依然として失敗するのでしょうか？

これは通常、DMARCのアライメント失敗が原因で発生します。DKIM署名は正常に検証される場合がありますが、 d= ドメインが From: ドメインと一致していないためです。

DKIMのセレクタとキーは、どのくらいの頻度で更新すべきですか？

セキュリティ上のベストプラクティスでは、DKIMキーを6～12か月ごとに更新することが推奨されています。更新中は、DNSの伝播中に検証エラーが発生しないよう、新旧両方のセレクタを一時的に有効にしておく必要があります。