Postfixのメールログの探し方・読み方・使い方を解説

Last Updated on 2024.11.12

メールにトラブルが起きた際には、メールの送信ログを確認することで何が原因か判断することができます。しかし、そもそもメールの送信ログがどこに保存されているのかわからない、ログを取得できても見方がわからない、という悩みもよく耳にします。ログを読むことを諦め、トラブルの原因を追求しないままメールを運用し続けている方も多いのではないでしょうか。

ですが、メールのトラブルを放置することはメール到達率の低下に大きな影響をおよぼします。送信ログの取得方法や読み方をしっかり学び、メールサーバーに起きている問題を把握し、解決できるようにしておきましょう。
本稿では、昨今多くのメールサーバーで利用されているMTAの「Postfix」を例に、メールログの確認方法や読み方についてまとめました。

メールログファイルの保存場所を探す方法

昨今、三大MTAと呼ばれるものにはPostfix・Sendmail・qmailがありますが、各MTAのメールログの保存場所はシステムの構成によって多少異なるものの、大抵の場合は以下のディレクトリに保存されています。

⚫︎　/var/log/maillog

⚫︎　/var/log/mail.log

⚫︎　/var/adm/maillog

⚫︎　/var/adm/syslog/mail.log

上記の場所にない場合は、「各ミドルウェアの設定ファイル(config)」および「/etc/rsyslog.conf」（※CentOS7の場合）でメールログの保管場所がどこになっているか検索してください。

メールログの読み方

本稿ではPostfixのメールログの読み方をご紹介しますが、ほかのMTAの場合でも大きく変わりません。

ログに含まれている情報

メールログには、大まかに以下の内容が含まれています。

①　処理の発生日時

②　ホスト名

③　プロセス名

④　メールキューID

⑤　内容

　　⚫︎　送信元SMTPサーバー

　　⚫︎　メッセージID

　　⚫︎　送信元のメールアドレス

　　⚫︎　送信先のメールアドレス

　　⚫︎　送信結果

ログの解説

メールログは、1通のメールに対し1行の文章ではなく、複数行に跨ってログが出力されます。

今回は、実際の環境を利用し、あるアプリケーション（baremail.jp）が外部ドメイン（link.co.jp）に対してメール送信する場合のMTA（Postfix） の配信ログの見方について解説します。

メール送信環境の構成イメージは以下のとおりです。

メールログは以下の流れで出力されます。

① 送信元からのSMTP接続ログ

まず、メール送信元であるアプリケーションからのSMTPログは以下のとおり出力されます。

アプリケーションからMTAまでのSMTP通信が確立されると、２行目にあるようにメールキューID（EE294BC02A6）が生成されます。

メールキューIDとは、サーバー内部でメールを処理するときに付与されるユニークなIDで、メール送信が完了するまでログに記載されます。以下②で記載されるメッセージIDもメールを特定するためのユニークなIDですが、こちらはログの1行目にしか記載されません。

そのため、複数行に分割されるログを解析するには、メールキューIDを基準に次の②〜⑤のログを追っていく必要があります。

② メッセージIDと送信元メールアドレス（エンペロープFrom）のログ

SMTP接続後、メールを特定するためのメッセージID・送信元メールアドレスの情報が記載されます。ここで記載される送信元メールアドレスが、エンベロープFromアドレスになります。

③ 送信元とのSMTP切断ログ

メール送信元のアプリケーションから、メール送信に必要な情報がすべてMTAへ渡されるとSMTP接続が切断されます。

④ 送信先へのメール送信ログ

外部ドメインの宛先（link.co.jp）にメールを送信しているときのログが以下です。

※送信先が複数の場合は、以下ログが送信先分出力されます。

＜ログに記載されている項目＞

⚫︎「to=」        ：送信先メールアドレス情報

⚫︎「relay=」   ：送信先SMTPサーバ情報

⚫︎「delay=」   ：メール送信の処理時間

⚫︎「status=」  ：送信結果

⚫︎「末尾の()内」：送信先SMTPサーバからの応答コードおよびメッセージ

sent以外の場合は、メールの送信ができていない状態となりますので「末尾（）内」に記載される内容より、送信ができなかった原因を確認する必要があります。

⑤ メールキューの削除（メール送信処理終了）

メール送信が完了すると、最終的にメールキューを削除し、送信処理が完了となります。

ログの操作について

メールログはメールが送信されてから、相手先のサーバーに届くまでの間に発生した処理のすべてが記録されており、関連する処理はメールキューIDで管理されます。

そのため、より詳しく調査したい場合は、対象となるメールのアドレスや日時などの条件で検索し、該当の処理に対して振り分けられているメールキューIDをキーにログの絞り込みを行う必要があります。ここからはその方法を記述します。

以下1・２のように、特定の文字列（パターン）が含まれている行を検索する際には、「grep」コマンドを使用します。

メールアドレスなど、特定の条件で検索する

メールアドレス指定：grep 202107exmple@link.co.jp /var/log/maillog

日時指定              　　：grep “Jul 26 08:” /var/log/maillog

※ログファイルの保存場所や日時の表記は、その環境の設定によります。

キューIDをもとに、特定のメールにおけるすべての処理を確認する

キューID指定　　　：grep EE294BC02A6 /var/log/maillog

※注意：キューIDで抽出した場合、Connectionログ・Disconnectionログは表示されません。

抽出したログをもとに、エラー内容などを確認する

例）特定のメールが送信できなったため、その原因を知りたい。

statusが表示されている行を確認します。

sent以外の場合は、メールの送信ができていない状態となりますので、「末尾（）内」に記載される内容より、送信ができなかった原因を確認する必要があります。こちらには必ず「xxx x.x.x」といった3桁の数字から始まるSMTPエラーコードが記載されます。

例えば、「4xx x.x.x 」などの400番台のSMTPエラーコードの場合は、一時的なエラー（ソフトバウンス）が原因のため、時間をおいてから再送することで届くケースがあります。

一方、500番台のSMTPエラーコードの場合は永続的なエラー（ハードバウンス）のため、何かしらの対応が必要となります。

SMTPエラーコードについては、こちらの記事で詳しく解説しておりますのでぜひご参照ください。

補足：　ログデータの保管量について

ログファイルは自動で更新され、一定期間が経過すると別のファイル名が付けられ世代管理されます。そのため、長く運用すればするほどログデータが膨大になり、メールサーバーのディスクを使い切ってしまいかねないため、定期的に自動、もしくは手動でログデータを削除する必要があります（ログローテート）。

さいごに

メールログを取得・確認することで、メールが送信できなかった原因に対し適切な対応をすることや、到達率を改善するためのメール運用環境を整えることが可能になります。また、メールを起因とするセキュリティインシデント（不正アクセス・情報漏洩など）発生時の原因究明にも役立ち、迅速な対処をすることで被害をおさえられるというメリットもあります。

しかし、メールログを取得できてもその読み方がわからなければ対処のしようもなく、対応には専門的な知識が必要となるケースも出てきます。また、何か起こるたびに技術担当者に依頼してサーバーのメールログを調査してもらうというのも手間と時間がかかり、担当者の負担にもなりかねません。

当社のメールリレーサービス「ベアメール」を利用するきっかけとして、お客さまから「メールログの確認の仕方や読み方がわからなかった」「ログを確認する時間があまり取れない」「いちいちログを調査するのが面倒」といったお声をよくお聞きします。

ベアメールは、そうしたお客さまの声に応えるべく、メールログを管理画面から誰でも簡単に、かつリアルタイムに確認できる便利な機能を搭載しています。実際に送信先から返された結果（ログ）をシンプルにわかりやすく表示するため、調査・解析する手間や専門的な知識も必要なく、今までログの確認に取られていた労力を削減し業務の効率化が図れます。メール配信で課題をお持ちなら、ベアメールにご相談ください。