DNSが反映されないときの確認方法｜設定を直す前に見る2つの答え
結論 — 権威サーバーに新しい値があるなら、設定を触り直さないでください
SiteKensaの診断結果で「反映待ち」と表示された方への結論を先に書きます。
ネームサーバーには、すでに新しい値が登録されています。設定作業自体は完了しています。まだ反映されていないように見えるのは、代表的な公開DNSリゾルバの側に、古い答えが一定時間残っているためです。この状態で対象の項目を触り直す必要はありません。設定を保存し直したり、値を消して入れ直したりすると、正しかった設定を上書きしてしまい、かえって反映を遅らせることがあります。しばらく時間を置いてから、もう一度診断してください。
以降は、この状態がなぜ起きるのか、他の状態とどう見分けるのかを、検索でこのページに来た方向けに説明します。
この記事が扱う範囲
この記事で扱う「反映」は、SiteKensaの診断が比較している3項目に限られます。
- SPFレコード — ドメイン本体のTXTレコードのうち、
v=spf1から始まるもの - DMARCレコード —
_dmarc.ドメイン名のTXTレコードのうち、v=DMARC1から始まるもの - MXレコード
ドメイン所有権の確認に使うTXTレコード（google-site-verification= のようなもの）や、AレコードやCNAME、NSレコードは比較の対象外です。これらのレコードが反映されているかどうかを知りたい場合、この記事の方法では判断できません。
まず2つの答えを確認する
「反映されているかどうか」は、DNSの問い合わせ先によって答えが変わります。次の2つを区別してください。
権威サーバーは、そのドメインの設定を実際に持っているサーバーです。ネームサーバーの管理画面で設定を保存すると、現在、権威サーバーが公開している値がその内容に変わります。ここには常に最新の設定が入っています。
再帰リゾルバは、私たちが普段使っているDNSサーバーです。契約しているプロバイダのものや、Google Public DNSのような公開サービスがこれにあたります。再帰リゾルバは権威サーバーに問い合わせた結果を一定時間覚えていて、覚えている間は権威サーバーに聞き直さずに、覚えている答えをそのまま返します。
多くの診断ツールは再帰リゾルバにしか問い合わせないため、権威サーバーには正しい値が入っているのに「設定されていません」と表示されることがあります。SiteKensaはこの2つを両方問い合わせて比較するため、反映待ちと未設定を区別して表示できます。
結果の読み方
権威サーバーと再帰リゾルバの値の組み合わせで、状態は次のように分かれます。
| 権威サーバー | 再帰リゾルバ | 状態 | すべきこと |
|---|---|---|---|
| 値あり | 同じ値あり | 一致 | 確認した2経路では反映済みです。他のリゾルバに古い値が残っている可能性はありますが、経過を待つ以外にすることはありません |
| 値あり | 値なし、または違う値 | 反映待ち | 権威サーバーには正しい値が入っています。触り直さずに待ってください |
| 値なし | 値あり | 古い値が残存 | 削除・変更した値が、一部の経路にまだ残っています。時間の経過で解消します |
| 値なし | 値なし | 未設定 | そもそも設定が入っていません。反映を待っているのではなく、追加が必要な状態です |
| 確認できず | 確認できず | 確認不能 | 問い合わせ自体がうまくいかなかっただけです。設定の良否とは無関係で、時間をおいて再確認してください |
「反映待ち」と「未設定」を混同しないことが重要です。SiteKensaでは、反映待ちの項目と未設定の項目が同時にある場合、それぞれ別の所見として表示します。反映待ちの項目は触り直す必要がなく、未設定の項目だけ追加の作業が必要です。この2つを同じ対応で扱うと、必要のない変更をしてしまったり、必要な設定を追加し忘れたりします。
原因は2つに分かれます
「反映されない」という状態は、実は仕組みが異なる2つの原因に分かれます。同じ説明では扱えません。
新しく設定した場合 — 「まだ存在しない」という答えが覚えられている
ドメイン本体にTXTレコードが今までひとつも無かった状態でSPFを追加した場合や、_dmarc というサブドメインをこれまで一度も設定していない状態でDMARCを追加した場合が該当します。
DNSでは、問い合わせた名前や種類のレコードが存在しないとき、その「存在しない」という答え自体も一定時間覚えられます。これは否定応答のキャッシュと呼ばれる仕組みで、RFC 2308ではこの否定応答を、名前そのものが無い場合（Name Error、§2.1）と、名前はあるが該当する種類のレコードが無い場合（No Data、§2.2）の2種類に分けています。
権威サーバーは、これらの否定応答を返すときにもSOAレコードを付けて返し、そのSOAレコードのTTLが否定応答の保持時間になります。このTTLは、ゾーンのSOAレコードのMINIMUMフィールドと、SOAレコード自体のTTLの、小さいほうから決まります（RFC 2308 §3）。SOAのMINIMUMフィールドは元々別の意味を持っていましたが、RFC 2308によって「否定応答に使うTTL」という意味に再定義されています（§4）。
つまり、レコードを追加する前に「まだ存在しません」という答えを一度でも受け取ったリゾルバは、そのTTL分の時間が経つまで、追加した後も古い答えを返し続けます。このTTLの長さはゾーンのSOA設定によって決まるため、一律の時間数では言えません。
参考までに、google.comの権威サーバーに実際に問い合わせたSOAレコードは次のとおりです。
google.com. 60 IN SOA ns1.google.com. dns-admin.google.com. 953810495 900 900 1800 60
先頭の 60 がこのSOAレコード自体のTTL、末尾の 60 がMINIMUMフィールドです。このドメインの場合はどちらも60秒なので、否定応答は60秒で消えます。ドメインによってこの値は異なるため、自分のドメインで同じ値になるとは限りません。
（この現象は「DNSの浸透」と呼ばれることがありますが、実際に起きているのは新しい設定が世界に広がっていくことではなく、各リゾルバが独立に持つ「まだ存在しない」という記憶が、それぞれ別のタイミングで消えていくことです。覚え方としては「反映」のほうが近い表現です。）
変更・削除した場合 — 古い値そのものが期限を迎えるまで残る
すでにSPFやDMARC、MXの値が存在していて、それを変更または削除した場合はこちらにあたります。
この場合は否定応答のキャッシュではなく、レコードそのものに設定されている通常のTTLが働いています。TTLは、そのレコードをどれだけの時間キャッシュしてよいかを示す値です（RFC 1035 §3.2.1）。変更前の値をすでに覚えているリゾルバは、そのTTLが切れるまで、変更後ではなく変更前の値を返し続けます。
新規追加と違う点は、負のキャッシュの保持時間（SOAのMINIMUM由来）ではなく、レコードごとに設定された個別のTTLで決まることです。TTLを短く設定していれば早く切り替わり、長く設定していれば時間がかかります。
自分で確認する方法
診断ツールで確認する
SiteKensaでドメイン名を入力すると、権威サーバーと再帰リゾルバ、両方の値を自動で取得して比較します。
「反映待ち」の所見には、次のような形式で両方の値が示されます。
SPF (TXT)
ネームサーバー上: v=spf1 include:_spf.example.jp ~all
公開DNSから見える値: (まだ見えない)
「ネームサーバー上」が権威サーバーの値、「公開DNSから見える値」が代表的な公開DNSリゾルバから見えている値です。この2行を見比べれば、権威サーバーには値が入っているのに公開DNS側にまだ届いていない、という状態が一目で分かります。
コマンドで確認する
同じ内容は、手元のパソコンからも確認できます。
まず、そのドメインの権威サーバー（ネームサーバー）を調べます。
dig NS example.jp
表示されたネームサーバーのいずれかを指定して、直接問い合わせます。@ の後にネームサーバーのホスト名を指定すると、そのサーバーに直接問い合わせられます。
dig @ネームサーバーのホスト名 TXT example.jp
dig @ネームサーバーのホスト名 TXT _dmarc.example.jp
dig @ネームサーバーのホスト名 MX example.jp
次に、公開DNSリゾルバに同じ内容を問い合わせます。SiteKensaが比較しているのはGoogle Public DNS（応答がない場合はCloudflare Public DNS）なので、同じサーバーを指定すると同じ経路を再現できます。
dig @8.8.8.8 TXT example.jp
dig @8.8.8.8 TXT _dmarc.example.jp
dig @8.8.8.8 MX example.jp
nslookupでも同じことができます。nslookup -type=txt example.jp ネームサーバーのホスト名 のようにサーバー名を指定すると、権威サーバーへの直接問い合わせになります。公開DNSリゾルバへの問い合わせでは、応答に「Non-authoritative answer」という表示が付きます。これは「権威サーバー本人からの回答ではない」という意味で、再帰リゾルバのキャッシュから返っていることを示しています。
2つの結果を見比べて、権威サーバー側にだけ新しい値がある場合は反映待ち、両方に値があって内容が一致していれば反映済み、権威サーバー側にも値が無ければ設定そのものが入っていない状態です。
権威サーバー側にも値が無い場合
権威サーバーへの問い合わせでも値が見つからない場合、反映待ちではなく、設定そのものが登録されていない状態です。この場合に確認すべきことが2つあります。
1つは、ネームサーバーの管理画面で保存した内容が、実際に保存されているかどうかです。事業者によっては、入力欄に値を入れただけでは保存されず、確認画面まで進む必要があります。
もう1つは、設定した画面が、実際に使われているネームサーバーのものかどうかです。ドメインを取得した事業者と、DNSを運用している事業者が別になっているケースは珍しくありません。お名前.comでドメインを取得し、エックスサーバーで運用している場合のように、ネームサーバーがサーバー会社のものになっているのに、ドメイン取得業者側の画面でレコードを追加しても、権威サーバー側には反映されません。まず dig NS の結果を見て、表示されたネームサーバーが、実際にレコードを設定した事業者のものかどうかを確認してください。
なお、原因が反映待ちや未設定ではなく、SPFやDMARCの内容そのものにある場合は、独自ドメインのメールが届かない原因は？で確認方法を解説しています。
この診断の観測範囲と限界
この比較には、次の限界があります。
代表的な公開DNSリゾルバとして問い合わせているのは、実際にはGoogle Public DNS1箇所です（応答が得られない場合のみCloudflare Public DNSに切り替えます）。世界中のすべての再帰リゾルバを確認しているわけではありません。この2つで一致していても、他のプロバイダのDNSキャッシュに古い値が残っている可能性はあります。
権威サーバーへの問い合わせは再帰しません。そのドメインのゾーン内にある名前しか解決できないため、SPFレコードに含まれる include の参照先など、他社のドメインにある設定はこの比較の対象外です。
「確認不能」という状態は、問い合わせ自体が失敗しただけで、設定が正しいかどうかとは無関係です。ネットワークの一時的な不調や、問い合わせのタイムアウトでも起こります。設定を疑う前に、時間をおいて再確認してください。
まとめ
反映待ちの状態は、権威サーバーにはすでに正しい値が入っている状態です。設定作業自体は完了しているため、この段階で触り直す必要はありません。
新しく追加した項目は、追加前の「存在しない」という答えが一定時間覚えられていることが原因で、保持時間はゾーンのSOA設定によって決まります。すでにあった値を変更・削除した項目は、その値自体の通常のTTLが切れるまで古い値が残ります。原因が異なるため、同じ言葉で説明しないことが大切です。
しばらく時間を置いてから、もう一度診断して確認してください。