DKIM署名ヘッダの各タグ完全解説

この記事でわかること

• メールヘッダの 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 の確認方法で詳しく扱っているので、本記事は「ヘッダの読み方」に絞ります。

まず実物の 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=）があります。

署名の前提と主体を示すタグ（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）を解説にまとめているので、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 セレクタとは何かをわかりやすく解説で詳しく扱っています。

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

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= の正規化方式とあわせて正規化の記事を確認します
• ヘッダの書き換わりが疑われる: h= に並ぶヘッダ名を確認し、転送やメーリングリストで件名などが改変されていないかを見ます
• 以前は通っていたのに急に失敗: x= の失効日時、もしくは a= が古い rsa-sha1 のままになっていないかを確認します
• DKIM は通るのに DMARC で弾かれる: d= が差出人ドメインと揃っているか（アライメント）を確認します

実際にヘッダを取り出して 1 通単位で検証する具体的な手順は、DKIM の確認方法で 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 が正しく署名・検証されているかは、ドメイン番人の無料診断で数秒で確認できます。DKIM-Signature ヘッダの読み解きや、複数サービスのセレクタ設計で迷う場合は、お問い合わせフォームから状況をお知らせください。専門家が一緒に整理いたします。