TXTレコードとは?SPF・DKIM・DMARC・ACME対応の設定方法と運用上の注意点ガイド

TXTレコードとは — 概要

TXTレコードはDNS(Domain Name System)のリソースレコードの一種で、ドメインに関連する任意のテキスト情報を格納するために使われます。タイプ番号は16で、RFC 1035で定義された基本的なDNSレコードの一つです。元々は管理情報や説明文のような自由テキストを載せるために設計されましたが、現在ではメール認証(SPF/DKIM/DMARC)、サービス検証(GoogleやMicrosoftのドメイン所有権確認)、Let's EncryptなどのACMEチャレンジ、TLSAやDNS-SDといったプロトコルのデータ格納に広く使われています。

技術的な仕様とフォーマット

  • RDATA形式:TXTレコードのRDATAは「character-string」の集合で構成されます。各character-stringは先頭に1バイトの長さフィールド(最大255)を持ち、その後に文字列本体が続きます(RFC 1035)。つまり一つのTXTレコードは複数の255バイト以下の文字列を連結して保持できます。

  • 長さの制限:各部分文字列は最大255バイトですが、RDATA全体の長さはDNSの仕様上最大で65535バイト理論上可能です。ただし、実際のDNSサーバやホスティングプロバイダ、管理画面では1レコードあたり255文字までしか入力できない等の実装制約があるため、実務上は注意が必要です。

  • 表記上の注意:ゾーンファイルでは文字列をダブルクォートで囲むのが一般的です。WebベースのDNS管理画面ではクォートの要否がプロバイダにより異なるため、取扱説明を確認してください。

主な用途(代表例)

TXTレコードは「任意テキスト格納」という汎用性の高さから、以下のような用途で広く使われます。

  • SPF(Sender Policy Framework)

    メール送信元の正当性をDNS上で定義するためにTXTレコードが使われます。例:「v=spf1 include:_spf.example.net -all」。RFC 7208で標準化されています。注意点として、SPF用のTXTレコードはドメインにつき1つが原則で、複数存在するとチェック中にエラー(PermError)となる可能性があります。また、SPFの評価ではDNSルックアップ数に上限(10回)があるため、includeの多用や長いレコードは避けるべきです。

  • DKIM(DomainKeys Identified Mail)

    DKIMの公開鍵はセレクタ名を付けたサブドメイン(selector._domainkey.example.com)にTXTレコードとして配置されます。例:「v=DKIM1; k=rsa; p=MIIBIj...」。RFC 6376で定義されています。公開鍵はBase64で表記されるため長くなりがちで、適切に分割(quoted-stringの連結)できるようにする必要があります。

  • DMARC(Domain-based Message Authentication, Reporting & Conformance)

    DMARCポリシーは _dmarc.example.com にTXTで配置します。例:「v=DMARC1; p=reject; rua=mailto:dmarc-rua@example.com」。RFC 7489で定義され、SPF/DKIMと組み合わせてメールの信頼性向上に使われます。

  • ACME DNS-01(Let's Encrypt等)

    証明書の発行でドメイン所有権を確認するDNSチャレンジ(DNS-01)では、_acme-challenge.example.com にTXTレコードを一時的に置きます(RFC 8555参照)。証明書の自動化で頻繁に使われるため、API経由でのDNS更新(RFC 2136等)と組み合わせることが多いです。

  • TLSA(DANE)

    TLS証明書の情報をDNSに格納するTLSAレコード(RFC 6698)が本来の用途ですが、補助的にTXTが使われる場面もあります。TLSA自体は専用RRですが、TXTは補助情報やヒントに使えます。

  • サービス発見(DNS-SD / mDNS)

    DNS-SD(サービス記述)やmDNSでは、サービスのメタデータ(例:ポート以外のキー=値形式)をTXTレコードに記述します。RFC 6763(DNS-Based Service Discovery)での利用が典型です。

  • ドメイン所有権確認・その他カスタム用途

    GoogleやMicrosoft、各種クラウドサービス・SNSがドメイン確認のために特定の文字列をTXTに要求することがよくあります。運用上は一時的なTXT追加・削除で済むため手軽です。

実務上の注意点とよくあるトラブル

  • TXTレコードの複数管理:SPFは1ドメイン1レコードが基本。SPF用のTXTが複数あると誤動作します(RFC 7208)。DKIMやその他の用途では同名サブドメインに複数のTXTが存在するケースはあるが、用途ごとに名前を分けるのが安全です(例:_dmarc、_acme-challenge、selector._domainkey)。

  • 文字数制限と分割:公開鍵など長い値はquoted-stringを複数並べることでゾーンファイル上で分割できますが、DNS管理画面での入力制限に注意。プロバイダによっては自動で分割・連結するものの、手入力では改行や余分なスペースで値が壊れることがあります。

  • SPFのDNSルックアップ制限:includeやa、mx、ptrなどの評価で発生するDNSルックアップは合計で10回まで(上限)です。複雑な構成は"permerror"や"temperror"を招くので、includeの多用や過度のフラット化に注意してください。

  • DNS伝播とTTLの影響:TXTレコードの変更が即時に反映しないことがあります。TTLによりキャッシュが残るため、証明書発行や検証の際はTTLを短くしておくか、事前に余裕を持って設定してください。

  • 整合性と改ざん:TXTレコード自体は平文なので、偽のTXTを注入されるとサービスに悪影響が出ます。DNSゾーンの管理権限を厳格に管理し、可能ならDNSSECを導入して応答の改ざん防止を検討してください(RFC 4033–4035)。

確認・検査のコマンド例

  • digを使う:dig +short TXT example.com

  • 特定のサブドメイン:dig +short TXT selector._domainkey.example.com

  • nslookup(Windows等):nslookup -type=txt example.com

  • オンライントラブルシュート:MXToolboxや各種DNSチェッカーでTXT、SPF、DKIM、DMARCの検査が可能です。

ベストプラクティス

  • 用途ごとに名前空間を分ける:_dmarc、selector._domainkey、_acme-challenge等を使い、TXT値の競合を避ける。

  • SPFは単一TXTにまとめ、includeやa/mxの多用を避ける。可能ならSPFフラット化ツールを使い、DNSルックアップ数を監視する。

  • DKIMキーは長くなるため、DNS側での分割表記(複数のquoted-string)を正しく扱えるか確認する。公開鍵が壊れていると署名検証に失敗する。

  • 自動化するならAPI経由でTXTを更新する仕組みを導入し、変更履歴とロールバックを残す。ACME等は短期での追加・削除が必要になる。

  • 可能ならDNSSECを導入してTXT応答の整合性を確保する。ただしDNSSEC導入には鍵管理や運用の負荷があるため、事前に検討する。

実例(よく見るTXTレコード)

  • SPF例:example.com. TXT "v=spf1 include:_spf.google.com ~all"

  • DKIM例:selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

  • DMARC例:_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensics@example.com"

  • ACME(Let's Encrypt)例:_acme-challenge.example.com. TXT "some-token-string"

まとめ

TXTレコードはDNSの中でも非常に汎用性が高く、メールの認証やサービス検証、証明書発行など多くの現代的な用途で中心的に用いられています。一方で実装や運用における文字数制限、プロバイダごとの入力仕様、メール関連プロトコルの固有ルール(SPFの単一レコード要件やDNSルックアップ制限など)に注意する必要があります。セキュリティ面では、DNSゾーン管理の適切な権限管理および可能ならDNSSECの導入を検討してください。

参考文献