TXTレコードを変更するときは、同じ名前に並んでいる他のTXTを消さないよう現状を控え、TTLを下げてから対象の値だけを書き換え、権威DNSと公開DNSで新しい値を確かめます。SPFは1つのレコードの中身を編集し、DKIMの鍵は上書きせず新しいセレクターを追加して切り替えるのが、メールを止めない基本です。この記事では、変更の前に確かめること、用途ごとの書き換え方、変更後の確認方法を順に説明します。
変更の前に確かめること
どのDNSで管理しているか
TXTを書き換える場所は、ドメインのネームサーバーが指しているDNSサービスです。レジストラとホスティング会社の両方に管理画面がある場合、ネームサーバーが向いていない側で編集しても反映されません。
dig example.com NS +short返ってきたネームサーバーがどのサービスのものかを確かめてから、そのサービスの管理画面を開きます。
同じ名前にどんなTXTが並んでいるか
TXTは、1つの名前に複数のレコードを置ける型です。ドメインの頂点（example.com）には、SPF、検索エンジンやメールサービスの所有確認用の値などが並んでいることがよくあります。変更する前に、すべてを控えます。
dig example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answer
dig selector1._domainkey.example.com TXT +noall +answerDMARCは _dmarc、DKIMは セレクター名._domainkey という別の名前に置かれます。セレクター名はメールサービスごとに違うため、送信サービスの設定画面か、届いたメールのヘッダーにある DKIM-Signature の s= の値で確かめます。
管理画面のエクスポート機能や、上のコマンドの結果を保存しておけば、誤って消したときに元へ戻せます。
現在のTTL
出力の2列目がTTL（秒）です。変更した値が広く行き渡るまでの時間は、このTTLが目安になります。
変更の手順
1. TTLを下げておく
急ぎでなければ、変更の前にTTLを300秒程度へ下げ、元のTTL分の時間を待ちます。元が3600秒なら1時間後、86400秒なら翌日以降に本番の変更を行います。こうしておくと、書き換えた後に古い値がキャッシュに残る時間が短くなり、問題があったときの戻しも早く効きます。
2. 対象の値だけを書き換える
管理画面によって、TXTの扱いが違います。
- 1行に1つの値を持つ画面: 対象の行だけを編集します。同じ名前の他の行には触れません
- 1つのレコードに複数の値をまとめる画面: Route 53のように、同じ名前のTXTが1つのレコードの中に複数行で入っている形式では、編集した内容でレコード全体が置き換わります。他の値の行を消してしまわないよう、全行を確かめてから保存します
画面の項目名は、サービスの更新で変わることがあります（2026年10月現在）。名前欄に @ を入れるのか、空欄にするのか、example.com まで書くのかも、サービスごとの決まりに従ってください。
3. 値の書き方を確かめる
TXTの値で、つまずきやすいのは次の点です。
- 引用符: 管理画面では引用符を付けずに入力し、サービス側が付けるものが多い一方、付けて入力する前提のサービスもあります。二重に付くと値が壊れるため、保存後に
digで確かめます - 255文字を超える値: DNSでは1つの文字列が255文字までで、それより長いDKIMの公開鍵などは複数の文字列に分けて1つのレコードに入れます。自動で分けるサービスもあれば、分けて入力する必要があるサービスもあります
- 余分な空白や改行: コピーしたときに入った改行や前後の空白で、認証に失敗することがあります
BINDのゾーンファイルで管理している場合は、編集前にファイルのバックアップを取り、SOAのシリアル番号を上げてから読み込み直します。
example.com. 300 IN TXT "v=spf1 include:_spf.mail-provider.example ~all"
selector2._domainkey.example.com. 300 IN TXT ( "v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...(公開鍵の続き)" )named-checkzone example.com /var/named/example.com.zone
sudo rndc reload example.com用途ごとの書き換え方
SPF：1つのレコードの中身を編集する
SPF（v=spf1 で始まる値）は、1つの名前に1つだけ置く決まりです。送信サービスを追加・変更するときに、新しいSPFレコードを別に作ると、SPFが2つある状態になり、受信側で認証エラー（permerror）として扱われます。既存のレコードを開き、include: を足す・外す形で編集します。
また、SPFの評価中に発生するDNSの参照は10回までと決められています（RFC 7208）。include: を足していくと上限を超えやすいため、使っていない送信サービスの記述は、この機会に外します。
DKIM：新しいセレクターを追加してから切り替える
DKIMの鍵を変えるとき、同じセレクターの公開鍵を上書きすると、配送途中のメールや、古い鍵をキャッシュしている受信側で署名の検証に失敗することがあります。新しいセレクターで公開鍵を追加し、送信側の署名を新しいセレクターに切り替え、しばらく問題が無いことを確かめてから古いセレクターのレコードを削除する、という順で進めます。
多くのメールサービスは、鍵の更新を画面から行えるようになっており、そのときに登録するレコードを表示します。表示に従うのが一番安全です。
DMARC：方針を段階的に強める
DMARCの p=none を p=quarantine や p=reject に変えるのも、TXTの変更です。いきなり強めると、SPFやDKIMの設定が漏れている送信元のメールが届かなくなるおそれがあります。集計レポート（rua= で指定した宛先に届くもの）で、正規の送信元がすべて認証に通っていることを確かめてから段階的に変えます。
所有確認の値：新しい値が確認されてから古い値を消す
検索エンジンやメールサービスの所有確認用のTXTを入れ替えるときは、新しい値を追加して確認が完了するまで、古い値を残しておきます。古い値を先に消すと、確認が外れてサービスの設定が止まることがあります。
変更後の確認
まず、権威DNSに直接問い合わせ、キャッシュを通さない値を確かめます。
dig @ns1.example-dns.net example.com TXT +noall +answer
dig @8.8.8.8 example.com TXT +noall +answer権威DNSのすべてで新しい値が返り、公開DNSでも古いTTLが切れた後に新しい値が見えれば、変更は外から見える状態です。公開DNSで古い値が見える間は、TTLの残り時間（2列目の数字）が減っていくかを見ます。
メールに関わる変更なら、自分宛てに送ったメールのヘッダーにある Authentication-Results で、spf=pass、dkim=pass、dmarc=pass が付いているかを確かめます。WordPressサイトからのメールをWP Mail SMTPなどのプラグインで外部の送信サービス経由にしている場合は、そのサービスの設定画面にもドメイン認証の確認機能があることが多いので、合わせて使います。
問題が無ければ、下げたTTLを普段の値（3600秒前後など）に戻します。
まとめ
- 変更前に、同じ名前に並ぶTXTと、DMARC・DKIMの別名のTXTをすべて控える
- TTLを下げて待ってから書き換えると、反映も戻しも早く効く
- 複数の値をまとめる画面では、保存でレコード全体が置き換わる点に注意する
- SPFは1つのレコードを編集し、DKIMは新しいセレクターを追加してから切り替える
- 権威DNS、公開DNS、メールの認証結果の順に確かめ、最後にTTLを戻す