RFC 8463: DKIM署名用のEd25519

Standards Track Email Authentication Published March 2026

ELI5: DKIMはもともとRSA鍵を使用していました—ウェブの大部分を保護するのと同じタイプの鍵です。しかしRSA鍵は嵩張ります。2048ビットの公開鍵はDNS TXTレコードで400文字以上を占めます。Ed25519はより新しく、洗練されたロックで、44文字に収まる鍵と同じくらい強力です。より小さな鍵、より高速な検証、同じ信頼—それがRFC 8463がDKIMにもたらすものです。

これが存在する理由

DKIM (RFC 6376)は元々RSAのみを署名用に指定していました。RSAは十分に機能してきましたが、次のようなコストがあります。

大きなキー。 2048ビットのRSA公開鍵はBase64エンコードで約400バイトです。DNS TXTレコードは実用的には1つの文字列につき約255バイトの制限があり(ほとんどのリゾルバーは最大約4096バイト対応)、大きなRSAキーはDNSで扱いにくく、脆弱になることがあります。
検証が遅い。 RSA署名検証は、特に大きなキーの場合、受信者が1時間に数百万のメッセージを処理する際に測定可能なCPU時間を消費します。
鍵サイズの段階的拡大。 RSAのセキュリティはキーの長さに依存します。計算能力の増加に伴い、2048ビットキーは最終的に3072または4096ビットになる必要があり、DNSの問題が悪化します。

Ed25519 (Curve25519を使用するEdwards曲線デジタル署名アルゴリズム)は、この3つの問題をすべて解決します。256ビットキーはおよそ3072ビットRSAと同等のセキュリティを提供し、公開鍵はわずか32バイト(Base64で44文字)で、検証は大幅に高速です。

動作方法

Ed25519での署名

署名プロセスは標準DKIMと同一ですが、2つの変更があります。a=タグはrsa-sha256の代わりにed25519-sha256を使用し、秘密鍵はRSAキーではなくEd25519キーです。

RFC 6376のルールに従ってヘッダーとボディを正規化します。
正規化されたボディのSHA-256ハッシュを計算します(bh=タグ)。
署名されたヘッダーとボディハッシュのSHA-256ハッシュを計算します。
Ed25519秘密鍵を使用してヘッダーハッシュに署名します。
a=ed25519-sha256付きのDKIM-Signatureヘッダーを出力します。

例: Ed25519 DKIM-Signature

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

DNS公開鍵レコード

キーレコードはk=ed25519を使用し、公開鍵はRSAよりも圧倒的に小さいです。

; Ed25519 DKIMキー — p=値がいかにコンパクトか注目 ed202601._domainkey.example.com. IN TXT "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=" ; RSA 2048ビットキーと比較 — はるかに大きい rsa202601._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2UMfREvlgajdSp3jv1oI...truncated (392 characters)..."

デュアル署名: 推奨アプローチ

すべての受信者がEd25519をサポートしているわけではありません。RFC 8463はデュアル署名を推奨しています。各メッセージにRSA署名とEd25519署名の両方を適用します。Ed25519を理解できる受信者はより強力な署名を検証でき、対応していない受信者はRSA署名にフォールバックします。

; 2つのDKIM-Signatureヘッダーを含むメッセージ: DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=example.com; s=ed202601; h=from:to:subject:date:message-id; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=Tg2ByC4LSy9F1F6xAQchD8JFh6kYH7aK... DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=rsa202601; h=from:to:subject:date:message-id; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=LjIEJLNOTAREALh8gAiGVQOr3K7qO6Sn7XIkfJV...

両方の署名は同じbh=(ボディハッシュ)とh=(署名されたヘッダー)を共有していますが、DNSの異なるキータイプを指す異なるセレクターを使用しています。

主な技術詳細

鍵サイズの比較

プロパティ	RSA-2048	Ed25519
セキュリティレベル(ビット)	~112	~128
公開鍵サイズ(Base64)	~392文字	44文字
署名サイズ(Base64)	~344文字	88文字
署名速度	中程度	高速
検証速度	高速	非常に高速
DNS TXTレコードサイズ	タイト、分割が必要な場合がある	単一の文字列に簡単に収まる

鍵生成

# OpenSSL 1.1.1+を使用してEd25519キーペアを生成 openssl genpkey -algorithm Ed25519 -out ed25519_private.pem # 公開鍵を抽出 openssl pkey -in ed25519_private.pem -pubout -out ed25519_public.pem # DNSのための生のBase64公開鍵を取得(PEMヘッダーを削除) openssl pkey -in ed25519_private.pem -pubout -outform DER | tail -c 32 | base64 11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo= # DNSに以下として公開: # ed202601._domainkey.example.com. IN TXT "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="

DNSレコード形式

標準DKIMキーレコードとの唯一の変更はk=ed25519です。その他のタグ(v=、p=、t=など)はRSAキーレコードと同じように機能します。

; 必須タグ v=DKIM1 ; バージョン(常にDKIM1) k=ed25519 ; 鍵タイプ(デフォルトは「rsa」でした) p=<base64> ; 44文字の公開鍵 ; オプションタグ(RSAと同じ) t=s ; 厳密モード: d=はFromドメインと正確に一致する必要があります t=y ; テストモード: 受信者は失敗を確定的に処理すべきではありません

受信者の動作

受信者がDKIM-Signatureでa=ed25519-sha256に遭遇する場合:

セレクターのDNSキーレコードを検索します。
キーレコードでk=ed25519を確認します。
p=タグから32バイトの公開鍵をデコードします。
正規化されたヘッダーのSHA-256ハッシュに対してEd25519署名を検証します。

受信者がEd25519をサポートしていない場合、署名を検証不可として扱い(ハード失敗ではなく)、メッセージ上の他のDKIM-Signatureヘッダーに進みます。

よくある間違い

デュアル署名なしでEd25519のみをデプロイする。 多くの受信者はまだEd25519署名を検証しません。RSAをドロップすると、これらの受信者は有効なDKIM署名を見ず、DMARC整合性と配信可能性に悪影響を与えます。
不正な鍵抽出。 PEM形式のEd25519公開鍵にはASN.1プレフィックスが含まれます。DNSp=値は、フルDERエンコード SubjectPublicKeyInfoではなく、生の32バイトキーである必要があります。これを間違えると、有効に見えるが検証に失敗するキーが生成されます。
古いOpenSSLバージョンを使用する。 Ed25519サポートはOpenSSL 1.1.1(2018年9月)で追加されました。古いバージョンはEd25519キーを生成または検証できません。多くのLinuxディストリビューションは2020年までも古いOpenSSLを出荷しました。
Ed25519が今日RSAに置き換わると仮定する。 Ed25519は将来の方向ですが、RSAはすべてのDKIM検証機がサポートするベースラインのままです。少なくとも次の数年間、デュアル署名を計画してください。
検証テストを行わない。 DNSレコードを公開した後、テストメッセージを送信して両方の署名が検証されることを確認します。opendkim-testkeyのようなツールはDNSレコードを独立して確認できます。
キータイプ間でセレクターを共有する。 RSAキーとEd25519キーに個別のセレクターを使用します。セレクターは1つのキータイプのみをポイントできます。単一のセレクターに負荷をかけようとすると、検証失敗が発生します。

配信可能性への影響

DNSフットプリントの削減。 Ed25519キーは簡単にDNS TXTレコードに収まり、大きなRSAキーを時々悩ます断片化の問題を排除します。DNS関連のDKIM障害が減ると、認証がより一貫性を持ちます。
将来への対応。 RSAキーサイズが増加する必要があるため(2048 → 3072 → 4096)、DNSの問題は悪化します。Ed25519は鍵サイズの段階的拡大なしでより強力なセキュリティを提供します。
大規模での検証が高速。 数十億のメッセージを処理する大容量受信者の場合、Ed25519検証はRSAより大幅に高速です。これにより、認証の計算コストを削減してエコシステムに利益をもたらします。
セキュリティの成熟度を実証。 Ed25519デュアル署名をデプロイすることで、送信者が積極的に認証インフラストラクチャを保守していることを示します。これは直接的なスコア要因ではありませんが、良い送信慣行と相関する運用の成熟度を反映しています。
デュアル署名をセーフティネットとして。 2つの独立した署名により、メッセージがDKIM検証に合格する2つのチャンスがあります。中間メッセージ修正により1つの署名が破損しても、もう1つが生き残る可能性があります。