WordPress のメール送信が遅い原因 – sendmail / Postfix / DNS の待ち時間を切り分ける

WordPress のメール送信が遅い場合、原因は「送信できない」時とは少し違います。経路自体は成立しているものの、PHP から sendmail を呼び出すところ、Postfix へ受け渡すところ、SMTP 応答を待つところ、DNS 正引き・逆引きのところで待たされている可能性があります。

この記事では、コンテナや Kubernetes 上の WordPress で、メール送信が遅くなる原因を切り分けます。前提として、メールがまったく送れない場合は、まず送信経路そのものを確認する必要があります。

発生する現象

メール送信の遅延は、次のような形で見えます。

• 問い合わせフォームの送信完了まで時間がかかる
• パスワードリセットメールの処理が遅い
• 投稿やコメントの通知処理で画面遷移が遅くなる
• SMTP プラグインのテスト送信が数秒から十数秒待たされる
• メール自体は届くが、WordPress の処理が重く感じる

この場合、メールが届くかどうかだけを見ると原因を見落とします。どの処理で待たされているのかを測る必要があります。

切り分けるレイヤー

WordPress のメール送信が遅い時は、処理の流れを分けて考えます。

重要なのは、WordPress から見た遅さと、Postfix 以降の配送遅延を分けることです。WordPress の画面が遅いのか、メールが相手に届くまでが遅いのかで、見る場所が変わります。

まず時間を測る

最初に、同じコンテナ内で sendmail や SMTP 接続にかかる時間を測ります。体感ではなく、どこで秒数が増えているかを見るためです。

コマンド

time php -r 'mail("user@example.com", "test", "test");'
time /usr/sbin/sendmail -t <<'EOF'
To: user@example.com
Subject: test

test
EOF

PHP の mail() が遅いのか、sendmail コマンド自体が遅いのかを分けます。PHP 経由だけが遅い場合は WordPress や PHP 設定、sendmail コマンドでも遅い場合は MTA や名前解決を疑います。

sendmail コマンドの有無と実体を見る

コンテナ内の sendmail は、本物の sendmail ではなく、Postfix などが提供する互換コマンドであることが多いです。まず、何が呼ばれているかを確認します。

コマンド

php -i | grep -i sendmail_path
which sendmail
readlink -f "$(which sendmail)"
ls -l /usr/sbin/sendmail /usr/lib/sendmail

sendmail_path が意図しない場所を指している、あるいは存在しないコマンドを呼んでいる場合、送信処理が不安定になります。コンテナイメージを更新した後に、ここが変わっていないかも確認します。

Postfix まで届く時間を見る

Postfix リレーを使っている場合、WordPress から Postfix までの受け渡しが速いかを確認します。Postfix まで届いた後に遅いのか、そもそも Postfix に渡す前に遅いのかで原因が変わります。

コマンド

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

ログでは、受信時刻、キュー投入、配送開始、配送完了、配送失敗の時刻を見ます。キュー投入までは速いが配送完了が遅い場合、WordPress ではなく Postfix 以降の問題です。

名前解決による遅延を疑う

メール送信の遅延でよくあるのが DNS です。配送先の MX レコード、送信先ホスト名、逆引き DNS、内部 resolver の応答遅延などで待たされることがあります。

コマンド

time getent hosts mail.example.com
time dig example.com MX
time dig -x 192.0.2.10
resolvectl status

特に Postfix は、配送時に名前解決を行います。DNS サーバーが遅い、逆引きがタイムアウトする、IPv6 側の名前解決や接続で待たされる、といった問題があると、メール配送が遅く見えます。

SMTP 接続の待ち時間を見る

外部 SMTP やリレー先 SMTP を使っている場合は、接続、TLS、認証のどこで待たされているかを確認します。

コマンド

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

TCP 接続が遅い場合はネットワークや Firewall、TLS 開始が遅い場合はサーバー応答や経路、認証後に遅い場合は SMTP サーバー側の処理を疑います。

Kubernetes での見方

Kubernetes 上では、WordPress コンテナ、Node、Postfix リレー、外部 SMTP のどこで遅いかを分けます。Pod からは遅いが Node からは速い場合、CNI、NetworkPolicy、DNS、Proxy、Pod の resolver 設定を確認します。

コマンド

kubectl -n wordpress-ext-system exec -it deploy/wordpress -- sh
time getent hosts smtp.example.com
time nc -vz smtp.example.com 587
time curl -Iv https://api.wordpress.org/

メール送信そのものだけでなく、Pod から外部へ出る通信全般が遅いかどうかも見ると、DNS や Proxy の問題を拾いやすくなります。

現在ならどう設計するか

現在のコンテナ運用では、WordPress コンテナ内に MTA を抱え込むより、SMTP プラグインまたは専用の Postfix リレーへ責務を分ける方が管理しやすいことが多いです。

• WordPress コンテナはアプリケーションに寄せる
• メール配送は SMTP サービスまたは Postfix リレーへ寄せる
• Postfix のログとキューを監視できるようにする
• DNS の正引き・逆引き・MX 解決を安定させる
• 配送遅延と WordPress 画面遅延を分けて見る

メールはアプリケーション機能に見えますが、実際には DNS、MTA、ネットワーク、認証、迷惑メール対策が絡みます。コンテナ内に全部を抱え込むと、原因の所在が見えにくくなります。

参考書籍

関連する記事

まとめ

WordPress のメール送信が遅い場合は、メールが届くかどうかだけでなく、どこで待たされているかを測る必要があります。PHP、sendmail、Postfix、DNS、SMTP 接続を分けて確認すると、原因を絞りやすくなります。

特にコンテナや Kubernetes 上では、WordPress コンテナ内の処理、Pod からの通信、Node からの通信、Postfix リレー、外部 SMTP を分けて見ることが大切です。

送信できない問題は経路の成立を確認し、送信が遅い問題は成立した経路のどこで待たされているかを測る。この分け方にすると、WordPress のメール関連トラブルを整理しやすくなります。

関連記事

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