DNS の設定に誤りがあると、サイトが一部の人だけ表示されない、引っ越し後も古いサーバーにつながる、WordPress から送ったメールが迷惑メールになる、SSL 証明書の発行に失敗する、といった問題が起きます。どれも WordPress の管理画面からは原因が見えません。
この記事では、WordPress サイトのドメインの DNS 設定を dig コマンドで点検し、問題があれば直す手順を説明します。なお、「DNSAudit」という名前の WordPress プラグインは、2026年10月時点で wordpress.org のプラグインディレクトリに見当たりません。この記事ではプラグインを使わず、コマンドと無料の確認サービスで点検します。
準備：digを使えるようにする
dig は DNS に問い合わせて、返ってきた答えをそのまま表示するコマンドです。
# Ubuntu・Debian
sudo apt install bind9-dnsutils
# AlmaLinux・Rocky Linux
sudo dnf install bind-utils
# macOS は最初から入っています
dig -vWindows では PowerShell の Resolve-DnsName で同じ確認ができます（例：Resolve-DnsName example.com -Type MX）。ブラウザーだけで確認したい場合は、Google の Admin Toolbox Dig も使えます。
以下の例の example.com は自分のドメインに、ns1.example-dns.net などは自分のドメインのネームサーバーに置き換えてください。dig の結果の読み方は digでDNSを問い合わせる手順と結果の読み方 で詳しく説明しています。
点検する項目の一覧
| 項目 | 確かめること | 問題があると起きること |
|---|---|---|
| 1. NS の委任 | 親ゾーンと自分のゾーンで NS が一致し、全部が答える | 一部の人だけ名前解決できない |
| 2. A・AAAA | 今のサーバーの IP を向いている | 古いサーバーや別のサーバーにつながる |
| 3. TTL | 用途に合った長さになっている | 変更がなかなか反映されない |
| 4. メール | MX・SPF・DKIM・DMARC がそろっている | WordPress からのメールが届かない |
| 5. CAA | 使っている認証局が許可されている | SSL 証明書の発行・更新に失敗する |
| 6. 使われていないレコード | 解約したサービスを向く CNAME などが残っていない | サブドメインを第三者に乗っ取られる |
| 7. DNSSEC | 有効にしているなら DS と署名が合っている | 検証するリゾルバーで名前解決が失敗する |
| 8. 応答時間 | ネームサーバーの応答が遅くない | 初回アクセスの表示が遅れる |
1. NSの委任を確かめる
まず、ドメインのネームサーバー（NS）がどこかを確かめます。
dig example.com NS +short次に、親ゾーン（.com なら .com のネームサーバー）に登録されている NS と比べます。レジストラの管理画面で設定したネームサーバーが、ここに出ます。
# .com・.net の場合
dig @a.gtld-servers.net example.com NS +norec
# .jp の場合
dig @a.dns.jp example.jp NS +norec親ゾーンの答えは AUTHORITY SECTION に出ます。2つの結果を比べ、次の点を確かめます。
- 親ゾーンと自分のゾーンで、NS の顔ぶれが同じ
- 引っ越し前の古い DNS 事業者のネームサーバーが混ざっていない
さらに、各ネームサーバーに直接 SOA を問い合わせ、全部が答えること、シリアル番号（SOA の3番目の値）がそろっていることを確かめます。
for ns in $(dig example.com NS +short); do
echo "== $ns"
dig @"$ns" example.com SOA +short +norec
done答えないネームサーバーがある、シリアルが食い違う、という場合は、そのネームサーバーを NS から外すか、DNS 事業者に問い合わせます。古い NS が残っているときの調べ方は NSレコードの重複を解消する調査方法 を参照してください。
2. A・AAAAレコードの向き先を確かめる
ドメインと www が、今の WordPress サーバーの IP アドレスを向いているかを確かめます。
dig example.com A +short
dig example.com AAAA +short
dig www.example.com +short見落としやすいのは AAAA（IPv6）レコードです。サーバーを引っ越したときに A だけを書き換え、AAAA が古いサーバーを向いたままになっていると、IPv6 で接続する人だけが古いサーバーにつながります。新しいサーバーが IPv6 に対応していないなら、AAAA は削除します。
www は CNAME でドメインを向けるか、ドメインと同じ A・AAAA を設定します。WordPress の「設定」→「一般」のサイトアドレスが www ありか、なしかに合わせ、もう一方からはリダイレクトされることもブラウザーで確かめておきます。
Cloudflare などの CDN をプロキシとして使っている場合、A・AAAA には CDN の IP アドレスが返ります。その場合は、CDN の管理画面で配信元（オリジン）の IP アドレスが正しいかを確かめます。
3. TTLを見直す
TTL は、リゾルバーが答えをキャッシュしてよい秒数です。権威ネームサーバーに直接問い合わせると、設定どおりの値が見えます。
dig @ns1.example-dns.net example.com A +norec +noall +answerexample.com. 3600 IN A 192.0.2.10 のように、2番目の数字が TTL です。
- 普段は 3600（1時間）程度で十分です。短すぎると、リゾルバーが頻繁に問い合わせに来るため、名前解決に時間がかかる回数が増えます
- サーバーを引っ越す予定があるときは、切り替えの前に TTL を 300 程度に下げておきます。下げる作業は、もとの TTL の時間以上前に済ませておく必要があります（もとの TTL が 86400 なら1日以上前）
- 引っ越しが終わって落ち着いたら、TTL を元に戻します
変更が反映されないときの確認手順は DNSの変更が反映されない時の確認方法 にまとめています。
4. メール関連のレコードを確かめる
WordPress は、パスワードリセットやフォームの通知をメールで送ります。送信元のドメインに SPF・DKIM・DMARC がそろっていないと、受け取る側で迷惑メールと判定されやすくなります。
# 受信用のメールサーバー
dig example.com MX +short
# SPF（v=spf1 で始まる TXT）
dig example.com TXT +short
# DMARC
dig _dmarc.example.com TXT +short
# DKIM（selector の部分はメール送信サービスで決まる名前）
dig selector._domainkey.example.com TXT +short確かめる点は次のとおりです。
- SPF の TXT が1つだけである（
v=spf1で始まる TXT が2つあると、SPF の検査は失敗します） - WordPress のメールを送っている経路（Web サーバー自身、または SMTP サービス）が SPF に含まれている
- DMARC のレコードがある（まずは
v=DMARC1; p=none; rua=mailto:...で集計レポートを受け取り、問題がないことを確かめてから強めます）
設定方法は SPFレコードを設定してメールのなりすましを防ぐ方法 と WordPressのメールが届かない問題を解決する方法 を参照してください。
5. CAAレコードを確かめる
CAA レコードは、そのドメインの SSL 証明書を発行してよい認証局を指定するものです。
dig example.com CAA +short何も返らなければ、どの認証局でも発行できる状態です。CAA を設定している場合は、実際に使っている認証局が含まれているかを確かめます。Let's Encrypt を使っているなら 0 issue "letsencrypt.org" が必要です。CDN が証明書を発行している場合は、その CDN が使う認証局も許可しておかないと、証明書の更新に失敗します。詳しくは CAAレコードの設定方法 を参照してください。
6. 使われていないレコードを整理する
DNS 事業者の管理画面で、ゾーンのレコードを一覧（またはエクスポート）にして、1つずつ用途を確かめます。特に注意が必要なのは、解約した外部サービスを向いたままの CNAME です。
dig shop.example.com CNAME +short
dig $(dig shop.example.com CNAME +short) A +shortCNAME の向き先が名前解決できない、または解約済みのサービスを向いている場合、第三者がそのサービスで同じ名前を取得すると、自分のサブドメインで別のサイトを表示できてしまいます（サブドメインの乗っ取り）。使っていないレコードは削除します。
あわせて、検証用に作った test. や staging. のサブドメインが、パスワードなしで公開されたままになっていないかも確かめます。
7. DNSSECの状態を確かめる
dig example.com DS +short何も返らなければ、DNSSEC は使っていません。DS が返る場合は、署名が正しく検証できるかを確かめます。
dig @1.1.1.1 example.com A +dnssecflags: に ad が付いていれば、検証に成功しています。status: SERVFAIL が返る場合は、DS と DNS 事業者の鍵が合っていない可能性があり、検証するリゾルバーを使う人からはサイトが見えなくなっています。設定と直し方は WordPressサイトのドメインにDNSSECを設定する方法 を参照してください。
8. ネームサーバーの応答時間を測る
各ネームサーバーに直接問い合わせ、Query time を見ます。
for ns in $(dig example.com NS +short); do
echo "== $ns"
dig @"$ns" example.com A +norec | grep "Query time"
done数回測って、特定のネームサーバーだけ遅い、答えないことがあるといった傾向がないかを見ます。遅いネームサーバーや不安定なネームサーバーがある場合は、エニーキャストで世界中に拠点を持つ DNS サービスへの移行を検討します。
表示速度の面での最適化
DNS の名前解決は、ブラウザーがそのドメインに初めて接続するときに1回行われ、その後はキャッシュが使われます。そのため、DNS の設定だけで表示速度が大きく変わることは多くありません。効果があるのは次のような点です。
- CNAME を何段も重ねない：CNAME の先がさらに CNAME になっていると、その分だけ問い合わせが増えます
- 外部ドメインを減らす：ページが読み込む外部ドメイン（フォント・広告・解析タグなど）が多いほど、名前解決と接続の回数が増えます。使っていないタグやプラグインを外します
- よく使う外部ドメインに事前接続する：WordPress の
wp_resource_hintsフィルターで、<link rel="preconnect">を出力できます
<?php
// 子テーマの functions.php などに追加します
add_filter( 'wp_resource_hints', function ( $urls, $relation_type ) {
if ( 'preconnect' === $relation_type ) {
$urls[] = array(
'href' => 'https://fonts.gstatic.com',
'crossorigin' => 'anonymous',
);
}
return $urls;
}, 10, 2 );https://fonts.gstatic.com は例です。実際にページの表示で使っている外部ドメインだけを指定してください。使わないドメインに事前接続しても、無駄な接続が増えるだけです。
点検を続けるために
- DNS を変更したら、変更内容と日付を記録し、この記事の項目を確かめ直します
- サーバーの引っ越し、メール送信サービスの変更、CDN の導入・解約のときは、2・4・5・6 の項目を見直します
- DNSSEC を使っている場合は、外部から定期的に
dig @1.1.1.1 example.com A +dnssecでadが付くことを確かめると、設定の食い違いに早く気付けます
まとめ
- DNS の誤りは WordPress の管理画面からは見えないため、
digで直接確かめる - NS の委任、A・AAAA（特に古い AAAA の残り）、TTL、メール用レコード、CAA、使われていない CNAME、DNSSEC、応答時間の8項目を順に点検する
- 表示速度のための DNS の最適化は、CNAME を重ねない、外部ドメインを減らす、必要な外部ドメインに preconnect する、の3点が中心
関連記事: