どなたかが御社のお問い合わせフォームに入力します。ページには「ありがとうございます。追ってご連絡いたします」と表示されます。その方はタブを閉じ、御社からの連絡を待ちます。
しかし御社から電話がかかることはありません。メッセージを受け取っていないからです。メールは届きませんでした。その日も、それ以降もです。見込み客はしばらく待った後、フォームがきちんと機能している次の会社を探しに行ってしまいます。どちらの画面にも、送信に失敗したことを知らせる表示は一切ありませんでした。
WordPressは実際にどうやってメールを送っているのか
仕組みをわかりやすくご説明します。WordPressのフォームが送信されると、サイトはwp_mailという関数を呼び出します。この関数は初期設定のままだと、専用のメール配信サービスではなく、PHPに組み込まれたmail()関数にメッセージを渡します。PHPのメール機能はどこにもログインせず、送信者が本当に御社であることを証明することもなく、GmailやOutlookが正当な送信者に期待する検証済みのインフラも経由しません。ただウェブサーバーにメールを外へ押し出すよう頼み、うまく届くことを祈るだけです。以前はそれで十分でした。しかし今ではほとんど通用しません。メールプロバイダーは、まさにこうした認証のない簡易的な配信に対する警戒を強めており、単純なmail()の呼び出しがその基準を満たすことはめったにないからです。
メールは御社から送られたふりをしているが、誰も信じない
お問い合わせフォームは通常、you@yoursite.comのようなアドレスから、あるいはwordpress@yoursite.comのような実在すらしないアドレスから「送信」するよう設定されています。差出人欄には御社からのメールだと書かれていますが、実際に送信しているサーバーは、御社のドメインとしてメールを送る許可を一度も得ていません。現在、主要なメールプロバイダーはすべてこの許可を確認しています。許可がない場合、プロバイダーは御社が気づけるような明確なエラーとともにメッセージを差し戻すことはしません。黙って破棄するか、御社が決して開かない場所に振り分けてしまいます。見ただけでわかるような形でサイトが壊れているわけではありません。証明できない主張をしているだけであり、プロバイダーはその主張を鵜呑みにするのをやめたのです。
ホスティング会社がメールを送らない、またはほとんど送らない
すべてのホスティングプランが、サイトから自由にメールを送ることを許しているわけではありません。特に共用サーバーでは、1つのドメインが1時間あたりに送れるメール数に上限を設けていたり、PHPのメール機能そのものをブロックしていたりすることがよくあります。同じサーバーの別の利用者がかつてその機能を使ってスパムを送ったため、ホスティング会社が機能全体を封じてしまったというわけです。ご利用中のホスティング会社が厳しい会社であれば、フォーム自体はまったく問題ないように見えても（ページには完了と表示され、コードもエラーなく動作します）、実際の送信は建物の外に出る前に飲み込まれてしまいます。失敗は御社から中が見えないインフラの上で起きるため、エラーメッセージが表示されることもありません。
ドメインがメールの正当性を証明できない
メールが実際に送信された場合でも、受信側のプロバイダーはSPFとDMARCと呼ばれるDNSレコードを確認し、そのメールを信頼するかどうかを判断します。この2つを組み合わせることで、御社のドメインは、どのサーバーが御社の名義でメールを送ってよいのか、そして確認に失敗したメッセージを受信側のサーバーがどう扱うべきかを表明します。誰も意図して設定していないWordPressサイトでは、これらのレコードが存在しないか、誤って設定されていることが少なくありません。その結果、御社のドメインから送られたメールは、まさにこうした仕組みが排除するために存在するタイプのメッセージそっくりに見えてしまうのです。
うまく動いていたのに、アップデートで何かが変わった
WordPress本体、テーマ、そしてサイト上のすべてのプラグインは、それぞれ独自のスケジュールで更新され、そのどれもがメールの送信方法を気づかないうちに変えてしまう可能性があります。フォーム用プラグインの更新で、メール送信に使うライブラリが入れ替わります。セキュリティ用プラグインが、以前は許可していた外部への接続をブロックし始めます。キャッシュ用プラグインが、サーバー側での送信が失敗し始めた後も古い完了ページを表示し続けます。WordPressの視点からはフォームは正常に送信されているため、こうした問題はダッシュボードにエラーとして表示されることはありません。気づかないうちに動かなくなったのはその下の層であり、誰も意図して触れていないのにその層が変わってしまう最も一般的な原因が、アップデートなのです。
10分間のテスト
何かを直す前に、実際に何が起きているのかを確認しましょう。所要時間は10分ほどで、上で説明したどの失敗パターンに当てはまるのかがわかります。
- 実際にテスト送信を行ってください。 その際はGmail以外のメールアドレスを使います。仕事用のアドレスやOutlookのアカウントなど、お手持ちのもので構いません。Gmailの迷惑メールフィルターはそれだけでかなり厳しいため、Gmailだけでテストすると、別のプロバイダーなら見つけられた問題が隠れてしまうことがあります。
- テストに使ったアドレスの、受信トレイだけでなく迷惑メールフォルダも確認してください。 迷惑メールフォルダに入っているメッセージは、まったく届かなかったメッセージとは別の問題であり、ホスティング側のブロックではなく、上のSPFとDMARCのセクションを疑うべきだというサインです。
- 完了メッセージではなく、実際のメールログを確認してください。 ほとんどのホスティング会社では、cPanelやコントロールパネルにメールログがあります。あるいは、WP Mail Loggingのような無料のプラグインをインストールすれば、WordPressが送信を試みたすべてのメールと、その成否が記録されます。この一手順だけで、WordPressがそもそも送信を試みたのかどうかがわかります。
- 別のプロバイダー宛てに2通目のテストを送ってください。 Outlookには届くのにGmailには届かない場合、ホスティング全体のブロックではなく、特定のプロバイダーが御社のドメインをどう評価するかに起因する認証の問題である可能性が高いと言えます。
- 御社のドメインをウェブサイト健康診断にかけてください。 SPFとDMARCのレコードを確認し（DKIMは別の種類の照会が必要なため対象外です）、御社のドメインがメールの正当性を証明できるよう設定されているかどうかを1分以内にお知らせします。ここで警告が出れば、たいていそれで上記のすべてに説明がつきます。
誠実な解決策
どの失敗パターンに当てはまるのかがわかれば、解決策はたいていいくつかの選択肢のどれかです。どれも小手先の技ではなく、それぞれが本当に問題を解決する方法です。
SMTPプラグインを導入する。 開発者の定番の回答であり、妥当な回答でもあります。SMTPプラグインは、送信メールをPHPのmail()関数ではなく本物のメール配信サービス経由で送るように切り替えます。メールがプロバイダーからすでに信頼されているインフラから送られるようになるため、認証の問題を根本から解決できます。APIキーを作成して設定画面に貼り付ける作業に抵抗がなければ、20分ほどで完了します。そうでなければ、開発者に任せるのにちょうどよい1時間ほどの作業です。
フォームサービスに切り替える。 wp_mailに後付けしたプラグインではなく、フォームの送信処理専用に作られたツールは、自社の検証済み送信インフラを通じて通知を送ることが多く、問題そのものを回避できます。フォームの見た目や動作を細かく制御できる余地は少し減ります。その代わり、メッセージを確実に届けることだけを仕事にしているサービスが手に入ります。
サイトの運用を誰かに任せる。 SPFが何の略かを覚えたくないとお考えなら、それはもっともな立場であり、御社の落ち度ではありません。これはまさに、自社で管理しているWordPressサイトで見落とされがちな保守作業です。見込み客が競合他社に電話するまで、誰も気づきません。アップデートで何かが壊れるたびにメールログを確認する役目から解放されたいのであれば、もう二度と悩まずに済む選択肢へどうぞ。
なぜこれは繰り返し壊れるのか
WordPressサイトは、完成させて終わりというものではありません。WordPress本体、テーマ、十数個のプラグイン、そしてそのすべての下にあるホスティングという、それぞれ独立して更新される部品の積み重ねであり、どれか一つが動けば、ほかの部品の足場も揺らぎます。半年後のプラグインの更新で、この同じフォームがまったく違う形で再び壊れることもありえます。それは今と同じく、御社のせいではありません。誰も積極的に見守っていないソフトウェアを運用するとは、そういうことなのです。私たちがこれまでに見た中で最も極端な例は、フォームの問題ですらありませんでした。退役軍人が経営する引っ越し会社のWordPressのコードに32件の隠れたスパムリンクが埋め込まれ、ページ上では見えないまま、監査で発見されるまで検索順位を静かに押し下げていたのです。お問い合わせフォームの故障は、見込み客からの電話が途絶えるので気づける失敗です。WordPressの不具合の多くは、まったく気づかれないまま終わります。
もう二度とこの問題に悩まされたくない方へ
これが壊れるたびにメールログを確認したり、DNSレコードを読み解いたりする役目を担いたくないのであれば、それこそがSurmado Sitesがサイト運用の一環として引き受ける仕事です。ホスティングとメール配信、そして次のアップデートで修正が元に戻らないようにする保守まで対応します。わかりやすい言葉で一度ご依頼いただければ、直った状態が続きます。
よくある質問
メールが届かないのに、なぜフォームには「送信完了」と表示されるのですか？
「送信完了」の表示は、フォームが送信されてwp_mailが呼び出された瞬間に、WordPressによって生成されます。多くのお問い合わせフォームの設定は配信状況を確認するようには作られていないため、メッセージが実際に届いたかどうかについてメールサーバーからの返答を待つことはありません。この表示が意味するのは、WordPressが送信を試みたということです。誰かが受け取ったという意味ではありません。
送信されたメールは迷惑メールフォルダに入っているのですか？
その場合もありますが、いつもではありません。SPFやDMARCのレコードが誤って設定されている場合、実際に送信されたメールは、受信側のプロバイダーが御社のドメインからのものだと確認できないため、迷惑メールフォルダに振り分けられることがよくあります。一方、ホスティング会社が送信そのものをブロックしている場合や、プラグイン同士の競合によってサーバーから出る前に止められている場合は、メールはそもそも送信されていないため、迷惑メールフォルダにもありません。メールログ、またはウェブサイト健康診断の結果を確認すれば、実際にどちらの状況なのかがわかります。
アップデートの後に動かなくなったのはなぜですか？
一連のアップデートのどこかで、メールの送信方法、あるいは送信されるかどうかそのものが変わり、その変化がWordPressのどこにも目に見えるエラーとして表示されないためです。最初に疑うプラグインが原因であることはまれです。だからこそ、手探りで原因を探し始める前に、アップデートの直後にメールログを確認する2分間には価値があるのです。
SMTPプラグインは必要ですか？
必ずしも必要ではありませんが、必要なことは多いです。御社のドメインのSPFとDMARCのレコードに問題がなく、本当の原因がホスティング会社によるPHPメールのブロックや制限である場合は、本物のメール配信サービス経由でメールを送るSMTPプラグインが最も直接的な解決策です。DNSレコードに問題がある場合は、まずそちらを修正してください。ドメイン自体が正当性を証明できないままでは、送信方法を変えても効果はありません。いずれにしても、SMTPプラグインは一時しのぎではなく、一般的で確かな解決策です。ただし、設定して動作を維持し続けなければならないものがもう一つ増えることにもなります。フォームサービスや運用代行付きのサイトなら、まさにその部分を御社に代わって引き受けます。