DKIM「no key for signature」：セレクターとローテーションの修正（2026）

公開日 2026-07-08

データは 2026-06-29 時点 · メソドロジー v7。 261 百万採点済みドメインを対象とした集計センサスデータ。採点方法を参照。

「no key for signature」は、DKIM 署名が指す DNS レコード — selector._domainkey.yourdomain — をクエリしたところキーが見つからなかったことを意味する：レコードが公開されていないか、ローテーション中に削除されたかのどちらかだ。署名者が実際に使用するセレクターを公開する。Defaults.Exposed の採点済み 261,086,232 ドメインのセンサスによると、SPF+DKIM+DMARC トライアドを完了しているのはわずか 10,092,481 ドメイン（3.87%）だ。

修正はDNSレコード1件で、1つのヘッダーから見つかる。実際の DKIM-Signature ヘッダーから s= と d= タグを読んでメールがどのセレクターで署名されているかを特定し、そのレコードを公開（または修正）し、CNAME 委任を優先してプロバイダーにキーローテーションを任せる。その後、以下のランブックに従ってローテーションする — このエラーは通常、誰かが古いセレクターを早まって削除したことを意味する。

「dkim no key for signature」とはどういう意味か？

すべての DKIM 署名は、公開鍵の取得場所を受信側に示す2つのタグを持つ：d=（署名ドメイン）と s=（セレクター）。受信側はこれらから1つの DNS 名を構築する — s._domainkey.d — そこからキーを取得する。「no key for signature」はそのクエリが空だったことを意味する：署名は存在するが、その署名が名指しするキーが存在しない。

この表現は Authentication-Results ヘッダーと DMARC アグリゲートレポートに現れる — 受信側によって表現は異なるが、2種類が重要だ：

結果文字列（断片、広く観測されているもの）	実際に何が起きたか	一時的か？
`dkim=temperror (no key for signature)`	DNS クエリが失敗またはタイムアウトした — 受信側が回答を得られなかった	はい — 再試行で通ることが多い；持続する場合のみ調査
`dkim=permerror (no key for signature)`	DNS クエリは成功し、回答は「そのレコードなし」だった — セレクターが本当に存在しない	いいえ — 公開するまでレコードは存在しない

一度きりの temperror は DNS の気まぐれだ。permerror — または複数日・複数の受信側にわたって繰り返される temperror — は、署名が指すレコードがゾーンに存在しないことを意味する。それがこのガイドの対象だ。

結果として：検証できない署名は DKIM なしと同等に扱われ、DMARC は SPF だけにフォールバックする — しかし SPF は転送で壊れる。署名が存在するが（キー欠如ではなく）無効な場合（ボディハッシュ、壊れたキー）は別の失敗だ — 「DKIM signature not valid」を参照。

メールがどのセレクターで署名されているかを確認するには？

プロバイダーのドキュメントから推測するのではなく、実際のメッセージから読む：

影響を受けているシステムから自分が管理するメールボックス（Gmail のアドレスで十分）にメールを送る。
生ソースを開く（Gmail の「元のメール」、Outlook の「メッセージソースを表示」）。
DKIM-Signature: ヘッダーを見つけて2つのタグを読む：s= がセレクター、d= が署名ドメイン。例：DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
受信側がクエリするレコードは s._domainkey.d — この例では mail2026._domainkey.yourdomain.com。自分でチェックする：dig TXT mail2026._domainkey.yourdomain.com +short。空の回答 = すべての受信側でエラーが実在する。
送信システムごとに繰り返す。1通のメッセージは複数の DKIM 署名を持てる — メールボックスプロバイダー、ニュースレターツール、ヘルプデスク — それぞれ独自の s=/d= ペアとレコードを持つ。失敗しているものを修正し、その d= をメモする：From ドメインと一致する d= を持つ署名のみが DMARC に役立つ。

セレクターレコードが存在しない理由は？

これらのエラーのほぼすべては4つの原因のいずれかだ — この順番でチェックする：

そもそも公開されなかった。 署名者が有効になった（またはデフォルトで有効だった）が、誰も DNS にセレクターを追加しなかった。新しいツールや予期せず署名するゲートウェイで一般的だ。
ローテーション中に削除された。 誰かが古いセレクターを「クリーンアップ」した時点で、そのセレクターで署名されたメッセージがまだ転送中、再試行キュー内、または転送待ちだった。そのメールはすでに s=old で署名されており；old._domainkey を削除するとそれらすべてのメッセージが遡って壊れる。
DNS UI が CNAME ターゲットを破損させた。 多くのプロバイダーは CNAME 経由で委任する（s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com）が、多くの DNS パネルはターゲットにゾーンを黙って付加する — s1.domainkey.u123.esp.com.yourdomain.com が保存され、何にも解決しない。ターゲットを確認する：dig CNAME s1._domainkey.yourdomain.com +short。ツールの移行中にも同じ落とし穴がある — メールツール切り替え後の DKIM 失敗を参照。
プロバイダーがローテーションしたが、ゾーンが追随しなかった。 （CNAME ではなく）静的な TXT レコードとして貼り付けられたプロバイダーキーは、定期ローテーションで孤立する — 署名者が公開していないセレクターに移動する。センサスの 261 百万ドメインのうち、スキャン時点で発見可能な DKIM キーを提示しているのはわずか 51.84%（2026-06-29 時点データ）だ。

「no key for signature」を修正するには？

DNS を変更する前に defaults.exposed で無料スキャンを実行する。 ライブの DKIM、SPF、DMARC レコードを読み取り、受信側が実際に見ているものを表示する — セレクターが解決するか、CNAME ターゲットが壊れていないかを含む。
署名者が実際に使用するセレクターを公開する — 古いランブックのものではなく、ヘッダーの s= の値を使う。プロバイダーの管理コンソールからレコードを取得し（Google Workspace DKIM 設定 · Microsoft 365 DKIM 設定）、s._domainkey.yourdomain.com に正確に追加する。
TXT キーを貼り付けるより CNAME 委任を優先する。 プロバイダーが DKIM CNAME を提供している場合はそれを使う：キーはプロバイダーのゾーンに存在するため、DNS を再度触ることなくローテーションしてくれる — 原因4が不可能になる。ニュースレタープラットフォームはほぼすべてこの方法で動作する；Mailchimp/Brevo/Klaviyo メールの DMARC 失敗を参照。
パネルの外から確認する。 ネットワーク外の端末から dig TXT s._domainkey.yourdomain.com +short（または委任されたセレクターには dig CNAME …）を実行する。パネルでレコードが表示されていても、ゾーンが異なるものを返していれば意味がない。
再スキャンしてテストメッセージを再送する。 Authentication-Results が dkim=pass と表示されるはずだ。次にDKIM の修正ページでスキャンがフラグを立てた残りの問題を対処する — From ドメインとアライメントしない合格署名は DMARC で失敗する。

このエラーを起こさずに DKIM キーをローテーションするには？

ローテーションは動作している設定を壊す場所だ。それを防ぐルール：セレクターを削除するのは、そのセレクターで署名された最後のメッセージが消化された後のみ — 切り替え時ではない。 署名済みメールは想像より長生きする：再試行キューは何日も続き、転送されたメッセージは移動するたびに再検証される。

ステップ	操作	次のステップへの条件
1. 追加	古いセレクターの隣に新しいセレクター（`s2._domainkey…`）を公開する	外部から `dig` でセレクターが解決することを確認
2. 切り替え	署名者を新しいセレクターに向ける	テストメッセージが `s=s2` と `dkim=pass` を示す
3. 待機	転送中、キュー内、転送されたトラフィックが消化されるまで古いセレクターを公開し続ける	7日以上；古いセレクターが DMARC アグリゲートレポートに現れなくなるまで監視する
4. 廃止	古いキーを削除する — または空の `p=` タグで再公開する方が良い：「廃止済み」であって「存在しなかった」ではない	切り替え時に絶対開始しない — 早まった削除が「no key for signature」の第1の原因だ

CNAME 委任では、プロバイダーが自分のゾーン内でこのランブックを実行してくれるため、あなたは何も見ない — 委任する最も強力な理由だ。

よくある質問

「no key for signature」は temperror か permerror か？ 両方の文字列が存在する：temperror は失敗またはタイムアウトした DNS ルックアップ — 一時的で、再試行で解消することが多い — permerror は DNS が「そのレコードなし」と回答したことを意味する。複数の受信側にわたって繰り返される temperror は、実際に欠落しているレコードが原因であることが多い。dig でチェックしてラベルではなく回答を信頼する。

このエラーは誰かが自ドメインをなりすましていることを意味するか？ いいえ — なりすまし攻撃者はあなたのセレクターで署名しない。自分のメールが受信側が検証できない署名を持っていることを意味し、署名なしと同等に扱われ、DMARC は SPF だけに依存する。完全でアライメントされた認証は稀だ：Defaults.Exposed センサス（2026-06-29 時点）では、261,086,232 ドメインのうち SPF+DKIM+DMARC トライアドを完了しているのはわずか 10,092,481 ドメイン（3.87%）だ。

新しいセレクターが機能し始めたらすぐに古いセレクターを削除できるか？ すぐには削除できない。そのセレクターで署名されたメッセージがまだ再試行キューや転送経路に存在する；キーを削除するとそれらが遡って壊れる。古いレコードを少なくとも1週間は維持し、古いセレクターが DMARC レポートに現れなくなるまで監視してから廃止する — 削除よりも空の p= タグの方が望ましい。

プロバイダーのチェッカーが DKIM は設定済みと言っているが、受信側はキーなしと報告する。なぜか？ ほぼ常に CNAME ターゲットの落とし穴だ：DNS パネルがターゲットにゾーンを付加して（…esp.com.yourdomain.com）、レコードは存在するが何にも指していない。dig CNAME selector._domainkey.yourdomain.com +short で保存されているターゲットを文字通り表示する — プロバイダーが指定したものと一文字ずつ比較する。

オーナーにレポートを送る

クライアントや雇用主のためにこれを修正している場合、証拠で締めくくる。セレクターが解決したら無料スキャンを再実行し、採点レポートをビジネスオーナーに転送する：日付入りで平易な言葉で、DKIM が検証されていることを示す。それがサイバー保険更新や次の取引先セキュリティアンケートに必要な成果物だ — クローズされたチケットではなく、機能しているコントロールの証明だ。

DKIM を無料でチェックする

セレクターが解決するか、正確に何を修正すべきかを — プライベートかつオーナー限定で確認する。

ドメインをチェックする → · 「DKIM signature not valid」→ · DKIM を修正する → · Google Workspace で DKIM を設定する → · 集計データのみ使用。データは EU 内で保存・処理。