TXTレコードのTTLは、DNSサービスの管理画面やゾーンファイルで、そのレコードのTTL欄を書き換えれば変更できます。ただし、新しいTTLが効き始めるのは、古いTTLでキャッシュされた答えが切れてからです。SPFやDKIM、ドメインの所有権確認などの値を書き換える予定があるなら、値を変える前にTTLを下げ、古いTTLの分だけ待ってから本番の変更をするのが基本の流れです。この記事では、その手順と、TXT特有の注意点（同じ名前に複数のTXTが並ぶ場合、CNAMEで他社に任せている場合）を説明します。
TTLを変えると何が変わるのか
TTLは、キャッシュDNSがその答えを保持してよい秒数です。TXTレコードのTTLが3600なら、一度問い合わせたキャッシュDNSは、最長1時間は権威サーバーに聞き直さずに同じ値を返します。
TXTレコードでTTLが関わるのは、主に次の場面です。
- SPFを書き換えるとき：送信サービスを追加・削除したあと、古いSPFがキャッシュに残っている間は、受信側が古い内容で判定します。
- DKIMの鍵を入れ替えるとき：新しい公開鍵が行き渡る前に新しい鍵で署名を始めると、検証に失敗するメールが出ます。
- DMARCの方針を変えるとき：
p=の値の変更が受信側に届くまで時間差があります。 - 所有権確認や証明書発行で一時的なTXTを置くとき：確認する側がキャッシュを持っていると、追加した値がすぐに見えないことがあります。
TTLを変えても、TXTの値そのものは変わりません。TTLだけの変更でメールの判定が変わることはないため、値の変更より前に済ませておける安全な準備作業です。
手順1：今のTTLを確かめる
最初に、権威サーバーが今どのTTLで答えているかを確認します。この数字が「TTLを下げた設定が行き渡るまでに待つ時間」の上限になります。
# ドメインのネームサーバーを調べる
dig example.com NS +short
# 権威サーバーに直接聞く。2列目がTTL（秒）
dig @ns1.example-dns.net example.com TXT +norecurse +noall +answer
dig @ns1.example-dns.net _dmarc.example.com TXT +norecurse +noall +answer
dig @ns1.example-dns.net selector1._domainkey.example.com TXT +norecurse +noall +answerselector1 はDKIMのセレクタ名の例です。実際の名前は、メール送信サービスの設定画面やDKIM署名ヘッダーの s= で確かめます。
手順2：管理画面またはゾーンファイルでTTLを変える
TTLの変え方は、使っているDNSの種類で異なります。画面の項目名はサービスによって違い、変わることもあるため、ここでは役割で説明します（2026年10月現在）。
DNSサービスの管理画面の場合対象のTXTレコードの編集画面を開き、TTLの欄だけを変えて保存します。値の欄に触れる必要はありません。長いTXT（DKIMの公開鍵など）を編集画面で開くと、保存時に値が分割・結合されたり引用符が付いたりすることがあるため、保存後に値が変わっていないかを手順4で確かめます。
TTLに「自動」を選べるサービスもあります。たとえばCloudflareのDNSでは、自動を選ぶと一定の既定値が使われます。既定値はサービスの仕様で決まるため、数字が必要な場面では明示的に指定します。
BINDなどのゾーンファイルの場合レコードの行にTTLを書くと、その行だけに効きます。書かなければ、ファイル先頭の $TTL の値が使われます。
$TTL 3600
@ IN TXT "v=spf1 include:_spf.example-mail.net ~all"
; この行だけTTLを300にする
@ 300 IN TXT "google-site-verification=your-verification-token"ゾーンファイルを書き換える前にはファイルを控えておき、編集後はSOAのシリアル番号を上げてから読み込み直します。セカンダリDNSがある場合は、シリアル番号が上がらないと変更が転送されません。
# 構文を確かめてから読み込み直す（BINDの例）
named-checkzone example.com /etc/bind/zones/example.com.zone
sudo rndc reload example.com同じ名前に複数のTXTがある場合
ルートドメイン（@）には、SPF、検索エンジンの所有権確認、各種サービスの確認用など、複数のTXTが並ぶことがよくあります。DNSでは、同じ名前・同じタイプのレコードの集まりを1つの単位（RRセット）として扱い、その中のTTLは同じにすることになっています（RFC 2181）。
このため、DNSサービスによって次のように動きが違います。
- 名前とタイプごとに1つのTTLしか持てず、複数の値をまとめて1つのTTLで管理するサービス（Amazon Route 53 のレコードセットなど）
- 行ごとにTTL欄があるように見えても、実際の応答では1つに揃えられるサービス
- 行ごとに違うTTLをそのまま返してしまう構成
TTLが揃っていない応答を受け取ったキャッシュDNSは、その中の一番短いTTLで扱うことが規格で推奨されています。1行だけTTLを変えても期待どおりにならないことがあるため、同じ名前のTXTはまとめて同じTTLにするのが分かりやすい運用です。変更後は手順4で、すべての行が同じTTLで返っているかを確かめます。
CNAMEで他社に任せているTXTは自分では変えられない
DKIMでは、メール送信サービスが selector._domainkey をCNAMEで自社のホスト名へ向ける方式を案内していることがあります。この場合、最終的なTXTの値もTTLも送信サービス側が決めており、自分のDNSで変えられるのはCNAMEのTTLだけです。
# CNAMEをたどっているかを確かめる
dig selector1._domainkey.example.com TXT +noall +answer答えの中にCNAMEの行が出てくれば、TXTのTTLは向け先の事業者の設定です。鍵の入れ替えの時期や方法は、その事業者の案内に従います。
手順3：値を変える予定があるなら「下げて待つ」
SPFやDKIMの値を書き換える予定があるときは、次の順で進めます。
- 手順1で今のTTL（例：3600秒）を控える
- TTLだけを短い値（例：300秒）に下げる
- 控えた古いTTLの時間（例：1時間）以上待つ。これで、古いTTLでキャッシュされた答えが消えます
- TXTの値を書き換える。ここからは短いTTLで入れ替わります
- 新しい値で問題が無いことを確かめたら、TTLを元の長さに戻す
3の待ち時間を省くと、TTLを下げた意味がありません。キャッシュDNSは、取得したときのTTLを使ってカウントダウンするため、下げたTTLは次に取りに来たときから効きます。
TTLを短いままにしておくと、権威サーバーへの問い合わせが増えるうえ、権威サーバーに障害が起きたときに影響が早く出ます。値が落ち着いたら、数時間〜1日程度の長さに戻すのが一般的です。
手順4：変更後に確かめる
権威サーバーと、いくつかの公開DNSで確かめます。
# 権威サーバー：設定したTTLがそのまま出るか、値が変わっていないか
dig @ns1.example-dns.net example.com TXT +norecurse +noall +answer
# 公開DNS：2列目は残りTTL。古いTTL以下の値から減っていく
dig @8.8.8.8 example.com TXT +noall +answer
dig @1.1.1.1 example.com TXT +noall +answer確かめる点は3つです。
- 権威サーバーが、新しいTTLで答えているか（ネームサーバーが複数ならすべて）
- 同じ名前のTXTがすべて同じTTLで返っているか
- TXTの値が編集前と一字一句同じか（とくにSPFの
v=spf1が1行だけか、DKIMの鍵が欠けていないか）
公開DNSの残りTTLが、新しいTTL以下の数字になっていれば、新しいTTLが行き渡り始めています。
まとめ
- TXTのTTLは、レコードのTTL欄（ゾーンファイルなら行のTTLか
$TTL）で変更します。値の変更とは切り離して行えます。 - 新しいTTLが効くのは、古いTTLでキャッシュされた答えが切れてからです。
- 値を書き換える予定があるなら、TTLを下げる、古いTTLの分待つ、値を変える、TTLを戻す、の順で進めます。
- 同じ名前のTXTは1つのRRセットとして扱われるため、TTLを揃えます。
- CNAMEで送信サービスに任せているDKIMなどは、TXTのTTLを自分では変えられません。