PTRレコード（逆引きDNS）

この用語をシェア

PTRレコードとは

PTRレコード（Pointer Record）は、IPアドレスからホスト名を逆引き（Reverse DNS／rDNS）するDNSレコードです。通常のDNSレコード（Aレコード・MXレコードなど）が「ドメイン名からIPアドレスを引く」正引きであるのに対し、PTRレコードはその逆方向、「IPアドレスからドメイン名（ホスト名）を引く」ために存在します。DNSの基本仕様であるRFC 1035で定義されている、DNSレコードタイプの中でも最も古くから存在するものの一つです。

メールサーバー運用の文脈でPTRレコードが特に重視されるのは、SMTPには「送信元を自己申告する」という構造的な弱点があるためです。SMTPのHELO/EHLOコマンドや送信元メールアドレスのドメインは、送信側が自由に名乗れてしまいます。そこで受信側メールサーバーは、DNSという第三者（送信者が単独では書き換えられない台帳）に問い合わせて送信元IPアドレスの逆引き結果を取得し、「名乗っている送信元と、DNS上の登録内容に食い違いがないか」を検証する材料として利用します。PTRレコードが未設定、あるいは内容が実態と食い違っている場合、受信側メールサーバーはそのIPアドレスからのメールを配信不可能なメールサーバーからの通信とみなし、拒否またはスパムとして扱う可能性が高くなります。

仕組み・詳細解説

正引き（Aレコード）と逆引き（PTRレコード）の非対称性

正引きはドメイン名を起点に権威DNSサーバーへ問い合わせますが、逆引きは仕組みが異なります。IPアドレスにはドメインのような所有者による直接管理の仕組みがないため、DNSではin-addr.arpaという特別な逆引き専用ドメイン配下に、IPアドレスを構成する各オクテットを逆順に並べたゾーンを作り、そこにPTRレコードを登録するという設計になっています。この非対称性のため、Aレコードは自分が管理するドメインのゾーンファイルに自由に追加できる一方、PTRレコードはそのIPアドレスブロックの管理者（多くはISPやクラウド事業者）が管理するゾーンに登録する必要があり、利用者側だけで完結しない点が実務上の大きな違いになります。

in-addr.arpaゾーンによる逆引き解決の流れ

IPv4アドレス 192.0.2.10 を例にすると、DNS上では次のようにオクテットを逆順にした名前として扱われます。

# IPアドレス 192.0.2.10 の逆引き名
10.2.0.192.in-addr.arpa.

# ゾーンファイルでのPTRレコード定義例
10.2.0.192.in-addr.arpa. IN PTR mail.example.com.

名前解決の際は、ルートDNS → arpa. → in-addr.arpa. → 2.0.192.in-addr.arpa.（多くの場合ここがISP・クラウド事業者に委任されているゾーン）という順に権威委任をたどり、最終的に該当IPアドレスに紐づくPTRレコードへ到達します。この「委任チェーンの末端を管理しているのが利用者ではなくIPアドレスの割り当て元である」という構造が、PTRレコードの設定を自社DNSサーバー側だけでは完結できない理由です。

FCrDNS（Forward-Confirmed reverse DNS）検証プロセス

受信側メールサーバーが行う代表的な検証がFCrDNSです。送信元IPアドレスを逆引きしてホスト名を取得し、そのホスト名を今度は正引きして、得られたIPアドレス群の中に元の送信元IPアドレスが含まれるかを確認します。両者が一致した場合のみ「正引きで裏付けが取れた逆引き」として信頼度が上がります。

# 1. 逆引き: IP → ホスト名
192.0.2.10 → mail.example.com

# 2. 正引き: ホスト名 → IP（逆引きで得たホスト名を再度引く）
mail.example.com → 192.0.2.10

# 3. 突き合わせ
# 元の送信元IPが正引き結果に含まれていれば FCrDNS 検証成功

ここで重要なのは、FCrDNSは「PTRレコードとAレコードの両方を、送信者側で整合させて初めて成立する」検証だという点です。PTRレコードだけ設定してAレコード側のホスト名が異なる、あるいはその逆といった片手落ちの設定は、FCrDNS不一致としてそのまま評価を下げる要因になります。

IPv6とip6.arpaによる逆引き

IPv6アドレスの逆引きはip6.arpaドメインを使用し、128ビットのアドレスを4ビット（1桁の16進数）単位・ニブル単位で逆順に並べた、非常に長いドメイン名で表現します。

# IPv6アドレス 2001:db8::1 の逆引きゾーン名（一部省略せず展開した例）
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.

桁数が多く手作業でのゾーンファイル管理は煩雑になりやすいため、実務ではゾーン生成ツールやクラウド管理コンソールでの自動生成に頼るのが現実的です。IPv6でメール送信を行う場合、主要な受信側メールサーバーはIPv4以上に逆引き・FCrDNSの整合を厳しく見る傾向があるとされ、IPv6アドレスからの送信を計画する際はPTR設定を後回しにしないことが定石です。

具体例・ユースケース

ケース1: 自社構築Postfixメールサーバーでの新規PTR設定

固定グローバルIPを1つ取得し、そのIP上にPostfixで自社ドメインのメールサーバーを構築する典型的なケースです。まずAレコードでmail.example.comをそのIPに向け、続いてIPアドレスの割り当て元（データセンター事業者やISP）に対してPTRレコードの設定を依頼し、mail.example.comを指すよう登録します。PostfixのmyhostnameもこのFQDNに一致させておくことで、HELO名・Aレコード・PTRレコードの三点が揃い、FCrDNS検証も含めて整合が取れた状態になります。実務では、この三点のどれか一つでもズレていることに気づかず「メールが届かない」原因調査が長引くケースが少なくありません。

ケース2: 共有ホスティング・レンタルサーバーでの制約

1つのIPアドレスを多数の利用者で共有するレンタルサーバー・共有ホスティングでは、PTRレコードもホスティング事業者側のホスト名（例: server123.hosting-provider.example）に固定されていることが一般的です。この場合、利用者が独自ドメインでメールを送っても、PTRレコードは自社ドメインと一致しないため、FCrDNSは成立しません。多くの受信側メールサーバーはこの状態を直ちにスパムとは判定しないものの、送信量が多い・評判の悪い共有IPと同居している場合は配信率に影響しやすく、本格的にメール送信を行いたい場合は専用IPアドレスの利用を検討すべき典型例です。

ケース3: クラウド環境（AWS/GCP/Azure）からの送信

クラウドの動的グローバルIP（Elastic IPなど）からメールを送信する場合、既定では逆引きがクラウド事業者のドメイン（例: ec2-xxx-xxx-xxx-xxx.compute.amazonaws.comのような形式）を指しており、自社ドメインとは一致しません。多くのクラウド事業者は、迷惑メール対策のため新規アカウントのSMTPアウトバウンド（25番ポート）自体を制限しており、PTR設定の申請とあわせて送信解禁の申請が必要になる場合があります。一般に、AWSではサポートセンター経由で該当Elastic IPに対する逆引きDNSレコードの変更を申請する運用が案内されており、申請時に送信目的やドメインの正引き設定状況の説明を求められることがあります。GCPやAzureでも、コンソールやサポート経由でのリクエストが必要になる場合がある点は共通しています。

メリット・デメリット（注意点）

観点	メリット	デメリット・注意点
メール到達率	正しく設定・FCrDNSが一致していれば、受信側の初期フィルタで弾かれるリスクを下げられる	PTRレコードだけでは不十分で、SPF/DKIM/DMARCなど他の認証技術と組み合わせないと十分な信頼性は得られない
管理コスト	一度設定すればゾーン変更頻度は低く、運用中に何度も触る必要がない	自社DNSだけで完結せず、IPアドレスの割り当て元（ISP/クラウド事業者）への申請が必要になり、変更に時間がかかることがある
信頼性の可視化	ホスト名からIPの正当性を推測できるため、ログ調査やセキュリティ監査でも有用な情報になる	共有IP環境では設定を利用者側でコントロールできず、意図せず評判の悪いIPと同居してしまうことがある
IPv6対応	IPv6でも同様の仕組み（ip6.arpa）で信頼性検証が可能	ゾーン名が非常に長くなり、手動管理でのミスが起きやすい。ツールや自動生成に頼る必要がある

混同されやすい用語・類似技術との違い

PTRレコード と Aレコード

AレコードはFQDNからIPアドレスを引く正引き用のレコードで、ドメイン管理者が自身のDNSサーバー上で自由に追加・変更できます。一方PTRレコードはIPアドレスからFQDNを引く逆引き用で、管理権限はそのIPアドレスの割り当て元にあります。両者は対になっていますが、管理主体も更新可能性も別物であるという点を混同しないことが重要です。

PTRレコード と SPF/DKIM

SPFは「そのドメインからのメールを送ってよいIPアドレスの一覧」をDNSのTXTレコードとして送信ドメイン側が公開する仕組み、DKIMはメール本文・ヘッダーに電子署名を付与し改ざん検知を行う仕組みです。いずれも送信ドメインの管理者が自分のDNSゾーンだけで完結して設定できます。対してPTRレコードは送信元IPアドレスを起点とした検証であり、設定主体もIPアドレスの割り当て元というまったく異なるレイヤーの仕組みです。「SPF/DKIMを設定したのでPTRは不要」という誤解は実務でしばしば見られますが、多くの受信側メールサーバーはPTR・SPF・DKIM・DMARCを別々の観点として組み合わせて評価するため、どれか一つで代替できるものではありません。

PTRレコード と RBL（ブラックリスト）

RBL（Realtime Blackhole List）は、スパム送信元として報告・観測されたIPアドレスやドメインを蓄積したリストで、外部の運営団体が管理しています。PTRレコードの有無・整合性はDNSの仕組みそのものの検証であるのに対し、RBLは「過去の送信実績・評判」に基づくブラックリスト方式の検証です。PTRレコードが正しく設定されていても、スパム送信の実績があるIPアドレスはRBLに掲載され得ますし、逆にPTRが未設定でもRBLに未掲載であることもあります。両者は独立した検証軸であり、メール到達率を上げるにはPTR・RBL双方の状態を確認する必要があります。

rDNS（逆引きDNS）とFCrDNSの違い

「rDNS」はPTRレコードによる逆引きという仕組みそのものを指す一般名称です。一方「FCrDNS」は、その逆引き結果をさらに正引きし直して元のIPアドレスと突き合わせる、一段階踏み込んだ検証手法を指します。単にPTRレコードが「設定されているだけ」で満足せず、FCrDNSまで一致させて初めて多くの受信側メールサーバーから高い信頼度を得られる、という段階の違いを理解しておく必要があります。

PTRレコードの設定

DNSゾーンファイル形式

# 192.0.2.10 の逆引き設定（逆引きゾーンを自社で権威管理している場合）
10.2.0.192.in-addr.arpa. IN PTR mail.example.com.

# TTLを明示する場合
10.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.

IPアドレスの逆順変換

PTRレコードでは、IPアドレスの各オクテットを逆順にし、末尾にin-addr.arpaを付けます：

• 通常表記: 192.0.2.10
• 逆引き名: 10.2.0.192.in-addr.arpa

末尾のホスト名（PTRレコードの値）には、複数の値を登録することも技術的には可能ですが、実務上は1つのIPアドレスに対して1つのホスト名を登録し、そのホスト名を指すAレコードと完全に対にしておくのが定石です。複数登録するとFCrDNS検証の際にどのホスト名で正引きすべきか受信側の実装依存になり、かえって信頼性を損なうことがあります。

クラウド環境・VPSでの設定

VPS/クラウドでは、PTRレコードの設定方法がプロバイダーによって大きく異なります。多くの場合、自社の権威DNSサーバーではなく、IPアドレスを割り当てている事業者側の逆引きゾーンを変更してもらう必要があります。

• AWS EC2: 一般に、AWSサポートセンターから該当Elastic IPに対する逆引きDNSの変更をリクエストする運用が案内されています。事前にそのIPを指すAレコードを正しく設定しておくことが前提条件になります。
• Azure: パブリックIPリソースの設定項目からリバースDNS（PTR）を直接指定できる場合があります。
• GCP（Compute Engine）: 標準の外部IPには既定のリバースDNS名が割り当てられており、独自ドメインへの変更には申請や条件（ドメイン所有の確認など）が必要になる場合があります。
• 国内VPS・レンタルサーバー各社: コントロールパネルから直接設定できる事業者と、サポート窓口への申請が必要な事業者に分かれます。契約前に「PTRレコードを自社で設定できるか」を確認しておくと、後になって専用IPへの移行を迫られる事態を避けられます。

PTRレコードの確認方法

コマンドラインでの確認

# 逆引き確認（digコマンド）
dig -x 192.0.2.10 +short
# → mail.example.com. のように表示されれば設定済み

# nslookupでの確認
nslookup 192.0.2.10

# hostコマンドでの簡易確認
host 192.0.2.10
# → 10.2.0.192.in-addr.arpa domain name pointer mail.example.com. のように出力される

# FCrDNS検証（逆引き結果を正引きし直して突き合わせる）
dig mail.example.com +short
dig -x 192.0.2.10 +short

PTRレコードが未設定の場合、dig -xの応答はANSWERセクションが空（ANSWER: 0）になります。ゾーンの権威サーバーへの問い合わせがタイムアウトする場合は、逆引きゾーン自体が正しく委任されていない可能性を疑います。

オンラインツール

• MxToolboxのReverse Lookupツールで、PTRレコードの有無とFCrDNSの一致状況をまとめて確認できます。
• DNSCheckerのPTR Lookupのように、複数拠点からの問い合わせ結果を比較できるツールもあり、DNS変更直後の伝播状況の確認に有用です。

自社メールサーバー運用への応用

設定手順

1. IPアドレスの固定: 動的IPではなく静的（固定）グローバルIPアドレスを取得する
2. 正引き設定: mail.example.com → 192.0.2.10（Aレコード）を自社DNSゾーンに登録する
3. 逆引き申請・設定: IPアドレスの割り当て元に対し、192.0.2.10 → mail.example.com（PTRレコード）の設定を依頼する
4. 整合性検証: digコマンド等でFCrDNSが一致していることを確認する
5. 送信テスト: 実際にGmail等の主要プロバイダー宛にテストメールを送り、ヘッダーやSPAM判定結果を確認する

PostfixでのHELOホスト名・受信側チェックの設定

自社がメールを送信する側としては、PostfixのHELO名をPTR/Aレコードと完全に一致させておくことが基本です。

# /etc/postfix/main.cf - 送信時のHELO名をPTRレコードと一致させる
myhostname = mail.example.com
smtp_helo_name = $myhostname

逆に、自社がメールを受信する側として相手のPTRレコードを検証したい場合は、smtpd_recipient_restrictionsやsmtpd_client_restrictionsに逆引き関連の制限を追加できます。

# /etc/postfix/main.cf - 受信時に相手のPTR/逆引きを検証する例
smtpd_client_restrictions =
    reject_unknown_client_hostname
    permit

# より緩やかに「逆引きは通るが正引きと不一致」なホストのみ拒否したい場合
smtpd_client_restrictions =
    reject_unknown_reverse_client_hostname
    permit

reject_unknown_client_hostnameはPTRレコード自体が存在しない、またはFCrDNSが不一致のクライアントを拒否する厳しめの設定です。正当だが逆引き未整備な送信元まで巻き込んでしまうリスクがあるため、いきなり本番投入せず、まずはwarn_if_rejectを付けてログのみ出力する運用や、postscreenのpostscreen_dnsbl_*系設定と組み合わせた段階的な検証がすすめられます。なお、DovecotはIMAP/POP3でのメール受信（メールボックスアクセス）やLMTPでのローカル配送を担うソフトウェアであり、SMTPの送信元IPに対するPTR検証そのものには関与しません。PTR/FCrDNSの検証はあくまで外部からのSMTP接続を受け付けるPostfix（あるいはExim、Sendmailなど）側の責務である、という役割分担を混同しないようにします。

トラブルシューティング

よくある問題と対処

• PTRレコード未設定: ISPまたはホスティング事業者にPTRレコードの設定を依頼します。依頼時は対象IPアドレスと、設定したいFQDN（Aレコードで正引きできる状態にしておくこと）を明示します。
• FCrDNS不一致: PTRレコードが指すホスト名と、Postfixのmyhostname・実際のAレコードが食い違っていないか確認し、三者を統一します。
• 共有IPでの評判低下: 同じIPを使う他の利用者の送信品質に引きずられている可能性があります。専用（占有）IPアドレスへの移行や、送信専用のSMTPリレーサービスの利用を検討します。
• DNS変更が反映されない: TTL分の時間が経過するまでキャッシュが残ります。変更前のTTLが長く設定されていた場合、浸透までに数時間〜1日程度かかることがあるため、余裕を持ったスケジュールで作業します。
• 逆引きゾーンへの権限がない: サブネットの一部だけを事業者から割り当てられている環境では、CNAMEを使った逆引き委任（RFC 2317方式）が必要になる場合があります。事業者側のドキュメントで対応可否を確認します。
• IPv6送信でPTRが反映されない: ip6.arpaゾーンは階層が深く記述ミスが起きやすいため、まずIPv4と同じホスト名を指しているか、桁数や区切りに誤りがないかを確認します。

まとめ

PTRレコードは、メールサーバー運用に必須のDNS設定です。設定していない、あるいはFCrDNSが一致していない場合、多くの受信側メールサーバーでスパムとして扱われるリスクが高まります。PTRレコードの設定自体は自社DNSだけで完結せず、IPアドレスの割り当て元への申請が必要になる点を踏まえ、自社メールサーバーを構築する際はPTRレコード設定とFCrDNS検証を必ず行い、SPF/DKIM/MXレコード/RBLと組み合わせて、信頼性の高いメール送受信環境を構築しましょう。

よくある質問（FAQ）

この用語についてもっと詳しく

PTRレコードに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。