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

- メールヘッダの `DKIM-Signature:` に並ぶ各タグ（`v=` `a=` `c=` `d=` `s=` `bh=` `b=` `h=` `t=` `x=`）の意味
- 実際のヘッダ例を見ながら、どの値が何を表しているかの読み解き方
- DKIM 認証に失敗したとき、どのタグを最初に確認すればよいか

## 「DKIM-Signature の呪文」を読めるようにする

送信したメールが迷惑メール判定されたり、相手に届かなかったりしたとき、調査の起点になるのがメールヘッダの `DKIM-Signature:` 行です。ところがこの行は `v=1; a=rsa-sha256; c=relaxed/relaxed; ...` のように記号と短い英字が延々と続き、初見ではどこを見ればよいか分かりません。

DKIM（ディーキム：メールに電子署名を付けて改ざんを検知する仕組み）の署名ヘッダは、RFC 6376 という公式仕様の 3.5 節でタグごとに意味が決められています。1 つずつ分解すれば、難しい暗号の知識がなくても「このメールはどのドメインが、どの鍵で署名したのか」を読み取れるようになります。

本記事では実際のヘッダ例を題材に、各タグの役割を平易に解説します。署名そのものの検証手順は[DKIM の確認方法](/blog/dkim-verification)で詳しく扱っているので、本記事は「ヘッダの読み方」に絞ります。

## まず実物の DKIM-Signature を見てみる

下のヘッダは、典型的な DKIM 署名の構成を示したものです。実際のメールでは値がもっと長くなりますが、並ぶタグの種類は同じです。

```
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.co.jp; s=selector1;
  h=from:to:subject:date;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AbCdEfGh1234...（実際は長いBase64文字列）
```

このように `タグ=値` がセミコロン区切りで並んでいます。タグには大きく分けて、署名の前提条件を示すもの（`v=` `a=` `c=`）、署名の主体を示すもの（`d=` `s=`）、署名の中身そのもの（`bh=` `b=` `h=`）、そして有効期間を示すもの（`t=` `x=`）があります。

![DKIM-Signature ヘッダを各タグに分解したアノテーション図](/blog/dkim-header-signature-fields/signature-tag-breakdown.svg)

## 署名の前提と主体を示すタグ（v / a / c / d / s）

### `v=`（バージョン）

`v=1` 固定で、DKIM 署名の仕様バージョンを示します。RFC 6376 上は必須タグで、現状の値は `1` のみです。基本的に読み飛ばして問題ありません。

### `a=`（署名アルゴリズム）

署名に使った暗号アルゴリズムを示す必須タグです。現在は `a=rsa-sha256` が標準で、RFC 6376 でも署名者は rsa-sha256 を使うことが推奨されています（SHOULD）。古いメールでは `rsa-sha1` を見かけることがありますが、安全性が低いため現在は非推奨です。`a=` に sha1 が残っている場合は、署名鍵まわりの設定が古い可能性を疑う手がかりになります。

### `c=`（正規化方式／canonicalization）

署名を作る前に、ヘッダと本文の表記ゆれ（空白や改行の差など）をどう揃えるかを示すタグです。`c=relaxed/relaxed`（ヘッダ／本文の順）のように 2 つの方式の組み合わせで書かれ、実際のメールでは `relaxed/relaxed` をよく見かけます。

転送経路で本文がわずかに書き換わると署名が壊れる、という DKIM 特有のトラブルはこの正規化方式と深く関わります。仕組みと「どちらを選ぶべきか」は[DKIM の正規化（canonicalization）を解説](/blog/dkim-canonicalization-explained)にまとめているので、`c=` の値で詰まったらそちらをご参照ください。

### `d=`（署名ドメイン）

そのメールの署名に責任を持つドメインを示す必須タグです。`d=example.co.jp` であれば、example.co.jp というドメインが「このメールは自分のところから出した」と表明していることになります。

DMARC（ディーマーク：SPF と DKIM の結果をまとめて判定する仕組み）では、この `d=` の値が差出人アドレスのドメインと揃っているか（アライメント）が重要になります。`d=` が自社と無関係なドメインになっていれば、DKIM は通っていても DMARC では認められません。

### `s=`（セレクタ）

公開鍵を引くための「鍵の名札」にあたる必須タグです。受信側は `s=` と `d=` を組み合わせて `<セレクタ>._domainkey.<ドメイン>` という DNS 名を作り、そこから署名検証用の公開鍵を取得します。

たとえば `s=selector1`、`d=example.co.jp` なら `selector1._domainkey.example.co.jp` を参照します。1 つのドメインで複数のメール配信サービスを使うときは、サービスごとに別のセレクタを割り当てて鍵を共存させます。セレクタの設計や命名規則は[DKIM セレクタとは何かをわかりやすく解説](/blog/dkim-selector-explained)で詳しく扱っています。

## 署名の中身と有効期間を示すタグ（bh / b / h / t / x）

![受信側が bh= と b= を使って DKIM を検証する流れ](/blog/dkim-header-signature-fields/dkim-verification-flow.svg)

### `bh=`（body hash、本文ハッシュ）

正規化したメール本文を要約した「本文の指紋」にあたる必須タグです。受信側は届いた本文から同じ手順でハッシュを計算し、`bh=` の値と一致するか比べます。一致しなければ本文が途中で書き換わったと判断され、検証は失敗します。

### `b=`（署名値）

DKIM の本体である電子署名そのものです。送信側が秘密鍵で作った Base64 のデータが入っており、最も長くなる必須タグです。受信側は `s=` と `d=` で取得した公開鍵を使い、この `b=` を検証します。

### `h=`（署名対象ヘッダ一覧）

署名の対象に含めたヘッダ名を、コロン区切りで列挙した必須タグです。`h=from:to:subject:date` であれば、From・To・Subject・Date の各ヘッダが署名に含まれていることを意味します。ここに含まれたヘッダが配送途中で書き換わると、署名検証は失敗します。とくに `from` はほぼ必ず含まれます。

### `t=`（署名のタイムスタンプ）

署名を作成した日時を、世界協定時の 1970 年 1 月 1 日からの経過秒数（Unix 時間）で示す任意タグです。RFC 6376 では付与が推奨されています。`t=1718000000` のような数値で、人が読むときは Unix 時間を日時に変換するツールを使います。

### `x=`（署名の失効日時）

その署名がいつまで有効かを、`t=` と同じ Unix 時間で示す任意タグです。指定された時刻を過ぎた署名は無効とみなされます。`x=` がなければ失効期限なしとして扱われます。古い `x=` が残っていると、正しく署名していても期限切れで弾かれることがあります。

## トラブル時にどのタグを見ればよいか

DKIM 検証に失敗したとき、闇雲に全部を見るのではなく、症状から当たりを付けると効率的です。

- **公開鍵が見つからない／検証が始まらない**: まず `d=` と `s=` を確認。この 2 つから組み立てた `<s>._domainkey.<d>` の DNS レコードが存在し、公開鍵が登録されているかを見ます
- **本文が原因で落ちている疑い（bh の不一致）**: `bh=` の検証が失敗している場合、配送途中の本文書き換えが疑われます。`c=` の正規化方式とあわせて[正規化の記事](/blog/dkim-canonicalization-explained)を確認します
- **ヘッダの書き換わりが疑われる**: `h=` に並ぶヘッダ名を確認し、転送やメーリングリストで件名などが改変されていないかを見ます
- **以前は通っていたのに急に失敗**: `x=` の失効日時、もしくは `a=` が古い `rsa-sha1` のままになっていないかを確認します
- **DKIM は通るのに DMARC で弾かれる**: `d=` が差出人ドメインと揃っているか（アライメント）を確認します

実際にヘッダを取り出して 1 通単位で検証する具体的な手順は、[DKIM の確認方法](/blog/dkim-verification)で `dig` や受信メールの確認方法とあわせて解説しています。

## まとめ

- `DKIM-Signature:` は `タグ=値` がセミコロンで並んだ構造で、RFC 6376 で各タグの意味が定義されている
- `v=` `a=` `c=` が署名の前提、`d=` `s=` が署名の主体、`bh=` `b=` `h=` が署名の中身、`t=` `x=` が有効期間を表す
- トラブル時は症状に応じて見るべきタグを絞れる（鍵が引けないなら `d=` と `s=`、本文起因なら `bh=` と `c=`、急に失敗したなら `x=` や `a=`）
- DKIM は通るのに DMARC で弾かれるときは `d=` のアライメントを疑う

## 自社の DKIM 設定を確認しませんか

自社ドメインの DKIM が正しく署名・検証されているかは、ドメイン番人の[無料診断](/diagnose)で数秒で確認できます。`DKIM-Signature` ヘッダの読み解きや、複数サービスのセレクタ設計で迷う場合は、[お問い合わせフォーム](/contact)から状況をお知らせください。専門家が一緒に整理いたします。