PTRの問題を調べるには、まず実メールの送信に使われたIPを特定し、そのIPの管理者へ逆引き設定を確認します。WebサイトのDNSを編集できることと、送信IPの逆引きを変更できることは同じではありません。利用する配信サービスやホスティング会社の担当範囲を確かめてください。

最初に分ける条件

国内の制作会社が管理するWebサイトからメールを送る場合、サイトのIPとメールの送信IPが一致するとは限りません。外部SMTPを使っているなら、そのサービスの経路を調べます。管理画面に表示された接続情報だけでなく、届いた原文や配送ログで実際のIPを照合することが重要です。

Gmailの公式ガイドラインには、送信インフラの正引き・逆引きDNSに関する要件があります。PTRで名前が返ることだけでなく、その名前の正引きとの関係も確認します。独自の設定例を無理に当てはめず、共有の配信基盤か専用の基盤かをサービス提供者へ確認しましょう。

証拠を残す確認手順

調査記録には、送信時刻、利用経路、IP、逆引きの結果、関連する正引き結果を残します。設定が現在正常でも、障害時には別IPを使っていた可能性があります。複数IPから送信するサービスは、成功した一つだけを確認して全体が正常とまとめないようにします。

想定例として、日本語の問い合わせ自動返信が新サーバーへ移した後だけ拒否されるケースを考えます。ログで新IPのDNSに関する応答が見つかったら、サイトのMXを変更する前にサーバー管理者へ送信IPの設定を確認します。受信向けMXと送信IPの逆引きは役割が違うため、無関係な変更を避けられます。

共有サービスでは利用者が直接PTRを編集できないことがあります。その場合は、問題のIPと受信側の応答を提供者へ渡し、正式な対応を確認します。テストのためにIPを次々変えるのではなく、変更後の新しいメールで実際の配送経路と応答を確認し、他の通知への影響も記録してください。

PTRが整っていても、SPFやDKIM、受信者側の分類まで保証されるわけではありません。Inbox Checkで原文を確認できる場合も、その一通の経路の証拠として使います。DNSの正常性と配置は別々に報告し、他のIPや未測定の日本向けサービスについては未確認であることを示してください。

測定方法と対象の制約を読み、Inbox Checkのテスト対象を確認してください。標本結果は個々の実顧客への保証ではありません。