PTR レコード(Pointer Record)
概要
PTR レコード(Pointer Record) は、IP アドレスからドメイン名を逆引きするための DNS レコードです。タイプコードは 12 で、RFC 1035 で定義されています。通常の DNS が「ドメイン名 → IP アドレス」(正引き)を解決するのに対し、PTR レコードは「IP アドレス → ドメイン名」(逆引き)を解決します。
PTR レコードには主に 3 つの用途があります。
- メールサーバーの送信元認証 — 受信サーバーが送信元 IP の正当性を検証する
- ネットワーク診断ツール —
tracerouteやpingで IP アドレスの代わりにホスト名を表示する - サーバーログの可読性向上 — IP アドレスの代わりにホスト名をログに記録する
メール送信の文脈では、PTR レコードの設定状況が直接配信率に影響します。2024 年 2 月から Google と Yahoo はすべての送信者に対して PTR レコード(FCrDNS)を必須化 しており、設定がないドメインからのメールは拒否またはスパム判定されます。
仕組み
PTR レコードは in-addr.arpa(IPv4)または ip6.arpa(IPv6)という特殊なドメインのゾーンに格納されます。
IPv4 の場合
IPv4 アドレスのオクテットを逆順に並べ、.in-addr.arpa を付与したドメイン名を構成します。
IP アドレス: 93.184.216.34
逆引き名: 34.216.184.93.in-addr.arpa.
このドメインへの DNS 問い合わせに PTR レコードが返す値が、そのアドレスに対応するホスト名です。
34.216.184.93.in-addr.arpa. IN PTR mail.example.com.
IPv6 の場合
IPv6 は 128 ビットを 16 進数のニブル(4 ビット)単位で逆順に並べ、.ip6.arpa を付与します。完全展開した IPv6 アドレスの各桁を 1 文字ずつドット区切りで逆順にする形式です。
IPv6 アドレス: 2001:0db8:0000:0000:0000:0000:0567:89ab
完全展開: 2001:0db8:0000:0000:0000:0000:0567:89ab
逆引き名: b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR mail.example.com.
管理権限の委任
PTR レコードは通常のドメインの DNS 設定とは管理者が異なります。in-addr.arpa ゾーンの管理権限は、IP アドレスブロックの割り当て元(ARIN、RIPE NCC、APNIC などの地域インターネットレジストリ)から、そのアドレスを使用するホスティングプロバイダーへ委任されています。ドメインの所有者が自分で PTR レコードを設定することは原則できず、VPS や専用サーバーの場合はコントロールパネルや API で設定し、クラウドプロバイダー(AWS EC2、GCP など)でも各サービスの管理画面から設定を行います。
| プロバイダー | PTR 設定方法 |
|---|---|
| 一般的な VPS | コントロールパネルの逆引き設定画面 |
| AWS EC2 | Elastic IP の逆引き DNS 設定(申請フォーム経由) |
| GCP | プロジェクトの DNS 設定から逆引きゾーンを作成 |
| 共有ホスティング | 個別設定不可(IP を複数ユーザーで共有しているため) |
FCrDNS(Forward-Confirmed Reverse DNS)
PTR レコードが単に設定されているだけでは不十分な場合があります。セキュリティの文脈では FCrDNS(Forward-Confirmed Reverse DNS)と呼ばれる双方向検証が求められます。
# 正引き(A レコード)
mail.example.com. IN A 93.184.216.34
# 逆引き(PTR レコード)
34.216.184.93.in-addr.arpa. IN PTR mail.example.com.
この双方向が一致している状態が FCrDNS です。スパマーはゾンビコンピュータや乗っ取ったサーバーを使って送信するため、PTR は設定できても A レコードと整合させることができません。FCrDNS はこの非対称性を利用した信頼性検証の手法です。
メール配信への影響
2024 年 2 月以降、Google(Gmail)と Yahoo はすべての送信者に対して PTR レコード(FCrDNS)の設定を必須化しました。これは 2026 年現在も継続して適用されているベースライン要件であり、未設定の場合は配信拒否またはスパムフォルダに振り分けられます。
受信サーバーは次の順で検証を行います。
- 送信元 IP の PTR レコードを確認する(逆引きが存在するか)
- PTR が指すホスト名の A または AAAA レコードを確認する(正引きが元の IP を指しているか)
- PTR が指すホスト名と、メールの送信ドメイン(ヘロードメイン)が関連しているかを確認する
PTR レコードが mail.example.com. を指しているのに、実際の送信ドメインが attacker.net なら、FCrDNS は通過しますが DMARC で別途検証されます。PTR はあくまでも送信元 IP の正当性を示すものであり、SPF や DKIM と組み合わせて初めて完全な認証が成立します。
設定例
PTR レコードの設定はホスティングプロバイダーやクラウドの管理画面から行いますが、ゾーンファイル上の表記は次の通りです。
; IPv4 の PTR レコード
; 93.184.216.34 に対して mail.example.com を返す
34.216.184.93.in-addr.arpa. IN PTR mail.example.com.
; IPv6 の PTR レコード
; 2001:db8::1 に対して mail.example.com を返す
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR mail.example.com.
確認方法
特定の IP の逆引きを手動で確認する場合は dig -x を使います。
# IPv4 の逆引き確認
dig -x 8.8.8.8
出力の ANSWER SECTION に PTR レコードが表示されます。
;; ANSWER SECTION:
8.8.8.8.in-addr.arpa. 7118 IN PTR dns.google.
TTL フィールドの値(上記では 7118)がキャッシュの残り秒数です。
IPv6 の逆引きや、特定のネームサーバーを指定して確認することもできます。
# IPv6 の逆引き確認
dig -x 2001:4860:4860::8888
# Google Public DNS を使って外部から確認する
dig -x 8.8.8.8 @8.8.8.8
A レコードと PTR レコードの整合(FCrDNS)を確認する場合は次の手順を踏みます。
# 1. mail.example.com の A レコードを確認する
dig A mail.example.com
→ 93.184.216.34 が返ることを確認
# 2. その IP の PTR レコードを確認する
dig -x 93.184.216.34
→ mail.example.com. が返ることを確認
# 3. FCrDNS が成立していることを確認
# PTR の結果 (mail.example.com) の A レコードが元の IP と一致すれば OK
外部の視点からも確認したい場合は、Labee Dev Toolbox の IP API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/ip?ip=8.8.8.8"
レスポンスは次の形式で返ります。
{
"success": true,
"data": {
"ip": "8.8.8.8",
"type": "IPv4",
"isPrivate": false,
"ptr": "dns.google"
},
"error": null,
"meta": { "responseTime": 42 }
}
data.ptr に逆引き結果のホスト名が返ります。PTR レコードが設定されていない IP アドレスでは ptr が null になります。ip パラメーターを省略すると、リクエスト元(自分自身)の IP アドレスに対する結果が返ります。
よくある問題
PTR レコードの設定は IP アドレスの管理者に委ねられるため、ホスティング環境によっては制約があります。
PTR レコードが設定できない
共有ホスティングの場合、IP アドレスを複数ユーザーで共有しているため、PTR レコードを個別に設定することができません。メール送信専用のサーバーを別途用意するか、SendGrid や Postmark などの ESP(Email Service Provider)を使います。これらのサービスは自社の送信 IP に PTR レコードを設定済みで、SPF の include 設定で許可する形式をとります。
PTR が設定されているのにメールが届かない
PTR が存在していても FCrDNS が成立していない場合があります。PTR が指すホスト名の A レコードが元の IP を指していないケースです。プロバイダーのデフォルト PTR(例: 93-184-216-34.compute.example.com)を使っていて、そのホスト名の A レコードが存在しない場合に発生します。この場合は PTR を mail.送信ドメイン のような形式に変更し、A レコードと整合させます。
IP を変更したが PTR の反映が遅い
PTR レコードも通常の DNS レコードと同じく TTL でキャッシュされます。プロバイダーの管理画面で PTR を変更しても、旧 PTR の TTL が切れるまで古い値が返り続けます。メールサーバーの IP 移行時には PTR の TTL を事前に確認し、短縮しておくことが望ましいです。
クラウドプロバイダーの Elastic IP と PTR
AWS の Elastic IP や GCP の External IP に PTR レコードを設定する場合、サービスごとに手順が異なります。AWS では EC2 インスタンスの「逆引き DNS」設定から申請フォームを経由する手順が必要で、即時反映はされません。GCP はプロジェクトの DNS 設定から逆引きゾーンを作成する形式をとります。いずれの場合も、PTR を設定できる IP は使用中のアカウントに紐づいたものに限られます。