Postfixログの見方とメール配送トラブルの調べ方
場所の確認から、Queue IDでの追跡、配送結果の判断、現在のキューの確認まで。サーバー管理者向けに、ログの読み方を順番に解説します。
公開・更新:
ログの出力先を確認する
まず対象サーバー、発生日時、タイムゾーン、送信元・送信先を整理します。Postfixは通常syslogに記録しますが、独自のロギングも利用できます。/var/log/maillogや/var/log/mail.logは代表例で、OS名だけでは出力先を確定できません。
postconf mail_version maillog_file
sudo tail -n 100 /var/log/maillog
maillog_fileが空ならsyslog側の出力先を確認します。設定は/etc/rsyslog.confや/etc/rsyslog.d/など、利用しているログサービスによります。古いPostfixではこのパラメーターが存在しない場合があります。非空ならPostfix自身の出力先設定を確認します。
systemdのjournalを利用する環境では、sudo journalctl --since '2026-09-20 10:00:00' --until '2026-09-20 11:00:00'のように期間を絞り、Postfixのプロセス名を探します。サービス単位の絞り込みだけでは別インスタンスの記録を見落とすことがあります。日時は調査対象とサーバーのタイムゾーンに合わせて置き換えてください。
ログが見つからない場合は、読み取り権限、サービスの稼働、syslogの振り分け、ローテーション済みファイル、コンテナの標準出力を順に確認します。ファイルがないことだけでは「配送がなかった」と判断できません。出力設定の詳細はPostfix公式のログ出力ガイドと調査ガイドを参照してください。
ログの実例をQueue IDで読む
以下は項目を説明するための架空のログです。アドレス・IP・Queue IDは実環境の値ではありません。実際の書式はバージョン、配送方式、ログ設定によって変わります。
Sep 20 10:15:01 mail postfix/smtpd[1201]: 4F2A812345: client=client.example.org[192.0.2.10]
Sep 20 10:15:01 mail postfix/cleanup[1202]: 4F2A812345: message-id=<example-001@example.org>
Sep 20 10:15:01 mail postfix/qmgr[1203]: 4F2A812345: from=<sender@example.org>, size=2048, nrcpt=1 (queue active)
Sep 20 10:15:02 mail postfix/smtp[1204]: 4F2A812345: to=<recipient@example.net>, relay=mx.example.net[198.51.100.20]:25, delay=1.2, delays=0.1/0.1/0.4/0.6, dsn=2.0.0, status=sent (250 2.0.0 accepted)
Sep 20 10:15:02 mail postfix/qmgr[1203]: 4F2A812345: removed
この例は4F2A812345というQueue IDでつながっています。smtpdが接続元を記録し、cleanupがメッセージを処理、qmgrが配送対象を管理し、smtpがrelayへ渡します。Postfix公式の構成図でも各プロセスの役割を確認できます。
| 項目 | 確認する内容 |
|---|---|
| 日時・ホスト・PID | どのサーバーのどのプロセスが記録したか。年がないsyslog形式では、ファイルの保管時期も確認します。 |
| client / from / to | 接続元ホスト・IP、エンベロープ送信元、配送対象の宛先。ヘッダーのFrom・Toとは別の情報です。 |
| size / nrcpt | メッセージサイズと宛先数の手掛かり。複数宛先は配送結果をそれぞれ確認します。 |
| relay / dsn / status | 次の配送先、配送状態通知コード、配送結果。行末の応答文と一緒に読みます。 |
| removed | そのキューのメッセージが取り除かれた記録。これだけで全宛先への成功を意味しません。 |
sudo grep -F '4F2A812345:' /var/log/maillog
対象IDとパスを置き換え、前後のログも調べます。転送やフィルター通過で新しいIDが付くことがあり、Queue IDは複数サーバーを通して一意とは限りません。同じサーバーでも再利用の可能性があるため、日時やmessage-idも照合します。
配送失敗・遅延を切り分ける
- 受付の有無:
NOQUEUE: rejectならキュー投入前の拒否を調査します。SASL authentication failedなどがあれば認証方式や接続元、時刻を確認します。 - 宛先ごとの結果:
sentはその配送処理の成功、deferredは一時保留、bouncedは恒久的な失敗です。SMTP配送先が受け付けても、受信箱への格納や既読は保証しません。 - 応答と時間:DNS解決失敗、接続タイムアウト、相手側の拒否など、実際のエラーメッセージで切り分けます。接続先や応答内容を見ずにネットワーク障害と決めつけないでください。
- 後続の試行:deferredのあとにsentがあるか、キューに残っているかを確認します。調査期間の最後の状態だけで過去の一時障害を見落とさないようにします。
delayは配送までの経過時間、delays=a/b/c/dは、受け付けから最後のactiveキュー入りまで/そこから接続開始まで/接続の準備/メッセージ転送、という時間の内訳です。接続準備にはDNSやSMTP・TLSのやり取りが含まれる場合があります。詳細はPostfix公式のdelay表示仕様を確認してください。
詳細ログは必要な相手と期間に限定します。ログレベルを無制限に上げると容量が増え、機密情報の扱いも難しくなります。設定変更は公式のデバッグ手順に沿って行い、調査後に戻します。
現在のキューと本文を確認する
postqueue -p
キューID、サイズ、到着時刻、送信元、未配送の宛先や前回の失敗理由を確認できます。*はactive、!はholdの印です。現在のキューは変化するため、過去ログの件数とは一致しません。対応バージョンではpostqueue -jでJSON Lines形式を取得できます。postqueue公式マニュアル
通常の配送ログにはメール本文全体は記録されません。権限があり、メッセージがまだキューに存在するときは、管理者がsudo postcat -q QUEUE_IDで内容を確認できます。QUEUE_IDを対象IDに置き換えてください。出力には本文や個人情報が含まれるため、公開サイトや問い合わせにそのまま貼らないでください。postcat公式マニュアル
このページの確認コマンドはキュー削除や再送要求を行いません。原因の調査前に一括削除すると、確認したかったメールが失われます。
過去ログの可視化とLIVE監視
大量の行を追う場合は、LogGraphicのデスクトップアプリに保存済みPostfixテキストログを読み込み、開始日時、Queue ID、アドレスなどで絞り込めます。ブラウザー上のこの解説ページへログを送る機能ではありません。
ADDRESS FLOWではメールアドレス間、MAIL FLOWでは実際のrelayサーバーへの配送を表示します。時刻に沿った再生・一時停止・早送りに対応し、SSH接続を設定すればLIVE監視もできます。DKIM表示はログに記録された処理の可視化であり、メールの署名を独立に再検証する機能ではありません。
ログ調査のよくある質問
status=sentなら必ず相手の受信箱に届いていますか?
いいえ。SMTP配送では次の配送先が受け付けたことを示します。最終受信箱への格納や既読は保証せず、後続の転送や迷惑メール隔離を確認する必要がある場合があります。
ログから削除済みのメール本文を復元できますか?
通常の配送ログには本文全体が含まれないため、本文の復元はできません。残っているキューファイルや、別途保管したメール・バックアップを確認します。
deferredの行数は失敗したメールの通数ですか?
一致するとは限りません。同じメールの再試行や複数宛先で複数行になります。宛先、Queue ID、日時、後続の結果を合わせて確認します。