WordPressのwp_mail()がtrueでもメール到達までは確認できない

WordPressのwp_mail()がtrueを返すのは、使用した送信方法が要求をエラーなく処理できたという意味です。受信者のメールサーバーが受け取ったことや、受信箱へ表示されたことまでは確認していません。

「WordPressから送れた」と「相手へ届いた」を一つにすると、調査する担当と記録が曖昧になります。wp_mail()の戻り値、サーバーからの送出、相手側の受信、受信箱での表示を順に分けます。

wp_mail()のtrueは配送完了ではない

wp_mail()のWordPress公式文書は、trueが返っても、利用者がメールを正常に受信したことを自動的には意味しないと説明しています。戻り値が示すのは、選ばれた送信方法が要求をエラーなく処理できたかどうかです。

確認地点を五つに分けます。

フォームに「送信しました」と表示する場合も同じです。フォーム処理がwp_mail()のtrueだけを見ているなら、その表示は受信箱への到達確認ではありません。問い合わせ記録を別に保存していない構成では、画面表示だけを受付の正本にしないようにします。

WordPressはPHPMailerからPHPのmail()を呼ぶ

WordPressの公式wp_mail()実装は、同梱するPHPMailerを準備し、宛先、件名、本文、ヘッダー、添付ファイルを設定します。標準ではPHPMailerのIsMail()を選び、PHPのmail()を使って送信します。

最後にPHPMailerのSend()を呼び、送信処理が成功すればtrue、例外が起きればfalseを返します。同梱PHPMailerの公式ソースでも、mail()が失敗した場合は例外となり、送信処理は成功扱いになりません。

ただし、PHPのmail()が要求を受け付けた後にも配送工程があります。WordPressのPHP処理は、相手の受信箱を直接操作しません。受信者への到達を確かめるには、送信サーバーと受信側の記録が必要です。

phpmailer_initを使う独自コードがあれば、PHPMailerの送信方法や設定は変わります。標準実装だけを見て結論を出さず、テーマ、プラグイン、mu-pluginsに送信設定の変更がないかを担当者へ確認します。

falseならWordPressから送信方法までを調べる

wp_mail()がfalseを返すなら、受信箱を探す前に、WordPressから送信方法を呼び出すまでを調べます。有効な宛先が一件も残らない、本文が空、PHPMailerがメッセージを組み立てられない、PHPのmail()を実行できないなど、要求の組み立てまたは送出時に失敗した可能性があります。

一回のテストについて、次を記録します。

• 実行日時
• 宛先
• 件名
• wp_mail()の戻り値
• Fromの名前とメールアドレス
• 添付ファイルの有無
• どの機能から送ったか

問い合わせ本文やパスワード再設定URLを、そのまま公開ログへ残しません。個人情報や秘密を含まない試験用の件名と本文を使います。戻り値を記録する一時コードは公開テンプレートへ置かず、実行者と削除時刻を決めます。

PHPエラーがある場合はWordPressのデバッグログを確認します。wp_mail()が例外をfalseへ変える箇所もあるため、画面に何も出ないことを成功の根拠にしません。サーバー担当者には、日時、宛先、From、戻り値を渡し、PHPとメール送信処理のログを確認してもらいます。

trueで届かないなら配送経路を後ろから確認する

trueなら、次はWordPressの外側を確認します。受信者に「届いていない」と聞くだけで終えず、同じ試験メールについて順に調べます。

1. 宛先の綴りと受信可能な状態を確認する。
2. 通常の受信箱、迷惑メール、隔離、振り分け規則を確認する。
3. サイトの送信窓口やサーバー管理者へ戻ったエラー通知がないか確認する。
4. 送信サーバーのキューと配送ログを、実行日時と宛先で確認する。
5. 管理できる別ドメインの宛先にも一通送り、受信先による違いを確認する。

同じ宛先へ何十通も再送すると、原因が分からないまま重複メールを作ります。件名へ試験番号を入れ、一つの条件で一通ずつ送ります。本文、From、送信方法を同時に変えず、変更した条件を記録します。

送信サーバーの記録に相手側の受け付けが残るなら、受信側の振り分けを確認します。送信待ちや拒否が残るなら、サーバー担当者がその応答を調べます。WordPressの管理画面だけで、どの配送段階まで進んだかを推測しません。

Fromの標準値と実在性を確認する

wp_mail()は、指定がなければFromの名前をWordPress、メールアドレスをサーバー名から作るwordpress@...とします。公式コアのコメントも、存在しないFromを一部のhostが拒否する可能性を挙げています。

試験時は、実際に使われたFromを確認します。Fromを無関係な外部ドメインへ書き換えて通そうとしません。サイトを運営するドメインの送信方針と、返信を受け取る窓口をサーバー管理者と決めます。Fromを変更する独自コードがあるなら、変更箇所と担当者を記録します。

wp_mail()の標準のContent-Typeはtext/plainです。HTMLメールへ変える処理があれば、送信後に設定を戻さないと、ほかのWordPressメールへ影響する可能性があります。まずプレーンテキストの短い試験メールで経路を確認し、その後でHTML、添付ファイル、複数宛先を一つずつ加えます。

問い合わせはメール以外にも受付記録を残す

問い合わせフォームがメールだけを作り、保存記録を持たない場合、配送障害が起きると問い合わせ自体を確認できなくなります。利用者へ完了画面を表示する条件と、事業者が受付済みと判断する条件を分けます。

少なくとも、受付日時、受付番号、送信処理の成否、担当者の確認状態を、取り扱う情報に合った場所へ残します。保存する項目、閲覧権限、保存期間は先に決めます。メールは担当者への通知に使い、問い合わせ記録そのものの唯一の保存先にしません。

実装を外部へ頼んでも、送信domain、受信窓口、サーバー契約、配送ログを確認できる担当、障害時に見る受付記録は事業者側で把握します。trueを最終成果とせず、受信確認と対応開始までの責任を決めます。