コンテナ上の WordPress からメールが送信できない原因 – SMTP / sendmail / Postfix を切り分ける

コンテナ上の WordPress からメールが送信できない場合、原因は WordPress 本体だけではありません。PHP の mail()、sendmail コマンド、SMTP プラグイン、Postfix リレー、DNS、Firewall、迷惑メール対策のどこで止まっているかを分けて確認する必要があります。

この記事では、WordPress をコンテナや Kubernetes 上で運用している前提で、メール送信経路を切り分ける考え方を確認します。ここでは「送信できない」問題を扱い、配送が遅い問題は別記事の範囲とします。

WordPress のメール送信経路を分解する

WordPress のメール送信は、見かけ上は管理画面やプラグインから送っているだけに見えます。しかし実際には、いくつかの経路があります。

まず、自分の WordPress がどの方式でメールを送る設計なのかを決める必要があります。コンテナ内に Postfix を入れるのか、外部 SMTP に寄せるのか、Node や別サーバーの Postfix にリレーするのかで、見る場所が変わります。

まず WordPress から送信テストする

最初に、WordPress から実際にメール送信テストを行います。問い合わせフォーム、パスワードリセット、SMTP プラグインのテスト送信など、WordPress が使う経路で確認します。

• 管理画面上でエラーが出るか
• WordPress のデバッグログにエラーが出るか
• SMTP プラグインのログに接続エラーや認証エラーが出るか
• リレー先の Postfix にログが残るか
• 相手先に届かないだけなのか、そもそも送信処理が始まっていないのか

この段階で重要なのは、WordPress 側で失敗しているのか、WordPress から外へ出た後に失敗しているのかを分けることです。

PHP の sendmail 設定を確認する

PHP の mail() を使う場合、PHP から呼び出される sendmail 互換コマンドが必要です。コンテナイメージによっては、sendmail コマンドも Postfix も入っていないことがあります。

コマンド

php -i | grep -i sendmail_path
which sendmail
ls -l /usr/sbin/sendmail /usr/lib/sendmail

sendmail_path が未設定、または指定先のコマンドが存在しない場合、PHP の mail() は期待通りに動きません。WordPress 側の問題というより、コンテナイメージ内のメール送信機能が不足している状態です。

コンテナ内に Postfix を入れるべきか

コンテナ内に Postfix を入れる構成は可能ですが、基本的には慎重に考えた方がよいです。Web アプリケーションのコンテナに MTA を同居させると、ログ、キュー、配送再試行、設定、監視、永続化の責務が混ざります。

Kubernetes 上では、WordPress コンテナに Postfix を入れるより、SMTP プラグインで外部 SMTP を使うか、内部の Postfix リレーに送る構成の方が運用しやすいことが多いです。

SMTP プラグインを使う場合

SMTP プラグインを使う場合は、WordPress から SMTP サーバーへ直接接続します。ここでは、WordPress の設定だけでなく、コンテナから SMTP サーバーへ TCP 接続できるかを確認します。

コマンド

getent hosts smtp.example.com
nc -vz smtp.example.com 587
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com </dev/null

587 番ポートを使う場合は Submission、465 番ポートを使う場合は SMTPS です。認証方式、TLS の方式、サーバー証明書、Firewall の許可を合わせて確認します。

Postfix リレー側で見ること

Postfix リレーを使う場合、WordPress 側からリレーへ届いているかをログで確認します。WordPress 側のテスト送信が成功しているように見えても、リレー側で拒否されている、キューに残っている、外部配送で失敗している場合があります。

コマンド

postqueue -p
journalctl -u postfix --since "10 minutes ago"
grep -i postfix /var/log/mail.log

リレー側では、送信元 IP が許可されているか、mynetworks や認証設定が意図通りか、宛先ドメインへの配送でエラーが出ていないかを見ます。Kubernetes から出た通信が Node の IP に SNAT される場合は、リレー側で見える送信元 IP も確認します。

DNS と迷惑メール判定も到達性に関係する

メール送信では、SMTP 接続が成功しても、相手に届くとは限りません。送信元ドメインの DNS 設定や迷惑メール判定も関係します。

• 送信元ドメインの SPF が正しいか
• DKIM 署名が必要な構成になっていないか
• DMARC の方針と送信経路が矛盾していないか
• 逆引き DNS と HELO / EHLO 名が不自然ではないか
• 送信元 IP のレピュテーションに問題がないか

ただし、この記事で扱う主題は「送信できない」問題です。DNS や迷惑メール判定は到達性に関係しますが、まずは WordPress から SMTP リレーまで届いているかを先に確認します。

切り分けの順序

メール送信の切り分けは、内側から外側へ順番に見ると見通しやすくなります。

この順序で見れば、WordPress の問題、コンテナの問題、SMTP 接続の問題、Postfix リレーの問題、外部配送の問題を分けやすくなります。

参考書籍

関連記事

まとめ

コンテナ上の WordPress からメールが送信できない場合、WordPress だけを見ても原因は分かりません。PHP の sendmail 設定、SMTP プラグイン、Postfix リレー、DNS、Firewall、迷惑メール対策を分けて確認する必要があります。

特に Kubernetes 上では、WordPress コンテナに MTA を同居させるより、SMTP プラグインや専用の Postfix リレーに責務を分ける方が管理しやすいことが多いです。

まずは WordPress から送信処理が始まっているか、次にコンテナから SMTP サーバーへ接続できるか、最後に Postfix リレーと外部配送を確認する。この順序で見ると、メール送信できない原因を切り分けやすくなります。

関連記事

WordPress のメール送信が遅い原因 – sendmail / Postfix / DNS の待ち時間を切り分ける WordPress が wordpress.org に接続できない時の切り分け – DNS / Proxy / Firewall / Kubernetes を確認する WordPress の JSON レスポンスエラーを切り分ける – REST API / WAF / PHP / パーマリンクを見る WordPress の予約投稿が 9 時間ずれる原因 – Docker / Kubernetes 環境のタイムゾーンを確認する WordPress を Kubernetes で運用する構成 – コンテナ、永続化、DB、メール、外部公開を分けて考える WordPress のサイトマップが生成されない原因 – パーマリンクと URL 設計を確認する WordPress のパーマリンク変更手順 – 旧 URL を守るリダイレクト設計 WordPress 更新後に ModSecurity が反応する理由 – WAF の偽陽性と例外設計を見る