Linuxのメール送信が突然できなくなった日の話｜PostfixではなくDNSが原因だと気づくまで2時間かかった経験と障害診断の考え方

ＨＯＭＥ ＞ リナックスマスター.JP 公式ブログ ＞ Linux学習ガイド ＞ Linuxのメール送信が突然できなくなった日の話｜PostfixではなくDNSが原因だと気づくまで2時間かかった経験と障害診断の考え方
宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
「Linuxのメール送信が突然できなくなった。」

SE時代の2004年頃、客先に常駐していたときのことです。それまで何事もなく動いていたシステムからアラートメールが来なくなり、夕方になって初めて気づきました。気づいたきっかけも情けない話で、別の作業をしていた同僚から「今日、メール来てる？」と声を掛けられたからです。

すぐにメール送信ができなくなっていることを確認し、私が最初に疑ったのはPostfixでした。当然の判断だと思います。しかし2時間後、原因はPostfixではなくDNSにあることがわかりました。

この記事では、20年以上サーバーを運用してきた経験から、あの日の失敗が教えてくれた「障害診断で疑う範囲を広げる」という考え方についてお話しします。

この記事のポイント

・障害対応では「最も詳しいレイヤー」だけを掘り続けることが最大の落とし穴
・メール送信不可はPostfixだけでなくDNS（名前解決）まで疑う範囲を広げる
・行き詰まったら「隣のレイヤー」を確認し、外部からのテストも必ず入れる
・ログに「送信拒否の理由が見えない」ときはDNS/ネットワーク起因を疑うサイン


Linuxのメール送信が突然できなくなった日の話｜PostfixではなくDNSが原因だと気づくまで2時間かかった経験と障害診断の考え方
「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

なぜ私はPostfixを2時間疑い続けたのか

人はトラブルが起きると、自分が一番よく知っている場所から調べ始めます。私の場合、Postfixの設定を日常的に触っていたので、まずそこを疑うのは自然な判断でした。しかし、これが落とし穴でした。

「自分がよくわかっている場所」は調べやすい。だから、そこに答えがないとわかっても、別の可能性を疑うのが遅くなるのです。

セミナーで3,100名以上を指導してきた中でも、この「詳しい場所に執着して時間を溶かす」パターンは本当によく見ます。特にLinuxを学び始めて2～3年目の方に多い傾向があります。

2時間で確認したこと、できなかったこと

1. maillogに向き合い続けた

まず/var/log/maillogを開きました。PostfixのSMTPプロセスがエラーを出しているはずだと思って。

# /var/log/maillogの該当部分（ホスト名・アドレスはマスク済み）
Sep 15 14:32:18 srv01 postfix/smtp[2841]: 3A9F62C8D1: to=, relay=none, delay=30, status=deferred (Host or domain name not found. Name service error for name=client-xx.co.jp type=MX: Host not found, try again)
Sep 15 14:33:20 srv01 postfix/smtp[2841]: 3A9F62C8D1: to=, relay=none, delay=30, status=deferred (Name service error for name=internal.co.jp type=MX: Host not found, try again)
今見ると「Name service error」という文字がはっきり見えます。DNSを疑えという強烈なサインです。

しかしあのときの私は「relay=none」と「deferred」にしか目がいかず、「PostfixのMX参照設定が何かおかしい」と思い込んでいました。

2. main.cfを何度も見直した

/etc/postfix/main.cfの設定を何度も確認しました。relayhost、mydestination、mynetworks。いずれも変更した覚えはなく、設定値に問題も見当たりません。

「設定は正しいはずなのに、なぜ動かない。」

ここで一度立ち止まれればよかったのですが、私は「見落としがあるはずだ」という気持ちでもう一巡、同じ設定ファイルを見直しました。

3. 行き詰まったとき、同僚に声をかけた

2時間が経った頃、同僚のSEに「ちょっとPostfixの設定見てもらえますか」と声をかけました。彼が一瞥して言ったのが「これ、DNSじゃないですか」という一言でした。

そのときの「…あ」という感覚を今でも覚えています。

メール送信エラーの正体｜原因はDNSの名前解決だった

1. pingで一発で確認できた

同僚に言われた瞬間、外部ドメインへのpingを打ちました。

# 外部ドメインへのping（名前解決の確認）
# ping -c 1 client-xx.co.jp
ping: client-xx.co.jp: Name or service not known

# 内部IPへの直接pingは通る（ネットワーク自体は生きている）
# ping -c 1 192.168.x.x
PING 192.168.x.x: 56 data bytes
64 bytes from 192.168.x.x: icmp_seq=0 ttl=64 time=0.4 ms

# /etc/resolv.confを確認（ネームサーバーのIPを確認）
# cat /etc/resolv.conf
nameserver 192.168.x.1
名前解決はできないが、ネットワーク自体は通っている。典型的なDNS障害の症状でした。

/etc/resolv.confには正常に見えるネームサーバーのIPが記載されていましたが、そのDNSサーバー自体がメモリ過負荷で停止していました。それを調べるのは別チームの担当でしたが、すぐにresolv.confのネームサーバーを別のIPに差し替えることで復旧しました。

Postfixは何も悪くなかった。設定を2時間眺め続けた時間は、ほぼ無駄でした。

あの失敗から身についた障害診断の考え方

1. 「行き詰まり」を感じたら、隣のレイヤーを疑う

OSI参照モデルを持ち出すまでもなく、システムはレイヤー構造になっています。Postfixが送信できないとき、問題は「アプリ層（Postfix）」かもしれないし、「名前解決（DNS）」かもしれないし、「ネットワーク」かもしれない。

20年以上の運用経験から言うと、「同じレイヤーを30分以上掘っても答えが出ないとき」は一度止まって隣のレイヤーを確認するのが鉄則です。あのときの私にはその習慣がありませんでした。

2. 「外部から見た動作」を早めに確認する

今の私がメール障害に当たったとき、最初の5分以内にやることは次の4つです。

・メールの送受信テスト（自分のアドレスへの送信確認）
・外部ドメインへのping（名前解決の確認）
・/var/log/maillogの直近10行確認（エラーメッセージの文字列確認）
・dig コマンドでMXレコードが引けるか確認

この手順を決めておくことで、調査の入り口でDNSを疑う機会が自然に生まれます。システムの内側だけを見るのではなく、外部から見た動作も最初のチェックリストに入れておくことが重要です。

3. ログに「理由が出ていない」は、別レイヤーのサインかもしれない

Postfixのログにエラーが少ない場合、「Postfix自体は問題なく動こうとしている」ことを示している場合があります。動こうとしているのに送れない。それはPostfixの外側に問題があるサインです。

この読み方は経験を積まないとなかなか身につかないのですが、セミナーでは「ログに出ていない箇所にこそ原因がある」という逆説的な見方も伝えるようにしています。

本記事のまとめ

あの日の失敗から学んだことを一言でまとめると、「詳しいところだけ調べても、原因がそこにあるとは限らない」です。

Linuxの障害対応は、関連する技術領域が広いからこそ、診断のスコープを意識的に広げる習慣が大事になります。
状況 まず確認すること
メール送信ができない 外部ドメインへのping・dig MXでDNS確認
maillogにName service errorが出る /etc/resolv.confのネームサーバー死活確認
同じレイヤーを30分以上調べても答えが出ない 一度止まって隣のレイヤー（DNS・NW）を疑う
外部への通信は通るがメールだけ届かない ポート25の外向き疎通と相手サーバーのMX確認
Linuxのメール周りの技術については「Postfixのバージョン確認・設定確認方法」も参考にしてください。また、DNS設定で詰まることがある方は「LinuxのDNS設定（resolv.conf・nmcli）」もあわせてご覧ください。

「次はすぐに気づける」障害対応の型を、最初から体系的に身につけませんか？

メール送信エラーもDNS障害も、原因を一発で特定できる診断の型があります。ネットの断片情報を拾い集めるより、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒） ＞＞ 図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。