![DKIM確認コマンドのOS別対比](/blog/dkim-check-commands/os-commands.svg)

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

- DKIM レコードを DNS から引き出す `dig` / `nslookup` / PowerShell の具体的なコマンド
- 受信メールの `Authentication-Results` ヘッダから DKIM 検証結果とセレクタを読み解く方法
- セレクタ名が分からないときに「逆引き」で特定する手順

DKIM の概念は[DKIM設定の確認方法](/blog/dkim-verification)にまとめています。本記事は確認作業をターミナルとメールソフトで進めるためのコマンド逆引き集です。

## DKIM レコードはどこに公開されているか

DKIM の公開鍵は次の場所に TXT または CNAME で登録されています。

```
<セレクタ>._domainkey.<ドメイン名>
```

たとえば `example.co.jp` を Google Workspace で運用していれば、確認すべきホスト名は `google._domainkey.example.co.jp` になります。Microsoft 365 なら `selector1._domainkey.example.co.jp` と `selector2._domainkey.example.co.jp` の2本です。セレクタ名がサービスごとに違う背景は[DKIMセレクタとは](/blog/dkim-selector-explained)で整理しています。DNS が Cloudflare の場合の登録手順は [Cloudflare DNS で DKIM を設定する手順](/blog/cloudflare-dkim-setup) を参照してください。

## dig コマンド（macOS / Linux）

最も標準的な確認方法です。`+short` オプションを付けると値だけが返るため、見やすくなります。

### Google Workspace の DKIM を確認

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

返り値の例:

```
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
```

### Microsoft 365 の DKIM を確認（CNAME）

Microsoft 365 は CNAME 経由のため、最初に CNAME を辿ります。

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

CNAME 先が分かれば最終 TXT も辿れます。

### 出力の読み方

DKIM レコードは次のタグで構成されています。

- `v=DKIM1`：バージョン識別子（必須）
- `k=rsa`：鍵種別（省略時は rsa）
- `p=`：公開鍵本体（base64）
- `t=y` がついていると **テストモード**（受信側は失敗してもエラー扱いしない）

`p=` の値が空（`p=;`）のレコードは「失効済み」を意味し、その鍵での署名は受信側で全て失敗扱いになります。

## Windows 環境（nslookup と PowerShell）

### nslookup

Windows 環境では `nslookup` が標準で使えます。`-q=TXT` でレコード種別を指定します。

```
nslookup -q=TXT google._domainkey.example.co.jp
```

CNAME を確認する場合は次のとおりです。

```
nslookup -q=CNAME selector1._domainkey.example.co.jp
```

`nslookup` は OS によって出力が折り返され `p=` の値が途中改行されることがあるため、空白を取り除いて1行にしてから比べてください。

### PowerShell（Resolve-DnsName）

Windows の PowerShell には専用コマンドレットがあります。

```
Resolve-DnsName -Type TXT -Name google._domainkey.example.co.jp
```

DNS サーバーを明示したいときは `-Server 8.8.8.8` を付けます。社内 DNS が古い値をキャッシュしているケースの切り分けに有効です。

```
Resolve-DnsName -Type TXT -Name google._domainkey.example.co.jp -Server 8.8.8.8
```

![DKIMレコード確認の3ステップフロー](/blog/dkim-check-commands/three-step-flow.svg)

## メールヘッダーから「実際に動いているか」を確認

DNS にレコードが見えても、それが実際の送信メールで使われているとは限りません。最終確認は **受信メールのヘッダー** で行います。

Gmail に自社ドメインからテストメールを送り、`Authentication-Results` 行を探します。

```
Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.co.jp header.s=google header.b=...
  spf=pass smtp.mailfrom=example.co.jp
  dmarc=pass header.from=example.co.jp
```

確認すべきは次の3点です。

- `dkim=pass` になっているか（`fail` `neutral` `none` だと NG）
- `header.s=` のセレクタ名が想定通りか（DNS で確認した値と一致しているか）
- `header.i=` のドメインが From ヘッダーと一致しているか（DMARC アラインメントの観点）

`dkim=fail` の代表的な原因は、鍵長が短すぎる・公開鍵が DNS から引けない・転送経路で本文が改変された、の3つです。詳しい切り分けは[DMARC失敗時のトラブルシューティング](/blog/dmarc-fail-troubleshooting)も参考にしてください。転送や本文の差異で署名が壊れる挙動は正規化方式に左右されるため、[DKIM 正規化｜simple と relaxed の違い](/blog/dkim-canonicalization-explained)もあわせて読むと理解が深まります。

### セレクタが分からないときの逆引き手順

「他社経由で送信されているらしいが、どのサービスを使っているか不明」というケースは中小企業でよくあります。このときも `Authentication-Results` ヘッダが手がかりになります。

1. 該当するメールを受信し、ソースまたはオリジナルメッセージを表示
2. `header.s=` の値を控える（例: `s1024`、`mailo`、`em1234`）
3. ヘッダー全体に含まれる `From` ・ `Return-Path` ・ `Received` のホスト名から送信ベンダーを推測（mailgun.org、sendgrid.net、amazonses.com など）
4. 想定したセレクタで `dig TXT <セレクタ>._domainkey.<ドメイン>` を打ち、TXT が返れば一致

`header.s=` だけで送信元サービスが特定できない場合、`Received` 行に並ぶサーバー名を順に追うと配送経路が見えます。

### オンラインツールでまとめて確認する

コマンド操作が難しい場合や、社内で結果を共有したい場合はオンラインツールが便利です。

- **mxtoolbox**：セレクタを指定すると DKIM の TXT を解析してくれる
- **dmarcian**：DKIM・SPF・DMARC の整合性を1画面で表示
- **ドメイン番人 [/diagnose](/diagnose)**：日本語でレポートを返し、DMARC・SPF・DKIM・SSL を一括チェック

オンラインツールは「セレクタ名を入れる欄があるか」が要点です。ホスト名にセレクタを含む特殊なレコードのため、入力欄がないと正しく確認できません。メールヘッダー貼り付け型のツールはセレクタ自動検出が効くので、送信元サービスが不明なドメインの調査に向いています。

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。