2026年6月16日

2026年6月16日

TXTレコードを設定する方法|所有権の確認・証明書のDNS認証・メールのセキュリティ設定まで用途別に書く

TXTレコードは、ドメインに任意の文字列を載せるためのDNSレコードで、「このドメインの持ち主である」ことの証明や、メールの送信元認証、SSL証明書の発行時の認証などに使われます。設定の基本は「サービスが指定する名前に、指定された値をそのまま登録する」ことですが、用途ごとに置く名前や、登録後に消してよいかどうかが違います。この記事では、TXTレコードの書式の要点を押さえたうえで、WordPressサイトの運用でよく出てくる用途(サービスの所有権確認、Let's Encrypt などのDNS認証、メールのセキュリティ設定)ごとに、設定の手順と確認方法を説明します。

TXTレコードの書式の要点

ゾーンファイルの形で書くと、TXTレコードは次のようになります。

example.com.              3600 IN TXT "google-site-verification=your-verification-token"
_acme-challenge.example.com. 300 IN TXT "your-acme-token"

用途を問わず共通する決まりは次のとおりです。

  • 名前:ルートドメインに置くのか、_acme-challenge のような下線付きの名前に置くのかは用途で決まります。管理画面では名前欄にドメイン名が自動で付け足されることが多いため、_acme-challenge とだけ入力するのか、完全な名前を入れるのかを画面の説明で確かめます。
  • 値:ゾーンファイルでは引用符で囲みます。管理画面では引用符を自動で付けるものと付けないものがあり、二重に付くと値が変わってしまいます。
  • 長さ:1つの文字列は255バイトまでです。DKIMの公開鍵のような長い値は、複数の文字列に分けて1つのレコードとして登録します(多くの管理画面は自動で分割します)。
  • 同じ名前に複数置ける:TXTは同じ名前に何件でも置けます。所有権確認の値と、SPFの値がルートドメインに並ぶのは普通のことです。ただしSPFは1つの名前に1件だけ、という別の決まりがあります。
  • CNAMEと同居できない:CNAMEを設定した名前には、TXTを含むほかのレコードを置けません。

設定する前に確かめること

TXTレコードを登録するのは、ドメインのネームサーバーとして実際に使われているDNSです。まずそれを特定し、あわせて今あるTXTを一覧しておきます。

dig NS example.com +short
dig example.com TXT +noall +answer

既存のTXTは、何の用途のものかを控えておきます。整理のつもりで用途の分からないTXTを消すと、メールの認証やサービス連携が止まることがあります。削除や変更の前には、現在の一覧をファイルに残しておくと戻すときに役立ちます。

用途1:サービスの所有権を確認する

Google Search Console のドメインプロパティなど、多くのサービスはドメインの持ち主であることをTXTレコードで確認します。手順はおおむね共通です。

  1. サービスの画面で、登録すべき値(google-site-verification=... のような文字列)を表示させます。
  2. 指定された名前(多くはルートドメイン)にTXTレコードとして登録します。既存のTXTは消さず、追加します。
  3. 公開DNSで値が見えるのを確かめてから、サービス側で確認を実行します。
dig @8.8.8.8 example.com TXT +short

確認の画面やボタンの名前はサービスごとに異なり、変わることもあります(2026年10月現在)。

注意したいのは、確認が済んだ後も消さない のが原則という点です。Google Search Console のように、定期的に値の存在を確かめ、消すと所有権の確認が外れるサービスがあります。逆に、使わなくなったサービスの値は残しておく理由がないので、後の節の方法で整理します。

用途2:SSL証明書のDNS認証(_acme-challenge)

Let's Encrypt などACMEに対応した認証局では、ドメインの管理者であることをDNSで示す方法(DNS-01チャレンジ)があります。ワイルドカード証明書(*.example.com)を取る場合や、サーバーが外部からHTTPで到達できない場合に使います。

認証用の値は _acme-challenge.example.com という名前のTXTに置きます。値は発行のたびに変わるため、手作業で登録すると更新のたびに作業が必要です。certbot には、DNS事業者のAPIを使ってこのTXTを自動で登録・削除するプラグイン(Cloudflare 用、Route 53 用など)があり、継続して運用するならこちらが現実的です。

# 手作業で値を登録する方法(更新も手作業になる)
sudo certbot certonly --manual --preferred-challenges dns \
  -d example.com -d '*.example.com'

この方法では、certbot が表示した値をTXTとして登録し、公開DNSで見えることを確かめてから続行します。example.com と *.example.com を同時に申請すると、同じ _acme-challenge の名前に2つの値を並べて登録する必要があります。片方を上書きしてしまうと認証に失敗します。

DNS事業者のAPIを使う場合は、そのAPIトークンが「ゾーンを書き換えられる鍵」になります。権限は対象ゾーンのDNS編集だけに絞り、認証情報のファイルは root だけが読める権限(chmod 600 など)にしておきます。

認証局がドメインを検証する際には、CAAレコード(証明書を発行してよい認証局の指定)も参照されます。CAAを設定しているなら、使う認証局が許可されているかもあわせて確かめてください。

用途3:メールのセキュリティ設定

メール関連では、TXTレコードを使う設定がいくつかあり、それぞれ置く名前が決まっています。

設定 名前 値の書き始め
SPF ルートドメイン(メールアドレスの@の後ろ) v=spf1
DKIM セレクター._domainkey v=DKIM1
DMARC _dmarc v=DMARC1
MTA-STS _mta-sts v=STSv1
TLS-RPT _smtp._tls v=TLSRPTv1

SPF・DKIM・DMARCは送信元の認証で、WordPressから送るメールの届きやすさに関わります。SPFはルートドメインに1件だけ、という決まりがあるため、新しい送信サービスを足すときは既存のSPFレコードに追記します。2件目のSPFレコードを作ると、両方とも無効と判定されることがあります。

MTA-STS は、自分のドメイン宛てのメールを送る側に、暗号化(TLS)での配送を求めるための仕組みです。TXTレコードだけでは完結せず、https://mta-sts.example.com/.well-known/mta-sts.txt にポリシーファイルを置く必要があります。

_mta-sts.example.com.   3600 IN TXT "v=STSv1; id=20261018a"
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

id はポリシーファイルを変更したときに書き換える識別子で、送信側はこの値の変化を見てポリシーを取り直します。ポリシーで厳しい動作を選ぶ前に、まず試験的な動作から始め、TLS-RPTで届く報告を確かめてから切り替えると、メールの受信を止めずに済みます。

登録後の確認

登録したら、権威DNSサーバーと公開DNSの両方で値を確かめます。

# 権威DNSサーバーに直接問い合わせる(今の設定)
dig @ns1.example-dns.net _acme-challenge.example.com TXT +norecurse +short

# 公開DNSで外からの見え方を確かめる
dig @1.1.1.1 _acme-challenge.example.com TXT +short

見る点は次のとおりです。

  • 値が1文字も欠けずに表示されるか。引用符が二重になっていないか、前後に空白が入っていないか。
  • 名前がずれていないか。_acme-challenge.example.com.example.com のように二重に登録されていると、目的の名前では何も返りません。
  • 権威サーバーでは見えるのに公開DNSで見えない場合、登録前に問い合わせた「無い」という答えがキャッシュされている可能性があります。しばらく待ってから再確認します。

不要になったTXTを整理する

TXTレコードは追加する一方になりがちです。使っていないサービスの確認用の値や、手作業の証明書発行で残った _acme-challenge の値は、整理の対象になります。

整理するときは、まず現在のTXTを一覧して保存し、1件ずつ「どのサービスの何のための値か」を確かめてから削除します。用途が分からない値は、サービスの管理画面で該当する設定が無いかを確認し、確信が持てないものは残しておく方が安全です。削除後は、関連するサービス(Search Console、メールの送受信など)が引き続き動いているかを数日見守ります。

まとめ

  • TXTレコードは用途ごとに置く名前が決まっています。サービスが指定する名前と値をそのまま登録し、引用符の二重付けや名前の二重登録に注意します。
  • 所有権確認の値は、確認後も消さないのが原則です。使わなくなったサービスの値だけを整理します。
  • 証明書のDNS認証は _acme-challenge に置きます。継続運用するならDNS事業者のAPIを使うプラグインで自動化し、APIトークンの権限を絞ります。
  • SPFはルートドメインに1件だけで、追加は既存レコードへの追記で行います。MTA-STSはTXTとポリシーファイルの両方が必要です。
  • 登録後は権威DNSと公開DNSの両方で、名前と値が正しく見えるかを確かめます。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲