— DNSではなく「ローカル配送」が原因だった話 —
はじめに
XserverでWebサイトを運用し、メールはMicrosoft365（Outlook）で管理する構成はよくあります。
しかしこの構成で、次のような問題が発生することがあります。
- Microsoft365にメールが届かない
- なぜかレンタルサーバー側で受信される
- メールアカウント削除後にエラーになる
一見DNS（MXレコード）の問題に見えますが、実際には別の原因です。
本記事では、実際に発生した事例をもとに、原因と正しい対処方法を整理します。
※ 本記事のドメイン・IP・サーバー情報はすべてダミーです。
結論
今回の原因は、レンタルサーバーが同一ドメイン宛メールをローカル配送していたことでした。
DNS（MXレコード）は正しくても、この問題は発生します。
今回の構成（ダミー）
今回の構成をダミー情報で表すと、以下のようになります。
- 送信元：
user@example.co.jp（Xserverで運用） - 送信サーバー：
sv1234.example-server.jp - 宛先：
user@example.com（Microsoft365で運用） example.comのMXレコード：Microsoft365向き
この状態で、user@example.co.jp から user@example.com にメールを送ったところ、Microsoft365に届かず、想定外の挙動が発生しました。
発生した現象
実際には次のような現象が起きました。
- Microsoft365側にメールが届かない
- レンタルサーバー側に配送される、または配送エラーになる
たとえば、メールアカウント削除後には次のようなエラーになりました。
user unknown. Invalid user specified.このメッセージだけを見ると、宛先アドレスの設定ミスのように見えるかもしれません。
しかし、実際にはメール配送の経路に原因がありました。
DNSを確認しても問題はなかった
まず疑うのはMXレコードです。
実際に以下のように確認すると、ドメインは正しくMicrosoft365を向いていました。
dig mx example.com結果のイメージは以下です。
example.com. IN MX 0 example-com.mail.protection.outlook.com.この状態であれば、通常はMicrosoft365へ配送されるはずです。
さらに、パブリックDNSでも確認しておけば、DNSキャッシュの切り分けもできます。
dig mx example.com @8.8.8.8
dig mx example.com @1.1.1.1これらでも同じMXが返ってくるなら、DNS設定自体はほぼ問題ありません。
なぜDNSが正しくても届かないのか
ここが今回の本質です。
通常のメール配送は、次の流れで行われます。
送信サーバー → MXレコード参照 → 受信サーバーへ配送しかし今回は、この通常ルートを通りませんでした。
実際の挙動は次のようになります。
Xserverから送信
↓
宛先が「自分の管理しているドメイン」と判定される
↓
MXを見ずにローカル配送を試みる
↓
ユーザーが存在しなければエラーになるつまり、送信サーバー側のロジックによって、そもそもMXレコードが参照されていなかったのです。
原因の本質は「ローカル配送」
多くのメールサーバー（MTA）は、次のような動作をします。
自分が管理しているドメイン宛のメールは、外部配送よりも先にローカル配送を優先する
この挙動自体は珍しいものではありません。
むしろ一般的です。
今回問題になったのは、送信元のサーバーであるXserverが、宛先ドメイン example.com を「自分が管理しているドメイン」とみなしていたことです。
そのため、本来であればMicrosoft365へ行くべきメールが、Xserver内部でローカル配送されようとしてしまいました。
よくある誤解
この問題では、次のように考えてしまいがちです。
- ドメインが2つあるのが問題
- MXレコードが正しく設定されていない
- ネームサーバーを変えれば直る
- メールアカウントを削除すればMicrosoft365へ流れる
しかし、これらは本質ではありません。
正確には次の理解が重要です。
- 問題なのは「ドメインが2つあること」ではない
- 問題なのは「送信元サーバーが、宛先ドメインを自分のローカルドメインとして持っていること」
つまり、ドメイン数の問題ではなく、送信サーバーと宛先ドメインの関係が問題です。
実際のトリガーは何だったのか
今回のケースを整理すると、実質的なトリガーは以下でした。
example.co.jp と example.com が同じXserverに存在
↓
Xserverが example.com を「自分の管理ドメイン」と認識
↓
ローカル配送が発動ここで重要なのは、送信元アドレスのドメインが .co.jp で、宛先が .com だったとしても、送信サーバーが宛先ドメインを管理している限りローカル配送の対象になり得るという点です。
メールアカウント削除後に何が起きるか
では、Xserver側の user@example.com のメールアカウントを削除すれば解決するのか。
結論から言うと、それだけでは解決しません。
削除後の挙動はこうなります。
ローカル配送を試みる
↓
ユーザーが存在しない
↓
user unknown エラーつまり、ローカル配送には失敗しますが、そこで終わりです。
外部のMicrosoft365へ自動的に再配送されるわけではありません。
この点は非常に誤解されやすいところです。
重要なポイント：ローカル配送失敗後に外部配送へはフォールバックしない
今回ハマりやすかったのは、次の思い込みです。
ローカル配送に失敗したら、次にMXを見て外部配送してくれるのではないか
しかし、通常はそうなりません。
多くのサーバーでは、ローカル配送対象と判定した時点で配送経路が決まり、失敗しても外部配送へフォールバックしません。
そのため、メールアカウントを削除した結果は「Microsoft365に届く」ではなく、「配送エラーになる」です。
ネームサーバー変更では解決しない理由
この問題をDNSの問題と考えると、ネームサーバー変更を検討したくなります。
しかし、今回のケースでは根本解決になりません。
なぜなら、問題はDNSの参照前に発生しているからです。
Xserverがローカル配送を決定
↓
MXを見ない
↓
ネームサーバーの違いは影響しないネームサーバーを変更するとDNS管理先は変わりますが、Xserver側のローカル配送ロジックまでは変わりません。
したがって、今回の問題を解決する手段としては不適切です。
ケース別に見る挙動の違い
整理すると、挙動は次のようになります。
| 送信元サーバー | 宛先ドメインがそのサーバーに存在するか | 結果 |
|---|---|---|
| Xserver | 存在する | ローカル配送（問題発生の可能性あり） |
| Xserver | 存在しない | MX参照で外部配送 |
| 外部サーバー | 存在する / しないに関係ない | 通常はMX参照で配送 |
この表から分かる通り、今回の本質は「Xserverから送っていること」と「宛先ドメインがXserver上に存在していること」の組み合わせです。
では、送信元がXserver以外ならどうなるか
ここも重要な補足です。
もし user@example.co.jp がXserverではなく、別のメールサービスや別サーバーで運用されていた場合はどうでしょうか。
この場合、送信元サーバーはXserverではありません。
したがって、Xserver側のローカル配送ロジックは関与しません。
通常は以下のようになります。
外部サーバーから送信
↓
宛先ドメインのMXを参照
↓
Microsoft365へ配送つまり、送信元がXserver以外なら、今回のような問題は起きにくいということです。
この意味でも、問題の本質は「2つのドメインがあること」ではなく、「送信元と宛先ドメインが同じサーバー上にあること」だと分かります。
解決方法
今回の問題に対する解決方法は、主に以下の3つです。
1. 送信をMicrosoft365側に寄せる
もっとも素直な方法は、送信もMicrosoft365側に寄せることです。
ただし、ここで注意が必要です。
Microsoft365では、従来型のBasic認証SMTPは廃止方向に進んでいます。
そのため、今後の設計としては以下のような方法を検討するのが現実的です。
- SMTP AUTH（テナント設定で許可されている場合）
- Microsoft Graph API
- Exchange Online コネクタ
特に今後を見据えるなら、Microsoft Graph API を前提に設計するのが安心です。
2. Xserverから宛先ドメインを外す
もし example.com をXserverに持たせる必要がないのであれば、Xserver側からそのドメインを外す方法があります。
これにより、Xserverは example.com をローカルドメインとして認識しなくなります。
結果として、Xserverから送信しても外部ドメイン宛として扱われ、MXを参照してMicrosoft365へ配送されるようになります。
ただし、この方法はWeb運用など他の用途への影響もあるため、実際に採用するかは慎重に判断が必要です。
3. 送信サーバーを分離する
送信元がXserverであること自体が問題になるなら、送信サーバーを別に分ける構成も有効です。
たとえば、送信は別の外部メールサービスやAPI経由、受信はMicrosoft365という形にすれば、ローカル配送の問題を避けやすくなります。
実務でのベスト構成
実務上、もっとも安定しやすいのは次のような構成です。
- Web：Xserver
- 受信メール：Microsoft365
- 送信メール：Microsoft365または外部メールサービス
このように、受信だけでなく送信経路も明確に分けておくことで、配送トラブルや認証不整合を減らせます。
WordPressで起こりやすい理由
WordPress運用では、この問題がさらに起きやすくなります。
理由は、WordPressのメール送信が初期状態ではサーバー依存になりやすいからです。
たとえば、mail() 関数ベースで送っていると、実際にはそのサーバーのローカルMTAが配送を担当します。
その結果、今回のようにローカル配送が発生することがあります。
つまり、WordPressでフォーム送信や通知メールを使っている場合、次のような構成になっていると要注意です。
- Web：Xserver
- WordPressの送信：Xserverの
mail()またはローカルSMTP - 受信：Microsoft365
この場合、見た目では「受信はMicrosoft365だから大丈夫」と思っていても、実際には送信経路がXserverのままで、今回と同じ問題が起こります。
WordPress運用での対策
WordPressでこの問題を避けるには、送信経路を明示的に設計する必要があります。
たとえば次のような方法です。
- SMTPプラグインを使って外部メールサービスへ接続する
- Microsoft365連携を行う
- Graph APIなど、SMTP以外の安全な手段を使う
ポイントは、「受信先を変える」だけではなく、「どこから送るか」を明確にすることです。
SPF / DKIM / DMARCへの影響
この問題を放置すると、単に配送経路の問題だけでは済みません。
送信元と実際の配送経路が噛み合っていないと、以下のような認証系の問題も発生しやすくなります。
- SPF不一致
- DKIM未署名、または期待と異なる署名
- DMARC失敗
これらが起きると、迷惑メール判定や不達のリスクが高まります。
そのため、メールの送受信を複数サービスに分ける場合は、配送可否だけでなく認証設計まで含めて考える必要があります。
今回の学び
今回のトラブルから分かることは、次の通りです。
- メール配送はDNSだけで決まるわけではない
- MXレコードが正しくても届かないことがある
- 実際の配送では送信サーバーのローカル配送ルールが強く影響する
- 同じサーバー上に存在するドメイン宛メールは、意図せずローカル配送されることがある
- WordPressやサーバー標準のメール送信機能では、この問題が起きやすい
まとめ
今回のトラブルは、以下の流れで起きていました。
Xserverから送信
↓
宛先ドメインをXserverが自分の管理対象と判定
↓
MXを見ずにローカル配送
↓
ユーザーがなければ失敗（user unknown）つまり、問題はDNSではなく、送信サーバーの配送ルールにありました。
もしXserverとMicrosoft365を併用するなら、重要なのは「受信先」だけではありません。
送信経路も含めて設計することが必要です。
おわりに
XserverとMicrosoft365を併用する構成は珍しくありませんが、受信だけ切り替えて安心してしまうと、今回のようなメール配送トラブルに遭遇することがあります。
特に、WordPressのフォームメールや通知メールを運用している場合は要注意です。
今後メール構成を見直す際は、次の2点を必ず確認すると安全です。
- 宛先ドメインが送信元サーバーにローカルドメインとして存在していないか
- 実際の送信経路がどのサーバーになっているか
この2つを押さえるだけでも、かなりのトラブルを防げます。
コメント