DKIM設定の確認方法｜中小企業向けわかりやすく

この記事でわかること

• DKIMレコードの構造と、セレクタ（selector）の役割
• Google Workspace や Microsoft 365 などサービス別の設定値と確認ポイント
• dig コマンドとメールヘッダーで「ちゃんと動いているか」を確かめる手順

「DKIMの設定が終わったはずなのに、Gmail 側で dkim=pass になっているか確信が持てない」「セレクタ名が合っているか不安」という相談はよくいただきます。DKIM（ディーキム）は公開鍵暗号を使う仕組みなので、設定ミスがあってもエラー表示が出にくく、受信側のヘッダーを見て初めて「実は失敗していた」と分かるケースが少なくありません。本記事では、設定内容の確認方法を3つの経路で整理します。基本概念からおさらいしたい方は、先にSPF・DKIM・DMARCの違いをわかりやすく解説をご一読ください。

DKIMレコードの構造とセレクタ

DKIM（DomainKeys Identified Mail、RFC 6376）は、送信時にメールへ電子署名を付け、受信側が DNS に公開されている公開鍵で署名を検証する仕組みです。公開鍵は <selector>._domainkey.<ドメイン名> という形で公開されます。

たとえばドメインが example.co.jp でセレクタが google なら、DNSには次の位置にレコードが存在します。

google._domainkey.example.co.jp.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

• v=DKIM1: バージョン識別子（必須）
• k=rsa: 鍵種別（デフォルトは rsa、省略可）
• p=...: 公開鍵本体（base64）

セレクタは複数持てるのがDKIMの重要な特徴です。鍵を更新するとき、古い鍵を消さずに新しいセレクタで別レコードを立てておけば、配送中の古い署名が失敗せずに済みます。RFC 6376は「同じセレクタ名で鍵を差し替えるのではなく、新しい鍵は新しいセレクタに割り当てる」ことを推奨しています。

サービス別の設定値と確認ポイント

DKIMは送信サービスがセレクタ名とレコードの種別（TXT か CNAME か）を決めます。推測で書かず、必ず各サービスが指定した値を使います。

サービス	セレクタ	レコード種別	備考
Google Workspace	google（デフォルト、変更可）	TXT	管理コンソールで鍵を生成し、表示された公開鍵をDNSに貼る
Microsoft 365（Exchange Online）	selector1、selector2	CNAME	2025年5月以降の新規ドメインは動的パーティション文字付きの新形式
Resend	resend	TXT	ドメインごとに発行された公開鍵をDNSに貼る

Google Workspace

管理コンソールの「アプリ」→「Google Workspace」→「Gmail」→「メールの認証」から、鍵長を選んで（2048ビットが推奨、1024ビットも選択可）鍵を生成します。表示された値を google._domainkey.<ドメイン> の TXT として DNS に登録します。反映までに最大48時間かかる場合があります。

Microsoft 365

Microsoft 365 は TXT ではなく CNAME レコードでDKIMを有効化します。2025年5月以降に新しく追加したカスタムドメインは、以下のような新形式が発行されます。

selector1._domainkey.<ドメイン>  CNAME  selector1-<ドメイン>._domainkey.<テナント>.<文字>-v1.dkim.mail.microsoft
selector2._domainkey.<ドメイン>  CNAME  selector2-<ドメイン>._domainkey.<テナント>.<文字>-v1.dkim.mail.microsoft

<文字> は Microsoft 側で自動割当されるため、必ず Exchange Admin Center または Exchange Online PowerShell で発行された値を確認してください。既存ドメインは旧形式（<テナント>.onmicrosoft.com 末尾）のまま動作します。

Resend

Resend はドメインを認証する際に発行される DNS レコード一式（SPF / DKIM / MX など）を提示してきます。DKIM は resend._domainkey.<ドメイン> の TXT として貼ります。send.<ドメイン> のようなサブドメイン全体を送信用に切り出す運用もよく使われます。

設定の確認方法（3つの経路）

DKIMの動作確認には、dig / メールヘッダー / 管理画面 の3つの経路があります。

経路1｜dig コマンドで DNS に公開鍵が見えるか

DNS に公開鍵が正しく載っているかを、次のコマンドで確認します。

dig TXT google._domainkey.example.co.jp +short

v=DKIM1; k=rsa; p=... で始まる値が返れば、レコード自体は公開できています。Microsoft 365 の場合は CNAME なので次のように確認します。

dig CNAME selector1._domainkey.example.co.jp +short

経路2｜送ったメールのヘッダーを確認する

これが最も重要な確認です。Gmail などに自社ドメインからテスト送信し、受信したメールのヘッダーを表示します。

• Gmailなら「メッセージのソースを表示」
• Outlookなら「メッセージオプション」または「インターネットヘッダー」

ヘッダー内の Authentication-Results 行に次のような記述があれば、DKIM署名が正しく検証されています。

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.co.jp header.s=google header.b=...

dkim=pass の後ろに自社ドメインが表示されているかが要点です。header.s= にはセレクタが入ります。dkim=fail や dkim=neutral の場合は、公開鍵が見つからない・署名が壊れている・鍵長が短すぎるといった問題が考えられます。

経路3｜サービスの管理画面で状態を見る

各サービスの管理画面にも状態表示があります。Google Workspaceの管理コンソールには「認証中」「未認証」の表示があり、Microsoft 365 の Defender ポータル（Email authentication settings → DKIM）では Valid / CnameMissing / NoDKIMKeys といったステータスが確認できます。

よくあるつまずきポイント

セレクタ名を推測してしまう

「たぶん default だろう」「どこかの記事で dkim と書いてあった」と推測で設定すると、ほぼ確実に検証が失敗します。セレクタ名は送信サービスが決めるもので、自分で命名するのは自社でDKIM署名を行っている場合に限ります。必ず管理画面の指示通りに貼ってください。

鍵長が 1024bit のまま放置されている

RFC 6376は長期利用する鍵として1024ビット以上を必須としていますが、現代のセキュリティ水準では2048ビットが実質的な最低ラインです。Google Workspaceは鍵生成時に1024と2048のどちらかを選ばせます。初期設定のまま1024を選ぶと、将来的に弱い鍵として警告される可能性があります。新規設定では2048ビットを選び、既存ドメインでも順次移行するのが安全です。

DKIMだけではなりすまし対策は完結しない

DKIMは「改ざんされていない本物」を示すだけで、From欄のドメインと署名ドメイン（d= タグ）が一致しているかを自動では保証しません。自社を騙った偽メールを受信側で弾くには、DMARCのアラインメントが必要です。詳しい関係はSPF・DKIM・DMARCの違いをわかりやすく解説で、DMARCの設定手順はDMARC設定方法を徹底解説で解説しています。

まずは自社のDKIM設定を確認しましょう

要点を整理します。

• DKIMの公開鍵は <selector>._domainkey.<ドメイン> に載る
• セレクタ名とレコード種別（TXT / CNAME）はサービスが決めるので、推測せず指定値を使う
• 動作確認は「dig で DNS 公開 → メールヘッダーで dkim=pass → 管理画面ステータス」の3段階で見る
• 鍵長は2048ビットが現代的な最低ライン。将来のDMARC運用も見据えて強めに設定する

無料のドメイン診断ツールに自社ドメインを入力すると、SPF・DKIM・DMARCの設定状況がまとめて確認できます。セレクタ名が分からない、送信サービスが複数あって混乱している、という場合はお問い合わせフォームから状況をお知らせください。設定内容を整理し、必要な手順をお伝えします。