移行後にフォームのメールだけ届かない理由
サーバーを移し替え、トップページも下層ページも問題なく表示されている。管理画面にも入れる。ところが数日後、「問い合わせフォームから送ったのに返事がない」と外部から指摘される。ページは動いているのにメールだけが届かない——この状況では、サイトの見た目を何度確認しても原因にたどり着けない——という状況で読まれることを想定した記事です。
先に結論
- フォームが動いているかどうかと、メールが相手に届くかどうかはまったく別の話です。画面に「送信しました」と出ても、届いた保証にはなりません。
- 移行で変わる最大の要素はメールの送信元 IP アドレスです。ドメイン名が同じでも、送信元が変われば受信側の判定は変わります。
- SPF は「このドメインのメールは、この送信元から出ます」というDNS 上の申告です。移行後もこれが旧サーバーのままだと、新サーバーからのメールは申告外の送信になります。
- 切り分けは「送っていない」「送ったが拒否された」「届いたが迷惑メール扱い」の三つに分けるところから始めます。対処はそれぞれ違います。
表示とメールは、別の経路を通っている
ブラウザでページが表示されるのは、訪問者のブラウザと Web サーバーの間のやり取りが成立している、ということでしかありません。それ以上のことは何も意味していません。
フォーム送信のメールは、まったく別の経路をたどります。Web サーバーがメールを作り、それを受信者のメールサーバーへ渡す。この受け渡しは、ページの表示とは何の関係もないところで起きています。表示が正常であることは、メール経路が正常であることの根拠になりません。
移行作業の確認は、どうしても表示中心になります。トップページ、下層ページ、画像、管理画面。目で見て確かめられるものから順に潰していくため、目に見えないメール経路は最後まで検証されないまま公開されることがあります。
さらにやっかいなのは、フォームプラグインの「送信完了」表示です。多くの場合、この表示は WordPress がメール送信処理を呼び出したところまでしか保証していません。その先で受信側に拒否されたかどうかは、送信画面には反映されません。だから「表示は同じなのにフォームだけ届かない」という、一見ちぐはぐな状態が成立します。
送信元 IP が変わる、とはどういうことか
移行とは、サイトのファイルとデータベースを別のサーバーへ移す作業です。その新しいサーバーには、当然ながら別の IP アドレス——インターネット上の住所にあたる番号——が割り当てられています。
ドメイン名は同じままでも、実際にメールを送り出すコンピューターは別物に変わっている。これが移行後のメール問題の出発点です。
SPF とは何を申告しているのか
受信側のメールサーバーは、差出人のドメイン名だけでは本人確認ができません。差出人を詐称するメールが大量に流通しているためです。名乗りだけを信じる仕組みにはできません。
そこで受信側は「このドメインを名乗るメールが、正しい場所から出ているか」を確認します。その確認材料のひとつが SPF です。SPF は DNS に書かれた一行のテキストで、そのドメインのメールを送ってよい送信元の一覧を示します。ドメインの持ち主が「うちのメールはここから出ます」とあらかじめ申告しておく仕組み、と考えると分かりやすいと思います。
判定が合わないと何が起きるか
移行後も SPF が旧サーバーを指したままだと、新サーバーから出たメールは申告の外から出たことになります。受信側から見れば「名乗りと出所が一致しない」メールです。
この不一致をどう扱うかは、受信側の設定次第です。そのまま受け取るところもあれば、迷惑メールとして隔離するところも、接続の段階で拒否するところもあります。送信した側には、どう扱われたかが見えません。
拒否か、迷惑メールか、そもそも送っていないか
SPF の不一致があれば必ずメールが消える、というわけではありません。完全に拒否される場合と、迷惑メールフォルダに入る場合があります。後者なら、受信者が探せば見つかります。
同じサイトから出た同じメールでも、受信者が使うメールサービスによって結果が変わります。「A 社には届くが B 社には届かない」という報告は、この形の典型です。サイト側で何かが壊れているのではなく、判定の基準が受信側ごとに違うために起きています。
一方で、SPF とまったく関係のない原因もあります。そもそも送信処理が走っていない場合です。移行と同時に PHP のバージョンが上がり、メール送信まわりの処理が止まっているケースがこれにあたります。PHP のバージョンが上がったときに何が起きるかはPHP のバージョンを上げると、なぜ古いサイトが止まるのかで整理しています。
この三つを混ぜたまま設定をいじると、直ったのか直っていないのかが判断できなくなります。順番としては、まず送信処理が動いているかを確認し、そのあとに届き方の問題へ進みます。
担当者の手元でできる確認
テスト送信は宛先を変えて二通
自社ドメインの宛先だけでテストすると、結果を読み違えます。自社宛てと、外部のフリーメール宛て、最低でも二通を送って結果を比べてください。
片方だけ届かなければ、受信側の判定が疑われます。両方届かなければ、送信そのものが動いていない可能性が高くなります。この分岐だけで、次に見る場所が変わります。
ログとヘッダーで切り分ける
届いたメールには、本文の裏側にヘッダー情報という記録が付いています。多くのメールソフトで「メッセージのソースを表示」といった操作から見ることができ、そこに SPF の判定結果が記録されています。判定が通っているのか、失敗しているのかが読み取れます。
一通も届かず、エラーの返信もない場合は、送信処理そのものを疑います。サーバーのエラーログに手がかりが残っていることがあります。ログの置き場所と読み方はWordPress のエラーログはどこにあり、どう読むかにまとめました。
フォームプラグインに送信履歴を保存する機能があれば、そこも見ます。記録が残っているのに届いていないなら、WordPress 側は仕事をしており、その先の経路の問題だと絞り込めます。
DNS の SPF レコードは、契約中の DNS 管理画面——ドメイン事業者、またはサーバー会社の管理画面——で確認できます。移行前の記述がそのまま残っていないかを見てください。
直すときに気をつけること
SPF レコードは、ひとつのドメインにつき一つだけです。良かれと思って二行書くと、かえって判定が失敗します。追記が必要な場合は、既存の一行の中に書き足します。
メール配信を外部サービスに任せている場合は、そのサービスの送信元も SPF に含める必要があります。移行に合わせてサーバー分だけを書き換えると、今度は配信サービスから出るメールが落ちます。
DNS の変更は、世界中に伝わるまで時間がかかります。直した直後に届かなくても、それは失敗とは限りません。しばらく様子を見てから再度テストしてください。
近年は SPF に加えて、DKIM(メールに付ける電子署名)と DMARC(SPF や DKIM が合わなかったときの扱いをドメイン側が宣言する仕組み)も参照されます。大手メールサービス宛てでは、SPF だけでは足りない場合があります。
そして最も大きな分かれ道は、サーバー会社が提供するメール送信機能を使うのか、外部の配信サービスを使うのかです。どちらを選ぶかで必要な設定がまったく変わります。先に方針を決めてから手をつけてください。
移行の前に決めておけること
移行計画に「メールの送信経路をどうするか」を、独立した一項目として入れておきます。表示確認のチェックリストに混ぜると、見た目が直った時点で終わったことになりがちです。
公開前に、新サーバー側からテスト送信を行い、外部の宛先に届くところまで確認します。ここまでやって、はじめてメール経路を検証したと言えます。
問い合わせが業務に直結するサイトでは、切り替え後の数日間、届いた件数を誰かが目視で確認する体制を作っておくと安全です。ゼロ件が続いていれば、外部から指摘される前に気づけます。
🚨 DNS とメールの設定は、間違えるとサイトの表示まで巻き込んで止まります。戻せる状態を用意してから手をつけてください。「取ってある」と「戻せる」は別の話です。その違いについてはバックアップは「取れている」と「戻せる」が別物で書いています。
最後に、自社の管理範囲がどこまでかを整理しておくことをおすすめします。ドメイン、DNS、サーバー、メール。この四つの契約先が分かれていると、原因が分かっても直せる人が社内にいない、という事態が起こります。
移行で変わったのは見た目ではなく、そのサイトが外の世界に対してどう名乗るかという部分です。表示の確認だけで移行を終えると、名乗りの不一致は問い合わせが途切れた形で後から表に出ます。届いているかどうかを確かめる手段を、移行の手順の中に置いておくかどうかの違いです。
