DNS DKIM TXTレコード生成＆セレクタ設計 完全
メール認証スイート

DNS DKIM TXT Record Builder & Selector Helper

RFC 6376準拠のDNS DKIM TXTレコード（v=DKIM1; k=rsa; p=...）の構築、セレクタ命名規則、255文字制限の分割手法、および認証検証手順を解説します。

100% クライアント側プライバシー
RFC 1035 255-Byte Safe
プリセット:
DNSホスト名:google._domainkey.example.com
RSA 1024-bit (Legacy / Deprecated)
RFC 6376 詳細パラメータ
アルゴリズム: rsaBits: 1024鍵文字数: 332
ステータス: ACTIVE
レコード種別
TXT
ホスト / 名前
google._domainkey
TTL (有効期間)
3600 秒
TXTレコード値 (分割なし完全版):352 文字
v=DKIM1; s=email; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3Q2kZ4+jX6s1aL9mB/8uI7fUvX1Q2W3E4R5T6Y7U8I9O0P1A2S3D4F5G6H7J8K9L0M1N2O3P4Q5R6S7T8U9V0W1X2Y3Z4a5b6c7d8e9f0g1h2i3j4k5l6m7n8o9p0q1r2s3t4u5v6w7x8y9z0A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0U1V2W3X4Y5Z6a7b8c9d0e1f2g3h4i5j6k7l8m9n0o1p2q3r4s5t6u7v8w9x0y1z2A3B4C5D6E7F8G9H0I1J2K3L4M5N6O7P8QIDAQAB
RFC 6376 タグ内訳解説
タグ値
v=DKIM1
k=rsa
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...
s=email
レコード長: 352 バイトChunks: 2TTL: 3600s
RFC 6376 Compliant
セレクタ完全修飾ドメイン (FQDN)
google._domainkey.example.com
メール中継用のクエリ送信先
アルゴリズム
RSA 1024-bit
RSA 1024-bit (Legacy / Deprecated)
RFC 6376 Compliance
正常 & 検証済み
2 strings chunked (<255B)

ゼロナレッジ・完全ローカル実行

すべてのデータ処理、解析、コード生成はお使いのブラウザ内部メモリで完結します。外部サーバーへの送信はゼロです。

超高速・即時リアクティブ演算

最適化されたクライアント側解析パイプラインにより、キーストロークと同時に遅延なくリアルタイムで結果を生成します。

公式仕様準拠・高信頼アーキテクチャ

IETF RFCや公式業界仕様に厳格に準拠し、エッジケースの安全な処理とメモリリークのない堅牢な実行を保証します。

技術リファレンス＆アーキテクチャガイド

DNS DKIM TXTレコード生成＆セレクタ設計 完全 — リファレンスガイド

RFC 6376準拠のDNS DKIM TXTレコード（v=DKIM1; k=rsa; p=...）の構築、セレクタ命名規則、255文字制限の分割手法、および認証検証手順を解説します。

主要パラメータ＆設定項目

セレクタ名 (s)文字列（英数字・ハイフン）

DNSレコードのホスト名 <selector>._domainkey.<domain> を定義する識別子。複数のメール配信サービスや定期的な鍵ローテーションを同一ドメイン内で分離運用するために使用します。

初期値: default
公開鍵 (p)Base64文字列

ASN.1 DER SubjectPublicKeyInfo形式でエンコードされたRSAまたはEd25519公開鍵。PEMヘッダー（-----BEGIN PUBLIC KEY-----）や改行コードを除去して入力します。空値（p=）を指定すると鍵が失効します。

初期値: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
暗号アルゴリズム (k)列挙型 (rsa | ed25519)

署名に使用する公開鍵暗号アルゴリズム。世界中のすべてのMTAと互換性のある 'rsa'、またはRFC 8463で定義された高速・軽量な楕円曲線暗号 'ed25519' を選択します。

初期値: rsa
運用フラグ (t)フラグ (y | s | y:s | 未設定)

運用の動作制御フラグ。'y' はテストモード（検証失敗時も受信側で拒絶処理を控える）、's' はサブドメインでの署名利用を禁止し親ドメインと完全一致を要求します。

初期値: 未設定
サービス種別 (s)列挙型 (* | email)

公開鍵の適用サービスを限定するタグ。'email' はメール送信のみに制限し、'*' はすべてのサービスへの適用を許可します。

初期値: *

プロの活用テクニック＆推奨設定

DNSプロトコル

DNSプロトコル（RFC 1035）の仕様上、1つのTXT文字列は最大255バイトに制限されています。2048ビットRSA公開鍵はBase64化すると約392文字になるため、BINDゾーンファイルでは ("v=DKIM1; k=rsa; p=前半分..." "後半分...") のように二重引用符で文字列を2つに分割して括弧で囲みます。CloudflareやRoute 53などの最新DNSでは自動連結されます。

1024ビットRSAの完全廃止と2048ビットへの移行必須化

Googleや米Yahooの送信者ガイドライン、およびM3AAWG勧告により、DKIM鍵長は2048ビット以上が必須とされています。1024ビットRSAは現代のクラウドリソースで現実的な時間内に因数分解されるリスクがあります。一方、4096ビットはDNS応答パケットが巨大化しUDP 512バイト制限によるフォールバックを招くため推奨されません。

デュアルセレクタを活用したダウンタイムゼロの安全な鍵ローテーション

運用中のDKIMレコードを直接上書きしてはいけません。日付や四半期を付与した新しいセレクタ（例：2026q4）で新しいDNS TXTレコードを事前に公開し、dig等で世界的な伝播を確認した後にMTAの署名設定を切り替えます。旧セレクタは配送遅延メールの検証のため7〜14日間残してから削除します。

秘密鍵漏洩時は空の p= タグによる即時失効レコードを公開

署名用の秘密鍵が漏洩・紛失した際、単にDNSレコードを削除するとキャッシュの有効期限（TTL）中やDNS未登録扱いとなり判定が曖昧になります。該当セレクタに 'v=DKIM1; p='（pタグを空）を登録することで、受信側MTAに鍵が正式に失効したことを明示的に伝達できます。

よくあるトラブルと解決策

受信側メールサーバーで dkim=fail (bad signature) または鍵が見つからないと報告される

DNSのホスト名が <selector>._domainkey.<domain> の形式になっているか（_domainkey が抜けていないか）確認してください。また、公開鍵の p= の値に '-----BEGIN PUBLIC KEY-----' や改行コード（\r, \n）、不要なスペースが含まれていないか再確認してください。

DNS管理画面で「255文字を超えています」または構文エラー（Syntax Error）が表示される

お使いのDNSレジストラが255バイト超の自動分割に対応していない場合、BIND形式に従って文字列を2つの二重引用符で分割して入力するか、自動チャンク分割に対応したDNSプロバイダ（Cloudflare等）をご利用ください。

単体でのDKIM署名検証はパスするが、DMARC集計でアライメント不一致（unaligned）となる

DMARCアライメントでは、メールヘッダーの「From:（送信元アドレス）」のドメインとDKIM署名の「d=」タグのドメインが一致（または組織ドメイン一致）している必要があります。外部配信サービス（SendGrid等）を使用している場合、共有ドメインではなく独自ドメインでのカスタムDKIM設定（CNAME委託）を行ってください。

よくある質問 (FAQ)

DKIM、SPF、DMARCの決定的な役割の違いは何ですか？▼

SPFはエンベロープFrom（Return-Path）ドメインに基づき、メールを送信したサーバーのIPアドレスが正当であるかを検証します。DKIMは暗号署名によりメール本文や重要ヘッダーの改ざん防止と送信元ドメインの真正性を証明します。DMARCはこの2つの結果を統合し、表示Fromとのドメイン一致（アライメント）を確認した上で、ポリシー（none、quarantine、reject）を受信側に指示します。

なぜDKIMにはセレクタ（Selector）が必要なのですか？▼

セレクタは '_domainkey' サブドメイン配下で複数の独立した鍵ペアを名前空間として共存させるための識別子です。これにより、社内メールシステム（Google Workspace）とマーケティング配信システム（HubSpot等）で個別の秘密鍵を持たせることができ、鍵の定期ローテーション時にも他システムに一切影響を与えずに安全に更新できます。

2048ビットのRSA公開鍵をDNS TXTレコードの文字数制限内で登録するにはどうすればよいですか？▼

RFC 1035の仕様により、DNS TXTレコードの単一文字列は255文字（バイト）までに制限されます。約392文字の2048ビット公開鍵を登録する際は、BINDゾーン構文で ("v=DKIM1; k=rsa; p=前半分文字列..." "後半分文字列...") のように隣接する2つの引用符付き文字列に分割します。DNSリゾルバはこれらを空白を挟まずに結合して取得します。

RSAの代わりにEd25519（RFC 8463）をDKIM鍵として利用できますか？▼

利用可能です。RFC 8463によりEd25519楕円曲線署名が規格化されており、Base64形式でわずか44文字に収まるため255バイト制限の分割が不要です。ただし、一部の古いエンタープライズ系MTAがEd25519に対応していない場合があるため、現時点では2048ビットRSAを主軸とするか、RSAとEd25519の二重署名が推奨されます。

設定したDKIMレコードが正常にDNSに伝播し機能しているか検証する方法は？▼

ターミナルから 'dig TXT <selector>._domainkey.<ドメイン> +short' または 'nslookup -type=TXT <selector>._domainkey.<ドメイン>' を実行してレコード内容を確認します。また、Gmailなどの外部メールアドレスにテスト送信し、メールの「原本を表示」から 'Authentication-Results: dkim=pass' と表示されているか確認するのが最も確実です。

関連するおすすめ開発ツール

すべてのツール →
MTA-STS ポリシー＆TLS-RPT DNSレコードジェネレーターセキュリティ

RFC 8461準拠のMTA-STSポリシーファイル、_mta-sts DNS TXTレコード、およびRFC 8460 TLS-RPTレポートレコードの生成仕様と運用ベストプラクティス。

ツールを開く→
JWTトークンデコーダー＆セキュリティインスペクターセキュリティ

ブラウザ上でJSON Web Tokenをデコードし、RFC 7519およびOIDCクレームの確認、有効期限の精密検査、HMAC署名のローカル検証を行う開発者向けユーティリティ。

ツールを開く→
高強度パスワード・パスフレーズ自動生成ツールセキュリティ

暗号論的擬似乱数生成器（Web Crypto CSPRNG）を用いた高エントロピーパスワード、覚えられるDicewareパスフレーズ、PIN、APIトークンをブラウザ内で瞬時に安全生成。NIST SP 800-63B準拠。

ツールを開く→
暗号学的ハッシュ値・チェックサム一括計算ツールセキュリティ

SHA-256、SHA-512、MD5、SHA-1、SHA-3、Keccak、CRC32をブラウザ内で瞬時に一括算出。Web Crypto APIによる100%クライアントサイド完結。

ツールを開く→
JSON Web Token (JWT) デバッガー＆署名検証ツールセキュリティ

HMAC (HS256/384/512) および RSA (RS256/384/512) 署名のデコード・構造検査・検証をブラウザ内メモリで100%完結。外部サーバー送信一切なし。

ツールを開く→
パスワード強度チェッカーセキュリティ

zxcvbnアルゴリズムを用いたパスワードエントロピー計算、クラック所要時間推定、および安全基準検証ガイド。

ツールを開く→