SiteKensa

DKIM認証に失敗する原因|レコードは見つかるのに検証できないとき

公開日 更新日 DKIMメール独自ドメイン
DKIM認証が失敗する3つの状態(構文エラー・失効・レコードの重複)の見分け方とそれぞれの対応を示す図

診断で「セレクタ○○のレコードに問題があります」「セレクタ○○の鍵が失効しています」「セレクタ○○のレコードが○件あります」のいずれかが表示された場合、DKIMのレコード自体は見つかっています。中身に問題があるという意味です。

先に結論を書きます。

  • レコードが見つかった状態で認証に失敗する原因は、構文エラー・p=タグが空の「失効」・同じセレクタ名の複数レコードの3つに絞れます。診断結果の文言でどれに当たるかがすぐ分かります
  • 「失効しています」という表示は、ご自身でセレクタ名を指定して再診断した場合にだけ出ます。自動診断だけを行っている場合、実際には失効していても表示されないことがあります。「見つからない」ことと「失効していない」ことは別です
  • 失効はDNSの入力ミスではなく、事業者やご自身が鍵を無効化したことを意味する場合がほとんどです。焦る前に今も使っているセレクタかどうかを確認してください
  • DNSの画面で直せるのは構文エラーの一部だけです。多くの場合、直す場所は利用中のメールサービスの管理画面です
  • いまの状態はメール認証の診断にドメインを入力すると確認できます

この記事は、サイトを運営していてDNSにDKIMのレコードを追加したことはあるが、タグの意味までは追っていない方に向けて書いています。診断で「レコードに問題があります」「鍵が失効しています」「レコードが○件あります」のいずれかが表示された場合の読み方から直す場所の見分け方までを扱います。

用語をここで揃えます。すでにご存じの場合は読み飛ばしてください。

用語 意味
DKIM メールに電子署名を付け、途中で内容が書き換えられていないことを受信側が確認できるようにする仕組み
セレクタ 公開鍵を区別するための名前。セレクタ名._domainkey.ドメイン名 というTXTレコードに公開鍵が置かれる
tag=value DKIMのレコードが使う書式。v=DKIM1; p=... のように、名前と値を = で結び ; で区切る
p= 公開鍵そのものを表すタグ。必須のタグで、値が空だと「失効」を意味する
v= レコードの版を表すタグ。省略しても DKIM1 として扱われる
失効 鍵が使えなくなったことの明示的な宣言。未設定とは違う

診断結果の文言でまず自分の状態を確認する

自分のケースを先に選んでください。

診断結果の文言 意味 読む場所
セレクタ○○のレコードに問題があります 構文エラー このすぐ下の見出し
セレクタ○○の鍵が失効しています p= タグの値が空 p=が空のレコードは『失効』を意味します」
セレクタ○○のレコードが○件あります 同じセレクタ名にレコードが複数ある 「セレクタ名のレコードが複数あるとき」
DKIMが設定されていない可能性があります / DKIMセレクタを特定できませんでした レコード自体が見つからない DKIMセレクタの確認方法
セレクタ○○の鍵長が○○bit / セレクタ○○がテストモードのままです レコードは見つかったが、別の指摘 DKIMの鍵長は1024bitで足りるのか / DKIMのt=y(テストモード)とは
SPFはあるがDKIMが確認できません そもそもDKIMが要るかどうかの判断 SPFだけで足りるのか

「セレクタを特定できませんでした」に進んだ場合、レコードを自分で書いた記憶があるなら1点だけ確認してください。DKIMのレコードには v=DKIM1 という版を表すタグを書くことがありますが、値を書き間違えるとレコードごと無視され、レコードが無いのと同じ扱いになります。RFC 6376 セクション3.6.1 は「Records beginning with a "v=" tag with any other value MUST be discarded」(v= タグで始まり、それ以外の値を持つレコードは破棄しなければならない)と定めています。v=DKIM1 のつづりに誤りがないか確認してから上記のリンク先へ進んでください。

レコードは見つかったのに構文エラーになる3つのパターン

DKIMのレコードは「タグ=値」を ; で区切って並べる書式です。構文エラーになるのはこの形が崩れている場合で、原因は次の3つに絞れます。

tag=value の形式になっていない

; で区切られた各項目は、必ず 名前=値 という形になっている必要があります(RFC 6376 セクション3.2)。コピーしている途中で区切りの ; が抜けたり、= の無い文字列が紛れ込んだりするとその部分が独立した項目として読み取れず、この構文エラーになります。

同じタグが2回書かれている

RFC 6376 セクション3.2 は「Tags with duplicate names MUST NOT occur within a single tag-list; if a tag name does occur more than once, the entire tag-list is invalid」(同じ名前のタグが2回以上現れてはならない。現れた場合、そのタグリスト全体が無効になる)と定めています。鍵を更新するときに古いタグを消し忘れたまま新しい行を足すと起きやすいミスです。

公開鍵(p タグ)自体が書かれていない

p= はDKIMのレコードに必須のタグです(RFC 6376 セクション3.6.1)。v=DKIM1 のように版だけを書いて、肝心の p= をレコードに含め忘れるとこの状態になります。

ここで注意してください。p= のタグ自体が無い場合(この見出し)と p= はあるが値が空の場合は別の状態です。値が空の場合は、次の見出し(失効)で扱います。

公開鍵は長い文字列になるため、DNSのTXTレコードは複数の文字列に分けて登録されることがあります。RFC 1035 セクション3.3 は長さを表す1バイトを含めて1つの文字列を256バイトまでと定めており、セクション3.3.14 はTXTレコードが複数の文字列を持てると定めています。この分割そのものは構文エラーの原因になりません。本サイトの診断は、複数の文字列を1本に結合してから読んでいます。

p= が空のレコードは「失効」を意味します

p= のタグはあるのに値が空になっている場合、それは設定ミスではなく「失効」の明示的な宣言です。RFC 6376 セクション3.6.1 は次のように定めています。

p= Public-key data (base64; REQUIRED). An empty value means that this public key has been revoked.

(p は公開鍵のデータを表す必須タグ。値が空の場合、この公開鍵は失効したことを意味する)

同じ節には、なぜ空にするのかという理由も書かれています。

INFORMATIVE RATIONALE: If a private key has been compromised or otherwise disabled (e.g., an outsourcing contract has been terminated), a Signer might want to explicitly state that it knows about the selector, but all messages using that selector should fail verification.

(参考: 秘密鍵が漏えいした場合や何らかの理由で使えなくなった場合(委託先との契約終了など)、署名者はそのセレクタを認識していることを明示しつつ、そのセレクタを使ったメールはすべて認証に失敗すべきだと伝えたいことがある)

つまり、p= が空になっているのは多くの場合、鍵の持ち主(利用中のメールサービスやご自身)が意図して行った操作です。DNSへの入力ミスでこの状態になることは考えにくく、事故ではなく意図的な無効化を疑ってください。

実際にまれな状態です。Majestic Millionに掲載されている .jp ドメイン19,065件のうち、DKIMの鍵を取得できた9,937件の中で p= が空だったのは4件(0.04%)でした(2026-08-04測定、scripts/measure-dkim-keys.mjs)。まれだからこそ見つかったら偶然ではなく理由があると考えて、次の見出しで今も使っているセレクタかを確認してください。

なお、この「失効しています」という表示が出るのはご自身でセレクタ名を入力して再診断した場合に限られます。自動診断が候補のセレクタを順に試したとき、値が空の p= が見つかっても失効とは表示されません。推測で試したセレクタは、そもそも使われていない名前かもしれないため、失効と断定できないからです。利用中のセレクタが分かっている場合だけ、指定して確認してください。

セレクタ名のレコードが複数あるとき

診断で「セレクタ○○のレコードが○件あります」と表示された場合、同じセレクタ名に複数のTXTレコードが登録されています。RFC 6376 セクション3.6.2.2 は次のように定めています。

TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined.

(特定のセレクタ名に対するTXTレコードは一意でなければならない。つまり、1つのレコードセットに複数のレコードがある場合、結果は不定である)

「不定」としているだけです。必ず認証に失敗すると決まっているわけではありません。受信側がどちらのレコードを使うかが仕様で決まっていないという状態です。診断がこの項目を「修正が必要な項目」ではなく「確認が必要な項目」にしているのはこのためです。ただし、古い鍵のレコードが選ばれればそのレコードで署名を検証しようとしたメールは失敗します。

直し方は、いま使っている1件だけを残すことです。どちらが古い鍵かは診断側では判定できないため、値は示しません。現在有効なセレクタの値を利用中のメールサービスの管理画面で確認してください。確認できたらDNSの画面でもう1件を削除してください。

鍵を差し替える作業の途中で一時的に2件になることがあります。この状態そのものは珍しくありませんが、2件ある間に届いたメールは失敗する可能性があるため、作業中だからといって放置してよいわけではありません。差し替えが終わったら早めに古いレコードを削除してください。

今も使っているセレクタか確認する

失効しているセレクタが、いまの送信で使われているかどうかで対応の優先度が変わります。

確認するには、問題が起きている送信経路から自分宛にテストメールを送り、届いたメールの DKIM-Signature ヘッダーに含まれる s= の値を見ます。読み方はDKIMセレクタの確認方法の「まずDKIM-Signatureのd=とs=を確認する」で扱っています。

  • いまの送信経路が失効したセレクタと同じ s= で署名している場合、そのメールは認証に失敗し続けます。優先して直してください
  • いまの送信経路が別のセレクタで署名している場合、失効したセレクタは過去に使われていた古い鍵です。いまのメール配送への影響はありませんが、DNSに残したままにする理由もないため、削除を検討してください

直す場所は、値を作った側と入力した側で変わります

公開鍵はメールサービス側が発行するもので、DNSの画面には値を貼り付けるだけです。診断が生成する設定値の一覧にこの記事が扱う3つの項目の値が出てこないのはこのためです。書き換えるべき正しい値を診断側で知る手段がありません。

直す場所は状態によって変わります。

  • 構文エラーで、メールサービスの指示を自分でDNSへ入力した記憶がある場合: 入力時のミス(区切りの脱落・コピー漏れ・タグの重複)が疑われます。この場合はDNSの画面で値を直せば解決します。管理画面から元の指示を出し直し、あらためて貼り付けてください
  • 構文エラーで、入力した記憶がない、あるいはメールサービスが自動でDNSへ反映する仕組みを使っている場合: メールサービス側の出力そのものに問題がある可能性があります。管理画面でDKIMの設定を確認し、鍵を再発行してください
  • 失効の場合: DNS側の入力ミスでは起きません。利用中のメールサービスの管理画面でDKIMの鍵を作り直してください
  • レコードが複数ある場合: 確認はメールサービスの管理画面、削除はDNSの画面です。詳しくは「セレクタ名のレコードが複数あるとき」を参照してください

利用中のメールサービスがはっきりしている場合は、事業者別ガイドからDKIMの設定手順を確認できます。

直したあと、何が出ていれば直っているか

設定を直したら、メール認証の診断でドメインを再診断してください。「DKIMは正しく設定されています」という表示に変わり、見つかったセレクタの一覧が示されれば直っています。

まだ「セレクタ○○のレコードに問題があります」や「セレクタ○○の鍵が失効しています」や「セレクタ○○のレコードが○件あります」が表示される場合、直した値が反映されていないか別のセレクタにも同じ問題が残っています。この記事の最初の表に戻り、表示されている文言を確認し直してください。

自分のドメインで確認する

いま自分のドメインのDKIMがどの状態にあるかは、メール認証の診断にドメインを入力すると確認できます。レコードが見つかった場合は、セレクタごとに構文エラー・失効・レコードの重複の有無を表示します。

そもそもレコードが見つからず「DKIMが設定されていない可能性があります」と表示された場合は、この記事の対象ではありません。本当に無いのかを確かめる手順は「DKIMが設定されていない可能性があります」と出たときで扱っています。

まずは全体を診断してみましょう

専門知識がなくてもいまの設定状況と具体的な対処方法をわかりやすく確認できます。

ドメイン設定を診断する

利用中のDNS事業者が分かっているなら事業者別の設定手順から直接進めます。