DNSのテキストレコードについて

DNSのTXTレコードは、ドメインに対して文字列データを公開するためのDNSレコードです。

Webサイト運営、メール設定、SaaS連携、ドメイン認証など、実務で非常によく使われます。

一見すると単なる「文字情報の保存場所」に見えますが、実際には、外部サービスがその文字列を参照して、ドメイン所有確認やメール認証などを行う重要な役割を持っています。

TXTレコードとは

TXTレコードは、DNS上にテキスト形式の情報を登録するためのレコードタイプです。

DNSにはいくつか代表的なレコードがあります。

• Aレコード：ドメイン名をIPv4アドレスに対応づける
• AAAAレコード：ドメイン名をIPv6アドレスに対応づける
• CNAMEレコード：別のホスト名への別名を設定する
• MXレコード：メール配送先サーバーを指定する
• TXTレコード：文字列データを公開する

TXTレコードの特徴は、IPアドレスや配送先のような固定的な意味を持つのではなく、その文字列の意味を、利用するサービスや仕様側が定義することです。

つまりTXTレコードは、単に「自由な文章を書く場所」というより、

DNS上に文字列を置き、それを外部サービスや認証仕様が読み取って利用する仕組み

と考えるとわかりやすいです。

TXTレコードの主な用途

TXTレコードは、主に次のような用途で使われます。

ドメイン所有確認

もっともよくある用途のひとつが、ドメインの所有確認です。

Google Search Console、Google Workspace、Microsoft 365、各種SaaS、CDN、SSL証明書のDNS認証などでは、

• このドメインを本当に管理しているか
• DNSを編集できる権限があるか

を確認するために、指定された文字列をTXTレコードとして追加するよう求められます。

たとえば次のような値です。

google-site-verification=abc123example

サービス側はDNSを参照し、その文字列が存在すれば、「このユーザーはDNS設定を変更できる管理者である」と判断します。

SPF（送信元メールサーバーの許可設定）

TXTレコードの代表的な用途として、SPFがあります。

SPFは、このドメインからメール送信してよいサーバーはどれかを定義する仕組みです。

例

v=spf1 include:_spf.google.com ~all

この例では、

• v=spf1：SPFのルールであることを示す
• include:_spf.google.com：Googleの送信サーバーを許可する
• ~all：それ以外は明確には許可しない

という意味になります。

SPFが正しく設定されていないと、

• 正常なメールが迷惑メール扱いされる
• 送信ドメインの信頼性が落ちる
• なりすまし対策が弱くなる

といった問題につながります。

なお、ここで重要なのは、同じホスト名にSPFポリシーを複数作ってはいけないという点です。

TXTレコード自体は複数あっても問題ないことがありますが、v=spf1 で始まるSPF設定は1つに統合する必要があります。

DKIM（メール署名の公開鍵の公開）

DKIMも、TXTレコードを使って設定されることが一般的です。

DKIMは、送信メールに電子署名を付与し、受信側が

• そのメールが正規の送信元から送られたか
• メール本文が途中で改ざんされていないか

を確認するための仕組みです。

DNSには、検証用の公開鍵をTXTレコードとして登録します。

例

selector1._domainkey.example.com
TXT "v=DKIM1; k=rsa; p=公開鍵文字列"

ここで重要なのは、受信側がDNS上に公開された鍵を見て署名検証を行うという点です。

また、DKIMの公開鍵は文字列が非常に長くなることがあります。

そのため、DNS上や管理画面上では、1つのTXTレコード内で複数の文字列に分かれて表示されることがあります。

ただし、正しく登録されていれば通常は問題ありません。

DMARC（メール認証ポリシー）

DMARCもTXTレコードで設定します。

DMARCは、SPFやDKIMの認証結果を踏まえて、認証に失敗したメールをどう扱うかを定義するポリシーです。

例

_dmarc.example.com
TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

この例では、

• v=DMARC1：DMARCのポリシーであることを示す
• p=quarantine：怪しいメールは隔離対象にする
• rua=mailto:...：集計レポートの送信先を指定する

という意味です。

DMARCを適切に設定すると、

• なりすましメール対策の強化
• ドメインブランド保護
• 認証状況の可視化

に役立ちます。

各種サービス連携・認証

TXTレコードは、メール以外にも幅広いサービスで使われます。

たとえば次のようなケースです。

• Google Search Console のドメイン確認
• Google Workspace のドメイン認証
• Microsoft 365 のドメイン確認
• SSL証明書のDNS認証
• MAツールやCRMのドメイン認証
• CDNや外部配信サービスとの接続確認

このようにTXTレコードは、「そのドメインを自分が管理していることを証明するための標準的な方法」として広く利用されています。

TXTレコードの基本構成

DNS管理画面でTXTレコードを追加する際は、一般的に次の項目を設定します。

• ホスト名（名前）
• タイプ
• 値
• TTL

例

• ホスト名：@
• タイプ：TXT
• 値：google-site-verification=abc123example
• TTL：3600

各項目の意味

ホスト名

どの名前に対してTXTレコードを付けるかを指定します。

例

• @ → ルートドメイン（example.com）
• _dmarc → _dmarc.example.com
• selector1._domainkey → selector1._domainkey.example.com

ただしDNSサービスによって、

• @ をルートドメインとして扱う
• 空欄がルートドメインになる
• example.com をそのまま入れる

など、入力方式が異なることがあります。

タイプ

TXT を選択します。

値

サービスから指定された文字列そのものを入力します。

例

google-site-verification=abc123example

v=spf1 include:_spf.google.com ~all

TTL

TTLは、そのDNS情報をどれくらいキャッシュしてよいかを表す値です。

秒単位で指定されることが一般的です。

例

• 300 → 5分
• 3600 → 1時間
• 86400 → 24時間

ここで注意したいのは、TTLは「設定反映そのものの待ち時間」ではなく、以前のDNS情報がキャッシュに残りやすくなる時間に関係するという点です。

そのためTTLが長いと、変更後すぐでも、環境によっては古い情報が見え続けることがあります。

よくあるTXTレコードの記述例

ドメイン確認用

@  TXT  "google-site-verification=xxxxx"

SPF

@  TXT  "v=spf1 include:_spf.google.com ~all"

DMARC

_dmarc  TXT  "v=DMARC1; p=none; rua=mailto:report@example.com"

DKIM

selector1._domainkey  TXT  "v=DKIM1; k=rsa; p=公開鍵文字列"

実務で混乱しやすいポイント

ルートドメインの書き方がサービスごとに違う

同じ意味でも、DNS管理画面によって表記方法が違います。

• @
• 空欄
• example.com

などの違いがあるため、案内文をそのままコピペすると意図しない名前になることがあります。

ダブルクォーテーションの扱いがUIごとに違う

TXT値は、管理画面やAPIによって

• クォーテーションなしで入力する
• 自動的にクォートされる
• 表示時だけクォート付きになる

といった差があります。

これはDNSの意味が違うというより、管理画面や入力形式の違いです。

そのため、基本的には利用中のDNSサービスの仕様に従うのが安全です。

同じホスト名にTXTレコードが複数あってもよい場合がある

たとえばルートドメインに、

• Google認証用TXT
• 別サービスの認証用TXT
• SPF用TXT

が並ぶことはあります。

これは必ずしも問題ではありません。

ただし注意点として、SPF設定だけは複数作らないことが重要です。

たとえば次のような構成は避けるべきです。

@ TXT "v=spf1 include:_spf.google.com ~all"
@ TXT "v=spf1 include:spf.protection.outlook.com ~all"

SPFは分けて複数書くのではなく、必要な送信元を1つのポリシーにまとめます。

反映確認には時間差がある

DNS設定は保存直後に権威DNSへ反映されても、各地のDNSキャッシュの影響で、すぐには見えないことがあります。

そのため、

• 管理画面では登録済み
• でも検証サービスでは未確認
• 端末や回線によって見え方が違う

という状態が一時的に起こることがあります。

DKIMなど長い値は分割表示されることがある

長い文字列を持つTXTレコードでは、DNS仕様や管理画面の表示上、1つのレコード内で複数の文字列に分けて見えることがあります。

見た目上分割されていても、登録方法が正しければ問題ないケースがあります。

TXTレコードとメール運用の関係

TXTレコードの中でも、特に重要なのがメール認証です。

SPF

送信を許可するメールサーバーを定義する

DKIM

メールに電子署名を付け、その検証用公開鍵をDNSで公開する

DMARC

SPFやDKIMの結果に基づいて、失敗メールの扱い方を定める

この3つを正しく運用すると、

• なりすましメールへの対策
• 送信ドメインの信頼性向上
• 迷惑メール判定の抑制
• 認証状況の可視化

につながります。

TXTレコード追加の基本手順

一般的な流れは次の通りです。

指定情報を確認する

まず、設定を求めているサービスから次の情報を確認します。

• ホスト名
• レコードタイプ
• 値
• TTLの指定があるか

DNS管理画面にログインする

ドメインのDNSを管理しているサービスに入ります。

例

• Cloudflare
• Route 53
• お名前.com
• ムームードメイン
• Xserver
• さくらインターネット

など

TXTレコードを追加する

指定された情報を、そのDNSサービスの書式に合わせて入力します。

保存して反映を待つ

保存後すぐに見えることもありますが、キャッシュ状況によっては時間差があります。

検証する

サービス側の「確認」「Verify」ボタンを押すか、dig や nslookup で確認します。

確認コマンドの例

dig

dig TXT example.com

DMARCを確認する場合

dig TXT _dmarc.example.com

nslookup

nslookup -type=TXT example.com

これでTXTレコードが返ってくれば、その問い合わせ先からは見えている状態です。

よくあるトラブル

レコードが見つからない

原因として多いのは次のようなものです。

• ホスト名の入力ミス
• ルートドメインとサブドメインの混同
• 保存先DNSの取り違え
• まだキャッシュが残っている
• 反映確認先が異なる

認証が通らない

よくある原因は以下です。

• 値のコピー漏れ
• 余計なスペースや改行
• ホスト名の誤り
• クォーテーションの扱いミス
• フルドメイン名の二重入力

SPFエラーが出る

よくある原因

• SPFが複数ある
• include の設計ミス
• 構文エラー
• 送信元サービスの入れ忘れ

DKIMが動かない

よくある原因

• セレクタ名の誤り
• 公開鍵の欠落
• 文字列の貼り付けミス
• メール送信側サービスでDKIMが有効化されていない

TXTレコードとCNAMEの違い

ドメイン認証では、TXTを求められる場合もあれば、CNAMEを求められる場合もあります。

TXTレコード

• 文字列情報を公開する
• 所有確認やポリシー公開に向いている

CNAMEレコード

• 別のホスト名への別名を設定する
• 接続先の委譲やホスト名の参照に向いている

つまり、TXTは「文字列で証明・宣言する」用途、CNAMEは「別名として接続先を示す」用途、と考えると整理しやすいです。

初心者向けに一言で言うと

TXTレコードは、

DNS上に文字列を置き、その文字列を外部サービスや認証の仕組みが読みに来るためのレコード

です。

その結果として、

• ドメイン所有確認
• メール送信元の認証
• セキュリティポリシーの公開
• 外部サービスとの連携確認

などができるようになります。

実務で覚えておきたい重要ポイント

特に押さえておきたいのは次の点です。

1. TXTレコードはDNS上に文字列データを公開する仕組み
2. Google認証や各種SaaS連携で頻繁に使う
3. SPF・DKIM・DMARCはTXTレコードを使って設定される
4. TXTが複数あること自体は問題ないが、SPFは1つにまとめる
5. TTLは反映時間そのものではなく、古い情報のキャッシュ残存に影響する
6. DNS管理画面ごとにホスト名やクォートの扱いが異なる

まとめ

DNSのTXTレコードは、単なる補助的な設定ではありません。

現在のWeb運用では、

• ドメイン認証
• メール認証
• セキュリティ運用
• SaaS連携

といった重要な場面で使われる、非常に実務的なレコードです。

Search Console認証やメール到達率改善に関わる場面が多いため、「TXTレコードは文字列を置くもの」だけでなく、何の目的でその文字列を置くのかまで理解しておくことが大切です。

以上、DNSのテキストレコードについてでした。

最後までお読みいただき、ありがとうございました。