DKIM徹底解説 — 署名ヘッダーの中身と、守れる範囲
最終更新: 2026-09-09
こちらは踏み込んだ解説です。まず全体像をつかみたい方はDKIMとは？（かんたん解説）からどうぞ。このページでは、実際に付いている DKIM-Signature ヘッダーを1タグずつ読み、DKIMが何を守っていて、何を守っていないのかを確認します。
DKIM-Signatureヘッダーの、読むべき4つのタグh=に挙げていないヘッダーは、後から足しても署名が壊れないこと- 転送に耐えるかどうかが
c=（正規化）で決まること l=を使ってはいけない理由と、鍵まわりの実務
署名と検証 — 秘密鍵で押し、公開鍵で照合する
DKIMは、送信側がメールに電子署名を付け、受信側がDNSで公開鍵を取ってきて照合する仕組みです。鍵は2つで1組で、秘密鍵は送信サーバーの中だけにあり、公開鍵だけをDNSに置きます。
DKIM-Signature ヘッダーを1タグずつ読む
実際に届いたメールには、こんなヘッダーが付いています。
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=yourdomain.com; s=selector1; t=1756400000;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj59LmIUuBFR0BOJa2mB0Ho=読むべきタグは4つです。残りは仕組み上の付帯情報なので、後回しでかまいません。
d= と s= で公開鍵の在り処が決まり、h= で守る範囲が決まるh= — DKIMが守るのは、ここに挙げた欄だけ
これがDKIMでいちばん見落とされる点です。h= に書かれていないヘッダーは署名の対象外なので、途中で書き換えても署名は壊れません。「DKIMがpassした＝メール全体が無傷」ではありません。
h= に挙げた欄だけが署名の対象。挙げていない欄は後から足せる実務上は、少なくとも from to subject date は署名対象に入れてください。reply-to と list-unsubscribe も入れておくと安全です。返信先だけをすり替える改ざんは、reply-to が署名対象でないと成立してしまいます。
オーバーサイン — 「後から足させない」ための書き方
RFC 6376は、h= に、実際に存在する回数より多くヘッダー名を並べてよいと定めています。たとえば h=from:from:subject と書くと「Fromは1つしかない。これ以上増やすな」という宣言になり、2つ目のFromを足す改ざんが署名を壊すようになります。これをオーバーサインと呼びます。
c= 正規化 — 転送に耐えるかどうかが、ここで決まる
c= は「照合の前に、どこまで整形をそろえてよいか」の指定です。ヘッダー/本文 の形で書きます。
| 指定 | 意味 | 転送・メーリングリスト |
|---|---|---|
simple | 1バイトも変えてはいけない | ほぼ壊れます。途中の装置が改行や空白を整えるだけでfail |
relaxed | ヘッダー名の大文字小文字、連続する空白、行末の空白などの差は無視する | ある程度耐えます。実務上はこちら |
いま一般的なのは c=relaxed/relaxed です。それでも本文に一言でも追記されれば bh= が合わなくなり、DKIMはfailします。メーリングリストが件名に [ml] を付けたり、フッターを足したりすると壊れるのはこのためです（→転送・ML・ARC対策）。
l= は使わないでください
l= は「本文の先頭から何バイトぶんだけ署名するか」の指定です。これを使うと、署名対象の後ろに文章を継ぎ足しても、DKIMはpassしたままになります。
l=1200 ← 先頭1200バイトだけ署名
［署名された本文］
──────────────── ここから先は署名の対象外
［第三者が後から追記した文面］ ← それでもDKIMは passRFC 6376はこれを §8.2「Misuse of Body Length Limits」として明示的に警告しています。本文は常に全体を署名してください。受け取ったメールのヘッダーに l= があったら、送信元の設定を疑ってよい材料になります。
鍵まわりの実務 — 長さと、DNSの255文字制限
- 鍵長は2048ビットを標準に。1024ビットは現在も検証されますが、新規に作るなら2048です。4096は、後述のDNSの都合で扱いにくくなります
- DNSのTXTレコードは、1つの文字列が255文字までです。2048ビットの公開鍵はこれを超えるため、
"…" "…"のように分割して並べます（連結して1つの値として扱われます）。多くの管理画面は自動で分割しますが、手で貼るときに改行や空白が混ざって壊れるのは典型的な失敗です - 鍵の入れ替えは、セレクタを変えて行います。同じセレクタの中身を差し替えると、DNSが行き渡るまでのあいだ検証に失敗します（→DKIM鍵ローテーション）
p= が空（p= だけ）になっているものは、「この鍵は失効しました」という意味です。消し忘れではなく、意図的に無効化されている場合があります。複数サービスを使うとき
SPFと違い、DKIMはセレクタが違えば何本でも共存できます。Google Workspaceが google._domainkey、配信サービスが selector1._domainkey、というように別々に置けます。1通のメールに複数のDKIM署名が付くこともあり、どれか1つが検証に成功すればDKIMはpassです。
ただしDMARCの観点では、d= がFrom欄のドメインと揃っている署名でなければ意味がありません。配信サービスが自社ドメインで署名している（d=esp.example.net）だけの状態は、DKIMはpassでもDMARCはfailします（→アライメント不一致の直し方）。
確認のしかた
公開鍵はセレクタが分かれば引けます。セレクタは、届いたメールの DKIM-Signature の s= を見るのが確実です。
# 公開鍵を引く（selector1 の場合）
dig +short TXT selector1._domainkey.yourdomain.com
# 実際に届いたメールでの検証結果
# → Authentication-Results ヘッダーの dkim=pass / dkim=fail を見るセレクタが分からないときの調べ方はDKIMセレクタの調べ方に、ヘッダーの読み方はAuthentication-Resultsの見方にまとめています。このサイトの診断では、メールのヘッダーを丸ごと貼り付けると s= と d= を自動で読み取って判定します。