![DKIMはDNSとメールヘッダーで確認](/blog/dkim-verification/hero.avif)

## この記事でわかること

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

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

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

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

![DKIM署名と検証の流れ](/blog/dkim-verification/dkim-flow.svg)

たとえばドメインが `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 か）を決めます。推測で書かず、必ず各サービスが指定した値を使います。

![サービス別セレクタとレコード種別](/blog/dkim-verification/service-selectors.svg)

| サービス | セレクタ | レコード種別 | 備考 |
|---|---|---|---|
| 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つの経路があります。

![DKIM設定の3つの確認経路](/blog/dkim-verification/verification-paths.svg)

### 経路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 ビット以上を推奨（SHOULD）していますが、現代のセキュリティ水準では **2048 ビットが実質的な最低ライン**です。Google Workspace は鍵生成時に 1024 と 2048 のどちらかを選ばせます。初期設定のまま 1024 を選ぶと、将来的に弱い鍵として警告される可能性があります。新規設定では 2048 ビットを選び、既存ドメインでも順次移行するのが安全です。

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

DKIMは「改ざんされていない本物」を示すだけで、From欄のドメインと署名ドメイン（`d=` タグ）が一致しているかを**自動では保証しません**。自社を騙った偽メールを受信側で弾くには、DMARCのアラインメントが必要です。詳しい関係は[SPF・DKIM・DMARCの違いをわかりやすく解説](/blog/spf-dkim-dmarc-difference)で、DMARCの設定手順は[DMARC設定方法を徹底解説](/blog/dmarc-setup-guide)で解説しています。`d=` を含む DKIM-Signature の各タグの読み方は[DKIM署名ヘッダの各タグ完全解説](/blog/dkim-header-signature-fields)で整理しています。

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

要点を整理します。

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

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

SSL 証明書、Web セキュリティヘッダ、サブドメイン棚卸しの単発チェックも合わせて [無料ツール一覧](/tools) にまとめています。