DKIMが失敗したら、署名のd=で示すドメインとs=のセレクター、受信側の検証結果を確認します。公開鍵が見つからない問題と、署名後に本文などが変わった問題は別です。DNSに鍵があるという確認だけで終わらせず、その一通がどの鍵で署名されたかから調査します。

最初に分ける条件

日本の企業で複数のメールサービスを使っている場合、同じ会社名の通知でも署名ドメインが違うことがあります。店舗の予約、請求、販促を一つの結果で判断しないでください。失敗した通知を生成したサービスと、最後に設定を変更した担当者を特定すると、適切な公開鍵を確認しやすくなります。

セレクターは公開鍵を参照するための手掛かりです。古い鍵のDNSだけを見て正常と判断すると、現在のメールが別のセレクターを使っていることを見落とします。管理画面の表示と原文を照合し、権威DNSでの値や公開状態を確認します。秘密鍵を外部の診断資料へ貼り付ける必要はありません。

証拠を残す確認手順

転送やゲートウェイで本文や署名対象のヘッダーが変わる場合は、経路の管理者と確認します。署名の方式や正規化も関わるため、フッター追加を見つけただけで唯一の原因とは断定しません。直接配送と問題の経路を通した検証を比べ、変化が生じる段階を絞り込みます。

想定例として、国内の会員案内が直接送信では成功し、社内の中継を経由した場合だけDKIM failになるケースを考えます。中継が問い合わせ先の文言を追加しているなら、その処理を含めて調べます。DNSの鍵を何度も作り直す前に、原文の差と管理者の記録から署名後の変更を確認してください。

鍵を更新するときは、配信サービスの公式手順に従い、古いメールの検証が必要な期間や移行方法も確認します。新鍵を保存した時点で全経路が切り替わるとは限りません。新旧セレクターと使い始めた時刻を記録し、問題が起きた場合にどの設定へ戻すかを担当者間で共有します。

DKIMの成功はFromとの整合性や受信箱への配置を自動的に保証しません。複数の署名があるメールは、どの署名が成功し、どれがDMARCへ使われたかを確認します。Inbox Checkでは原文と配置の観察を分け、未検証の企業経路や携帯メールについては別の確認が必要だと明記してください。

測定方法と対象の制約を読み、Inbox Checkのテスト対象を確認してください。標本結果は個々の実顧客への保証ではありません。