「主要な配送先が落ちている時に、再送間隔を短くして早く復旧したい」
この記事では、Postfixでメッセージの再送信時間を設定する方法を、現場で20年以上Linuxサーバーを運用してきた経験から実務目線で解説します。
minimal_backoff_time / maximal_backoff_time / queue_run_delay の3つのパラメータの関係、main.cf での設定手順、設定反映の確認、現場でよくあるトラブル対処までを一気通貫で扱います。
動作確認環境：RHEL 9.4 / Ubuntu 24.04 LTS / Postfix 3.x（systemd管理）。
この記事のポイント
・Postfixの再送信時間は main.cf の minimal_backoff_time / maximal_backoff_time で設定する
・queue_run_delay はキュー全体のスキャン間隔で、再送間隔とは別の指標
・設定変更後は postfix reload で反映、postconf -d でデフォルト値を確認できる
・短すぎる再送間隔はDNSレートリミット・SMTPブロックを誘発する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Postfixの再送信の仕組み：minimal_backoff_time と maximal_backoff_time
Postfixは、SMTPでメッセージを送信できなかった場合（一時的なネットワーク障害・宛先メールサーバーのダウン・グレーリスティング等）、deferred キューにメッセージを保留し、一定時間ごとに再送信を試みます。この「一定時間」を決めているのが、main.cf の minimal_backoff_time（初回再送までの最小待ち時間）と maximal_backoff_time（再送間隔の最大値）の2つのパラメータです。
Postfixは「指数バックオフ」で再送間隔を伸ばしていきます。最初は minimal_backoff_time の値で再送を試み、失敗するたびに間隔を倍々に伸ばし、最終的に maximal_backoff_time に到達した後はその値で再送し続けます。
# Postfixのデフォルト値を確認する $ postconf -d minimal_backoff_time maximal_backoff_time queue_run_delay minimal_backoff_time = 300s maximal_backoff_time = 4000s queue_run_delay = 300s
記事の冒頭で「デフォルトでは、60秒」と書いていますが、これはPostfix 2.x の古い時代の話で、現代のPostfix 3.x では300秒がデフォルトです。バージョンによって既定値が異なる点に注意してください。
main.cf で再送信時間を設定する基本手順
main.cf を編集して、再送信間隔を変更します。設定ファイルは通常 /etc/postfix/main.cf にあります。# main.cf を編集する $ sudo vi /etc/postfix/main.cf # 再送間隔を最小180秒、最大1800秒（30分）に設定する例 minimal_backoff_time = 180s maximal_backoff_time = 1800s queue_run_delay = 180s
設定保存後、Postfixに設定を再読み込みさせます。
# 設定の文法チェック $ sudo postfix check # 設定再読み込み（systemd管理環境） $ sudo systemctl reload postfix # または $ sudo postfix reload
queue_run_delay と minimal_backoff_time の違い
混同しがちな2つのパラメータの違いを整理します。・queue_run_delay：Postfixのqmgrデーモンが deferred キューを「スキャン」する間隔。デフォルト300秒。
・minimal_backoff_time：個別のメッセージを再送するまでの「最小待ち時間」。デフォルト300秒。
queue_run_delay を短くしても、各メッセージの minimal_backoff_time が経過していなければ再送は試みられません。逆に minimal_backoff_time を短くしても、qmgrのスキャン周期である queue_run_delay の解像度でしか実際の再送タイミングは決まりません。
つまり、再送を実質的に早めたい場合は、両方を揃えて短くする必要があります。
| パラメータ | 役割 | デフォルト（Postfix 3.x） |
|---|---|---|
| minimal_backoff_time | 初回再送までの最小待ち時間 | 300s |
| maximal_backoff_time | 再送間隔の上限 | 4000s |
| queue_run_delay | キュー全体のスキャン間隔 | 300s |
| maximal_queue_lifetime | メッセージをキューに保持する最大時間 | 5d |
postconf コマンドで現在の設定を確認する
main.cf を直接 grep してもよいですが、postconf コマンドのほうが安全で確実です。コメントアウトや上書きの影響を反映した「実際に有効な値」を返してくれます。# 現在有効な値を確認する $ postconf minimal_backoff_time maximal_backoff_time queue_run_delay minimal_backoff_time = 180s maximal_backoff_time = 1800s queue_run_delay = 180s # main.cf に明示的に書かれた項目だけを表示する $ postconf -n | grep backoff maximal_backoff_time = 1800s minimal_backoff_time = 180s
deferred キューを即時にフラッシュして再送信を強制する：postqueue -f
「設定変更したから今すぐ再送して確認したい」という場面は現場で頻発します。再送タイマーを待たずに deferred キューを即時フラッシュするには、postqueue -f を使います。# deferred キューの内容を確認する $ sudo postqueue -p -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- A12B3C4D5 1234 Fri May 16 14:23:11 sender@example.com user@dest.example.com # キューを即時に再処理する $ sudo postqueue -f
【重要】Postfixの再送信間隔を短くしすぎる時の落とし穴
「再送間隔を10秒にすれば早く配送できる」と考えがちですが、これは現場で必ずトラブルを引き起こします。私がセミナーで3,100名以上を指導してきた中で、再送間隔の短縮による事故を何度も目にしてきました。・DNSキャッシュサーバーへのレートリミット抵触：再送のたびにMXレコードを引きに行くため、外部DNSキャッシュサーバー（Google Public DNS等）から一時的にレートリミットでブロックされる
・宛先SMTPサーバーからのIPブロック：短時間に同じ宛先へ大量の再送試行を行うとスパム判定され、送信元IPがブロックされる
・queue.q が肥大化してdisk fullに：連続再送でログとキュー領域が圧迫される
・グレーリスティング対策に逆効果：多くのメールサーバーは「短時間で何度も来るメールは怪しい」と判断する。1分以上空けるのが現代の常識
私の現場での推奨値は、minimal_backoff_time = 180s（3分）、maximal_backoff_time = 3600s（1時間）程度です。商用環境でデフォルトより短くする場合でも、180s 未満には絶対に下げないでください。
maximal_queue_lifetime：Postfixがメッセージをキューに保持する最大時間
再送し続ける期間にも上限があります。maximal_queue_lifetime がそれで、デフォルトは5日（5d）です。この時間を超えても送信できないメッセージは、送信者に「配送失敗（Undelivered Mail Returned to Sender）」のメールが返り、deferred キューから削除されます。# 配送諦め時間を3日に短縮する例 $ sudo vi /etc/postfix/main.cf maximal_queue_lifetime = 3d bounce_queue_lifetime = 3d
「postfix/qmgr: warning: ...」がログに出た時の対処
設定変更後にログを確認すると、qmgr が警告を出すことがあります。/var/log/maillog または journalctl -u postfix で確認できます。# Postfixのログを確認する（RHEL系） $ sudo tail -f /var/log/maillog # systemd journal で確認する（Ubuntu系） $ sudo journalctl -u postfix -f # qmgrが minimal_backoff_time の値を無効と判断した時の典型例 postfix/qmgr[1234]: warning: minimal_backoff_time is greater than maximal_backoff_time
本記事のまとめ：Postfix再送信時間の設定早見表
Postfixの再送信時間設定の要点を一覧化しておきます。| やりたいこと | コマンド・設定 |
|---|---|
| デフォルト値を確認する | postconf -d minimal_backoff_time maximal_backoff_time |
| 現在の有効値を確認する | postconf minimal_backoff_time maximal_backoff_time |
| main.cfに明示された値だけ確認する | postconf -n | grep backoff |
| 再送間隔を変更する | sudo vi /etc/postfix/main.cf で minimal_backoff_time / maximal_backoff_time を設定 |
| 設定を反映する | sudo systemctl reload postfix |
| deferredキューを即時フラッシュする | sudo postqueue -f |
| キューの内容を確認する | sudo postqueue -p |
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Postfixでメールキューの内容を確認する
- 前のページへ：Postfixでメールサイズの制限を設定する｜main.cf編集と関連パラメータ整合性確認
- この記事の属するカテゴリ：Linuxtips・Postfix・サーバー管理・メールサーバー管理へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます