サーバー移行時の盲点：同一サーバー内ドメインによる「ローカル配送」の罠
メールサーバーの移行作業において、送受信テストのために「自動返信設定をしたアカウント」を利用することがあります。
しかし、設定は正しいはずなのに「なぜかメールが返ってこない」という現象に直面することがあります。
その背後に隠れた「ローカル配送」の仕組みについてまとめました。
1. 構成環境とテスト内容
新サーバー（移行先）: 作業PCのメーラーで送信サーバーとして設定済み。
テスト用（自動返信）アカウント: 特定のサーバー（旧環境と同一拠点）で稼働中。
DNS設定: MXレコードはすでに「新サーバー」を向いている。
この状態で、新サーバーからテスト用アカウントへメールを送信し、自動返信が戻ってくる事を確認。
2. トラブルの現象
送信は成功し、テスト用アカウント側にもメールは届した。
しかし、そこからの自動返信メールが、新サーバー側の受信箱にいつまで経っても届かないという事象が発生した。
3. 原因解析：DNSを無視する「ローカル配送」の挙動
この問題の原因は、自動返信メールがインターネット上のDNS（MXレコード）に従わず、サーバー内部で完結してしまったことにあります。
1.送信フェーズ: 新サーバーから送信されたメールは、DNSに従ってテスト用アカウントがあるサーバーへ正常に到達した。
2.受信・返信フェーズ: テスト用アカウントがあるサーバー（旧環境と同じネットワーク内）がメールを受信し、返信メールを生成する。
3.ローカル配送の発生（核心）:返信先（example.com）のドメイン設定が、そのサーバー内にまだ残っていると、サーバーは「わざわざ外（DNS）に聞きに行かなくても、自分の中にこの宛先がある」と判断する。
4.配送の完結:結果、MXレコードがどこを向いていようと関係なく、サーバー内部の「旧受信箱」へ直接メールを放り込んで（ローカル配送）終了してしまう。
4. なぜ「外部」からチェックできなかったのか
・MXレコードの「逆転現象」: MXレコードは新サーバーを向いているため、Gmailなど「外の世界」から送ったメールはすべて新サーバーへ届く。そのため、旧サーバーのメールボックスは「もう何も届かない空の箱」だと思い込んでしまう。
・「身内」だけの閉じたルート: しかし、そのサーバー自身が発信したメールだけは、DNSを見に行かないという独自のルール（最短ルート）を通る。その結果、本来新サーバーに届くべき返信メールが、旧サーバー内の「今はもう使っていないはずの受信箱」に隔離されてしまった。
5. 今後の対策と教訓
移行期間中はサーバー固有の配送ルールが優先されるリスクがあるため、以下の対策を推奨。
・「完全外部」の自動返信環境を活用する
移行元・移行先のどちらのサーバー設定とも物理的に無関係な、第三者のドメイン（外部の疎通確認サービスや、自動応答をオンにしたGmail等）をテストの宛先に指定する。
・内部配送の可能性を常に疑う
「返信が来ない」＝「疎通失敗」と断定せず、送信元サーバーの内部にメールが留まっていないか、旧環境側のボックスも念のため確認する。
まとめ
「サーバーは、外部のDNS（MXレコード）よりも、自分自身の内部設定を優先する」。
この特性を理解しておかないと、移行期のテストで思わぬ時間ロスを招くことになる。サーバー移行は、単にデータを移すだけでなく、こうした「メールの流路」のねじれを考慮することも重要です。
