株式会社Blue Leaf

AI活用術

ログ調査・postfix・AWS・DNS をまたいだメール不達の対応を、Claude Code と進めました

メール不達の原因特定から解除申請まで：ログ調査・postfix・AWS・DNS をまたいだ対応の記録

受託で保守しているシステムで、「協力会社にメールが届かない」という問い合わせがありました。

原因は、サーバーのIPアドレスが迷惑メール判定のリストに載っていたことでした。この調査から、一時的な回避、リストからの解除申請、恒久対応の提案までを Claude Code と一緒に進めた記録です。作業はログの調査・メールサーバー（postfix）の設定・AWS の構成変更・DNS の設定と、いくつもの領域にまたがりました。

「メールが届かない」「画面が開かない」といった問い合わせは、原因がどの領域にあるのかも分からないところから始まります。今回はその切り分けから、本番環境の構成変更、外部への申請までを1人で完了できました。こんな風に Claude Code を使えるんだ、という事例の一つとして参考になれば幸いです。

起きていたこと

システムは Web サーバー2台（以下 web1 / web2）構成で、ロードバランサーがリクエストを振り分けます。メールは、そのリクエストを処理した側のサーバーから直接送信される作りでした。

問い合わせは「協力会社にメールが届かない」というものです。この時点では、アプリの不具合なのか、送信基盤の問題なのかも分かっていません。

1. 原因の特定まで、4分

調査は Claude Code に投げました。動いた順番はこうです。

時刻 見に行った先 分かったこと
14:30:07 メール送信まわりのアプリのコード 送信処理の実装を確認
14:30:46 web1 のメールログ 全部 0 バイト（1ヶ月以上、記録なし）
14:30:53 web2 のメールログ 正常に記録あり
14:31:01 web2 のログを該当社名で検索 1件だけ、しかも送信成功。合わない
14:31:15 アプリのコード（送信箇所） 同期送信＝リクエストを受けたサーバーから出る
14:31:23 web1 の送信キュー 63件が滞留
14:31:31 キューの中身 ここに答えが書いてあった
14:31:44 「根本原因が判明しました」 調査開始から 1分37秒
14:34:12 裏取りを終えて結論を報告 調査開始から 4分5秒

キューに、答えが書いてありました

キューに残っていたメールには、受信側のサーバーが返した拒否理由がそのまま入っていました。

(host mx.example.jp[203.0.113.10] refused to talk to me:
 550 Service Unavailable. Your ip [203.0.113.20] is listed in Spamhaus.
 See https://check.spamhaus.org/query/ip/203.0.113.20)

Spamhaus は、迷惑メールの送信元とみなされたIPアドレスを公開している国際的な組織です。多くのメールサーバーがこのリストを参照して受信を拒否します。web1 のIPがここに載っていたため、web1 から出たメールだけが相手に拒否されていました。

原因の固有名詞は、ログに残っていました

Claude Code は「Spamhaus を調べよう」と考えたわけではありません。原因の固有名詞は、受信側のサーバーが拒否理由として返してくれていました。やったのは、ログ → アプリのコード → 送信キュー、と事実が書いてある場所を順に見に行ったことだけです。私自身、この時点では Spamhaus という名前を知りませんでした（何なのかを聞いたのは、原因が確定した2時間後です）。

2. 一時対応：2台構成を、いったん1台に寄せる

原因は分かりましたが、載ってしまったIPはすぐには外せません。そこで、web1 を切り離して web2 だけで動かす（＝クリーンなIPからだけメールが出る状態にする）ことにしました。

作業は土曜の朝、お客様の業務が始まる前に実施しました。段取りはこうです。

  1. web1 をロードバランサーの振り分け先から外す
  2. 残る web2 の処理能力を上げる（インスタンスのスペックとワーカー数）
  3. 動作確認（協力会社側からの利用まで実際に確認）
  4. web1 を停止

このとき私が Claude Code に伝えたのは「AWS の操作は1コマンドずつ確認します」の1点です。本番環境を触るので、コマンドは Claude Code が組み立て、実行の可否は私が1つずつ判断しました。

戻すための情報を、その場で書き残す

あわせて、元に戻すための情報を課題管理システムに書き残すよう指示しています。処理能力を上げたぶんを戻すこと、デプロイ設定のタグを戻すこと、といった「戻し忘れると事故になる項目」です。実際、5日後の復旧作業ではこのチェックリストを消化する形で進められました。

滞留していたメールは、内容を確認したうえで破棄すると判断しました。

3. IPを替えても、また載る

次に、web1 に新しいIPアドレスを確保しました。ここで必要になったのが DNS の変更です。

SPF レコードの変更を依頼する

送信ドメインには SPF レコード（そのドメインのメールを送ってよいサーバーを列挙した DNS の設定）があり、ここに新しいIPを足し、載ってしまった旧IPを消す必要がありました。このドメインは私の側では変更できないため、変更内容をまとめてお客様に依頼し、当日中に対応いただいています。反映後に確認したところ末尾の ~all が ~al と1文字欠けており、これを指摘して同日中に修正いただきました。

5日後、今度は web2 が Spamhaus に載りました

そして5日後、2台構成に戻す作業をしている最中に、想定していた事態が起きました。

今度は web2 のIPが同じリストに載っていました。

web1 を止めて全てのメールが web2 から出るようになった結果、載る条件を満たしていた側が入れ替わっただけでした。IPを差し替えても、送信が集中した側が順番に拾われます。ここで「IPの差し替えは一時しのぎにしかならない」ことが実際の形で確認できました。

4. 解除申請：却下される条件を、先に潰す

そこで、リストからの解除申請に進みます。Spamhaus のページはブラウザでの操作が必要だったため、ここは Claude in Chrome（Claude がブラウザを操作する仕組み） で画面を見ながら進めました。

まず、Spamhaus の診断画面を読む

申請フォームにたどり着く前に、Claude Code が診断結果の画面から却下される条件を見つけます。

項目 実際の値 判定
HELO（送信サーバーが相手に名乗る名前） ip-10-0-0-2.ap-northeast-1.compute.internal 外部から解決できない内部名
PTR（IPから名前を引いた結果） ec2-203-0-113-20.ap-northeast-1.compute.amazonaws.com HELO と不一致

画面には「上記の対処を済ませてから進んでください。済ませない場合、要件を満たさないものとして却下されます」と書かれていました。

.compute.internal は、AWS の内部でしか通用しない名前です。受信側から見ると「インターネット上に存在しない名前を名乗ってメールを送ってくるサーバー」になり、迷惑メールの送信元と同じ挙動に見えます。設定を確認したところ、postfix に名乗る名前が明示されておらず、OS のホスト名がそのまま使われていました。2台とも同じ状態で、これが「載る側が入れ替わる」現象の説明にもなっていました。

必要だった3つの作業

必要な作業は3つでした。

  1. サーバー2台それぞれに、外部から引ける名前（web1.example.jp / web2.example.jp）を DNS に登録する
  2. postfix の設定（myhostname）に、その名前を設定する
  3. IPアドレスの逆引き（PTR）を、同じ名前に設定する

目指す形は、1つの名前と1つのIPが、名乗り・正引き・逆引きの3方向で一致している状態です。

HELO      web1.example.jp
IP        203.0.113.21
DNS (A)   web1.example.jp → 203.0.113.21
DNS (PTR) 203.0.113.21    → web1.example.jp

申請から解除まで、数分

3つの作業を終えて申請したところ、即時解除で受理されました。申請から解除の判定まで数分です。滞留していたメールは、その後の自動再送で全て配送されました。

5. 恒久対応の提案

ここまでは、あくまで元に戻しただけです。各サーバーから直接メールを送っている構成が変わっていないので、条件が揃えばまた載ります。

そこで Claude Code から出てきた提案が、Amazon SES（AWS のメール送信サービス）への移行でした。各サーバーから直接送るのをやめ、送信を1か所に集約し、あわせて電子署名（DKIM）となりすまし対策の宣言（DMARC）を整える、という内容です。

提案にあたって、次の実測値も並べて出てきました。

  • 送信量は1日およそ1,400通、宛先の99%は社内
  • 外部の企業宛は数通だが、見積依頼や取引先への通知など、届かないと業務が止まる種類が集中している
  • 移行方式は2案あり、それぞれ切り戻しの難易度が違う

通数の少なさと重要度は別、という切り分けは、実測しないと出てきません。 この提案は工数見積とあわせてお客様への起票まで済ませ、現在は方式の検討段階です。まだ実装していません。

5つの領域を、1人で追いかける

今回1件の対応で触ったのは、次の領域でした。

領域 やったこと
アプリケーション 送信処理のコードを読み、どのサーバーから送信されるかを確定
メールサーバー（postfix） 送信キューの調査、名乗る名前の設定
AWS ロードバランサーの振り分け変更、インスタンスの停止・起動・スペック変更、IPアドレスの確保と付け替え、逆引きの設定
DNS SPF レコードの変更依頼と検算、Aレコードの追加、権威サーバーの確認
外部サービスの手続き Spamhaus の診断内容の読解と解除申請

どれか1つが専門であっても、5つ全部を1人で追いかけるのは簡単ではありません。今回は、調べる・確かめる・手順に落とす部分を Claude Code に任せ、私は実行してよいかの判断と、お客様とのやり取りに集中していました。本番環境のコマンドは1つずつ承認し、外部への申請は入力内容を確認してから送信しています。

システム運用の困りごとを相談する

← 記事一覧に戻る