Defaults.Exposed

Defaults.Exposed › 修正 › Guides

メールツール切り替え後に DKIM が失敗する：CNAME とセレクター移行ガイド（2026）

公開日 2026-07-08

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

ツールを切り替えた後に DKIM が壊れるのは2つの機械的な理由による：DNS パネルが新しいツールの CNAME ターゲットを壊した（通常は自ドメインを付加することで）か、古いツールのセレクターがそのメールが消化される前に削除されたかだ。Defaults.Exposed の採点済み 261,086,232 ドメインのセンサスによると、SPF+DKIM+DMARC トライアドを完了しているのはわずか 3.87%（10,092,481）のみだ。

修正の順序：ドメインをスキャンし、次に dig で各新しい CNAME の保存されたターゲットを確認する — 自ドメイン名で終わるターゲットが決定的証拠だ。権威ネームサーバーでレコードを修正し、実際のメールをルーティングする前に新しいツールが署名して合格することを確認し、古いツールのセレクターはトラフィックが消化されるまで公開し続ける。

ツールを切り替えたら DKIM が壊れたのはなぜか？

DKIM 自体は何も変わっていない — セレクターが変わった。古いツールはそのセレクターで署名していた；新しいツールは異なるセレクターで署名する。通常はオンボーディング中に追加された2〜3件の CNAME レコードで委任される。移行後の DKIM 失敗のほぼすべてを説明する4つの落とし穴がある：

  1. DNS パネルが CNAME ターゲットにゾーンを付加した。 多くのパネルはペーストされたホスト名を相対的なものとして扱い、target.provider.com の代わりに target.provider.com.yourdomain.com を黙って保存する。レコードは存在し、パネルには緑のチェックが表示されるが、何にも解決しない。
  2. 末尾ドットの混乱。 一部のパネルは「絶対 — ゾーンの付加をやめる」を意味するために末尾ドット（target.provider.com.）を必要とする；他のパネルはドットを無効として拒否して絶対性を自分で処理する。同じ貼り付けた値が一方のパネルでは正しく、次のパネルでは壊れる。
  3. 古いツールのセレクターが切り替え当日に削除された。 古いツールがすでに署名したメールが再試行キューや転送経路に数日間存在する；セレクターを削除するか（または古いアカウントを閉じて委任された CNAME を無効にする）、そのメールが遡って壊れる。
  4. 間違ったネームサーバーで確認した。 移行にネームサーバーの変更が含まれていた場合、修正されたレコードは一方の NS セットに存在するが、受信側はまだもう一方をクエリしている可能性がある。

センサスの 261 百万ドメインのうち、スキャン時点で発見可能な DKIM キーを提示しているのはわずか 51.84%（2026-06-29 時点データ）だ。

同じ移行は SPF の残骸も残すことが多い — 1,013,416 ドメイン（SPF を試みているドメインのおよそ 138 件に1件）が2つの v=spf1 レコードを実行している。これはプロバイダーの切り替えで既存のレコードをマージせず追加してしまったという典型的なサインだ。その側の移行には独自のガイドがある：メールプロバイダー切り替え後に SPF が動作しなくなった。

壊れた CNAME レコードを見分けるには？

パネルを信頼しない — DNS に実際に何を保存したか確認する。新しいツールが提供した各セレクターの CNAME ターゲットをクエリする。SendGrid スタイルの委任セレクターを模した例（プロバイダーのターゲットの形は異なる）：

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

プロバイダーは s1.domainkey.u1234567.wl123.sendgrid.net を要求したが、保存されたターゲットは .yourdomain.com で終わっている。パネルがゾーンを付加した；その名前は何にも解決しないため、受信側はキーを見つけられない。正常なバージョン：

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

（dig 出力の1つの末尾ドットは正常だ — 完全修飾名を示す。）ターゲットが正しければ1ホップ先を確認する：dig TXT s1._domainkey.yourdomain.com +short でプロバイダーのキーが返るはずだ。正しい CNAME で空の回答は、委任のプロバイダー側に問題があることを意味する — 検証ステップを完了するか、セレクターレベルの診断については DKIM「no key for signature」を参照。

移行ランブック：前・中・後

失敗は通常レコード自体ではなく、順序の問題だ。DKIM の移行が切り替え時に失敗するのは、実際のメールがすでに失敗している後で検証が行われるからだ。

フェーズ何をするか次に進む前の条件
切り替え前新しいツールの DKIM CNAME（とバウンスドメインレコード）を追加し、それを証明する：ネットワーク外から各 CNAME の保存されたターゲットを dig で確認し、ツール独自の検証ステップを完了し、新しいツール経由で管理するメールボックスにテストメールを送るテストメッセージが d= = 自ドメインで dkim=pass を示す — 未検証のツールに実際のメールをルーティングしない
切り替え当日実際のトラフィックを新しいツールに移行。古いツールに属するものは一切触らない：セレクター、CNAME、アカウントをそのまま維持新しいツールのメールは実際の受信側で合格；古いツールはまだ流れているものすべてで合格し続ける
消化後古いツールのセレクターが DMARC アグリゲートレポートに現れなくなるまで監視し（再試行キューと転送は数日続く — 1週間以上見る）、その後レコードとアカウントを廃止する削除前7日以上レポートから古いセレクターが消える

太字の行が移行が成功するか失敗するかの場所だ：その中のすべてのチェックは切り替えの数日前に実行でき、ライブメールへのリスクはゼロだ。セレクター廃止の仕組み（空の p= で再公開する方が削除より優れている理由を含む）はローテーションランブックでカバーしている；このテーブルはツール切り替え自体の順序についてだ。

切り替え後に DKIM を修正するには？

  1. DNS を変更する前に defaults.exposed で無料スキャンを実行する。 ライブレコードを読み取り、受信側が実際に見ているものを表示する — ゾーンが付加された CNAME ターゲットや解決しないセレクターを含む。
  2. 新しいツールが期待する DKIM レコードをリストアップする。 管理コンソールから — メールボックスプロバイダーの場合、Google Workspaceと Microsoft 365のセットアップガイドに場所が示されている；ニュースレターと CRM ツールはドメイン認証の下に CNAME を掲載している（Mailchimp/Brevo/Klaviyo メールの DMARC 失敗を参照）。
  3. dig CNAME <name> +short で各レコードの保存されている値を確認し、ツールが要求したものと一文字ずつ比較する。自ドメインで終わるターゲット = ゾーンが付加されている；再入力し、パネルが付加し続ける場合は末尾ドットを追加する（またはパネルがドットを拒否する場合は削除する）。
  4. 権威ネームサーバーで確認する。 dig +short NS yourdomain.com で NS を調べ、@<そのネームサーバー> に対して CNAME チェックを繰り返す。移行でネームサーバーが変更された場合は両方のセットを確認する — 委任が伝播するまで受信側がまだ古い方をクエリしている可能性がある。
  5. ツールの検証を再実行してテストメッセージを送る。 Authentication-Results ヘッダーが自ドメインに等しい d= で dkim=pass を示すはずだ — ツールのデフォルトドメインでの合格は DMARC にとってアライメントしない。
  6. 古いツールのセレクターをメールが消化されるまで公開し続け、その後意図的に廃止する。次に再スキャンし、DKIM の修正ページでフラグが立ったものを対処する。

よくある質問

DKIM CNAME に末尾ドットは必要か、不要か？ それは完全にパネルによる。ドットは「絶対名 — ゾーンを付加しない」を意味する；一部のパネルは必要とし、一部は自動的に追加し、一部は拒否する。重要な唯一のテストは保存後の dig CNAME <selector>._domainkey.yourdomain.com +short の出力だ：ターゲットが自ドメインで終わっていれば、パネルがゾーンを付加したのでドットが必要（または別の入力形式）。

切り替え当日に古いツールの DKIM レコードを削除できるか？ いいえ。古いツールが署名したメールがまだ再試行キューや転送経路にあり、それが指すキーを削除するとそれらのメッセージが遡って壊れる。DMARC アグリゲートレポートで現れなくなるまで（1週間以上）古いセレクターをライブのまま維持し、それより前に古いアカウントも閉じない。

DNS パネルと新しいツールの両方が「検証済み」と言っているが、受信側はまだ DKIM が失敗する。なぜか？ 2つの一般的なケース：ツールがキャッシュされたチェックに対して検証したが権威ネームサーバーが別のものを返している（dig @<ns> で直接クエリする）か、DKIM は合格しているがあなたのドメインではなくツールのデフォルト署名ドメインで合格しているため DMARC がアライメントで失敗している。スキャンで両者を区別できる。

移行のオーバーラップ期間中に両方のツールの DKIM レコードが共存できるか？ はい — そうすべきだ。DKIM には単一レコードルールがない：各セレクターは独自の DNS 名なので、両方のツールのレコードが競合なく並存し、古いセレクターを消化が完了するまで維持するルールに自由に従える。（SPF は逆だ — 2つの v=spf1 レコードは無効にする。それがSPF 移行ガイドがマージについて説明している理由だ。）

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

クライアントや雇用主のためにこの移行を実施している場合、証拠で締めくくる。新しいツールが署名してアライメントしたら、無料スキャンを再実行し、採点レポートをビジネスオーナーに転送する：日付入りで平易な言葉で、切り替えによってドメインが完全に認証された状態が維持されていることを示す。「移行が完了した」という主張を文書に変えるためにサイバー保険更新や次の取引先セキュリティアンケートに必要な成果物だ。

DKIM を無料でチェックする

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

ドメインをチェックする → · プロバイダー切り替え後に SPF が壊れた → · DKIM を修正する → · Google Workspace で DKIM を設定する → · 集計データのみ使用。データは EU 内で保存・処理。