メールサーバーが止まったときは、まず「送れない・受け取れない・読めない」のどれが起きているかを切り分け、次にキューの中のメールを失わないように守ってから原因を直す、という順番で進めるのが安全です。受信側は相手のサーバーが数日間は再送を続けるため、数時間の停止なら多くのメールは後から届きます。この記事では、Postfix と Dovecot で構成した一般的なLinuxメールサーバーを例に、症状別の切り分け、復旧作業、再送の確認、そして次の障害に備える準備までを解説します（2026年10月現在の Ubuntu・RHEL 系の標準パッケージを想定しています）。
最初の5分でやること：症状を3つに分ける
障害の連絡が来たら、いきなり再起動せずに状況を記録します。再起動で一時的に直っても、原因が分からないまま同じ障害が繰り返されるからです。
症状はおおむね次の3つに分かれ、それぞれ見るべき場所が違います。
- 送信できない：メールソフトからの送信（587番・465番）か、Postfixから外部への配送（25番）のどちらかで止まっている
- 受信できない：外部から25番で受け付けられていないか、受け付けた後のローカル配送で止まっている
- 読めない：メールは届いているが、Dovecot（IMAP・POP3）にログインできない、またはメールボックスが開けない
# サービスの状態
systemctl status postfix dovecot --no-pager
# 待ち受けポート（25, 465, 587, 993, 995）
ss -tlnp | grep -E ':(25|465|587|993|995) '
# 直近のエラー（Debian/Ubuntu は /var/log/mail.log、RHEL系は /var/log/maillog）
journalctl -u postfix -u dovecot --since "1 hour ago" -p warning --no-pagerログの場所はディストリビューションによって違い、rsyslog を入れていない環境では journalctl でしか見られません。どちらで記録しているかを平常時に確認しておくと、障害時に迷わずに済みます。
原因になりやすい箇所と復旧方法
ディスク容量・inodeの枯渇
メールサーバーの障害で最も多い原因の一つです。Postfix はキューの置き場に十分な空きがないと受信を一時的に拒否し、ログに Insufficient system storage と記録します。容量だけでなく、小さなファイルが大量にできる Maildir ではinodeが先に尽きることもあります。
df -h /var /var/spool/postfix /home
df -i /var /home
du -sh /var/log/* | sort -h | tailログの肥大化が原因なら、logrotate の設定を見直してから古いログを圧縮・移動します。ユーザーのメールボックスが原因の場合は、勝手に削除せず、容量制限（クォータ）の導入やユーザーへの整理依頼で対応します。空きができれば、Postfix は特に操作しなくても受信を再開します。
設定ファイルの誤り
パッケージ更新や手作業の変更の直後に止まった場合は、設定ミスを疑います。Postfix と Dovecot にはそれぞれ設定の検査コマンドがあります。
postfix check # 権限やファイルの不整合を検査
postconf -n # 既定値から変更している設定だけを表示
doveconf -n # Dovecot の有効な設定を表示（構文エラーがあればここで分かる）postconf -n の出力を平常時に保存しておけば、障害時に差分を取るだけで変更箇所が分かります。
TLS証明書の期限切れ
証明書が切れると、メールソフトによっては送受信がまとめて失敗します。外部から実際に接続して有効期限を確認します。
openssl s_client -connect mail.example.com:587 -starttls smtp -servername mail.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -enddate
openssl s_client -connect mail.example.com:993 -servername mail.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -enddateLet's Encrypt の自動更新で証明書自体は新しくなっていても、Postfix や Dovecot を再読み込みしていないために古い証明書を提示し続けていることがあります。更新後に systemctl reload postfix dovecot を実行するフックを入れておくと防げます。
DNS・ブラックリスト・ポート制限
送信だけが失敗する場合は、相手先に拒否されているのか、そもそも接続できていないのかをログで区別します。status=deferred に Connection timed out が続くなら、VPS事業者による25番ポートの外向き制限やファイアウォールが疑われます。550 や 554 で拒否されているなら、SPF・DKIM・逆引き（PTR）の不備や、IPアドレスがブラックリストに載っている可能性があります。
dig +short MX example.com
dig +short -x 192.0.2.25 # 送信IPの逆引き
dig +short TXT example.com # SPFDovecotのメールボックス・インデックス破損
「ログインはできるが受信箱が開けない」「件数がおかしい」といった症状は、インデックスの破損が原因のことがあります。Dovecot のインデックスはメール本体から作り直せるため、次のコマンドで再同期できます。
doveadm force-resync -u user@example.com INBOXこのコマンドが扱うのはインデックスで、メール本体は消えません。ただし実行前にそのユーザーのメールボックスをコピーしておくと安心です。
キューのメールを守り、復旧後に再送する
送信側で配送が止まっていた間のメールは、Postfix のキューに溜まっています。キューの中身は原因が直れば自動で再送されるため、慌てて削除しないことが何より大切です。
postqueue -p | tail -n 1 # キューの総件数
postqueue -p | less # 宛先と保留理由の一覧
postcat -q QUEUE_ID | less # 個別メールの中身とヘッダー原因を直したら、再送を待たずに即時配送を試みます。
postqueue -f特定の宛先ドメインだけ溜まっている場合や、送信先の制限を受けたくない場合は、一度保留にしてから少しずつ戻す方法もあります。
postsuper -h ALL deferred # deferred キューをすべて保留に
postsuper -H QUEUE_ID # 個別に保留を解除一方、スパムの踏み台にされて大量の不正メールがキューに入った場合は、正規のメールまで消さないよう、送信者や宛先で絞り込んでから postsuper -d で削除します。postsuper -d ALL はキュー全体を消す取り消しのきかない操作なので、実行前に /var/spool/postfix を丸ごとバックアップしてください。
なお、Postfix は配送できないメールを既定で5日間（maximal_queue_lifetime）保持して再送を続けます。外部のメールサーバーも同様に数日間は再送するため、受信側の停止が数時間で済めば、多くのメールは復旧後に届きます。相手から届いていないと言われた場合でも、まずは時間を置いて再送を待つのが現実的な判断です。
サーバーが再起動できないときの復元
ハードウェア障害やOSの破損でサーバー自体が戻らない場合は、別のサーバーに復元します。メールサーバーの復元に必要なのは、次の組み合わせです。
- 設定：
/etc/postfix、/etc/dovecot、OpenDKIMなどの関連設定 - 秘密鍵類：TLS証明書と鍵、DKIMの秘密鍵
- ユーザー情報：仮想ユーザーのパスワードファイルやDB
- メール本体：Maildir などのメールボックス
- 未配送のメール：
/var/spool/postfix（可能であれば）
DKIM鍵を失うと、DNSの公開鍵を作り直すまで署名が通らなくなります。メールボックスは所有者（vmail など）と権限を保ったまま戻さないと、Dovecot が読めません。rsync -aHAX のように所有者・ハードリンク・ACLを保持するオプションで転送するのが無難です。
新しいサーバーのIPが変わる場合は、MXが指すAレコード、逆引き（PTR）、SPFレコードをすべて更新し、DNSのTTL分だけ切り替えに時間がかかることを関係者に伝えます。
次の障害に備える事前準備
障害対応の速さは、ほとんど事前準備で決まります。最低限、次のものを用意しておくと復旧時間が短くなります。
- 監視：25・587・993番への接続、証明書の残り日数、ディスクとinodeの使用率、キューの件数を監視し、しきい値を超えたら通知する
- バックアップ：設定・鍵・メールボックスを定期的に別の場所へ保存し、実際に別サーバーで戻せるかを年に一度は試す
- 平常時の記録：
postconf -n、doveconf -nの出力、DNSレコードの一覧を保存しておく - 連絡手段：メールが止まったときに利用者へ知らせる別の経路（チャットや電話）を決めておく
- 手順書：この記事のような切り分け手順を、自分の環境のパスやコマンドに書き換えて手元に残す
キューの件数は、次のような短いスクリプトで定期的に確認できます。
#!/bin/bash
# キュー件数が閾値を超えたら標準出力に警告を出す（cron から実行して通知に回す想定）
THRESHOLD=200
COUNT=$(postqueue -j 2>/dev/null | wc -l)
if [ "$COUNT" -gt "$THRESHOLD" ]; then
echo "WARNING: postfix queue has ${COUNT} messages (threshold ${THRESHOLD})"
fipostqueue -j はキューの内容を1件1行のJSONで出力するため、行数がそのまま件数になります（Postfix 3.1 以降で使えます）。
まとめ
- 再起動の前に、送信・受信・閲覧のどこが止まっているかを切り分け、ログを記録する
- 原因はディスク・inodeの枯渇、設定ミス、証明書の期限切れ、DNSや25番ポートの制限が多い
- キューのメールは原因を直せば自動で再送される。削除せず、
postqueue -fで再送を促す - 外部のサーバーは数日間再送するため、短時間の受信停止なら多くのメールは後から届く
- 復元には設定・鍵・ユーザー情報・メールボックスの4点が必要。権限ごと戻す
- 監視・バックアップ・平常時の設定記録が、次の障害の復旧時間を短くする