Postfixのログ確認とトラブルシューティング：ログの読み方と原因別の対処

Postfix でメールが届かない、送れないといったトラブルは、ほとんどの場合メールログに理由が書かれています。この記事では、ログの場所とログ1行の読み方、キューIDを使って1通のメールを追う方法を説明したうえで、よくある原因を起こりやすい順に並べ、それぞれの確認方法と対処を紹介します。

ログはどこにあるか

Postfix のログは、多くの環境で syslog 経由で書き出されます。

• Debian / Ubuntu: /var/log/mail.log
• RHEL / AlmaLinux / Rocky Linux: /var/log/maillog
• rsyslog が入っていない環境: ファイルは作られず、systemd の journal にだけ記録されます。最近の Debian では rsyslog が既定で入らないため、ファイルが見つからないときはこちらを疑ってください。

journal から読む場合は次のようにします。ユニット名は環境によって postfix や postfix@- などになるため、見つからなければ systemctl list-units | grep postfix で確認します。

sudo journalctl -u postfix --since "1 hour ago"
sudo tail -f /var/log/mail.log

Postfix 3.4 以降では、syslog を使わず maillog_file で専用のログファイルに書き出す設定もできます（2026年10月現在）。利用中のバージョンは postconf mail_version で確認してください。

ログ1行の読み方

送信が成功したときの典型的な行は次のような形です（値は例です）。

Oct 28 10:15:02 mail postfix/smtp[12345]: 4ABCD1234E: to=<user@example.net>, relay=mx.example.net[203.0.113.10]:25, delay=1.2, delays=0.05/0.01/0.6/0.54, dsn=2.0.0, status=sent (250 2.0.0 OK)

各項目の意味は次のとおりです。

• postfix/smtp: どのプロセスが書いたか。smtpd は受信、smtp は外部への送信、qmgr はキュー管理、cleanup はメッセージの整形、local や lmtp はローカル配送です。
• 4ABCD1234E: キューID。1通のメールに付く番号で、この値で検索すると受付から配送までの流れがつながります。
• relay: 実際に接続した相手のサーバー。
• delays=a/b/c/d: a はキューに入るまで、b はキューでの待ち時間、c は接続確立（DNS・TLS 含む）、d は送信にかかった時間です。どこで時間がかかっているかの見当がつきます。
• dsn と status: status=sent は相手に渡せた、deferred は一時的な失敗で再試行中、bounced は恒久的な失敗で差出人に通知済み、という意味です。括弧内は相手サーバーの応答そのものです。

1通のメールを追う手順

1. 送信時刻と宛先で、該当する行を探します。

sudo grep "to=<user@example.net>" /var/log/mail.log | tail -n 5

1. 見つかった行のキューIDで全体を検索します。

sudo grep "4ABCD1234E" /var/log/mail.log

1. まだキューに残っているメールは、キューの一覧と中身で確認できます。

sudo postqueue -p
sudo postcat -vq 4ABCD1234E

キューに溜まったメールをまとめて再送したい場合は sudo postqueue -f を使います。原因を直さずに再送しても同じエラーになるだけなので、先に原因を潰してください。キューのメールを削除する postsuper -d は取り消せない操作です。削除してよいか（正規のメールが混ざっていないか）を確認してから実行します。

よくある原因と対処（起こりやすい順）

1. 外向きの25番ポートが塞がれている

ログに connect to ...:25: Connection timed out が並ぶ場合、クラウドや VPS の事業者が迷惑メール対策として外向きの25番ポートを止めていることが多いです。

• 確認: nc -vz mx.example.net 25 などで外部の MX サーバーの25番に接続できるか試します。
• 対処: 事業者の申請手続きで解除してもらうか、外部の SMTP リレーサービスを relayhost に指定し、587番ポートと認証で送ります。

2. リレーの拒否（Relay access denied）

554 5.7.1 ... Relay access denied は、自分のサーバーが、許可されていない送信者からの中継を断ったときのメッセージです。

• 確認: postconf mynetworks smtpd_relay_restrictions で、どの送信元に中継を許しているかを見ます。
• 対処: メールソフトや WordPress から送る場合は、mynetworks を広げるのではなく、587番ポートで SMTP 認証をして送る構成にします。mynetworks を広げすぎると第三者に悪用される「オープンリレー」になります。

3. 相手サーバーに認証不備で拒否される

550 5.7.26 や SPF・DMARC に触れたエラー文は、送信ドメイン認証が通っていないことを示します。送信元のドメインの SPF レコードに自分のサーバーの IP が含まれているか、DKIM 署名が付いているかを確認します。

4. DNSの名前解決に失敗する

Host or domain name not found や Name service error が出る場合、宛先ドメインの MX が引けていないか、サーバーの DNS 設定に問題があります。

• 確認: dig +short MX example.net で MX が返るか。
• 対処: 宛先の誤字を確認し、サーバー側の resolver 設定を見直します。Postfix を chroot で動かしている場合、chroot 内の etc/resolv.conf が古いままになっていることがあります。

5. リレー先へのSMTP認証に失敗する

relayhost を使っていて SASL authentication failed が出る場合は、資格情報の設定ミスです。

• 確認: /etc/postfix/sasl_passwd のホスト名とポートの書き方が relayhost の値と一致しているか、変更後に postmap を実行したか。
• 対処: ファイルを直したら sudo postmap /etc/postfix/sasl_passwd と sudo systemctl reload postfix を実行します。このファイルにはパスワードが平文で入るため、権限を 600（root のみ読み書き）にしてください。

6. TLSのエラー

TLS library problem や certificate verify failed は、証明書の期限切れやホスト名の不一致、相手側が古いプロトコルしか使えない場合に出ます。openssl s_client -starttls smtp -connect mx.example.net:25 で相手側の証明書を確認できます。

7. ディスク容量やキューの肥大化

No space left on device や not enough free space が出る場合は、ディスクが逼迫しています。df -h で空きを確認し、キューに大量の迷惑メールが溜まっていないか postqueue -p | tail -n 1 で件数を見ます。急にキューが増えたときは、フォームの悪用やアカウントの乗っ取りによる不正送信を先に疑ってください。

ログの詳細度を一時的に上げる

通常のログで理由がわからないときは、特定の相手との通信だけ詳しく記録できます。

sudo postconf -e 'debug_peer_list = mx.example.net'
sudo systemctl reload postfix

調査が終わったら空に戻して reload します。詳細ログはサイズが大きく、通信内容の一部も含まれるため、つけっぱなしにしないでください。設定の変更前には postconf -n > ~/postconf-backup.txt のように現在値を控え、変更後は sudo postfix check で設定ファイルやパーミッションの問題がないか確認すると安全です。

日々の確認を楽にする

毎日ログを目で追うのは大変なので、pflogsumm のような集計ツールで送信数・バウンス数・拒否の理由を日次でまとめると、異常に気づきやすくなります。キューの滞留状況を宛先ドメインごとに見たい場合は qshape も役に立ちます（どちらもディストリビューションによって別パッケージです）。

まとめ

• ログは /var/log/mail.log（Debian/Ubuntu）か /var/log/maillog（RHEL 系）、無ければ journal を見る。
• 1行の中では、キューID、relay、delays、dsn、status と括弧内の応答に注目する。
• キューIDで検索すると1通の流れを追える。キューの中身は postqueue -p と postcat -vq で確認する。
• 多い原因は、25番ポートの遮断、リレー拒否、送信ドメイン認証、DNS、リレー先の認証、TLS、ディスク容量。
• 詳細ログは調査中だけ有効にし、終わったら戻す。

• Postfixのメールキュー管理
• SMTP認証（SASL）の設定方法