5つのあるある事例に見るメールトラブルの原因、未然に防ぐ運用とモニタリングの具体的ポイント集：意外と知らないメールサーバ構築・運用の基本（8）

・原因：ブラックリストに登録された

　送信元のIPアドレスやドメインが、スパム対策団体が運営するブラックリストに登録されてしまうと、メールがブロックされる確率が高まります。特に「Spamhaus」のような影響力の強いブラックリストに登録されてしまうと、メールがほとんど届かない状態にもなり得ます。

　ブラックリストに登録されても、IPアドレスやドメインの保有者に通知が来るわけではないので、気付かないまま送信を続けてしまうケースも多くあります。しかしその状態を放置すると、送信者としてのレピュテーション（信頼性）も下がり、ますます届かなくなるという悪循環に陥ってしまいます。

【ケース3】Gmailにだけメールが届かない！

・原因1：レピュテーションが低い

　「Gmail」をはじめとするメールサービスプロバイダーは、過去の送信実績を基に送信者のレピュテーションを評価しています。このレピュテーションが低いと、迷惑メールフォルダに振り分けられたり、受信拒否されたりすることがあります。

　特に新規に取得したばかりのドメインやIPアドレスはレピュテーションが高くないので、より慎重な運用が求められます。

・原因2：ガイドラインに対応していない

　Gmailでは、2024年からメール送信者向けの新しいガイドラインが施行され、前回紹介したSPF（Sender Policy Framework）やDKIM（DomainKeys Identified Mail）、DMARC（Domain-based Message Authentication, Reporting & Conformance）による認証、TLS（Transport Layer Security）の対応、ワンクリックでの購読停止機能など、従来より厳しい要件が求められるようになりました。

　ガイドラインに準拠していない場合、メールが届かなくなるケースがあります。特に新規ドメインやメールサーバ導入時には注意が必要です。

【ケース4】メールキューがたまって遅延してしまう！

・原因：送信サーバのキャパ不足

　大量メールを一括で送信する場合、サーバの処理能力を超えてしまうとメールの処理待ちが発生し、キューに滞留してしまいます。これにより、配信の遅延や、タイムアウトが発生することになります。

　CPUやメモリのリソース不足、受信側サーバの接続制限などが複合的に関与しており、事前のリソース見積もりや監視が重要です。

【ケース5】意図しないメールが大量に送信された！

・原因1：アカウントが乗っ取られた

　外部からの不正アクセスにより、メール送信アカウントが乗っ取られ、スパムの送信元として悪用されることがあります。正当なアカウントから送信されているので気付きにくく、大量のスパム配信によってキューがたまったり、ブラックリストに登録されたりすることでようやく判明するケースもあります。

・原因2：メールフォーム攻撃

　Webサイトに設置されたお問い合わせフォームや資料請求フォームなどの自動返信機能を悪用して、スパムメールを送信させる攻撃があります。攻撃者が自動化ツールやbotなどを使って短時間で大量に投稿することで、自社のメールサーバから大量のスパムメールが出てしまい、結果としてレピュテーションの悪化につながります。また、この際に攻撃者が使用する送信リストにブラックリストのスパムトラップ＊が含まれていた場合、ブラックリストに登録されてしまう要因にもなります。

＊スパムトラップ：迷惑メールを配信するスパマーをあぶり出すために用意された、実際には使用されていないアドレス。スパムトラップ宛てにメールを送信するとブラックリストに登録されてしまう。

トラブルを未然に防ぐ運用とモニタリング

　前章で紹介したようなメール配信トラブルは、日頃の運用とモニタリングによって多くを未然に防ぐことができます。この章では、配信の健全性を保つための運用ポイントを紹介します。

バウンスレートを低く保つ

　Amazon SESに限らず、バウンス率を低く保つことはメールの安定配信を維持するために非常に重要です。対策としては、バウンス率を監視することと、バウンスの発生を抑えることが大切です。

・テストに架空のアドレスを使わない

　テストに架空のメールアドレスを使用すると、バウンスが発生してしまいます。特に大量配信の場合は事故の元となるので、テスト用のアドレスや配信リストを用意するなど、実在する宛先に配信するようにしましょう。

・配信リストのクリーニングをする

　長期間整理していない配信リストには、既に使われなくなったアドレスなど、無効な宛先が含まれている可能性が高いです。「User Unknown」などのバウンスが発生したアドレスは、定期的にリストから除外するようにしましょう。

・バウンスレートの監視

　Amazon SESなどの配信サービスを使用している場合は、バウンス率を管理画面から確認できます。基準値（理想は2％未満）を超えないよう、日頃からバウンス率をモニタリングするようにしましょう。

　自社でメールサーバを運用している場合は、ログやバウンスメールなどに記載されるSMTP（Simple Mail Transfer Protocol）のステータスコードをチェックすることでバウンスを監視できます。

【具体的なログの監視方法】

　メール送信ログには、配信結果が「ステータス」として記録されています。

　使用しているMTA（Mail Transfer Agent）にもよりますが、例えば「Postfix」なら「/var/log/maillog」に次のようにログが出力されます。

May 15 12:35:05 mail postfix/smtp[5678]: 9876543210: to=<[email protected]>, relay=mail.example.com[XXX.XXX.XXX.XXX]:25, delay=5.5, delays=0.1/0.1/2.3/3, dsn=2.0.0, status=bounced (host example.com[XXX.XXX.XXX.XXX] said: 550 5.1.1 < recipient @example.com>: Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO command))

　上記のように、「status=bounced」の場合は、メールアドレスが存在しない、メールボックスの容量超過、受信側のポリシー違反などの理由で、宛先への配送に失敗しています。

　例えば1日分のメールログから「status=bounced」の数を集計することで「1日にどれくらいのメールがバウンスしているか」をモニタリングできます。

　全てのステータス件数をカウントすることで、バウンス率も計算できます。

ブラックリスト対策

　ブラックリストの対策としては、ブラックリストに登録される要因を減らすこと、そして登録を早期に検知することが挙げられます。万が一、ブラックリストに登録された場合は、管理団体に対して解除申請が必要となるので、早期発見が重要です。

・配信リストのクリーニングをする

　配信リストの定期的なクリーニングは、ブラックリスト対策としても重要です。使われなくなったアドレスがスパムトラップとしてリサイクルされることもあり、気付かぬうちにスパムトラップが配信リストに紛れ込む可能性があるので、定期的なリストの精査が必要です。

・ツールを利用したモニタリング

　「MultiRBL」「MXToolbox」などのWebサービスを使い、主要なRBL（リアルタイムブラックリスト）に自社IPアドレスやドメインが登録されていないかどうかを定期的にチェックする方法もあります。

　管理するIPアドレスが多い場合などは手間がかかるので、ログ監視や、ブラックリストやレピュテーションを監視できる有償ツールを利用する手もあります。

・ログに含まれるメッセージを監視

　バウンスにはエラーの原因が簡易的に書かれており、ブラックリストが原因の場合もその旨がエラーメッセージに記載されます。そのため、ログに特定のメッセージが出力されたときにアラートを通知するようにすると、ブラックリストへの登録を早期に検知できます。

【具体的なログの監視方法】

　下記は、ブラックリストの中でも有名な「Spamhaus」にメール送信サーバのグローバルIPが登録されていたためにブロックされたログの例です。

554_5.7.1_Service_unavailable;Client_host[XXX.XXX.XXX.XXX]_blocked_using_sbl.spamhaus.org

　例えば、「block」「banned」「not_allowed」「spamhaus」といったキーワードを検知できるようにするとよいでしょう。

　なお、メッセージ内容は非定期で更新されるので、半年に1回などの頻度でキーワードを見直すことをお勧めします。

レピュテーション管理

　送信メールが迷惑メール扱いされないようにするには、レピュテーションの管理も不可欠です。

・ログ監視などで異変があった際に確認するフローを整備

　レピュテーションについては、公開情報ではないので「SenderScore」などのサービスを使って確認するしかありません。人力で日々チェックするのは大変なので、バウンス率が大幅に上がった場合など、他の監視で異変を検知した場合にレピュテーションを確認するフローを整備しておくとよいでしょう。

ガイドラインへの準拠チェック

　Gmailや「iCloud」「Outlook.com」などの主要なメールサービスでは、送信者向けの技術ガイドラインが存在します。特に2024年以降は要件が厳しくなっているので、以前は問題なく送信できていた環境でも、意図せずガイドライン違反になって届かなくなるケースも増えています。

・ガイドライン違反を通知するエラーがないかどうか

　Gmailではガイドライン違反を理由にメールを拒否する場合、その旨をエラーメッセージに記載します。例えば「For more information, go to Email sender guidelines」というメッセージが含まれていれば、ガイドライン違反が原因と考えられます。「どの点が違反しているか」も併せて記載されているはずなので、バウンスの内容をよくチェックしましょう。

参考：Google Workspace 管理者ヘルプ「GmailのSMTPに関するエラーとコード」

・新規ドメイン・送信環境の追加時チェック

　ドメイン追加やインフラ構成の変更時には、SPFやDKIM、DMARC、DNS（Domain Name System）の設定に不備が発生しがちです。ガイドラインの項目をチェックリスト化し、リリース時に確認するプロセスを取り入れましょう。

メールサーバの監視

　メールサーバのリソース不足や障害は、配送遅延やシステムダウンにつながります。以下のような日常的な監視も欠かせません。

・リソース監視

　CPU、メモリ、ディスク使用量などの基本的なリソース監視は必須です。また、Postfixなどメール送信用ミドルウェアのプロセス監視も併せて行いましょう。

・メール送信の正常性監視

　メールの正常性の確認には、「送信できたかどうか」だけではなく「宛先に届いたかどうか」まで監視することが理想です。テスト用のアカウントを作成し、メールが届いているかどうかを確認する仕組みを作ることでモニタリングが可能です。

【具体的な監視方法】

　下記リストで、メール正常性監視に必要なものと仕組みについて記載しておくので、参考にしてみてください。

・キュー監視

　メールの送信キューが滞留していないかどうかを監視します。急激な増加があれば、何らかの異常が発生している可能性があります。

【具体的な監視方法】

　Postfixなら「mailq」コマンドで滞留しているメール件数を把握できます。独自スクリプトを作成し、Cronで10分単位に滞留しているキューをモニタリングすることもできますが、集計したデータの可視化やアラート発報の仕組みまでスクリプトで作成するのは困難です。そのため、監視ツールのプラグインを利用することをお勧めします。

　例えば、有償監視サービス「Mackerel」の「mackerel-plugin-mailq」ならば、サーバにインストールするだけでキューの件数も時系列で可視化し、アラート設定も可能です。

不正送信・メールフォーム攻撃の対策

　外部からの不正送信を防ぐには、Webフォームや認証情報の取り扱いにも注意が必要です。

・ログ監視などで異常を早めに察知する

　万が一、踏み台にされたり、Webサイトを悪用されたりした場合の対策として、意図しない宛先に対してメールが送信されていないかどうかを監視することは重要です。不審な挙動はログを通じて察知できます。

【具体的な監視方法】

　企業にもよりますが、国内事業・国内サービスの場合は「.jp」「.com」宛てのメールが大半だと思います。攻撃によってスパムの踏み台にされてしまった場合は、通常時にはあまり配信されないはずの海外ドメイン宛てのメールが増えるケースがよくあります。

　そのため、1時間に1回「.jp」「.com」以外の宛先に送信している件数をモニタリングするだけで、早期に異変に気付けるようになるでしょう。

・フォームに対するセキュリティ対策

　CAPTCHAの導入、フォームのリファラチェック、IP制限など、フォームへのスパム対策も重要です。攻撃されやすい状態で放置していると、自社のサーバがスパムの踏み台にされるリスクがあります。

メールの安定運用に向けて

　ここまで見てきたように、メール配信にはさまざまなトラブル要因が潜んでおり、それらを防ぐには日常的な運用管理が欠かせません。最後に、安定したメール運用のための全体的な考え方と姿勢について整理します。

モニタリングが重要

　どれだけ設定を正しく整えても、それを継続的に監視、運用しなければ、トラブルは必ず起こります。安定運用のカギは「変化を素早く検知する」ことにあります。ログやツールを活用して日々モニタリングし、異常を見逃さない体制を整えましょう。

高速化したい場合はアウトソースしよう

　リアルタイム性が強く求められる通知や、膨大なユーザーへの一括配信など、要件によっては自前の仕組みでは対応が難しくなるケースもあります。

　そうした場合は、メール配信に特化した外部サービスの活用も検討すべきです。安定性とスピード、どちらも求められるシーンでは、「餅は餅屋」に任せる判断も立派な運用戦略の一つです。

まとめ

　これで連載は締めくくりとなりますが、メールの世界は依然として「古くて新しい」分野です。本連載が、読者の皆さまのメール基盤の見直しと、より安定した配信の実現に少しでも役立てば幸いです。