Webとメールが別管理？WordPressのメール不達をインフラ視点で解決する方法

Web制作の現場でよくある構成の一つに、「Webサイトはレンタルサーバーだが、メールは別の法人向けプロバイダ（CPIやMicrosoft 365など）を使っている」というケースがあります。

この「別管理」の状態では、WordPressからのメール送信が非常に失敗しやすくなります。今回は、インフラエンジニアの視点でこの問題をどう切り分け、解決すべきかを整理しました。

1. なぜ別管理だとメールが届かないのか？

通常、WordPressはサーバーの標準機能を使ってメールを送ろうとします。しかし、Webとメールのサーバーが分かれている場合、受信側のサーバーから見ると以下の理由で不審なメールと判定されます。

これを解決するには、DNSの設定と、WordPress側の送信エンジンの変更が必須です。

まずは、ドメインがどこでメールを受け、どこからの送信を許すかを定義します。

■MXレコード
メールの受け口を正しく指定します。今回の事例では、メール専用サーバー（CPI等）を指定することで、メール運用をWebサーバーから完全に切り離しました。

■SPFレコード
ここが重要です。「このサーバーからの送信を許可する」という宣言をします。「+mx」という記述を入れることで、MXレコードが指している正規のメールサーバー経由の送信も許可されます。インフラ側でのこの一行が、到達率を左右するセーフティネットになります。

次に、PHPの標準機能を使わず、「正規のメールアカウントでログインして送る（SMTP認証）」方式に切り替えます。

使用プラグイン：WP Mail SMTP

この設定により、WordPressはWebサーバーから勝手に送るのではなく、正規のメールサーバーにログインし、そこから代理で送ってもらうという正規のルートを通るようになります。

インフラ側が整っても、フォームの設定が悪いと送信は失敗します。特に法人向けの厳しいサーバーでは以下のチェックが入ります。

■送信元（From）の不一致
ログインしたアカウントのアドレスと、送信元として表示させたいアドレスが異なると、なりすましと判断されます。送信元は必ず自社の正規アドレスに固定し、返信先（Reply-To）にお客様のアドレスを指定する設定に変更します。

■ヘッダーの日本語（エンコード）エラー
返信先などに、メールアドレスではないサイト名などの日本語が混じっていると、パケットが不正とみなされます。徹底的に引き算をして、純粋なメールアドレスのみを記述するのが定石です。

今回の事例では、メール送信エンジンとしての開通はインフラ設定で100パーセント完了できました。

Web制作において、インフラの知識は守りの要です。「設定は合っているはず」という思い込みを捨て、以下の3点を現物確認することが解決への最短ルートです。

インフラに強いWebエンジニアとして、目に見えない配送ルートを一つずつ確定させていく作業。これこそが、クライアントの信頼を守るプロの仕事だと考えています。

一人で抱え込みがちな技術トラブルの解決から、現場での立ち振る舞いを含めたメンタリングまで。現状を打破したい方は、お気軽にご相談ください。