集中力を維持。スマートなメールアプリ。
高速かつクロスプラットフォームなメールアプリは、重要なことに集中できるように設計されています。
定義
💡 Reverse DNS lookup（逆引き DNS）: IP アドレスをドメイン名に戻して解決するプロセスで、通常の DNS の動作とは逆になります。 メールにおいては、受信サーバーが送信元 IP アドレスが本当に主張しているドメインに属しているかを確認する仕組みです。 通常の DNS はドメインから IP へと進みます。 逆引きDNS は IP からドメインへと戻ります。 両方向が一致する必要があります。
これはあなたに影響しますか？
おそらく直接は影響しませんが、その理由を知っておく価値はあります。
Gmail、Google Workspace、Outlook、または Microsoft 365 経由でメールを送信している場合、逆引きDNS は Google と Microsoft が自社の送信 IP 上で自動的に処理します。 あなたが触れることはありません。 Mailchimp や Klaviyo のようなプラットフォームの共有 IP でも同じです。 これらの ESP は、自社サーバーが送信する IP アドレスの PTR レコードを管理します。
逆引きDNS があなたの問題になるのは、（SendGrid や Mailgun のようなサービス経由で）専用 IP アドレスから送信している場合や、VPS やクラウドインスタンス上で自分のメールサーバーを運用している場合です。 そうした状況では、あなたの IP の PTR レコードは自動的に設定されません。 自分で設定する必要があります。 そして、それが欠けていたり設定が誤っていたりすると、メールの到達性が低下します。
実践的なチェック方法: メールがスパムに振り分けられていて、 DKIM、SPF、 DMARC レコードがすべて合格している場合、PTR レコードの欠落や不備は次に確認すべき論理的な項目です。
逆引きDNS lookup の仕組み
このプロセスは Forward-Confirmed reverse DNS（FCrDNS）と呼ばれます。 あなたのメールが受信サーバーに届いたときに起こることは次のとおりです。
受信サーバーは、あなたの送信元 IP アドレスを取得し、それに関連付けられた PTR（Pointer）レコードを DNS に問い合わせます。 このルックアップは in-addr.arpa と呼ばれる特別な DNS ゾーンに入ります。 PTR レコードが設定されていれば、ルックアップは mail.yourbusiness.com のようなホスト名を返します。
次に受信サーバーは、そのホスト名に対して通常の順引き DNS ルックアップを行い、元の IP に戻って解決されるかを確認します。 IP が一致すれば、チェックは合格です。 ホスト名が別の IP に解決されたり、PTR レコードがまったく存在しなかったりすると、送信者は信頼できないように見えます。
その双方向の検証がポイントです。 誰でも yourbusiness.com から送信していると主張できます。 しかし、PTR レコードと順引き DNS の両方を一致するように操作できる人ははるかに少ないのです。 Google と Yahoo が 2024 年に一括送信者の要件を厳格化して以来、Gmail は有効な PTR レコードを持たない IP に対して特定のエラー（421 4.7.23）を返すようになりました。 相応の量を送信する人にとって、もはや任意ではありません。
逆引き DNS の欠落や不一致は、最も見つけにくい到達性の問題のひとつです。 必ずしも明確なバウンスを生じるわけではありません。 あなたのメールは、説明もなく静かにスパムに振り分けられるだけかもしれません。
PTR レコードの確認方法
何かを修正しようとする前に、PTR レコードが存在するか、そしてそれが正しいかを確認しましょう。
MXToolbox: mxtoolbox.com/ReverseLookup.aspx にアクセスし、メールサーバーの IP アドレスを入力します。 PTR レコードを返すか、存在しなければフラグを立てます。
コマンドライン（Mac/Linux/Windows）：
nslookup [your IP address]
または Mac/Linux では：
dig -x [your IP address]
出力には、メールサーバーのホスト名を指す PTR レコードが表示されるはずです。 何も表示されない場合や、クラウドプロバイダーのデフォルトホスト名（ec2-203-0-113-25.compute-1.amazonaws.com）のような汎用的なものを指している場合は、修正する価値のある問題です。
PTR レコードの設定または修正方法
ほとんどの人が誤解している重要な点はこれです: PTR レコードは IP アドレスの所有者（ドメインレジストラーではなく、ホスティングまたは VPS プロバイダー）によって管理されます。
Cloudflare や GoDaddy で PTR レコードを設定することはできません。 DigitalOcean、Vultr、Hetzner、AWS、Linode、またはメールサーバーの IP が存在する場所を通じて設定します。
一般的な手順（セルフホストのメールサーバー）：
- ホスティングプロバイダーのダッシュボードにログインする
- ネットワークまたは IP 管理セクションを見つける（「Reverse DNS」または「PTR records」を探す。場所はプロバイダーによって異なります）
- サーバーの IP に対する PTR 値として、メールサーバーのホスト名（例: mail.yourdomain.com）を入力する
- 保存し、DNS の伝播に時間を与える（通常は 1 時間、場合によっては最大 48 時間）
- MXToolbox の逆引きツールを使って確認する
FCrDNS に合格するには、メールサーバーのホスト名が同じ IP に戻って解決される A レコードを持っていることも確認する必要があります。 両方向が機能しなければなりません。
ESP 経由で専用 IP を使用している場合: SendGrid、Mailgun、および同様のサービスには、ダッシュボード内に独自の逆引きDNS 設定フローがあります。 SendGrid の場合は、Settings > Sender Authentication > Reverse DNS にあります。 詳しい手順については SendGrid の逆引きDNS ガイドをご覧ください。 レコードを生成し、公開まで案内してくれます。
ESP 経由で共有 IP を使用している場合: プロバイダーが共有 IP の PTR レコードを処理します。 何も設定する必要はありません。
逆引きDNS を良好に保つ
汎用的なクラウドホスト名を避ける。 クラウドプロバイダーのデフォルト PTR は、「管理されたメールサーバー」ではなく「汎用的な VPS インスタンス」を示唆します。 受信サーバーはそれを注意信号として扱います。 それをあなたのドメインに一致するカスタムホスト名に置き換えましょう。
PTR は 1 つの層であり、スタック全体ではない。 良好な PTR は基本的な送信の正当性を確立するのに役立ちますが、DKIM、SPF、DMARC の代わりではなく、それらと併せて機能します。 完璧な PTR があっても DKIM がなければ、やはり苦戦します。 まず 3 つの認証層をすべて整えてから、PTR を確認しましょう。
インフラの変更後は必ず再確認する。 新しいサーバーに移行したり、新しい IP を取得したり、ホスティングプロバイダーを切り替えたりしても、PTR レコードは自動的には引き継がれません。 新しい IP に対して再設定する必要があります。 忘れやすいものです。 確認する価値があります。
IP ごとに 1 つの PTR レコードを、送信ホスト名を指すように設定する。 あなたの PTR レコードは、SMTP サーバーが SMTP 通信（HELO/EHLO コマンド）で宣言するのと同じホスト名に解決されるべきです。 不一致はスパムフィルターにとって一貫性がないように見えます。
関連用語