Labee Dev Toolbox
技術ノートガイド用語解説
無料で試す
  1. ホーム
  2. / 用語解説
  3. / FCrDNS（正引き確認済み逆引き DNS）
ネットワーク

FCrDNS（正引き確認済み逆引き DNS）

2026年3月3日 更新

概要

FCrDNS（正引き確認済み逆引き DNS） は、IP アドレスの逆引き結果（PTR レコード）を正引き（A / AAAA レコード）で再検証し、双方向の一致を確認する DNS の検証手法です。単なる逆引き（rDNS）が「IP → ホスト名」の片方向だけを見るのに対し、FCrDNS は「IP → ホスト名 → IP」の往復を検証して、そのホスト名が本当にその IP アドレスの所有者のものかを確認します。

この仕組みは RFC 8601（2019 年）の Authentication-Results ヘッダーで iprev という認証方式として定義されています。RFC 7001（2013 年）で初めて導入され、RFC 8601 で置き換えられました。

メール配信の文脈では、2024 年 2 月に Google（Gmail）と Yahoo が全送信者に対して FCrDNS の設定を必須化しました。この要件は送信量に関係なく適用され、FCrDNS が成立していない送信元からのメールは拒否またはスパムフォルダに振り分けられます。SPF・DKIM・DMARC と並ぶ送信者認証のベースライン要件です。

仕組み

FCrDNS の検証は 2 段階で行われます。

  1. 送信元 IP アドレスの PTR レコードを引いて、ホスト名を取得する（逆引き）
  2. 取得したホスト名の A レコード（IPv6 なら AAAA レコード）を引いて、元の IP アドレスが含まれているかを確認する（正引き）

この 2 つが一致していれば FCrDNS は pass です。

# ステップ 1: 逆引き（PTR）
93.184.216.34  →  PTR  →  mail.example.com

# ステップ 2: 正引き（A）
mail.example.com  →  A  →  93.184.216.34

# 結果: IP が一致 → FCrDNS pass

一方、PTR レコードが指すホスト名の A レコードが別の IP を返す場合、または A レコードが存在しない場合、FCrDNS は fail になります。

# ステップ 1: 逆引き（PTR）
198.51.100.25  →  PTR  →  server1.hosting.example.net

# ステップ 2: 正引き（A）
server1.hosting.example.net  →  A  →  203.0.113.50

# 結果: IP が不一致 → FCrDNS fail

なぜ双方向検証が必要なのか

PTR レコードだけの検証では不十分な理由は、PTR レコードの管理構造にあります。PTR レコードは IP アドレスブロックの管理者（ホスティングプロバイダーなど）が設定するものであり、任意のホスト名を指すことが技術的に可能です。攻撃者が VPS を契約して PTR レコードを mail.legitimate-company.com に向けることは、ホスティング事業者の管理画面からできてしまいます。

しかし、mail.legitimate-company.com の A レコードは legitimate-company.com のドメイン管理者しか変更できません。FCrDNS は、PTR レコードの指すホスト名を A レコードで再検証することで、ドメイン管理権限を持たない第三者による PTR の不正設定を検出します。

メールサーバーの検証フロー

受信サーバーが SMTP 接続を受け付けたとき、FCrDNS の検証は次のタイミングで行われます。

  1. TCP 接続を受け付ける — 送信元 IP アドレスが確定する
  2. PTR レコードを引く — IP に対応するホスト名を取得する
  3. 取得したホスト名の A / AAAA レコードを引く — 正引きで IP を再確認する
  4. 元の IP と一致するか判定する

この検証は SMTP の HELO / EHLO コマンドの前に行われるため、メールヘッダーの内容には依存しません。SPF がエンベロープ From のドメインを使い、DKIM が署名ヘッダーを使うのとは異なり、FCrDNS は純粋に IP アドレスレベルの検証です。

Authentication-Results ヘッダーでの表記

受信サーバーが FCrDNS の検証結果を記録する際、Authentication-Results ヘッダーに iprev として記載します（RFC 8601）。

Authentication-Results: mx.example.com;
  iprev=pass (mail.example.com) smtp.remote-ip=93.184.216.34;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com

iprev=pass は FCrDNS が成功したことを示します。iprev=fail の場合、PTR レコードが存在しないか、正引きとの一致が確認できなかったことを意味します。

設定例

FCrDNS を成立させるには、PTR レコードと A レコードの両方を正しく設定します。

IPv4 の場合

送信サーバーの IP が 93.184.216.34、ホスト名が mail.example.com の場合、次の 2 つのレコードが必要です。

; A レコード（ドメインの DNS で設定）
mail.example.com.  IN  A  93.184.216.34

; PTR レコード（ホスティングプロバイダーで設定）
34.216.184.93.in-addr.arpa.  IN  PTR  mail.example.com.

IPv6 の場合

IPv6 アドレス 2001:db8::1 を使う場合も同様に、AAAA レコードと PTR レコードの双方を設定します。

; AAAA レコード（ドメインの DNS で設定）
mail.example.com.  IN  AAAA  2001:db8::1

; PTR レコード（ホスティングプロバイダーで設定）
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN  PTR  mail.example.com.

命名のベストプラクティス

PTR レコードのホスト名は送信ドメインと関連付けるのが望ましいです。

; 推奨: 送信ドメインのサブドメイン
mail.example.com → 93.184.216.34

; 非推奨: プロバイダーのデフォルトホスト名
93-184-216-34.compute.provider.net → 93.184.216.34

プロバイダーのデフォルトホスト名でも FCrDNS 自体は pass しますが、受信サーバーによっては PTR のホスト名と HELO ドメインの関連性も追加でチェックします。送信ドメインのサブドメインを使うことで、関連性の検証にも対応できます。

確認方法

FCrDNS の検証は dig コマンドで手動で再現できます。

# ステップ 1: 送信サーバー IP の逆引き
dig -x 93.184.216.34
# ステップ 2: PTR の結果（ホスト名）を正引き
dig A mail.example.com

ステップ 1 で返ったホスト名をステップ 2 で正引きし、元の IP アドレスが含まれていれば FCrDNS は成立しています。

実際の Google Public DNS（8.8.8.8）で試すと、次のようになります。

# 逆引き
dig -x 8.8.8.8
dns.google.
# 正引き
dig A dns.google
8.8.8.8
→ IP が一致するため FCrDNS pass

ワンライナーで検証する場合は次のように組み合わせます。

# PTR を取得し、その結果を正引きして IP の一致を確認する
PTR=$(dig -x 8.8.8.8 +short) && dig A "$PTR" +short

外部の視点からも確認したい場合は、Labee Dev Toolbox の IP API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/ip?ip=8.8.8.8"

レスポンスは次の形式で返ります。

{
  "success": true,
  "data": {
    "ip": "8.8.8.8",
    "type": "IPv4",
    "isPrivate": false,
    "ptr": "dns.google"
  },
  "error": null,
  "meta": { "responseTime": 42 }
}

data.ptr に逆引き結果のホスト名が返ります。この値が null の場合、PTR レコードが設定されていないため FCrDNS は成立しません。PTR が返った場合は、そのホスト名を dig A で正引きして、元の IP と一致するかを確認します。

メール認証全体の設定状況は、Mail Auth API でも確認できます。

curl "https://labee.dev/api/mail-auth?domain=example.com"

レスポンスは次の形式で返ります。

{
  "success": true,
  "data": {
    "spf": {
      "record": "v=spf1 include:_spf.google.com ~all",
      "exists": true
    },
    "dkim": {
      "record": null,
      "exists": false,
      "selector": "default"
    },
    "dmarc": {
      "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com",
      "exists": true
    },
    "bimi": {
      "record": null,
      "exists": false
    }
  },
  "error": null,
  "meta": { "responseTime": 120 }
}

data.spf、data.dkim、data.dmarc、data.bimi の各フィールドでドメインの認証レコードを一括確認できます。FCrDNS は IP アドレスレベルの検証のため直接は含まれませんが、SPF・DMARC の設定と合わせて確認することで送信者認証の全体像を把握できます。

よくある問題

FCrDNS のトラブルは、PTR と A レコードの不整合や、共有 IP・IPv6 環境での設定漏れに起因するケースが大半です。

PTR が設定されているのに FCrDNS が fail する

最も多いパターンです。ホスティングプロバイダーのデフォルト PTR（例: 93-184-216-34.compute.provider.net）が設定されていても、そのホスト名の A レコードが存在しなければ FCrDNS は fail します。解決するには、PTR レコードを自分のドメインのサブドメイン（例: mail.example.com）に変更し、そのサブドメインの A レコードが送信サーバーの IP を指すように設定します。

共有 IP 環境で FCrDNS を設定できない

共有ホスティングでは IP アドレスを複数ユーザーで共有しているため、PTR レコードを個別に設定できません。この場合の対処法は 2 つあります。

  • 専用 IP を持つ VPS やクラウドインスタンスにメールサーバーを移す
  • SendGrid、Amazon SES、Postmark などの ESP（Email Service Provider）を使う。これらのサービスは自社の送信 IP に対して FCrDNS を設定済みです

IPv6 の FCrDNS を忘れている

IPv4 で FCrDNS を正しく設定していても、サーバーが IPv6 でもメールを送信している場合、IPv6 側の PTR レコードと AAAA レコードの設定が必要です。IPv6 の PTR が未設定だと、IPv6 経由で送信されたメールだけが拒否されます。サーバーの IPv6 アドレスに対しても PTR と AAAA の双方を設定するか、メール送信を IPv4 に限定します。

クラウドプロバイダーでの PTR 設定に時間がかかる

AWS の Elastic IP では逆引き DNS の設定にサポートへの申請が必要で、即時反映されません。GCP はプロジェクトの DNS 設定から逆引きゾーンを作成する形式です。新しいメールサーバーを構築する際は、PTR レコードの設定を最初の工程として行い、DNS の伝搬時間（TTL による）を考慮したスケジュールを立ててください。

FCrDNS は pass しているのにメールが届かない

FCrDNS はメール配信の必要条件ですが、十分条件ではありません。FCrDNS が pass していても、SPF・DKIM・DMARC のいずれかが fail していればメールは拒否される可能性があります。Authentication-Results ヘッダーで iprev、spf、dkim、dmarc の各結果を確認し、全てが pass しているかを検証してください。

SPF・DKIM・DMARC との関係

FCrDNS は IP アドレスレベルの検証であり、メール認証の全体像の中では最も基礎的なレイヤーに位置します。

認証方式検証対象検証レイヤー
FCrDNS (iprev)送信元 IP の PTR と A レコードの整合IP アドレス
SPFエンベロープ From ドメインの送信許可 IP リストドメイン（エンベロープ）
DKIMメール本文とヘッダーの電子署名メッセージ
DMARCSPF / DKIM の結果とヘッダー From の一致ポリシー

FCrDNS が fail した場合、SPF や DKIM が pass していてもメールが拒否されることがあります。Google の送信者ガイドラインでは、FCrDNS は SPF・DKIM・DMARC とは独立した要件として位置付けられています。全ての認証方式を pass させることで、メール配信の信頼性が確保されます。

実際のドメインで確認してみる

登録不要、無料です。ドメイン名を入れるだけで外部からの見え方を確認できます。

無料で試す

関連用語

DNS

PTR レコード（Pointer Record）

IP アドレスからドメイン名を逆引きするための DNS レコード。メール配信の信頼性に影響する。

DNS

A レコード

ドメイン名を IPv4 アドレスに対応付ける DNS レコード。ウェブサイト公開の最も基本的な設定。

DNS

AAAA レコード

ドメイン名を IPv6 アドレスに対応付ける DNS レコード。IPv4 アドレス枯渇に伴い設定の必要性が増加。

メール認証

SPF（Sender Policy Framework）

メール送信元の IP アドレスがドメイン所有者に許可されているかを検証する仕組み。DMARC の前提条件の一つ。

メール認証

DMARC（Domain-based Message Authentication, Reporting and Conformance）

SPF と DKIM の認証結果を統合し、なりすましメールの処理方針をドメイン所有者が宣言する仕組み。Google・Yahoo が大量送信者に義務化。

コンテンツ 技術ノート ガイド 用語解説
ツール ツール一覧 API Reference
Labee 日本語トップ Labee LLC
© 2026 Labee LLC . All rights reserved.
ホーム ブログ ガイド 用語集