WordPress からメールが送信されるが、送信開始まで異常に時間がかかることがあります。特に WordPress をコンテナで動かし、メール送信用の MTA を別コンテナに分けている場合、単純な PHP の問題ではなく、sendmail、MTA、名前解決、コンテナの /etc/hosts 生成が絡むことがあります。
この記事では、当時の環境で起きた「WordPress からのメール送信が 10 秒弱遅れる」問題を、WordPress 運用上の切り分けとして整理します。結論としては、メール送信経路をアプリケーション、sendmail 互換コマンド、MTA、名前解決に分けて確認することが重要です。
書籍
Postfix詳解 MTAの理解とメールサーバの構築・運用
Postfix を中心にメールサーバーの構築と運用を確認したい場合の参考書籍です。Dovecot と組み合わせたメール基盤を理解する補助として使えます。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
書籍
WordPress 仕事の現場でサッと使える！デザイン教科書 [WordPress 6.x対応版] 改訂第3版
WordPress のサイト構築、テーマ、カスタマイズ、運用項目を確認したい場合の参考書籍です。価格や在庫、WordPress の最新仕様との差分はリンク先や公式ドキュメントで確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
前提となる関連記事
WordPress の構築、Kubernetes 上の WordPress 運用、Postfix のローカル MTA 構成と合わせて読むと、この問題の位置づけが分かりやすくなります。
- Ubuntu 22.04 WordPress – Apache / PHP / MariaDB で CMS を構築する
- WordPress を Kubernetes で運用する構成
- コンテナのWordPressからメールが来ない問題を解消
- Ubuntu 22.04 Postfix ローカル MTA – サーバー通知メールの最小構成
- Ubuntu 22.04 Postfix 内部向けメールサーバー – relayhost と配送設計
発生した現象
WordPress を Kubernetes 上で作り直した際、コンテナの原則として 1 コンテナ 1 プロセスを意識し、WordPress コンテナとは別に Postfix コンテナを用意していました。
最初の問題は、Postfix コンテナ自体は参照できるのに WordPress からメールが送信されないことでした。これは WordPress コンテナ側に sendmail 互換コマンドを用意することで解決しました。
次に起きたのが、メールは送信されるものの、送信開始までが異常に遅いという問題です。tcpdump で見ると、Postfix 側へパケットが送られるまで 10 秒弱の遅延がありました。
切り分けるレイヤー
| レイヤー | 確認する内容 |
|---|---|
| WordPress / PHP | wp_mail() が呼ばれ、PHP からメール送信処理が開始されているか。 |
| sendmail 互換コマンド | WordPress コンテナ内に sendmail コマンドがあり、PHP から実行できるか。 |
| MTA | Postfix などの MTA が受信でき、ログに配送処理が残っているか。 |
| 名前解決 | sendmail 実行時にホスト名、localhost、MX レコードの探索で待たされていないか。 |
| コンテナ基盤 | /etc/hosts や DNS 設定が Pod / コンテナの自動生成仕様と衝突していないか。 |
この問題で重要なのは、WordPress 側でメール送信が遅いように見えても、実際には WordPress 本体ではなく、sendmail 互換コマンドや名前解決で待たされている可能性があることです。
sendmail コマンドの有無を確認する
WordPress は PHP の mail 関数や SMTP プラグイン経由でメールを送信します。ローカル MTA 経由の構成では、コンテナ内に sendmail 互換コマンドが存在するかを確認します。
command -v sendmail
sendmail -bv root
php -i | grep -i sendmail非コンテナ環境では Postfix を同一ホストにインストールすると sendmail 互換コマンドも一緒に用意されることが多く、この点を意識しないまま動いていることがあります。しかし、WordPress コンテナと MTA コンテナを分けると、この前提が崩れます。
MTA まで届く時間を見る
メールが送信されないのか、送信されるが遅いのかを分けるため、WordPress 側、MTA 側、ネットワークのどこで時間が使われているかを確認します。
date
sendmail -t <<'EOF'
To: test@example.local
From: wordpress@example.local
Subject: WordPress mail delay test
test
EOF
dateMTA 側ではログを確認します。Postfix コンテナや別ホスト MTA を使っている場合は、WordPress 側で sendmail を実行した時刻と、Postfix が受信した時刻を比較します。
sudo journalctl -u postfix -n 100 --no-pager
sudo tail -n 100 /var/log/mail.log名前解決による遅延を疑う
今回の遅延は、sendmail 実行時の名前解決が原因でした。MX レコードの探索やホスト名解決で待たされ、Postfix へ接続する前に時間が消費されていました。
当時の環境では、/etc/hosts にホスト名を明示することで遅延が解消しました。ポイントは、localhost だけでなく、そのコンテナまたはホストが自分自身として扱う名前を解決できるようにすることです。
127.0.0.1 localhost.localdomain localhost yourhostnameただし、Kubernetes では /etc/hosts は Pod ごとに自動生成されます。全体を書き換えたり追加したりできる場合はありますが、通常のサーバーのように手作業で部分的に管理する前提にはしにくいです。
確認コマンド
名前解決の待ち時間を確認するには、ホスト名、localhost、MTA の名前を個別に引けるかを確認します。
hostname
getent hosts localhost
getent hosts "$(hostname)"
getent hosts postfix
getent hosts mail.example.localDNS の探索順やタイムアウトを見る場合は、/etc/resolv.conf と /etc/nsswitch.conf も確認します。コンテナでは、これらのファイルも基盤側から注入されることがあります。
cat /etc/resolv.conf
cat /etc/nsswitch.confKubernetes での設計上の選択肢
この種の問題は、単純に「Postfix を別コンテナに分ければよい」という話ではありません。WordPress から見て、メール送信の責務をどこへ置くかを決める必要があります。
| 方式 | 特徴 |
|---|---|
| WordPress コンテナ内に MTA を含める | 単純で動作しやすいが、1 コンテナ 1 プロセスの考え方からは外れやすい。 |
| MTA を sidecar にする | Pod 内で近い位置に置けるが、sendmail 互換コマンドや配送経路の設計が必要。 |
| 外部 SMTP を使う | WordPress から SMTP プラグインで送信する。認証、TLS、到達性、レート制限を管理する。 |
| 内部 Postfix に relay する | アプリケーションから内部 MTA へ集約できるが、DNS とネットワーク制御を整える必要がある。 |
当時の環境では、最終的に WordPress を実行するコンテナに Postfix を含める方針で解決しました。厳密にはコンテナ設計として割り切りがありますが、運用上の安定性を優先した判断です。
現在ならどう考えるか
現在の観点では、WordPress のメール送信は SMTP プラグインで外部または内部 SMTP サーバーに明示的に送る構成も有力です。その場合、sendmail 互換コマンドやローカル MTA の名前解決問題を避けやすくなります。
一方で、サーバー通知やローカル配送を含めて MTA を管理したい場合は、Postfix を内部のメール基盤として設計し、WordPress はその MTA へ配送する構成も自然です。どちらにしても、メール送信経路を暗黙にしないことが重要です。
まとめ
WordPress からのメール送信が異常に遅い場合、WordPress 本体だけを見ても原因にたどり着けないことがあります。今回のように、実際には sendmail 互換コマンドや名前解決で待たされ、MTA に届く前に時間が消費されていることがあります。
コンテナ環境では、通常のサーバーで暗黙に成立していた sendmail、localhost、ホスト名、/etc/hosts、MTA の前提が崩れます。メール送信を安定させるには、WordPress、sendmail、MTA、DNS、Kubernetes の自動生成設定を分けて確認することが大切です。
Related posts:
コンテナ上の WordPress からメールが送信できない原因 – SMTP / sendmail / Postfix を切り分ける
WordPress が wordpress.org に接続できない原因と切り分け方
WordPress の予約投稿が 9 時間ずれる原因 – Docker / Kubernetes 環境のタイムゾーンを確認する
WordPress の外部連携プラグインが重い原因 – 投稿時の同期処理を見直す
Ubuntu 22.04 WordPress – Apache / PHP / MariaDB で CMS を構築する
WordPress のショートコード運用を見直す – 経過日数表示を例に本文と機能を分離する
WordPress を Kubernetes で運用する構成 – コンテナ、永続化、DB、メール、外部公開を分けて考える
WordPress で Google Analytics 4 を導入する理由 – アクセス解析を運用改善に使う
WordPress ブロックエディタを使う理由 – 記事構造と再利用性を高める
WordPress のスパムコメント対策 – コメント欄を開くリスクと運用設計
WordPress のパーマリンクを変更する手順 – 旧 URL を守るリダイレクト設計
WordPress 更新後に ModSecurity が偽陽性判定する原因と調整方針