はじめに (対象読者・この記事でわかること)

この記事は、Linuxサーバ上で Postfix を運用しているシステム管理者や、メールシステムの挙動をカスタマイズしたいエンジニアを対象としています。
Postfix が外部ホストへの配送に失敗した際に、デフォルトで行われる再試行(リトライ)を無効化し、即座にバウンス(エラーメール)を送信者へ返す設定方法が具体的に分かります。設定ファイルの書き換えから、ポストマスターの再起動、テストメールによる検証手順までを実践的に解説するので、すぐに本番環境へ適用できる知識が身につきます。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。
- 基本的な Linux コマンド操作(catpostconfsystemctl など)
- Postfix の基本構成(main.cfmaster.cf)とメールキューの概念
- SMTP の基礎知識(送信者、受信者、ステータスコード)

背景と要件:リトライをやめて即時バウンスを返す理由

Postfix はデフォルトで配送失敗時に一定回数リトライを行い、最終的にキューに残すかバウンスメールを送ります。
しかし、業務システムやプライベートサービスでは、以下のような要件が出てくることがあります。

  1. 即時フィードバックが必要
    受信者側の問題(例: アドレス不存在)を送信者に速やかに知らせ、再送や修正を促すべき場面が多い。

  2. キューの肥大化防止
    大量の失敗メールがキューに残るとディスク容量が逼迫し、他の正常メールまで遅延するリスクがある。

  3. 監査・ログの単純化
    リトライが無い分、失敗メールは一度のバウンスで完結するため、ログ解析が容易になる。

これらの要件を満たすために、Postfix の queue_minretry_timemaximal_queue_lifetime の調整だけでなく、bounce プロセスの挙動を直接制御する設定が有効です。以下では、具体的な設定項目とその意味、そして実際にリトライをゼロに設定し、即座にバウンスメールを返す手順を詳細に解説します。

実装手順:リトライを無効化し即時バウンスを返す設定

ステップ 1:main.cf にリトライ回数とリトライ間隔を制御するパラメータを追加

Bash
# /etc/postfix/main.cf に以下を追記 # 失敗したメールは 0 回リトライしてすぐにバウンス default_destination_concurrency_limit = 1 smtp_destination_concurrency_limit = 1 # リトライ待機時間を最小に設定(実質リトライしない) minimal_backoff_time = 1s maximal_backoff_time = 1s # キューに残す最大時間を極端に短くする(例: 5 分) maximal_queue_lifetime = 300s
  • minimal_backoff_timemaximal_backoff_time はリトライ間隔の下限・上限です。1秒に設定することで、Postfix が「リトライしても意味がない」と判断し、即座にバウンスへ移行します。
  • maximal_queue_lifetime を 300 秒(5 分)にすると、キューに残っている間に再試行が行われる時間がほぼ無くなります。

設定を反映させるには postfix reload を実行します。

Bash
sudo postfix reload

ステップ 2:master.cf で bounce プロセスのキュー優先度を上げる

Postfix の bounce サービスは通常、低優先度でキューに入ります。これを即時実行させるために、master.cf に以下の行を追加します。

Bash
# /etc/postfix/master.cf の末尾に追記 bounce unix - - n - 0 bounce -o delay_warning_time=0 -o maximal_queue_lifetime=300s
  • delay_warning_time=0 により、遅延警告メールは出力されません。
  • ここでも maximal_queue_lifetime を短く設定し、bounce キューがすぐに処理されるようにしています。

設定後、postfix reload で反映させます。

ステップ 3:テストメールで動作確認

  1. テスト用の無効ドメインへ送信
    bash echo "Test mail" | mail -s "Postfix retry test" user@nonexistent.example.com nonexistent.example.com は DNS に存在しないドメインです。

  2. キューの確認
    bash sudo postqueue -p キューに残っていないこと、すぐにバウンスメールが送信者に届くことを確認します。

  3. バウンスメールの内容確認
    送信者側のメールクライアントで、以下のようなバウンスメッセージが届くはずです。
    Subject: Mail delivery failed: returning message to sender ... 550 5.1.1 <user@nonexistent.example.com>: Recipient address rejected: User unknown in virtual mailbox table

ハマった点やエラー解決

現象 原因 解決策
リトライがまだ行われる minimal_backoff_time がデフォルトの 1000s のままだった main.cfminimal_backoff_time = 1s を明示的に設定
バウンスメールが送信者に届かない master.cfbounce 行がコメントアウトされたまま 行頭の # を削除し、再度 postfix reload
キューログが大量に溜まる maximal_queue_lifetime がデフォルトの 5d のまま main.cfmaster.cf の両方で maximal_queue_lifetime = 300s を設定

完全な設定例(main.cf + master.cf

Conf
# /etc/postfix/main.cf ... default_destination_concurrency_limit = 1 smtp_destination_concurrency_limit = 1 minimal_backoff_time = 1s maximal_backoff_time = 1s maximal_queue_lifetime = 300s ... # /etc/postfix/master.cf ... bounce unix - - n - 0 bounce -o delay_warning_time=0 -o maximal_queue_lifetime=300s ...

この構成で、Postfix は配信失敗時に リトライせず即座にバウンスメール を送信者へ返すことが保証されます。

まとめ

本記事では、Postfix がメール配送に失敗した際に再試行を行わず、即時にエラーメール(バウンス)を送信者へ返す設定手順を解説しました。

  • リトライ回数・間隔を最小化minimal_backoff_time/maximal_backoff_time を 1 秒に設定
  • キュー寿命を短縮maximal_queue_lifetime を 300 秒に設定し、キュー肥大化を防止
  • bounce プロセスの優先度調整master.cfbounce のオプションを上書きし、即時処理を実現

これにより、システムは失敗メールを瞬時に通知し、運用上のリスクとディスク使用量を抑えることができます。今後は、複数ドメインや SPF/DKIM の連携と組み合わせた高度なバウンス制御や、モニタリングツールとの統合についても検討していく予定です。

参考資料