DKIM（DomainKeys Identified Mail）

概要

DKIM（DomainKeys Identified Mail） は、送信メールに電子署名を付与し、受信サーバーが DNS 上の公開鍵を使ってその署名を検証する仕組みです。仕様は RFC 6376（2011年）で定義され、その後 RFC 8301、RFC 8463、RFC 8553、RFC 8616 で更新されています。メールが送信後に改ざんされていないこと、そして署名ドメインが責任を持って送信したことを証明します。

SPF が「どのサーバーから送ったか」を検証するのに対し、DKIM は「メールの内容が途中で変わっていないか」を検証します。SPF と決定的に異なる点は、DKIM 署名がメール転送後も維持されることです。メールが別のサーバーを経由して転送されると SPF は fail しますが、DKIM 署名は本文とヘッダーの完全性が保たれている限り pass し続けます。

DKIM の署名はメールヘッダーの DKIM-Signature フィールドに埋め込まれます。受信サーバーはこのヘッダーを読み取り、指定されたセレクタとドメインから DNS で公開鍵を取得して署名を検証します。

仕組み

DKIM の検証フローは次の通りです。

1. 送信サーバーが署名対象のヘッダーと本文を指定したアルゴリズム（通常 rsa-sha256）でハッシュ化する
2. そのハッシュを秘密鍵で署名し、DKIM-Signature ヘッダーをメールに付与する
3. 受信サーバーが DKIM-Signature ヘッダーから s=（セレクタ）と d=（ドメイン）を読み取る
4. セレクタ._domainkey.ドメイン の形式で DNS TXT レコードを参照し、公開鍵（p= タグ）を取得する
5. 公開鍵で署名を検証し、一致すれば dkim=pass

セレクタの役割

セレクタは複数の鍵を使い分けるための識別子です。同一ドメインで Google Workspace と SendGrid を使う場合、それぞれ異なるセレクタを持つ DKIM レコードを発行できます。鍵をローテーションするときも、旧セレクタを維持したまま新セレクタを追加することで無停止で移行できます。

Google Workspace のデフォルトセレクタは google、SendGrid は s1 や s2 が一般的ですが、任意の名前に変更できます。s20260401 のように日付ベースのセレクタ名にすると、いつ発行した鍵かを追跡しやすくなります。

正規化（カノニカライゼーション）

DKIM-Signature の c= タグは、署名前にメールをどう正規化するかを指定します。c=relaxed/relaxed（ヘッダー/本文）が推奨設定です。

relaxed は、ヘッダー名の大文字小文字の正規化、複数の空白を 1 つに集約、末尾の空白除去を許容します。メールが経由する中継サーバーがヘッダーを軽微に変更しても署名が壊れません。simple は厳密な一致を要求するため、転送や一部のメールゲートウェイで署名が失効します。

署名アルゴリズム

RFC 6376 が定義する基本アルゴリズムは rsa-sha256 です。RFC 8463（2018年）では ed25519-sha256 のサポートが追加されました。Ed25519 は RSA より短い鍵長で同等以上の安全性を持ちますが、受信側のサポートが完全ではないため、現時点では rsa-sha256（2048 ビット）と Ed25519 のデュアル署名が推奨されます。1024 ビット RSA はすでに推奨されず、多くの受信サーバーで警告対象になっています。

設定例

Google Workspace、SendGrid での DKIM レコード例と、鍵ローテーション時の新旧セレクタ共存パターンを示します。

Google Workspace

Google Workspace の DKIM レコード例です。公開鍵の値は Google Workspace 管理画面の「Gmail」→「メールの認証」から取得します。

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

SendGrid

SendGrid の DKIM レコードは 2 つのレコードをセットで設定します。

s1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
s2._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

鍵ローテーション

鍵ローテーション時は新旧を共存させます。旧セレクタのレコードは、古いメールへの再検証が走る可能性があるため、新セレクタに切り替えてから少なくとも数日（可能なら 1 週間）は残しておきます。

# 新セレクタ（運用中）
s20260401._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=新しい公開鍵"

# 旧セレクタ（廃止予定、ドレインのため残す）
s20231001._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=古い公開鍵"

確認方法

特定のセレクタが正しく設定されているかは dig で直接確認できます。

dig TXT google._domainkey.example.com

;; ANSWER SECTION:
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

v=DKIM1 で始まる行が返れば、レコードが存在しています。p= タグの値が管理画面の公開鍵と一致するかを確認します。

外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/mail-auth?domain=example.com"

{
  "success": true,
  "data": {
    "spf": { "record": "v=spf1 include:_spf.google.com ~all", "exists": true },
    "dkim": {
      "mode": "auto",
      "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...",
      "exists": true,
      "selector": "google",
      "matches": [
        { "selector": "google", "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...", "exists": true }
      ],
      "checkedSelectors": ["google", "selector1", "selector2", "s1", "s2", "k1", "k2", "k3", "default", "dkim", "mail", "smtp"],
      "exhaustive": false
    },
    "dmarc": { "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com", "exists": true },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

data.dkim.exists が true であれば外部から DKIM レコードが確認できる状態です。selector パラメーターを省略すると、API は一般的なセレクター候補を自動検出します。false の場合は、送信サービスのドキュメントでセレクター名を確認し、selector パラメーターに指定して再検索してください。

よくある問題

DKIM の設定では公開鍵のコピーミス、セレクタ名の不一致、メーリングリストによる署名破壊が代表的なトラブルです。

公開鍵の値を誤ってコピーする

管理画面から取得した公開鍵は長い文字列で、コピー時に途中が欠けることがあります。DNS に設定後、dig で取得した値と管理画面の値を文字数レベルで照合します。鍵が不正な場合、レコードは存在しても dkim=fail になります。

セレクタ名を間違える

受信サーバーは DKIM-Signature ヘッダーの s= タグを見て DNS を引きます。管理画面で設定したセレクタと、DNS に発行したレコードのサブドメイン名が一致していないと永遠に fail します。google._domainkey なのか mail._domainkey なのかを送信サービスのドキュメントで確認します。

本文の改ざんで署名が失効する

一部のメーリングリストソフトウェア（例: Mailman）はフッターを本文に追加します。c=relaxed/relaxed でも本文の追記には対応できないため、本文へのフッター追加は DKIM 署名を壊します。この問題は SPF でも同様に起き、DMARC が通らなくなります。

鍵をローテーションしない

M3AAWG は 90〜180 日ごとの鍵ローテーションを推奨しています。Google も四半期ごとのローテーションを推奨しています。同じ鍵を長期間使い続けると、鍵が漏洩した場合に過去のメールも遡って署名偽造される可能性があります。

他の認証方式との関係

DKIM は SPF の弱点を補います。SPF はエンベロープ From のみを検証し、転送で壊れます。DKIM は送信者ドメインをヘッダーに署名するため、転送後も検証可能です。ただし DKIM もヘッダー From との一致（アライメント）は自力では検証しません。

DMARC がこのアライメント検証を行います。DMARC は SPF の pass または DKIM の pass を確認したうえで、ヘッダー From ドメインとの一致を検証します。SPF が転送で fail しても、DKIM が pass していれば DMARC は通過できます。

BIMI は DMARC が p=quarantine 以上で機能する仕組みです。BIMI を有効にするには DKIM の正しい設定が前提条件になります。