ご訪問いただいている現在のこのドメイン（exiv.net）のメールサーバー（mail.exiv.net）において、ある時期を境に特定の送信先でメールが拒否される事象に遭遇しました。
Gmail宛に送信したメールは問題なく届くものの（SPF/DKIM/DMARC：すべてチェックOK）、@nifty 宛に送信したメールが接続時点で拒否されるという状況です。maillogを確認したところ、以下のように拒否理由が記録されていました。
554 FCrDNS check failed: reverse DNS does not match the connecting IP.
[※公開情報ではありますが、自動収集等を防ぐため、IPアドレスおよびホスト名は一部伏字としています。]
送信元IPの逆引き（PTR）は以下の通り（イメージ）です。
C:\Users\exiv> nslookup xxx.xxx.xxx.xxx 1.1.1.1
Server: one.one.one.one
Address: 1.1.1.1
Name: xxx-xxx-xxx-xxx.indigo.static.arena.ne.jp
Address: xxx.xxx.xxx.xxxWebArena Indigo では逆引きレコードを任意のホスト名に変更できないため、プロバイダ側で設定されたデフォルトホスト名がそのまま返されます。デフォルトホスト名を正引きした結果は下記のとおり（イメージ）。
C:\Users\exiv> nslookup xxx-xxx-xxx-xxx.indigo.static.arena.ne.jp 1.1.1.1
Server: one.one.one.one
Address: 1.1.1.1
*** one.one.one.one can't find xxx-xxx-xxx-xxx.indigo.static.arena.ne.jp: Non-existent domainPTRは存在するものの、PTRで得たホスト名のAレコードを確認できず、整合性が取れない状態（FCrDNS不整合）です。このことが原因で@niftyへの接続自体が拒否されている状況です。
2025年の秋頃に@nifty宛て送信テストを行っており、その際は、問題なく送信できていました。再度、2026年1月14日にテスト送信を行ったところ、@niftyメールサーバへの接続時点で拒否され、セキュリティ仕様が変更になっていることに気が付きました。
その後、2026年2月2日には「迷惑メール対策の強化について（FCrDNS導入）」という「お知らせ」が掲出されました。この「お知らせ」には「1月7日からFCrDNS検証を導入」と書いてあります。
（うん。知ってた。迷惑メール多いからね、わかるよ。 もうちょっと早く事前に告知して欲しいかも・・・）
現在、exiv.netのDNSサーバーサービスはCloudflareを利用していますが、逆引き設定はIPアドレスを管理しているサービスプロバイダー側に権限があるため、当然、外部サービスであるCloudflareでは逆引き設定はできません。
この問題を解決すべく、WebARENA Indigoの「DNSサービス（月額500円）」オプションを契約しようとしたのですが、よくよく確認したところ、このオプション契約でも、PTR（逆引き）レコード設定はできないことが判明しました。メールサーバー運用や一部の接続制限において逆引きが必要な場合は、他のVPSサービスの利用が推奨されているようです。
（だって、このサーバを作ったときは、こんなにチェックが厳しくなるなんて思ってなかったんだもん。）
メールサーバを別のVPSに移行することも検討しましたが、今回は、mail.exiv.netからの直接外部配送方式から、別のVPSをSMTPリレーとして利用する方式に変更することで、この「FCrDNSチェック」を回避しようと思います。
FCrDNSチェック対策の概要
別のVPSをSMTPリレーとして利用するにあたって、今回はConoHa VPS を選定しました。
理由は、今回の利用用途（SMTPリレー）に対して必要条件をシンプルに満たしていたためです。
まず、FCrDNSチェック対策としては、必須となる逆引き（PTR レコード）が設定可能であること。
次に、少量送信のリレー用途のため、低コストであること。
最後に、トラフィックが少ないため高スペックは不要であり、最小構成で十分である点です。
FCrDNSチェック対策計画を下図にまとめました。
メールサーバから外部へ直接メール送信するのではなく、Conoha VPSを経由してメール送信することで、FCrDNSチェックを回避しようという作戦です。
ConoHa VPS サインアップと費用感
ConoHa VPS（512MBプラン）3年契約で総額は10,637円（税込）でした。月額換算すると約296円です。用途はSMTPリレー専用、1日多くても送信50通。性能は不要と考えました。
今回、最も重視したのは「逆引きDNS（PTRレコード）の設定が可能であること」です。受信側メールサーバによってはFCrDNS（正引き・逆引きの整合）が必須となるため、SMTPリレーサーバ用途ではこの点が非常に重要になります。
なお、512MBプランではUbuntuが選択できなかったため、Debianを選択しています。使い慣れたAlma Linuxも検討しましたが、Debianで構築することにしました。
VPSの申し込みフォームでrootパスワードを設定、「オプションをみる」をクリック、詳細設定としてSSH Key キーを設定、セキュリティグループはそのままdefaultを指定しました。
セキュリティグループは、あとで自分で必要なポートを開放する必要があります。
セキュリティグループ設定
デフォルトのセキュリティグループでは、SSH接続もできないので、最初にセキュリティグループを設定しました。今回は、クラウド側のファイアウォールは以下の方針で設定しています。
【インバウンド】
外部からのアクセスは原則拒否、下記の通信を設定。
・SSH（22）は管理用グローバルIPアドレスのみ許可。
・SMTP（587）は送信元サーバのIPアドレスのみ許可。
【アウトバウンド】
SMTPリレーに限定して運用する前提、アウトバウンド通信は制限せず全て許可。
送信専用のため、外部からのメール受信は行わない構成です。
IPガチャ：IPレピュテーションの確認
ConoHa VPS自体は3年契約で作成。作成してから気がつきました（ものすごーく嫌な予感が）。
最初に確認すべきこと、そう、それは今回の利用用途で最も重視すべき内容。VPSに割り当てられたIPアドレスのレピュテーションの確認です。blacklistalert.orgで割り当てられたIPアドレスがブラックリストに掲載されていないか確認することにしました。
結果は３件のリストに掲載されている状態でした。
DNSBLチェック結果 抜粋
all.spamrats.com: Listed!
b.barracudacentral.org: Listed!
dyna.spamrats.com: Listed! See why判定結果を踏まえChatGPTに相談したところ、以下の理由から「VPSの再作成」が推奨されました。
- 効率性: Barracuda掲載IPの解除申請より、IP変更（再作成）の方が成功率・工数ともに有利。
- 到達率: 掲載状態のままではメール配送に悪影響が出るリスクがある。
- コスト: 再作成に伴う追加費用は微々たるもので、無視できるレベルである。
今回は3年間長期契約をしており、念のため、ConoHaサポートに確認したところ「キャンセル扱いとなり、VPS再作成した場合、新規作成扱いとなるため料金が発生する」との回答でした。
（危ない。再作成しないで良かった・・・）
チェック結果を再度確認したところ、幸いGoogleやMicrosoftが重視する Spamhaus（zen.spamhaus.org）には掲載されておらず、IPアドレスの汚れ具合は「致命的な汚染」ではないと判断しました。
以下を対策の上、現在払い出されたIPアドレスのまま対応を進めることにしました。
- PTRレコードを relay.exiv.net に変更
- 各DNSBLへの解除申請
解除申請については別記事でまとめます。Spamhaus（zen.spamhaus.org）に掲載されていたとしたら、サポートに泣きついてなんとかなったのだろうか・・・と、ちょっと不安も感じます。
基本設計
今回構築するリレーサーバでは、将来的に第三者へSMTPリレーサービスとして提供することを想定し、アカウント管理の検証も行います。単に送信元IPを固定するだけではなく、リレー用アカウントを管理し、SMTP AUTHによる送信認証を必須とする構成とします。
具体的には、リレーサーバがSMTP AUTHを受け付け、認証情報はPostfixAdmin / MariaDBを参照して判定します。これにより、リレー用アカウントの発行・停止・変更をDB側で管理できる構成を計画します。
役割定義
- 認証サーバ
リレー用アカウントを管理する（PostfixAdmin / MariaDB）
アカウントの有効／無効、パスワードを保持する - 送信元サーバ
メールを生成し、リレーサーバへ送信する
リレー用アカウント（ID/パスワード）を保持する - リレーサーバ
SMTP AUTHを受け付ける
認証サーバへ照会し、送信可否を判断する
認証済みメールのみ外部へ配送する
下図は役割を分離した概念構成を示していますが、今回の検証環境では認証サーバと送信元サーバは同一の mail.exiv.net 上に構築します。
リレーサーバの初期構築
基本設定は別記事にまとめました。
今回はここまで
送信元サーバおよび認証サーバとなる mail.exiv.net では、すでにメールサーバとしてPostfixAdminを構築し、運用しています。
そのため、mail.exiv.net 側の基本的なメールサーバ構築手順は省略します。PostfixAdminの構築については、以下の記事を参考にしました。
次回以降は実際に各サーバ設定について投稿する予定です。
(つづく)
コメント