DNSレコード分割ツール

Google Cloud DNS、AWS Route 53、Azure DNS、およびレコードを自動的に分割しないプロバイダー向けに、長いDNS TXTレコード（DKIM、SPFなど）を255文字単位に分割します。無料、即時対応、登録不要です。

DNSのTXTレコードを貼り付けてください 0文字

出力形式

引用

プレーン

Google Cloud DNS および AWS Route 53 では、引用符で囲んだ形式が必須です。複数行の生の入力を受け付けるプロバイダーでは、プレーン形式でも使用できます。

すべてブラウザ上で動作し、データは端末外に一切保存されず、ログも記録されず、登録も不要です

DNSレコードスプリッターの使用方法

長いDNS TXTレコードを入力欄に貼り付けてください。これは通常、DKIM公開鍵ですが、長いSPF、DMARC、またはドメイン認証レコードの場合もあります。

出力形式を選択してください。Google Cloud DNS、AWS Route 53、Azure DNS を使用する場合は「Quoted」を選択してください。プロバイダーが生の複数行入力を受け付ける場合は「Plain」を選択してください

「レコードの分割」をクリックします。このツールは文字数をチェックし、255文字を超える部分を分割して、フォーマットされた出力結果と、セグメントごとの内訳を表示します。

「コピー」をクリックし、フォーマットされた値をDNSプロバイダーのTXTレコード欄に貼り付けてください。保存した後、DNSの反映を待ちます（通常5～60分程度かかります）。

DNSのTXTレコードを分割する必要がある理由

DNSのTXTレコードは、RFC 1035で定められた制限により、1つの文字列につき255文字までとなっています。255文字を超える値は、複数の短い文字列に分割する必要があります。DNSリゾルバーは、クエリが送信されると、これらの文字列を自動的に結合して復元します。一部のプロバイダーでは、この処理が自動的に行われます。一方、Google Cloud DNSやAWS Route 53などのプロバイダーでは、手動で分割するまで、レコードをエラーとして拒否します。

DKIMキーの分割

このツールが必要となる最も一般的な要因は、DKIM公開鍵です。2048ビットのDKIM鍵は通常400～450文字の長さがあり、255文字という制限を大幅に超えているため、分割せずに単一のDNS文字列として公開することは不可能です。

2048ビットのDKIM鍵を生成すると、メールサービスや鍵生成ツールは、公開鍵全体を1つの連続した文字列として出力します。この文字列をDNSに登録するには、255文字以下の2つのセグメントに分割する必要があります。手動での分割を必要とするプロバイダーの多くは、各セグメントを二重引用符で囲み、1行に記述することを求めています。例えば、次のような形式です： "segment1" "segment2".

形式が間違っていたり、余分なスペースが入っていたり、鍵を間違った位置で切り取ったりすると、DKIM認証は失敗します。公開鍵は暗号データであるため、1文字でも欠落したり位置がずれたりすると、鍵全体が無効になってしまうからです。

上記のツールにDKIMキー全体を貼り付け、「Quotedformat」を選択し、出力された内容をDNSプロバイダーのTXTレコード欄に直接コピーしてください。当社のDKIMレコードジェネレーターでキーを生成し、ここで分割した後、DKIMチェッカーを使用して公開されたレコードが正しいか確認してください。

DNSプロバイダーと、長いTXTレコードの取り扱い方法

すべてのDNSプロバイダーの動作が同じというわけではありません。ここでは、主要なプロバイダーについて、手動でレコードを分割する必要があるかどうかをまとめた一覧をご紹介します。

プロバイダー	行動	推奨形式
Google Cloud DNS	長い未分割のTXTレコードを拒否し、 `invalid record data` エラー。分割は必須です	引用形式。各セグメントは二重引用符で囲む
AWS Route 53	各255文字の文字列は、それぞれ二重引用符で囲む必要があります	引用形式。すべてのセグメントを1行にまとめ、スペースで区切る
Azure DNS	ポータルまたはCLI経由でレコードを追加する際は、文字列を手動で分割する必要があります	引用形式
DigitalOcean	コントロールパネルから入力された長いTXT値は、自動的に分割されません	引用形式
クラウドフレア	保存時に長いTXTレコードを自動的に分割します。手動での操作は不要です	プレーンテキスト形式（レコード全体をそのまま貼り付けてください）
ゴーダディ	分割されていないレコード全体を受け入れ、内部で分割処理を行う	プレーンテキスト形式
Namecheap	ほとんどの場合、長いTXTレコードを自動的に処理します	プレーンテキスト形式
BIND（セルフホスト型）	両方の形式に対応しています。引用符で囲まれたセグメントは、従来のゾーンファイルの構文です	どちらでも構いませんが、分かりやすさを考慮して引用記号を使うことを推奨します

メール認証において、正しい分割が重要な理由

TXTレコードに不備があると、それに依存するプロトコルが機能しなくなります。DKIM、SPF、DMARCはいずれもTXTレコードで管理されているため、形式の不備（余分なスペース、引用符の欠落、文字の欠落など）があると、メール認証に失敗し、その原因の特定に多大な手間がかかることになります。

DKIM キーの整合性

2048ビットのDKIM公開鍵は暗号データです。1文字でも欠けると、受信サーバーは署名を検証できなくなり、メールはDKIMチェックに失敗します。

長いSPFレコード

多くのSPFレコード include: メカニズムは255文字を超える場合があります。分割を誤ると、予期せずDNSルックアップの制限（10回）に達してしまうこともあります。

DMARCレポート用URI

複数のDMARCレコード rua そして ruf URIや詳細なポリシーは制限を超える可能性があります。分割が不適切だと、DMARCレコード全体が解析不能になります。

トラブルシューティングにかかる時間を大幅に短縮

レコードの分割が誤っていると、特に伝播遅延が絡む場合、原因の特定に数時間かかることがあります。ツールを使用することで、人為的ミスの最も一般的な原因を排除できます。

レコードの設定が完了したら、当社のDKIMチェッカー、SPFチェッカー、DMARCチェッカー、または完全なDNSレコード検索機能を使用して、正常に機能するか確認してください。

255文字制限に関する技術的注意事項

RFC 1035 のセクション 3.3.14 および RFC 7208（SPF に関するもの）によると、TXT レコード内の単一の文字列は 255 オクテットに制限されています。これは、長さが 1 バイトのデータに、その前に長さを示すオクテットが付けられて格納されるためです。ただし、1つのTXTレコードには複数の文字列を含めることができ、総長さに関するDNSプロトコルの制限はありません（制限があるのはUDPメッセージサイズ（512バイト）のみであり、これが長いレコードによってDNSリゾルバーがTCPやEDNS0にフォールバックせざるを得なくなる理由です）。

DNSリゾルバが複数の文字列を含むTXTレコードを返した場合、最近のアプリケーションはすべて、区切り文字なしでそれらの文字列を結合して処理します。したがって "part1" "part2" は次のように解釈される part1part2…まるで、1つの長い文字列を保存したかのように。だからこそ、分割はあくまで保存上の詳細に過ぎず、レコードの値は、一度解決されれば同一のものとなります。

よくあるご質問

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

DNSレコードスプリッターとは、長いDNS TXTレコードを255文字のセグメントに分割し、レコードを自動的に分割しないDNSプロバイダーでも正しく保存できるようにするツールです。この255文字の制限は、DNSの初期仕様であるRFC 1035に由来するものであり、TXTレコード内の個々の文字列すべてに適用されます。レコードの値全体は保持されます。単に複数の短い文字列として保存され、クエリが発行された際にDNSリゾルバーがそれらを再び連結する仕組みです。

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

Google Cloud DNS、AWS Route 53、Azure DNS、およびDigitalOceanでは、長いTXTレコードを保存する前に手動で分割する必要があります。Cloudflare、GoDaddy、Namecheapでは、レコード全体を貼り付けると自動的に分割されます。BINDは両方の形式に対応していますが、引用符で囲まれたセグメントの方が従来のゾーンファイルの構文です。よくわからない場合は、まずそのまま貼り付けてみてください。プロバイダーから長さや形式に関するエラーが表示された場合は、ここに戻って分割してください。

TXTレコードを分割すると、その値が変わったり、DKIM検証が失敗したりしますか？

いいえ。DNSリゾルバーが複数の文字列を含むTXTレコードを取得した場合、最新のメールサーバーやライブラリはすべて、区切り文字なしでそれらを連結します。したがって、「part1」と「part2」は「part1part2」となり、分割されていない値と同じになります。DKIM署名は正しく検証され、SPFは同じメカニズムで評価され、DMARCも同じポリシーを解析します。この分割は、あくまで保存上の詳細に過ぎません。

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

ほとんどの 2048 ビット DKIM 公開鍵は 400 ～ 450 文字の長さであり、これは単一の TXT 文字列に対する 255 文字の制限を超えています。Google Cloud DNS、AWS Route 53、Azure DNS などのプロバイダーは、分割されていない値を「レコードデータが無効」などのエラーと共に拒否します。鍵を適切に引用符で囲まれた255文字のセグメントに分割することで、リゾルバーが読み戻した際に暗号学的値が同一のまま保たれ、プロバイダーがレコードを受け入れることが可能になります。

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

引用符付き形式では、255文字ごとのセグメントを二重引用符で囲みます（「segment1」「segment2」「segment3」）。これは、Google Cloud DNS、AWS Route 53、および Azure DNS で必要とされる形式です。プレーン形式では、セグメントが引用符なしで生の複数行テキストとして出力されます。これは、引用符のない複数行の入力を受け付けるプロバイダーや、カスタム構文を持つBINDゾーンファイル内で使用する場合に適しています。迷った場合は、Quoted形式を使用してください。これがより安全なデフォルト設定です。

このDNSレコードスプリッターは、秘密鍵と併用しても安全ですか？

このツールは完全にブラウザ上で動作するため、入力したレコード値が端末の外に出ることはありません。PowerDMARCのサーバーへデータが送信されることも、ログが記録されることもなく、登録も不要です。ただし、このDNSレコード分割ツールは、公開DKIM鍵、SPFレコード、DMARCポリシー、およびドメイン検証文字列を対象として設計されています。DKIMの秘密鍵を、本ツールを含めいかなるWebツールにも貼り付けてはいけません。分割が必要なのは公開鍵（DNSに公開する値）のみです。