IP アドレスからホスト名を調べる逆引きは、delv -x IPアドレス で実行できます。delv は PTR レコードを引くと同時に、その答えが DNSSEC で検証できたかどうかを先頭の1行で示すため、「逆引きが設定されているか」と「その答えが改ざんされていないと確認できるか」を1回で見られます。この記事では、IPv4・IPv6 の逆引きの書き方、出力の読み方、正引きとの一致確認、設定されていないときの調べ方を順に説明します。
逆引きと PTR レコードの基本
逆引きでは、IP アドレスを逆順に並べた名前（IPv4 なら in-addr.arpa、IPv6 なら ip6.arpa の下）に置かれた PTR レコードを問い合わせます。たとえば 203.0.113.25 の逆引きは 25.113.0.203.in-addr.arpa の PTR を引くことと同じです。
ここで押さえておきたいのは、逆引きゾーンを管理しているのはドメインの持ち主ではなく、IP アドレスを割り当てている側だという点です。VPS やクラウドではサーバー事業者、自社回線ならプロバイダーが管理者で、ドメインの DNS 管理画面に PTR を追加しても逆引きには反映されません。設定の窓口は、事業者のコントロールパネルの「逆引き」や「リバース DNS」といった項目（名称は事業者によって異なります）か、サポートへの依頼になります。
WordPress の運用で逆引きが関わる主な場面は次のとおりです。
- サーバーから直接メールを送る構成で、受信側に迷惑メール扱いされないように PTR と正引きをそろえるとき
- アクセスログに残った IP が、名乗っているクローラー本人のものかを確かめるとき
- 不審なアクセス元の IP がどの事業者のものか、おおまかに見当をつけるとき
delv で逆引きする
delv は BIND に付属する問い合わせツールで、dig と同じパッケージ（Debian・Ubuntu では bind9-dnsutils、RHEL 系では bind-utils）に入っています。-x を付けると、逆順の名前の組み立てと PTR の指定を delv が代わりに行います。
# IPv4 の逆引き
delv -x 203.0.113.25
# IPv6 の逆引き（省略形のまま渡せる）
delv -x 2001:db8::25
# 問い合わせ先のキャッシュサーバーを指定する
delv @1.1.1.1 -x 203.0.113.25
# 署名（RRSIG）の表示を省いて読みやすくする
delv -x 203.0.113.25 +nodnssecIPv6 の逆引きでは、アドレスを4ビットずつ（16進数1桁ずつ）に分けて逆に並べた長い名前になります。手で組み立てると桁の数え間違いが起きやすいため、-x に任せるのが安全です。
出力はおおむね次の形になります（値は説明用の例です）。
; unsigned answer
25.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.com.1行目が検証結果、2行目が答えです。左から「問い合わせた名前、TTL、クラス、種別、値」の順に並び、値の mail.example.com. が逆引きの結果です。表示される TTL は問い合わせたキャッシュサーバーでの残り時間なので、ゾーンに設定された値より小さく見えることがあります。
1行目の検証結果の読み方
逆引きゾーンは DNSSEC で署名されていないことが多く、その場合は ; unsigned answer と表示されます。これは「署名がないゾーンの答え」という意味で、エラーではありません。逆引きが正しく設定されているかどうかは、2行目以降の PTR の値で判断します。
; fully validated と表示された場合は、ルートから逆引きゾーンまで署名のつながりを確認できたという意味です。IP アドレスの割り当て元が逆引きゾーンを署名している場合に表示されます。
検証に失敗すると、失敗した旨とその理由が表示され、PTR は表示されません。名前解決の問題か DNSSEC の問題かを分けるには、-i で検証を止めた結果と比べます。
delv -x 203.0.113.25 -i-i を付けたときだけ PTR が返るなら、逆引きゾーンの署名や親ゾーンとの DS の対応に問題があります。この場合、修正できるのは逆引きゾーンの管理者（サーバー事業者など）なので、実行したコマンドと出力を添えて問い合わせます。失敗した段階を詳しく見たいときは +vtrace で検証の過程を表示できます。表示の文言は BIND の版によって多少異なります。
逆引きが見つからないときの切り分け
PTR が設定されていない IP を引くと、答えの代わりに「存在しない」ことを示す否定応答の表示になります。版によって「negative response」や「resolution failed」に続けて nxdomain などの理由が出る形で、PTR の行はありません。次の順に確認します。
- IP アドレスを取り違えていないか：メールサーバーの送信元とウェブサーバーが別の IP のこともあります。送信元はメールヘッダーの Received 行、ウェブサーバーは事業者の管理画面で確認します。
- 設定してから時間がたっていないか：事業者の画面で設定しても、反映に時間がかかることがあります。また、設定前に一度引いていると「存在しない」という答え自体がキャッシュされ、しばらく残ります。
@で別のキャッシュサーバーを指定して比べます。 - 設定した場所が正しいか：前述のとおり、ドメイン側の DNS に PTR を書いても逆引きには効きません。
小さなアドレスブロックを割り当てられている場合は、逆引きが CNAME で別のゾーンへ振り向けられていることがあります（RFC 2317 の方式）。このとき delv の出力には CNAME の行が先に出て、その先の PTR が続きます。CNAME の先が引けずに止まっている場合は、振り向け先のゾーンを管理している側に確認します。
正引きと一致しているかを確かめる
逆引きの結果は、その IP の管理者が自由に書けるため、それだけでは信用できません。逆引きで得たホスト名をもう一度正引きし、元の IP に戻ることまで確かめるのが基本です。メールの受信側の多くもこの組み合わせを確認しています。
ip=203.0.113.25
# 逆引きでホスト名を得る
name=$(delv -x "$ip" +short +nodnssec | grep -v '^;' | head -n 1)
echo "PTR: $name"
# 得たホスト名を正引きして、元の IP が含まれるかを見る
delv "$name" A +short +nodnssec | grep -v '^;' | grep -qFx "$ip" && echo "一致" || echo "不一致"+short は値だけを表示する指定で、grep -v '^;' は版によって残ることがあるコメント行を除くためのものです。IPv6 の場合は A を AAAA に読み替えます。不一致になる典型は、サーバー移転後に PTR だけ古いホスト名のまま残っている場合と、ホスト名の A レコードを作り忘れている場合です。前者は逆引きの設定を、後者はドメイン側の DNS を直します。
アクセスログのクローラー確認でも考え方は同じです。たとえば Google は、IP の逆引きが Google のドメインになり、そのホスト名の正引きが元の IP に戻ることで本物と判断する方法を Google Search Central で案内しています。対象のドメイン名や公開されている IP 範囲の扱いは更新されることがあるため、確認の際は最新の案内を参照してください（2026年10月現在）。
つまずきやすい点
/etc/resolv.confの問い合わせ先がローカルのスタブリゾルバ（例：127.0.0.53）だと、検証に必要なレコードを中継しきれず失敗することがあります。@1.1.1.1のように外部のキャッシュサーバーを指定して比べます。- delv に
@で権威サーバーを指定すると、検証に必要な親ゾーンの情報もそのサーバーに求めることになり、失敗しやすくなります。権威サーバーの生の値を見たいときはdig @権威サーバー -x IP +norecurseを使い、delv は検証の確認に使うと整理しやすくなります。 - 古い delv は、組み込みのルートのトラストアンカーが現行のものと合わず検証に失敗することがあります。OS のパッケージを更新してから使ってください。
- 1つの IP に PTR が複数あると、受信側の扱いが一定しないことがあります。メール送信に使う IP は、PTR を1つにしてその正引きと対応させておくと判断がぶれにくくなります。
まとめ
delv -x IPアドレスで、IPv4・IPv6 どちらの逆引きも名前を組み立てずに実行できます。- 逆引きゾーンは署名されていないことが多く、
; unsigned answerは正常な表示です。PTR の値で設定の有無を判断します。 - 検証に失敗したら
-iと比べ、DNSSEC の問題なら逆引きゾーンの管理者に連絡します。 - PTR はドメインの DNS ではなく、IP を割り当てている事業者の側で設定します。
- 逆引きの結果は正引きで元の IP に戻るかまで確かめてから使います。