TXTレコードは、DNSに任意の文字列を載せるためのレコードで、ドメインの所有権確認、メールのSPF・DKIM・DMARC、証明書のDNS認証などに使われます。追加作業そのものは「名前・値・TTLを入れて保存する」だけですが、名前欄の書き方、値の引用符と長さ、同じ名前にある既存のレコードとの関係でつまずく人が多いレコードです。この記事では、追加する前に確かめること、管理画面とゾーンファイルそれぞれでの登録方法、追加後の確認までを順に説明します。
追加する前に確かめること
どのDNSに登録するのかを特定する
レジストラ、レンタルサーバー、Cloudflare などのDNSサービスにはそれぞれ管理画面がありますが、実際に効くのはドメインのネームサーバー（NSレコード）に指定されている所だけです。別の会社の画面に登録しても、外からは見えません。
dig +short NS example.com表示されたネームサーバーの持ち主の管理画面で作業します。Windowsでは nslookup -type=NS example.com でも確認できます。
登録する内容を用途ごとに書き出す
TXTを求めるサービスは、多くの場合「名前（ホスト）」と「値」をセットで指示します。よく使う用途と名前の例は次のとおりです。
- 所有権確認（Google Search Console のドメインプロパティなど）: 頂点（
example.comそのもの）に、サービスが発行した文字列を登録 - SPF: 送信に使う名前（多くは頂点）に
v=spf1で始まる値 - DKIM:
セレクタ._domainkey.example.comに公開鍵 - DMARC:
_dmarc.example.comにv=DMARC1で始まる値 - 証明書のDNS認証（ACMEのDNS-01）:
_acme-challenge.example.comに一時的な値
指示された名前と値は、手で打たずにコピーして控えておきます。1文字の違いで認証に通らなくなるためです。
ステップ1：名前欄を正しく書く
もっとも間違いが多いのが名前欄です。多くの管理画面は、入力した名前の後ろに自動でドメイン名を付け足します。
- 頂点に登録するときは、
@と入力するか空欄にする（画面によって違います） _dmarc.example.comを登録したいときは、_dmarcだけを入れる_dmarc.example.comと全部入れると、画面によっては_dmarc.example.com.example.comという意図しない名前になる
保存後は一覧の表示だけで判断せず、後述の dig で実際の名前に問い合わせて確かめます。管理画面の表示形式はサービスごとに違い、更新で変わることもあります（2026年10月現在）。
ステップ2：値の書き方を確かめる
引用符
ゾーンファイルでは、TXTの値をダブルクォートで囲みます。管理画面では、自動で囲む画面と、自分で囲む必要がある画面があります。自動で囲む画面に引用符付きで入れると、値の中に引用符が文字として含まれ、検証に失敗することがあります。迷ったら引用符なしで保存し、dig の結果で値が "..." の1組だけで囲まれているかを確認します。
長い値
TXTの1つの文字列は255バイトまでという決まりがあります。DKIMの公開鍵（2048ビットのRSAなど）はこれを超えるため、複数の文字列に分けて1つのレコードに入れます。受け取る側は、分けた文字列を区切りなしでつなげて読みます。管理画面の多くは長い値を自動で分割しますが、分割を自分で行う画面や、長い値を受け付けない画面もあります。
余分な空白や改行
コピーしたときに先頭や末尾の空白、改行が混ざることがあります。特にDKIMの鍵は改行が入りやすいので、1行になっているかを見てから貼り付けます。
ステップ3：同じ名前の既存レコードとの関係を見る
TXTは同じ名前に複数置ける
頂点には、所有権確認の文字列、SPF、ほかのサービスの確認用文字列など、複数のTXTが並ぶのが普通です。新しいTXTは「追加」で登録し、既存のTXTを「編集」で書き換えないよう注意します。所有権確認のTXTを消すと、サービス側の定期確認で確認済みの状態が外れることがあります。
SPFは1つの名前に1つだけ
例外がSPFです。同じ名前に v=spf1 で始まるTXTが2つあると、SPFの検証はエラーになります。メール配信サービスを追加するときは、新しいSPFレコードを作るのではなく、既存のSPFの include: を足して1つにまとめます。
変更前: v=spf1 include:_spf.mail-a.example ~all
変更後: v=spf1 include:_spf.mail-a.example include:_spf.mail-b.example ~allSPFには、検証時のDNS問い合わせが10回までという制限もあります。include: を足しすぎると上限を超えるため、使っていない配信サービスの記述は外します。
CNAMEがある名前にはTXTを置けない
ある名前にCNAMEがあると、同じ名前にほかのレコードは置けません。www.example.com がCNAMEなら、www.example.com へのTXT追加は管理画面で拒否されるか、ゾーンの読み込みでエラーになります。サービスによっては、DKIMをTXTではなくCNAMEで登録するよう指示するものもあるため、その場合はTXTを追加しません。
ステップ4：登録する
管理画面の場合
レコードの種類で「TXT」を選び、名前、値、TTLを入れて保存します。TTLは既定値で問題ありません。DNS認証のように値を何度も入れ替える用途では、短めにしておくと再試行の待ち時間を減らせます。
BINDのゾーンファイルの場合
作業前にゾーンファイルをコピーしておき、レコードを追記したらSOAのシリアル番号を上げます。
@ 3600 IN TXT "google-site-verification=your-verification-token"
@ 3600 IN TXT "v=spf1 include:_spf.mail-a.example ~all"
_dmarc 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@example.com"
s1._domainkey 3600 IN TXT ( "v=DKIM1; k=rsa; p=your-public-key-first-part"
"your-public-key-second-part" )保存したら構文を確かめてから読み込みます。
named-checkzone example.com /var/named/example.com.zone
sudo rndc reload example.comステップ5：外から見えるかを確かめる
まず権威DNSに直接問い合わせて、登録した内容が返っているかを見ます。
dig @ns1.example.net +norecurse +noall +answer _dmarc.example.com TXT次に公開DNS経由で確認します。
dig @8.8.8.8 +short _dmarc.example.com TXT
dig @1.1.1.1 +short _dmarc.example.com TXT権威DNSでは見えるのに公開DNSで見えない場合は、追加前に誰かがその名前を問い合わせていて「存在しない」という応答がキャッシュされている可能性があります。この保持時間はSOAレコードの値で決まるため、少し待ってから再確認します。権威DNSでも見えない場合は、登録したDNSが違うか、名前欄の書き方を誤っています。
両方で見えたら、サービス側の「確認」ボタンなどで検証を実行します。
WordPressサイトでよく使う場面
WordPressからのメール送信を WP Mail SMTP などのプラグインで外部サービス経由にするときは、そのサービスが求めるSPFやDKIMのTXTを登録します。ワイルドカード証明書をDNS認証で取るときは _acme-challenge のTXTを使い、更新のたびに値が変わる点に注意します。どちらも、既存のTXTを消さずに追加するという原則は同じです。
まとめ
- 登録先は、NSレコードに指定されているDNSの管理画面
- 名前欄はドメイン名が自動で足されることが多いので、
_dmarcのように短く入れる - 値は引用符の重複、255バイトを超える長さ、余分な改行に注意する
- TXTは同じ名前に複数置けるが、SPFは1つにまとめ、CNAMEのある名前には置けない
- 追加後は権威DNSと公開DNSの両方に
digで問い合わせてから、サービス側で検証する