2026年6月12日

PTRレコードとDNSKEYレコードを併用する設定｜DNSSECで署名したドメインと逆引きを両立させる考え方

DNS・名前解決

PTRレコード（逆引き）とDNSKEYレコード（DNSSECの公開鍵）は、同じドメインの設定画面に並ぶことはありません。PTRはIPアドレス側の「逆引きゾーン」に、DNSKEYはドメイン名側の「正引きゾーン」に置かれるからです。そのため「併用」といっても1つのゾーンに両方を書く作業ではなく、別々のゾーンを、それぞれの管理者のもとで矛盾なく動かすことが目的になります。この記事では、両者の置き場所と関係を整理したうえで、VPSでメールを送るWordPressサイトを例に、DNSSECを有効にしても逆引きの確認が壊れないようにする設定順と確認方法を説明します。

PTRとDNSKEYはどこに置かれるのか

正引きゾーン（example.com）には、A・AAAA・MX・TXTなどのレコードが置かれます。DNSSECを有効にすると、このゾーンにDNSKEYが追加され、各レコードに署名（RRSIG）が付きます。親ゾーン（.com など）に登録したDSが、そのDNSKEYを指すことで検証の連鎖がつながります。

逆引きゾーンは、IPアドレスから作られる特別な名前の下にあります。IPv4の 203.0.113.10 なら 10.113.0.203.in-addr.arpa、IPv6なら ip6.arpa の下の名前です。このゾーンを管理しているのは、IPアドレスを割り当てた事業者（VPS事業者、クラウド事業者、回線事業者）であることがほとんどで、利用者は事業者の管理画面からPTRの値を指定します。

つまり、次のことがいえます。

example.com をDNSSECで署名しても、PTRレコードには署名が付かない
PTRに署名を付けるかどうかは、逆引きゾーンの管理者（多くは事業者）が決める
逆引きゾーンを自分に委任してもらっている場合に限り、自分で逆引きゾーンを署名できる

両者が関わり合う場面：正引きと逆引きの一致確認

PTRとDNSSECが実際に関わるのは、メールの受信側などが行う「正引きと逆引きの一致確認」（Forward-Confirmed reverse DNS、FCrDNS）です。受信側は次の2段階で確認します。

接続してきたIPアドレスのPTRを引き、ホスト名（例: mail.example.com）を得る
そのホスト名のA（またはAAAA）を引き、元のIPアドレスと一致するかを見る

2段階目の問い合わせは、DNSSECで署名された正引きゾーンに対して行われます。ここでDNSSECの設定に誤りがあり、検証するリゾルバが SERVFAIL を返すと、PTRは正しく設定されていても一致確認が失敗します。結果として、メールの受信拒否や迷惑メール判定につながります。

PTRとDNSKEYを「併用」するときに押さえるべき点は、ここに集約されます。逆引きが正しくても、正引き側のDNSSECが壊れていれば一致確認は通りません。

設定の順番

VPSから直接メールを送る構成で、これからDNSSECを有効にする場合を例に、設定の順番を示します。作業前に、正引きゾーンのエクスポートと、事業者の管理画面で設定しているPTRの控えを取っておいてください。

1. 正引きと逆引きの一致を先に整える

DNSSECを有効にする前に、FCrDNSが成り立っていることを確認します。問題を切り分けやすくするため、一度に変える箇所を減らすのが目的です。

# 逆引き：IPアドレスからホスト名
dig -x 203.0.113.10 +short
dig -x 2001:db8::25 +short

# 正引き：得られたホスト名からアドレス
dig mail.example.com A +short
dig mail.example.com AAAA +short

逆引きのホスト名を正引きすると元のアドレスに戻る状態になっていれば準備完了です。IPv6で送信している場合はIPv6の逆引きも必要です。送信に使うIPv6アドレスにPTRが無いのは、よくある見落としです。

2. 正引きゾーンでDNSSECを有効にする

DNSサービスの管理画面で署名を有効にし、表示されたDS（またはDNSKEY）をレジストラに登録します。自分でBINDを運用している場合は、BIND 9.16以降で使える dnssec-policy を使うと、鍵の作成と署名の更新を自動化できます。

zone "example.com" {
    type primary;
    file "/var/lib/bind/db.example.com";
    dnssec-policy default;
    inline-signing yes;
};

inline-signing の扱いはBINDのバージョンによって既定値が異なるため、利用中のバージョンのドキュメントで確認してください（2026年10月現在）。

3. 逆引きゾーンの署名は管理者を確認してから

逆引きゾーンが事業者の管理下にある場合、利用者が逆引きを署名することはできません。署名されているかどうかは、次のように確認できます。

dig -x 203.0.113.10 +dnssec | grep -E "PTR|RRSIG"
dig 113.0.203.in-addr.arpa DNSKEY +short

PTRの応答にRRSIGが付かなければ、逆引きは署名されていません。メールの一致確認で、逆引きの署名が求められることは一般的ではないため、通常はこの状態で問題ありません。

IPアドレスのブロックを自分に委任してもらっていて、逆引きゾーンを自分の権威サーバーで運用している場合は、正引きと同じ方法で逆引きゾーンも署名できます。このとき、DSを登録する先はレジストラではなく、逆引きゾーンの親を管理する組織（IPアドレスを割り当てたRIRや上位の事業者）になります。DS登録に対応しているか、どの手続きで受け付けているかは管理者ごとに異なるので、事前に確認してください。また、/24より小さい単位で委任されている場合はRFC 2317の方式（CNAMEを使った委任）になっていることが多く、署名の連鎖を組む手順はさらに複雑になります。

変更するときの注意

PTRのホスト名を変更するときは、正引きゾーンに新しいホスト名のA・AAAAを先に追加し、署名された応答が返ることを確かめてから、事業者の管理画面でPTRを書き換えます。順番が逆になると、一致確認が通らない時間が生まれます。マネージドDNSや dnssec-policy による自動署名なら追加したレコードはすぐ署名されますが、ゾーンファイルを手作業で署名している場合は、署名し直してから読み込む必要があります。

DNSSECの鍵を交換する（ロールオーバーする）ときは、DSとDNSKEYの対応が崩れると正引き全体が検証に失敗し、ウェブもメールも同時に影響を受けます。鍵の交換はDNSサービスの自動処理に任せるか、手順を確認したうえで、メールの送信量が少ない時間帯に行うのが無難です。

設定後の確認

DNSSECを有効にした後は、検証するリゾルバ経由で、メールのホスト名が正しく引けることを確かめます。

dig mail.example.com A +dnssec @1.1.1.1 | grep -E "flags|status"
delv mail.example.com A

status: NOERROR で、フラグに ad が付いていれば検証に成功しています。そのうえで、外部のメールアドレス（Gmailなど）へテストメールを送り、受信したメールのヘッダーで送信元IPと認証結果を確認します。Gmailの送信者向けガイドラインでは、送信元IPに正引きと逆引きが設定されていることが求められています。

WordPressからのメール送信は、サーバーから直接送るよりも、WP Mail SMTP などのプラグインで外部のメール送信サービスを使う構成の方が、到達率の面で扱いやすいことが多くあります。その場合、送信元IPはメール送信サービスのものになるため、PTRの管理は送信サービス側の責任になり、自分で管理するのは正引きゾーンのSPF・DKIM・DMARCとDNSSECになります。

まとめ

PTRは逆引きゾーン、DNSKEYは正引きゾーンにあり、同じゾーンには並ばない
正引きゾーンを署名してもPTRは署名されない。逆引きの署名は逆引きゾーンの管理者が決める
両者が関わるのは正引きと逆引きの一致確認。正引き側のDNSSECが壊れると、PTRが正しくても確認に失敗する
DNSSECの前にFCrDNSを整え、PTRの変更時は正引きのレコードを先に用意する
設定後は ad フラグとテストメールのヘッダーで確かめる