前方確認型逆引きDNS

フォワード確認リバース DNS ( FCrDNS ) は、フルサークルリバース DNS、ダブルリバース DNS、またはiprevとも呼ばれ、特定の IP アドレスに対して、フォワード (名前からアドレス) とリバース (アドレスから名前) の両方のドメイン ネーム システム (DNS) エントリが一致するネットワーク パラメータ構成です。これは、多くの DNS 依存プロトコルをサポートするインターネット標準で期待される標準構成です。David Barr はRFC 1912 (Informational) で、DNS 管理者にとってのベスト プラクティスとしてこれを推奨する意見を発表しましたが、DNS 標準自体には正式な要件は規定されていません。^{[ 1 ]}

FCrDNS検証は、ドメイン名の所有者とIPアドレスが割り当てられたネットワークの所有者との間に有効な関係が存在することを示す、弱い認証手段となります。この認証は弱いものの、ホワイトリスト登録に利用できるほど強力です。なぜなら、スパム送信者やフィッシング詐欺師は、ゾンビコンピュータを使ってメールのなりすましを行う際に、通常はこの検証を回避できないからです。つまり、逆引きDNSは検証に成功するかもしれませんが、通常は主張されているドメイン名とは異なるドメインの一部となります。

ISPのメールサーバーをリレーとして使用することで、逆引きDNSの問題を解決できる可能性があります。なぜなら、要件は送信リレーの正引きと逆引きのルックアップが一致していることであり、リレーするメッセージの送信元フィールドや送信ドメインに関連している必要はないからです。

電子メールでIPアドレスとドメインの関係を確立する他の方法としては、Sender Policy Framework（SPF）とMXレコードがあります。

リバースDNSを設定できない、または設定しないISPは、対応するAレコード（またはAAAAレコード）との一致を必要とするアプリケーションやプロトコルをサポートできないため、ネットワーク上のホストに問題を引き起こします。リバースDNSを提供できない、または提供しないISPは、最終的に、顧客が自社が提供するインターネットサービスを効果的かつ安全に利用する能力を制限することになります。

• ほとんどの電子メール転送エージェント（サーバーソフトウェア）はFCrDNS検証を使用し、有効なドメイン名があれば、「Received:」トレースヘッダーフィールドにそのドメイン名を格納します。
• 一部の電子メール転送エージェントは、SMTP HELOコマンドおよびEHLOコマンドで指定されたドメイン名に対してFCrDNS検証を実行します。
• Sender Policy Framework（SPF）の電子メール偽造防止システムは、「ptr:」メカニズムでFCrDNSチェックを使用しています。しかし、2006年のSPFの最初の標準化（ RFC 4408）以降、この「ptr:」メカニズムの使用は推奨されていません。
• 例えばRFC 8601によると、一部の電子メールスパムフィルタは、ドメイン名の認証方法またはホワイトリスト登録の目的でFCrDNSチェックを使用しています。
• SpamCopはFCrDNSチェックを使用しますが、メールサーバーに対して適切なDNSレコードとrDNSレコードを提供しないインターネットサービスプロバイダの顧客でもあるSpamCopユーザーに問題が発生する場合があります。 ^{[リンク削除] [リンク削除]}
• 一部のFTP、Telnet、およびTCPラッパーサーバーはFCrDNSチェックを実行します。Wayback Machineに2020年7月1日にアーカイブされました
• 一部のIRCサーバーは、不正利用を防ぐためにFCrDNSチェックを実施しています。