DKIM — DomainKeys Identified Mail

Internet Standard Email Authentication Published March 2026

ELI5: DKIMを手紙の改ざん防止用の封ろうだと考えてください。送信前に、メールサーバーはメッセージに独自の封印（暗号署名）を押します。到着時に、受信者はDNSに公開されている公開鍵に対して封印を確認できます。封印が無傷なら、メッセージは転送中に改ざんされておらず、そのドメインの秘密鍵にアクセスできる誰かから本当に来たものです。

このRFCが存在する理由

SPFはメッセージが認可されたIPアドレスから送信されたことを確認しますが、メッセージのコンテンツについては何も保証しません。メッセージはSPFに合格しても、その後に侵害されたリレーによって変更される可能性があります。また、メールが転送される場合、送信IPが変わるためSPFは機能しなくなります。

DKIMはこの両方の問題を解決します。メッセージ自体に暗号署名を付加することで、転送後も有効なドメインレベルのID主張（署名はメッセージとともに移動）を提供し、コンテンツの整合性を保証します（変更があれば署名は無効になります）。

2011年に公開されたRFC 6376が現在のDKIM仕様です。RFC 4871を廃止し、正規化、鍵管理、署名セマンティクスの改善を導入しました。これはSPFおよびDMARCと並んで、最新のメール認証の基盤となっています。

動作方法

署名（送信者側）

送信メールサーバー（またはアップストリームの署名エージェント）は、どのヘッダーとボディに署名するかを選択します。
simpleまたはrelaxedアルゴリズムを使用して選択されたコンテンツを正規化し、空白とケーシングを正規化します。
正規化されたボディのハッシュを計算してから、選択されたヘッダープラスボディハッシュのハッシュを計算します。
ドメインの秘密鍵（RSAまたはEd25519）を使用してヘッダーハッシュに署名します。
メッセージにDKIM-Signatureヘッダーを追加します。このヘッダーには署名、署名ドメイン（d=）、セレクタ（s=）、署名内容についてのメタデータが含まれます。

検証（受信者側）

受信者はDKIM-Signatureヘッダーからd=（ドメイン）とs=（セレクタ）の値を抽出します。
<selector>._domainkey.<domain>のDNSで公開鍵をクエリします。
署名で指定されたのと同じアルゴリズムを使用して、署名されたヘッダーとボディを再度正規化します。
公開鍵に対して署名を検証します。有効な場合、結果はpassです。

DKIM-Signatureヘッダーの例

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mtg20240101; h=from:to:subject:date:message-id:mime-version:content-type; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=LjIEJLNOTAREALSIGh8gAiGVQOr3K7...truncated...

DNS公開鍵レコード

mtg20240101._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB...truncated..."

主要な技術詳細

正規化

メールは転送中に微妙に変更される可能性があります（末尾の空白が削除、ヘッダーが再折り返される）。正規化はハッシュ化前にコンテンツを正規化するため、問題のない変更によって署名が破損することはありません。ヘッダーとボディに対して別々に指定される2つのアルゴリズムが利用可能です。

アルゴリズム	ヘッダー	ボディ
`simple`	ヘッダー値の末尾の空白を除いて変更なし	末尾の空行を除いて変更なし
`relaxed`	ヘッダー名を小文字化、行を展開、空白を圧縮	空白を圧縮、1行ごとの末尾の空白を削除

最も一般的な設定はc=relaxed/relaxedであり、転送中の最も一般的な変更を許容します。

鍵タイプ

RFC 6376はRSA署名を定義しました。RFC 8463はその後Ed25519サポートを追加しました。RSA鍵は少なくとも2048ビットである必要があります。1024ビット鍵は暗号学的に弱いと見なされ、一部の受信者に拒否されます。Ed25519鍵はより小さく（DNS内で44文字）、検証が高速です。

セレクタ

セレクタ（s=タグ）により、ドメインは複数のDKIM鍵を同時に公開できます。これは鍵ローテーションに不可欠です。新しいセレクタの下に新しい鍵を公開し、それで署名を開始してから、移行期間後に古いセレクタのDNSレコードを削除します。

`l=`タグ（ボディ長制限）

オプションのl=タグは、署名されるボディのバイト数を制限します。これはメーリングリストがフッターを追加する際に署名を破損させないようにするための意図でしたが、実際には署名の脆弱性を生み出します。攻撃者は署名された部分の後に悪意のあるコンテンツを追加できます。セキュリティ意識の高い実装のほとんどはl=を使用しません。

ヘッダー署名

h=タグは、署名に含まれるヘッダーを列挙します。ベストプラクティスは少なくとも以下に署名することです。From、To、Subject、Date、Message-ID、MIME-Version、Content-Type。Fromヘッダーは仕様により必須です。存在しないヘッダーに署名すると、署名後にそれが追加されるのを防ぎます（重要なリプレイ対策）。

一般的なミス

1024ビットRSA鍵の使用：これらは現代の基準では暗号学的に弱いです。Gmailおよび他の主要な受信者は信頼を低下させる可能性があります。常に2048ビットRSAまたはEd25519を使用してください。
鍵ローテーションを実行しない：DKIM秘密鍵は定期的に（6～12ヶ月ごとに）ローテーションすべきです。セレクタはこれをシームレスにします。新しい鍵を公開し、署名を切り替え、古い鍵を廃止します。
ドメインのミスアライメントで署名：DMARCがDKIMで合格するには、署名内のd=ドメインがFrom:ヘッダーのドメインと整合する必要があります（正確一致またはサブドメイン、DMARCポリシーによる）。ESPがd=esp.comで署名する場合、カスタムDKIM署名を設定しない限りDMARC整合は失敗します。
ヘッダーの過度署名対過度署名なし：重要なヘッダー（Subjectなど）に署名しないと、攻撃者がそれらを変更できます。中間機関が正当に追加するヘッダーに過度に署名すると、誤った失敗を引き起こす可能性があります。
DNSレコード伝播遅延：新しいDKIM鍵を公開した後、新しいセレクタで署名する前にDNS伝播を待ってください。存在しない公開鍵を参照する署名は検証に失敗します。
l=ボディ長タグの使用：これはメッセージに未署名のコンテンツを追加できるようにします。避けてください。

配信性への影響

DMARCの基礎：DKIM整合はDMARC合格への2つのパスの1つです（もう1つはSPF整合）。DKIMは転送後も有効ですがSPFはそうでないため、DKIMはより信頼性の高い認証パスです。
レピュテーション結合：DKIMはメッセージを署名ドメイン（d=タグ経由）に結合します。メールボックスプロバイダはこれを使用してドメインレピュテーションを構築します。一貫したDKIM署名は時間とともに肯定的なレピュテーションを構築します。
主要プロバイダに必須：GmailとYahooはすべての送信者に対してSPFまたはDKIMのいずれかの合格を要求します。大量送信者（Gmail宛1日5,000件以上のメッセージ）はSPFとDKIMの両方が合格する必要があり、さらにDMARCポリシーが必要です。
転送後も有効：SPFと異なり、DKIM署名はメッセージとともに移動します。メールがメーリングリスト、.forwardルール、またはエイリアス展開を通じて転送されるとき、DKIM は依然として検証できます（転送システムが署名されたコンテンツを変更しない限り）。これはDKIMをメーリングリスト互換性に不可欠にします。
コンテンツの整合性：認証以上に、DKIMはメッセージが転送中に改ざんされなかったことを証明します。これは中間者による変更から保護し、受信者の信頼を高めます。