DNSの管理画面でTXTレコードを削除したのに、dig やチェックツールで見るとまだ古い値が返ってくる。この場合、原因はキャッシュが残っているだけのこともあれば、そもそも使われていないDNSで削除していた、別の仕組みが同じ値を返している、といったこともあります。この記事では、削除したTXTが消えないときに原因を見分ける順番と、それぞれの確かめ方・直し方を説明します。あわせて、TXTを削除する前に確認しておきたい影響についても触れます。
TXTを「追加したのに見えない」場合の検証は、似ていますが確かめる順番が異なるため、ここでは削除に絞って扱います。
削除する前に：そのTXTは何に使われているか
まだ削除していない、またはこれから作業を見直す場合は、対象のTXTが何に使われているかを先に確認してください。TXTには、消すとすぐには分からない形で影響が出るものが多くあります。
v=spf1で始まる値：メール送信元の認証（SPF）。消すと送信メールが迷惑メール扱いになりやすくなる_dmarcの下の値：DMARCのポリシー○○._domainkeyの下の値：DKIMの公開鍵google-site-verification=などの値：サービスの所有確認。サービス側は定期的に確認し直すことがあり、消すと後日確認が外れる_acme-challengeの下の値：Let's Encrypt などのDNS認証用の一時的な値
削除の理由としてよくあるのは、SPFが2つ並んでいる（SPFは同じ名前に1つだけという決まりがあり、重複は認証失敗の原因になります）、使わなくなったサービスの確認用TXTが残っている、などです。消す前に値を控えておけば、問題が出たときに戻せます。
原因1：キャッシュがTTLの間残っている
もっとも多い原因です。キャッシュDNSは、TXTを受け取ったときのTTLの間、その値を使い続けます。TTLが3600秒なら最長1時間、86400秒なら最長1日、古い値が返る可能性があります。
キャッシュによるものかどうかは、権威サーバーへの直接の問い合わせと、公開DNSでの問い合わせを比べると分かります。
# 使われているNSを確認
dig example.com NS +short
# 権威サーバーに直接問い合わせる（キャッシュの影響を受けない）
dig @ns1.your-dns.example example.com TXT +norec
# 公開DNSに問い合わせる（ANSWER欄の数字がTTLの残り）
dig example.com TXT @8.8.8.8権威サーバーではすでに消えていて、公開DNSだけに残っているならキャッシュです。公開DNSの応答に表示されるTTLの残りが0になれば新しい応答に切り替わります。この場合は待つのが基本の対処で、自分のPCのDNSキャッシュを消すと手元の確認だけは早まります。
権威サーバーでも値が返る場合は、削除そのものが効いていません。原因2以降を見ます。
原因2：使われていないDNSで削除している
ドメインのNSが、作業した管理画面とは別のDNSサービスを指していると、どれだけ削除しても外から見える値は変わりません。以前使っていたレンタルサーバーのDNS、ドメインを取ったレジストラのDNS、Cloudflare など、複数の場所に同じドメインのゾーンが存在するのはよくあることです。
dig example.com NS +short の結果に表示されたホスト名が、作業したDNSサービスのものかを確認してください。違う場合は、NSが指している方のDNSで削除します。使っていない方のゾーンは、混乱を避けるため内容を整理しておくとよいでしょう。
原因3：同じ名前に複数のTXTがあり、別の値が残っている
TXTは、同じ名前に複数の値を持てます。ドメインの頂点にはSPFと複数の所有確認用の値が並んでいることが多く、管理画面ではそれらが1つのレコードの中の複数行として表示されることも、別々のレコードとして表示されることもあります。
1つ消したつもりで、実は別の値を消していた、あるいは同じ内容の重複がもう1つあった、という取り違えが起こりがちです。権威サーバーの応答をすべて表示して、残っている値を1つずつ確かめます。
dig @ns1.your-dns.example example.com TXT +norec +noall +answer長い値（DKIMの公開鍵など）は、255バイトごとに区切られた複数の文字列として表示されます。これは1つの値が分割表示されているだけで、別のTXTが残っているわけではありません。
原因4：CNAMEやワイルドカードが別の値を返している
削除したはずの名前で値が返る場合、その名前がCNAMEになっていないかを確認します。DKIMや証明書のDNS認証では、自分のゾーンにはCNAMEだけを置き、実際のTXTは外部サービスのゾーンに置く方式がよく使われます。
dig selector1._domainkey.example.com TXT応答に CNAME の行があれば、見えているTXTは参照先のものです。自分のゾーンでTXTを探しても見つからず、値を止めるにはCNAMEを削除するか、参照先のサービスで設定を変える必要があります。
もう一つは、*.example.com のようなワイルドカードのTXTです。TXTを削除した結果、その名前に他のレコードが何も無くなると、名前自体が存在しない扱いになり、ワイルドカードのTXTが代わりに返されます。名前に他のレコード（AやCNAME）が残っている場合はワイルドカードは使われません。ゾーンにワイルドカードがあるかを管理画面で確認してください。
原因5：自動で作り直されている
レンタルサーバーやメールサービスの中には、SPFやDKIMのTXTを自動で管理するものがあります。管理画面のメール認証の設定や、ドメイン設定の操作をきっかけに、削除したTXTが再作成されることがあります。
削除してしばらくしてから値が戻っている場合は、この可能性を疑います。そのサービスでメール認証を自動設定する機能を止められるか、または自動で書かれる内容を前提に他の設定を合わせるかを判断します。自分でゾーンファイルを管理している場合は、構成管理ツールやスクリプトが古い内容で上書きしていないかも確認します。
原因6：ゾーンの変更が権威サーバー全体に届いていない
BIND などで自分でゾーンを管理している場合、ゾーンファイルの行を消しても、SOAのシリアル番号を増やしていないとセカンダリサーバーに変更が伝わりません。NSが複数ある場合は、すべての権威サーバーで確認します。
for ns in $(dig example.com NS +short); do
echo "== $ns"; dig @$ns example.com SOA +short; dig @$ns example.com TXT +short
doneサーバーごとにSOAのシリアル番号が違えば、転送が止まっています。シリアルを増やし、named-checkzone で構文を確かめてから読み込み直してください。
削除が反映された後に確かめること
権威サーバーと公開DNSの両方で値が消えたら、削除の影響を確かめます。SPFやDKIMを整理した場合は、外部のメールアドレスへテストメールを送り、受信したメールの Authentication-Results ヘッダーで認証結果が pass になっているかを確認します。WordPressのお問い合わせフォームなど、サイトから送るメールも同様に確かめておくと安心です。
所有確認用のTXTを消した場合は、該当サービスの管理画面で確認状態がどうなっているかを、数日後にも見ておきます。DNSサービスやメールサービスの画面構成は（2026年10月現在）頻繁に変わるため、手順に迷ったら各サービスの最新のドキュメントを参照してください。
まとめ
- 消す前に、そのTXTがSPF・DKIM・DMARC・所有確認のどれかを確かめ、値を控えておく
- 権威サーバーで消えていて公開DNSに残るならキャッシュ。TTLの残りが0になるまで待つ
- 権威サーバーでも返るなら、NSの指す先・同名の別の値・CNAMEやワイルドカード・自動再作成・ゾーン転送の順に確かめる
- 長い値が分割表示されているのは1つのTXTで、別のレコードではない
- 反映後はメールの認証結果とサービスの確認状態を確かめる