DKIMレコードを分割する方法

メール認証の設定は、いざやってみると壁にぶつかるまで「5分もあれば終わるはず」と思いがちな作業の一つです。2048ビットの安全なDKIMキーを生成し、DNSプロバイダーのサイトに移動して、新しいTXTレコードの欄に貼り付け、保存ボタンを押すだけです。

成功メッセージが表示される代わりに、画面にエラーが点滅します。AWS Route 53は意味不明な「CharacterStringTooLong」というアラートを表示します。Google Cloud DNSは、単に「無効なレコードデータ」であると告げます。

DKIMレコードを追加する際に255文字の制限に直面しても、ご安心ください。鍵に問題があるわけではなく、セキュリティレベルを下げる必要もありません。DKIM TXTレコードを適切な方法で複数の文字列に分割するだけで済みます。DKIMレコードの分割は、標準的で安全な管理手順であり、一度公開されれば、DNSリゾルバーが自動的にそれらの断片をシームレスに結合します。

では、なぜこのような現象が起こるのか、そして手動の方法や自動DNSレコード分割ツールを使って、どのように段階的に解決していくのかを詳しく見ていきましょう。

DKIMレコードを分割する必要がある理由

DKIMレコードを分割する必要があるのは、インターネットの基本的な規則に起因しています。RFC 1035のセクション3.3.14によると、DNS TXTレコード内の単一の文字列は、最大255文字（またはオクテット）に制限されています。この制限が存在するのは、標準的なDNSパケット内の文字列の長さが1バイトで格納されるためであり、つまり255文字を超えることはできないからです。

この構造上の制限は、暗号鍵の長さによって非常に重要な意味を持つようになります：

• 1024ビットのDKIM鍵：これらの公開鍵文字列は短いため、通常は変更を加えることなく255文字の制限内に収まります。
• 2048ビットのDKIM鍵：これらの鍵はセキュリティを大幅に強化しますが、生成されるBase64形式の公開鍵文字列は、ほぼ例外なく350文字から500文字以上になります。

2048ビットのDKIM鍵は、その性質上255文字の制限を超えるため、単一の連続した文字列として格納することはできません。

この境界がどのように扱われるかは、完全にDNSホスティングプロバイダー次第です。2026年現在、主要なプラットフォームは依然として2つのグループに分かれています：

• 厳格なプロバイダー：AWS Route 53、Google Cloud DNS、Azure DNS などのサービスは、ユーザーインターフェースレベルで RFC 1035 を厳格に適用しています。300 文字を超える文字列を貼り付けると、即座に拒否されます。
• 自動化されたプロバイダー：Cloudflare、GoDaddy、cPanel などのプラットフォームでは、多くの場合、このフォーマット処理がバックグラウンドで自動的に行われ、レコードが内部で分割されるため、手動で処理する必要はありません。

重要な注意点：レコードを分割しても、DKIM署名に変更や破損が生じることはありません。受信メールサーバーがドメインのDKIM公開鍵を検索する際、そのDNSリゾルバーは、暗号化ハンドシェイクを処理する前に、分割された文字列を自動的に連結（結合）して、1つの連続した文字列に戻します。

DKIMレコードを分割する方法（手順解説）

暗号化データを無効にすることなくレコードを正しく分割するには、所定の書式規則に従う必要があります。

以下は、分割されていない生の2048ビットDKIMレコードの実際の例です。これは単一の連続した文字列であり、厳格なプロバイダーによって拒否されます。その後に、正しく分割された同じ鍵を示します：

以前 – 1つの連続した文字列（410文字、却下）：

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTyGJMuHbEL31IeL2HPcHyGcFRl1SPnXNYvMIHa/2o76umfXfKm/r5kJP1VrT+1FJors/6ILi8IHn5kxsC7tVO/HbkQfyy/KV5zjR3j1twdTKWTddB+XhkAS1voQG6yyzyN9zHYIa4UOrGNATMuDJawTgsu8PO+799nKSNrh9UCauSDmLhuVtcqcYezdZ/tDDj8hYs5suKcNd8Zra9A9sKPxZ9W3qLy7zKUVQDT7S8sTQCBNR3YbDgbleph1QHt61QTC4XATWS8PHp9NHfYjFM5DI4pZj59fhZ5R1Py4oJe2JbmPTuSgR7cMy+UcU3zr1ZtoLuCr64CxqlIOdNKhiwIDAQAB

その後――1つのTXTレコード、255文字の境界で分割された2つの引用文字列：

“v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTyGJMuHbEL31IeL2HPcHyGcFRl1SPnXNYvMIHa/2o76umfXfKm/r5kJP1VrT+1FJors/6ILi8IHn5kxsC7tVO/HbkQfyy/KV5zjR3j1twdTKWTddB+XhkAS1voQG6yyzyN9zHYIa4UOrGNATMuDJawTgsu8PO+799nKSNrh9UCauSDmLhuVtcqcYezdZ/tDD”
“j8hYs5suKcNd8Zra9A9sKPxZ9W3qLy7zKUVQDT7S8sTQCBNR3YbDgbleph1QHt61QTC4XATWS8PHp9NHfYjFM5DI4pZj59fhZ5R1Py4oJe2JbmPTuSgR7cMy+UcU3zr1ZtoLuCr64CxqlIOdNKhiwIDAQAB」

2048ビットのDKIM鍵の分割

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…wIDAQAB

1つの連続した文字列（410文字）が、AWS Route 53 / Google Cloud DNS によって拒否される

↓ 255文字の区切りで分割

1つのTXTレコード — 2つの引用符で囲まれた文字列

“v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…”

チャンク 1 · 255 文字

「…zrIZtoLuCr64CxqlIOdNKhiwIDAQAB」

チャンク 2 · 残り (≈155)

各チャンクの間には正確に1つのスペースを入れ、各チャンク内部にはスペースを入れない。

ステップ1：DKIMレコード全体を確認する

メールサービスプロバイダーのダッシュボード（Google Workspace、Microsoft 365、SendGrid、Mailchimpなど）にログインすると、生成された公開鍵を確認できます。このレコードは常に特定のタグで始まり、通常は以下の形式に厳密に従っています：

v=DKIM1; k=rsa; p=[非常に長いBase64文字列]

あるいは、当社の無料DKIMレコードチェッカーを使って、数秒でレコードを確認することもできます：

分割が本当に必要かどうかを確認するには、値全体をコピーしてシンプルなテキストエディタに貼り付け、文字数をチェックしてください。文字数が255文字を超える場合は、分割する必要があります。

ステップ2：キーの値を255文字単位に分割する

レコードを分割するには、手計算で行う方法と、自動ツールを使用する方法の2つの選択肢があります。

手動による方法

テキストエディタを開き、レコードの先頭から（v=DKIM1; k=rsa; p= というプレフィックスを含めて）正確に255文字を数え出してください。その255文字目の境界で文字列を切り取ってください。

個々のチャンクは、それぞれ二重引用符（“”）で囲む必要があります。重要な点として、チャンク内部にスペースが入らないようにしなければなりませんが、最初のチャンクの閉じ引用符と2番目のチャンクの開き引用符の間には、必ず1つのスペースを空ける必要があります。

自動方式（推奨）

人為的なミスを防ぐため、手動での文字数カウントは行わず、PowerDMARCの無料ツール「DNSレコードスプリッター」をご利用ください。

• ツールページへ移動してください。

• 分割されていない完全なDKIM TXTレコードを入力欄に貼り付けてください。

• 「引用符付き形式」を選択してください（AWSやGoogleなどの厳格なプロバイダーでは必須です）。

• 「レコードの分割」をクリックすると、正しい形式の文字列が即座に生成されます。

• 結果は以下のようになります：

ステップ3：DNSに分割レコードを追加する

管理者によくある間違いとして、DNS管理画面で各チャンクごとに2つのTXTレコードを作成しようとするケースがあります。これは絶対に避けてください。そうすると、認証が完全に機能しなくなります。

TXTレコードを1つ追加する必要があります。DNS管理画面で、引用符で囲まれた2つの文字列を「値」または「データ」フィールドに貼り付けてください。一般的なプロバイダーのほとんどでは、2つの文字列をスペース1つで区切ってください：

“v=DKIM1; k=rsa; p=CHUNK1” “CHUNK2”

（注：AWS Route 53をご利用の場合は、1行にスペースを空ける形式は使用せず、以下のプロバイダーセクションに記載されているプラットフォーム固有の改行方法に従ってください。）

ステップ4：DKIMレコードの確認

変更を保存したら、DNS情報がインターネット全体に反映されるまでしばらくお待ちください。通常は5分から30分程度で更新されますが、ゾーンのTTL（有効期間）設定によっては、最大48時間かかる場合もあります。

すべてが正常に機能していることを確認するには、PowerDMARCの無料DKIMルックアップツールを使用して、レコードが公開されており、正常に解決されているかを確認してください。

プロのヒント：DNSの反映を待つ前に作業内容を確認したい場合は、最終的に作成した文字列をコピーし、DKIMレコード分割ツールに貼り付けて、どのセグメントも255文字の制限を超えていないことを確認してください。

テストに合格すると、ステータスが「green」の完全な統合暗号鍵が返されます。失敗した場合は、データの欠落（切り捨て）、セカンダリチャンクの欠落、または閉じられていない引用符による構文エラーなどの問題がないか確認してください。

DNSプロバイダーごとのDKIMレコードの分割

DNSコントロールパネルによって、複数文字列のTXTレコードの入力処理方法は異なります。以下に、最も一般的な4つのプラットフォームにおける設定方法を説明します：

AWS Route 53

Amazon Route 53 は境界を厳格に適用しており、個々の文字列に引用符が欠けていたり、255 文字を超えたりすると、CharacterStringTooLong エラーが発生します。DNS リゾルバーは連続する文字列を、間にスペースを一切入れずに連結するため、1 行内の引用符の間にスペースを挿入すると、意図せず暗号鍵が破損してしまう可能性があります。

• コンソールでの操作方法：Route 53 コンソールの「値」ボックスに、各チャンクを引用符で囲んだ文字列として、それぞれ別々の行に入力してください。行末にスペースを入れないでください。Route 53 では、単一のテキストフィールドボックス内の連続する行を、単一の TXT レコード内の個別の文字列として扱います。そして、検索時にそれらを結合します。
• API/JSON メソッド：コードまたは AWS API を使用してインフラストラクチャをデプロイする場合は、レコードの入力を JSON 配列として構成し、各分割チャンクを独立した配列要素として指定してください：[“v=DKIM1…”, “…CHUNK2”]。

Google Cloud DNS

フォーマットされていない長い文字列を送信しようとすると、Google Cloud DNS では「無効なレコードデータ」という一般的な警告が表示されます。Google Cloud Console の UI 内でこの問題を解決するには、文字列を 1 行にまとめて貼り付けないでください。代わりに、各ブロックを二重引用符で囲み、「アイテムを追加」ボタンを使用して、同じリソースレコードセット内に複数の連続したデータフィールドを生成してください。

クラウドフレア

Cloudflareには、保存時に長いTXT文字列を自動的に解析し、ユーザーの操作を必要とせずにRFC準拠のセグメントに分割するインテリジェントなバックエンド機能が備わっています。ただし、自動解析に依存すると、キーが複雑な場合にまれに例外的なケースが発生することがあります。そのため、分割済みで引用符で囲まれた文字列をCloudflareダッシュボードに直接手動で貼り付けることが、依然として最適な導入方法となります。

cPanel / WHM

古いバージョンのcPanelゾーンエディタでは、標準のテキスト入力フィールドの文字数制限が255文字に固定されています。メインのインターフェースでこの文字数制限を超えるデータが入力できない場合は、「詳細DNSゾーンエディタ」をご利用ください。この拡張モードでは、分割前の複数ブロックからなるTXTデータフィールドをスムーズに入力するために必要な柔軟性が確保されています。

DKIMレコードを分割する際のよくある間違い

スプリットレコードを展開したにもかかわらず、認証チェッカーがドメインを問題視している場合は、以下の3つのよくある設定ミスを確認してください：

1. 分割後にDKIM署名が失敗する

• 原因：Base64暗号化チャンクの1つにおいて、閉じ引用符と開き引用符の間に厳密に配置されるべきスペースが、誤ってチャンク内部に挿入されてしまいました。
• 解決策：元のキーを空のファイルにコピーし、p=値の文字列内の余分な空白をすべて削除してから、再度分割処理を実行してください。

2. DNSにはキーの一部しか表示されない

• 原因：2つ目のデータブロックは、最初のレコード内に統合されるのではなく、ドメインホスト上で完全に独立した2つ目のTXTレコードとして保存されていました。
• 解決策：セカンダリレコードを完全に削除してください。プライマリのDKIM TXTレコードを編集し、2つの引用符で囲まれた文字列が1つの値フィールド内にまとめて配置されるようにしてください。

3. 分割後の文字数が255文字を超えている

• 原因：分割ポイントが誤って計算されたため、2つのチャンクのうち1つが255文字の制限をわずかに超えてしまいました（多くの場合、「v=DKIM1;」というプレフィックスが誤ってカウントされたことが原因です）。
• 解決策：レコードを正確に255文字目で分割し直すか、自動DNSレコード分割ツールにカウントを任せてください。

DKIMの分割がDMARCに与える影響

IT管理者にとって、公開鍵を分割するとDMARC処理における受信メッセージの処理方法が変わるかどうかが、よくある懸念事項です。

DKIMレコードが正確に分割されている場合、その動作は分割されていないレコードと全く同じになります。受信メールサーバーは照会時にチャンクを1つの文字列に再構築するため、DKIM署名はシームレスに検証され、DMARCのアラインメントには影響が及びません。

しかし、分割レコードの形式が不正であったり、フォーマットが間違っていたりすると、即座に深刻な結果を招くことになります：

• 受信側のメールサーバーでは、あなたの公開鍵を復元することはできません。
• DKIM認証に失敗します。
• DMARCは、SPF（Sender Policy Framework）との整合性に完全に依存せざるを得なくなります。
• SPFの一致も確認できない場合（またはDMARCポリシーで両プロトコルの一致が必須とされている場合）、正当な社内のメールがスパムフォルダに振り分けられたり、完全に拒否されたりする可能性があります。

DMARCポリシーの適用に全面的に依存する前に、DNS設定を変更した後は、必ず公開用DKIMキーの有効性を確認する必要があります。

まとめ

DKIMレコードの分割は、AWS Route 53やGoogle Cloud DNSのような厳格なDNSプロバイダーで、2048ビットのセキュアな鍵を管理する際に必要な管理手順です。基本的なフォーマット規則さえ理解していれば、安全かつ標準的な手順であり、簡単に実行できます。

記録を更新する際は、常に以下の基本ルールを忘れないでください：

• 文字列を255文字の境界で分割してください。
• 各ブロックを二重引用符で囲んでください。
• すべての情報を1つのTXTレコード内に記述してください（一般的なプロバイダーの場合はスペースで区切り、AWS Route 53のような厳格なインターフェースの場合は改行して記述します）。

文字数を推測してメール配信の停止リスクを冒さないでください。手計算は不要です。登録不要の無料ツール「PowerDMARC DNSレコード分割ツール」を使えば、キーを即座にフォーマットできます。

よくあるご質問

DNSレコードスプリッターとは何ですか？

DNSレコードスプリッターとは、長いDNS TXTレコードを255文字単位の個別のセグメントに分割するために設計されたユーティリティです。このフォーマット処理は、内部で文字列の分割を自動的に行わない厳格なDNSホスティングプロバイダーにおいて、レコードを正確に保存するために必要です。レコードの絶対的な内容は一切変更されず、単に構造化された短いブロックとしてフォーマットされるだけであり、受信システムはルックアップ時にそれらを再び結合します。

どのDNSプロバイダーが手動でのレコード分割を必要としますか？

いくつかの大手エンタープライズ向けプロバイダーは、インターフェースレベルで255文字の制限を厳格に適用しているため、長いテキスト値を保存する前に、あらかじめフォーマットを整えておく必要があります：

• AWS Route 53：長い文字列を引用符で囲んだ複数のブロックに分割しない限り、「CharacterStringTooLong」というエラーメッセージが表示されます。
• Google Cloud DNS：長い連続した文字列を完全に拒否し、「無効なレコードデータ」という警告を返します。
• Azure DNS：Azure Portal ダッシュボードまたは Azure CLI を通じて文字列を直接プロビジョニングする場合、テキストフィールドを手動で分割する必要があります。
• DigitalOcean：標準のWebコントロールパネルでは、長いTXTエントリのストリームを自動的に分割しません。

なぜDKIMレコードを分割する必要があるのですか？

TXTレコードを分割する主な要因は、セキュリティの高い2048ビットのDKIM公開鍵を導入することです。 1024ビットの鍵は1つの文字列に収まるほど短いですが、2048ビットの鍵は本質的に350～500文字以上の暗号化されたBase64データを含んでいます。RFC 1035のセクション3.3.14では、1つの連続した文字列を正確に255オクテットに制限しているため、これらの長い鍵は、標準的なDNSストレージアーキテクチャに収まるよう、個別のセグメントに分割する必要があります。

レコードを分割すると、データが変更されたり、メールの検証に失敗したりすることはありますか？

いいえ。長いTXTレコードを分割しても、その暗号学的価値が損なわれたり変更されたりすることはありません。受信側のメールサーバーがドメインの認証設定を要求すると、そのDNSリゾルバーが自動的に分割されたセグメントを読み取り、区切り文字のない1つの連続した値として結合（マージ）します。この分割形式はあくまでバックエンドの保存形式上の詳細に過ぎず、評価されるペイロード自体は全く同じままです。

「Quoted」出力形式と「Plain」出力形式の違いは何ですか？

• 引用符形式（推奨）：255文字ごとの各セグメントを、それぞれ一対の二重引用符（“chunk1” “chunk2”）で囲みます。これらは、1行内でスペースで区切るか、連続するデータフィールドまたは行に入力します。AWS Route 53 や Google Cloud DNS などの厳格なインターフェースでは、キーの破損を防ぐために、この正確なレイアウトが必須となります。
• プレーン形式：長い行を個別のブロックに分割しますが、二重引用符で囲んだり、余分な空白や句読点を追加したりはしません。このレイアウトは、生の複数行文字列ストリームを受け入れる最新のコントロールパネルや、セルフホスト型のBIND（Berkeley Internet Name Domain）システム環境向けに設計されています。

機密性の高い鍵や個人情報を扱う場合、このツールを使用しても安全ですか？

はい。PowerDMARCのDNSレコードスプリッターは、クライアントサイドのスクリプトを使用して、お客様のローカルWebブラウザ内のみで実行されます。 入力されたテキスト文字列がデバイス外に出ることはなく、インターネット経由で外部の処理サーバーにデータが送信されることもありません。また、追跡ログや強制的な登録も一切必要ありません。さらに、このツールは、公開DKIMキー、SPFインクルード、DMARCポリシー、ドメイン検証レコードなど、すでにウェブ上で公開されている設定専用に設計されている点にご注意ください。秘密鍵をオンラインツールに貼り付けることは絶対に避けてください。