SPFのptrメカニズムとは何か — そしてなぜ今なお950,631件のレコードに残り続けているのか？（2026年）

Q: ptrの代わりに何を使うべきですか？

自分が管理するサーバーにはip4:/ip6:ブロックを、あるいはプロバイダーが文書化したinclude:を使ってください。どちらも決定論的で、高速で、信頼できます。ptrにないものすべてです。

Q: ptrはSPFの10回ルックアップ上限に計上されますか？

はい。すべてのptrは、受信側がPermErrorで諦めるまでに実行する10回のDNSルックアップのうち、少なくとも1回を消費します。すでにinclude:メカニズムが積み重なったレコードでは、この死んだメカニズムこそが、あなたを上限超過に押しやる一撃になり得るのです。

公開日 2026-07-03

数値は2026-06-29時点 · methodology v7。 261百万件の採点済みドメインを横断した集計センサス。すべての数値は集計値であり、個々の事業者のレコードを示すものではありません。採点方法はこちらをご覧ください。

ptrは、逆引きDNSルックアップによって送信者を認可するSPFメカニズムです。そしてSPF規格そのものが2014年以来「使用しないこと」と述べてきました。それから12年、いまだに950,631件のドメインがこれを公開しています。これは、インターネット上に存在する139百万件のSPFレコードのうちおよそ146件に1件が、それらのドメインの一部が登録されるより前に仕様で非推奨とされたメカニズムを、依然として抱えている計算になります。

ptrは本来何をするはずだったのか

ptrはこう述べます。「逆引きDNSが自ドメインに戻って解決されるサーバーからのメールをすべて受け入れよ」。維持すべきIPリストが不要になるため、一見エレガントに聞こえます。しかし実際には、受信側は接続元IPの逆引きを行い、返ってきたホスト名を一つひとつ正引きで確認しなければなりません。RFC 7208（§5.5）は、これを平明な言葉で非推奨としています。このメカニズムは 「遅く、DNSエラー時には他のメカニズムほど信頼できず、.arpaネームサーバーに大きなリソース要求を課す」 とされ、「使用すべきではない（SHOULD NOT be used）」 と指示されています。

なぜ2026年になっても罠であり続けるのか

12年前に非推奨となったメカニズムが今なお問題となる理由は3つあります。

ルックアップ上限を消耗させる。 すべてのptrは、1回のチェックあたりDNSルックアップ10回というSPFの厳格な上限に計上されます。これは、いったん超過するとレコード全体をPermErrorで無効にしてしまう限界値です。何も確実には機能しないメカニズムが、あなたの本当に必要なinclude:メカニズムのための予算を、それでも消費してしまうのです。
予測不能に失敗する。 逆引きDNSは、たいていのネットワークで最も手入れのされていない片隅です。ptrルックアップがタイムアウトしたり正引き確認が失敗したりすると、あなたの正当なメールは、頼りにしていたはずのSPFパスを失います。
一部の受信側はまったく評価しない。 規格がこれを非推奨としているため、一部の実装は単純にptrを無視します。つまり、これが認可するはずだった送信者は、そもそも最初から保護されていなかったのです。

どこからやってくるのか

今日、ptrを自ら選んで使う人はほとんどいません。それは継承によってやってきます。2009年に書かれた設定ガイド、古いサーバー設定からコピーされたテンプレート、三度のホスティング移行を無傷でくぐり抜けた「動いている」レコード。これは、非推奨でありながら残存しているあらゆるメカニズムについて、私たちのセンサスが見出すパターンです。古い助言は死なず、ただコピー＆ペーストされていく。 ptrを抱えているドメインは不注意なのではありません。12年前に退役した指示に従っているだけなのです。

修正方法 — 無料、5分

自分のSPFレコードを見つける（dig TXT yourdomain.com、または無料でチェック）。
ptrが含まれていたら、どのサーバーがそれに依存していたかを特定する。
ptrを正確な形式に置き換える。自分が管理するサーバーにはip4:/ip6:ブロックを、あるいはプロバイダーが文書化しているinclude:を使う。
ついでに、レコードが本物の修飾子で終わっているかを確認する。~allと-allを参照。

よくある質問

SPFレコードにおけるptrとは何を意味しますか？ 逆引きDNSが自ドメインに解決されるサーバーをすべて認可します。RFC 7208 §5.5は2014年に、遅く信頼性に乏しいとしてこれを非推奨とし、使用すべきではない（SHOULD NOT be used）と述べています。それにもかかわらず、2026-06-29時点で950,631件のドメインがいまだにこれを公開しています。

SPFのptrメカニズムが有効な場面はありますか？ 今でも構文解析はされますし、一部の受信側は今なお評価します。しかし規格はあらゆる場合において非推奨とし、一部の受信側は無視し、そしてあなたの10回のDNSルックアップのうち1回を消費します。ptrが正解となる現代的な構成は存在しません。

ptrの代わりに何を使うべきですか？ 自分が管理するサーバーにはip4:/ip6:ブロックを、あるいはプロバイダーが文書化したinclude:を使ってください。どちらも決定論的で、高速で、信頼できます。ptrにないものすべてです。

ptrはSPFの10回ルックアップ上限に計上されますか？ はい。すべてのptrは、受信側がPermErrorで諦めるまでに実行する10回のDNSルックアップのうち、少なくとも1回を消費します。すでにinclude:メカニズムが積み重なったレコードでは、この死んだメカニズムこそが、あなたを上限超過に押しやる一撃になり得るのです。

あなたのレコードに潜む亡霊をチェック

12年前に非推奨となったメカニズムが、いまだにあなたのDNSに居座っている。それは、まさに誰も探そうとしない類のものです。探すのに要するのは30秒です。

あなたのドメインをチェック → · SPFを修正 → · SPFレコードが2つ＝1つもないのと同じ → · SPF成熟度モデル → · 集計データのみ。データはEU内で保存・処理されます。