「逆引きDNSがSMTPバナーと一致しません」エラーの修正方法

自社メールサーバーを管理している場合、メール配信テスト中に「逆DNSがSMTPバナーと一致しません」というエラーが発生する可能性があります。この警告は単なる形式的なものではありません。これを無視すると、メールの信頼性が直接損なわれ、スパムフィルタリングが強化され、GmailやOutlookなどの主要プロバイダーがメッセージを完全に拒否する原因となります。

逆DNSはサーバーの身分証明書として機能し、SMTPバナーは握手として機能します。これら2つの識別子が一致しない場合、受信サーバーはメールを不審なものとして扱います。この不一致はサーバー管理の不備を示し、スパムインフラの一般的な特徴です。

「逆引きDNSがSMTPバナーと一致しない」とはどういう意味ですか？

「逆引きDNSがSMTPバナーと一致しません」とは、送信IPアドレスに関連付けられたホスト名（逆引きDNSまたはPTRレコード）が、メールサーバーがSMTP接続時に通知するホスト名（HELO/EHLO）と一致しないことを意味します。これらが一致しない場合、受信メールサーバーは接続を信頼できないと見なし、メールにフラグを立てたりブロックしたりする可能性があります。
これは2つのサーバー間の検証プロセスと考えてください。

逆引きDNS

標準DNSはドメイン名をIPアドレスに変換します。逆引きDNSはその逆の処理を行い、IPアドレスを見て「これに紐づく名前は何か？」と問い合わせます。PTRレコードがこの処理を担当します。

SMTP バナー (HELO/EHLO)

サーバーが別のサーバーへの接続を開始する際、SMTPバナーと呼ばれる挨拶で自己紹介します。この挨拶にはホスト名（例：mail.example.com）が含まれます。

比較

メールが送信されると、受信サーバーは送信元のIPアドレスを確認し、PTRレコードをチェックします。PTRレコードが「server1.isp-provider.net」を示しているのに、SMTPバナーが「mail.yourdomain.com」と表示されている場合、不一致が発生します。

簡単な例：

• IPアドレス:1.2.3.4
• SMTP バナー:mail.business.com
• PTRレコード（逆引きDNS）：1-2-3-4.dynamic.cloudhost.com
• 結果:エラー！同一性が一致しません。

このエラーがメール配信率に与える影響

受信メールサーバーはこのチェックをスパマーを素早く見分ける手段として利用する。

1. スパムフィルターのトリガー

スパマーは設定されていないサーバーやボットネットを頻繁に利用する。汎用的または不一致のホスト名は、スパムフィルターが最初にフラグを立てる対象の一つである。

2. 評判と信頼

大手ISPはフォワード確認済みリバースDNSを優先します。これは、あなたのIPが特定の名前を指し、その名前が同じIPを指し戻すことを意味します。これがなければ、あなたの「信頼スコア」は急落します。

3. 認証信号

技術的には SPF、DKIM、DMARCとは技術的に別物ですがとは技術的に別物ですが、rDNSはサーバー健全性の「全体像」の一部です。基本接続が乱れている場合、DMARCポリシーだけではレピュテーションを守れない可能性があります。

ミスマッチの一般的な原因

以下に、よくあるミスマッチの原因をいくつか挙げます。

デフォルトのクラウドホスト名

VPSを利用しており、プロバイダーから割り当てられたデフォルトのPTRレコードを変更していません。

MTA設定を忘れる

DNSレコードを更新しましたが、メールソフト内の実際の設定を更新するのを忘れています。

共有ホスティング

あなたは共有IPアドレスを使用しており、プロバイダーがPTRレコードを自社の一次ドメインに設定しています。あなたのドメインではありません。

知的財産権の帰属問題

PTRレコードを変更する権限がありません。そのIPアドレスは、管理権限をあなたに委譲していないISPによって管理されているためです。

現在の値を確認する方法

設定を変更する前に、世界中の他の人が見ているものを確認する必要があります。

1. PTRレコードを確認する

ターミナルで簡単なコマンドを実行して、自分のIPアドレスに関連付けられているホスト名を確認してください：

• Mac/Linux:dig -x [あなたのIPアドレス]
• Windows:nslookup [あなたのIPアドレス]

2. SMTPバナーを確認する

TelnetまたはOpenSSLを使用して、サーバーが他者をどのように迎えるかを確認してください。応答の最初の行に、SMTPバナーのホスト名が表示されます。

3. 集中管理ツールを使用する

手動での確認でも問題ありませんが、 PowerDMARCのDNSレコード検索 は、PTRレコードやAレコードが世界的にどのように表示されるかを示し、誤った結果をもたらす「DNSの遅延」がないことを確認できます。

「逆引きDNSがSMTPバナーと一致しません」エラーの修正手順（ステップバイステップ）

エラーを修正するために取るべき重要な手順を以下に示します。

ステップ1: 送信元IPを特定する

メールサーバーがメール送信に使用する正確なパブリックIPを確認してください。ファイアウォール、NAT、またはプロキシの背後にある場合、ローカルサーバーのIPとは異なる可能性があります。

ステップ2: PTRレコードを修正する

これが多くの人がつまずく部分です。通常、ドメインのDNSパネルでは変更できません。IPを所有する会社を通じて行う必要があります。

• クラウドVPS：プロバイダーのダッシュボード（ネットワーク／静的IPセクション）に移動し、「逆引きDNS」または「PTR」を探してください。
• 専用/オンプレミス:ISPにサポートチケットを開く必要がある場合があります。
• 目標：PTRレコードを完全修飾ドメイン名（FQDN）に設定する。

ステップ3: SMTPバナー（HELO/EHLO）を更新する

次に、サーバーが自身の名前を認識していることを確認してください。多くのメールサーバーはSMTPの挨拶文にデフォルトのバナーテンプレートを使用するため、ステップ2で設定した完全修飾ドメイン名（FQDN）と同じものを通知するようメール転送エージェント（MTA）を設定する必要があります。

• Postfix:/etc/postfix/main.cf を編集し、myhostname = mail.example.com を更新してください。
• Exim:設定ファイル内の primary_hostname を更新してください。
• 変更後はサービスを再起動してください！

ステップ4: フォワードDNSの一致を確認する

ステップ2および3で使用したホスト名には、 Aレコード が設定されている必要があります。PTRレコードが名前を指し、名前がIPアドレスを指す状態が フォワード確認済み逆引きDNS（FCrDNS）が実現されます。

逆DNSエラーを回避するためのベストプラクティス

逆引きDNSエラーを回避するには、以下の手順に従ってください。

ホスト名ごとに1つのIPアドレス

可能であれば、メールの命名規則を統一してください（例: mail1.domain.com）。

一般的な名称は避ける

rDNSをstatic.123.45.clients.provider.comのままで放置しないでください。

定期監査

自動化されたツールを使用してインフラストラクチャを監視してください。 PowerDMARCは、レコードの不整合やIPのブラックリスト登録をリアルタイムで検知し、アラートを通知します。

認証と整合する

「ソフト」失敗を防ぐため、逆引きDNSホスト名をSPFレコードに含めることを確認してください。

このエラーがDMARCおよびメール認証とどのように関連しているか

DMARCがメッセージの完全性に焦点を当てる一方、リバースDNSとSMTPバナーは接続の完全性に焦点を当てます。これは二層のセキュリティと考えることができます：一つは小包（メッセージ）のため、もう一つは配達トラック（接続）のためです。
不一致が広範な認証戦略を損なう仕組みは以下の通りです：

評価の優先順位

ほとんどの受信サーバーは、DMARCやDKIMレコードを確認する前に「ハンドシェイク」チェックを実行します。もしあなたのrDNSとバナーが一致しない場合、DMARCの「Reject」ポリシーがメッセージの正当性を証明する機会すら得られないまま、メールがゲートウェイでスロットリングされたり拒否されたりする可能性があります。

「プロフェッショナリズム」のシグナル

セキュリティフィルターは、サーバーの健全性の指標としてrDNS整合性を利用します。整合性が取れていない場合、設定不良または乗っ取られたサーバー（ボットネットに典型的な状態）を示唆し、SPFレコードが完璧であっても評価スコアの低下を招く可能性があります。

FCrDNSコンプライアンス

主要なISPは、信頼の基盤としてフォワード確認済みリバースDNSを要求することが多い。SMTPバナーがPTRレコードやAレコードと同期していない場合、この検証に失敗し、DMARC準拠のメールが不審なものと見なされる。

見えない失敗

PowerDMARCのようなプラットフォームがなければ、こうしたインフラのギャップはしばしば見過ごされてしまいます。標準的なDNSチェックではレコードが「有効」と表示されるかもしれませんが、受信側のゲートウェイがバナーとIPアドレスの不一致をどのように解釈しているかは必ずしも判明しません。

PowerDMARCがrDNSとSMTP整合性を自動化する仕組み

手動でターミナルコマンドを確認したり、様々なVPSダッシュボードにログインしたりすることは、時間がかかり、人為的ミスを招きやすいものです。PowerDMARCは、サーバーの「ハンドシェイク」が常に有効であり、世界中のISPから信頼されることを保証するために設計された、一元化されたツールスイートを提供します。

1. リアルタイムPTRおよびFCrDNS検証

当社のDNSレコード検索ツールは、基本的なチェックにとどまりません。PTRレコードを確認すると同時に、その結果として得られるホスト名が送信元のIPアドレスを指していることを確認することで、FCrDNSを検証します。これにより、PTRレコードは存在するがAレコードと正しく紐付けられていないといった、「設定が不完全な」状態を特定するのに役立ちます。

2. 積極的な監視とアラート

DNSドリフトが発生したり、クラウドプロバイダーがレコードをリセットしたり、IP範囲が再マッピングされることがあります。レピュテーション監視サービスはインフラを24時間365日監視します。設定ミスによりrDNS整合性が崩れたり、サーバーIPが突然ブラックリストに登録された場合、配信率が低下し始める前にアラートを受け取れます。

3. 包括的な配信率ダッシュボード

rDNSが接続層を処理する一方で、PowerDMARCはこのデータをSPF、DKIM、DMARCのパフォーマンスと結びつけます。集計されたRUAレポートを確認することで、特定のIPアドレスがGmailやOutlookから高い拒否率を受けているかどうかを把握でき、配信問題の原因をSMTPバナーの不一致まで遡って特定するのに役立ちます。

最終チェックリスト

• PTRレコード はSMTPバナーと一致する。
• SMTPバナーは フォワードDNS（Aレコード）と一致する。
• IPの評判は良好です（ブラックリストに登録されていません）。
• SPF、DKIM、およびDMARCは完全に設定され、整合が取れています。

まとめ

結局のところ、メールは信頼がすべてです。IPアドレスとサーバーの挨拶文が一致しない場合、受信トレイに届くのは困難です。レコードを整合させることは単なる「ベストプラクティス」ではなく、メールを実際に読んでもらうための必須条件です。
このようなインフラストラクチャ上のエラーは、原因の特定が困難な場合があります。PowerDMARCは設定を監視し、正常な部分と問題のある部分を明確に報告することで作業を容易にします。配信性の悪夢となる前に、こうした設定の不整合を発見します。
PowerDMARCの無料トライアルをお試しください サーバーが外部からどのように見えているかを正確に確認しましょう。

よくあるご質問

ドメインレジストラでPTRレコードを修正できますか？
いいえ。PTRレコードはIPアドレスに紐づいています。ホスティング会社またはISPに相談してください。
この問題でDMARCは失敗しますか？
必ずしもそうとは限りませんが、ブロックされる可能性があります。多くのフィルタはDMARCレコードを確認する前にバナーの「ハンドシェイク」をチェックします。
修正後もエラーが残る理由は？
DNSの伝播です。新規レコードがインターネット全体に反映されるまで最大24時間かかる場合があります。
1つのIPに複数のドメインがある場合は？
問題ありません。これは非常に一般的です。ドメインごとに異なるバナーを設定する必要はありません。サーバーの「メイン」となる名前を1つ選び、PTRレコード、SMTPバナー、Aレコードのすべてがその名前を指すようにしてください。これらが一致していれば、そのIPから送信する他のドメインも問題ありません。

• について
• 最新記事

ユネス・タラダ

ドメインとメールセキュリティのエキスパートPowerDMARC

ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。

最新記事 by Yunes Tarada(全て見る)

• DMARCbisの解説 – 変更点と準備方法 - 2026年4月16日
• SOAシリアル番号の形式が無効です：原因と解決方法 - 2026年4月13日
• Gmailで安全なメールを送信する方法：ステップバイステップガイド - 2026年4月7日