Gmail や Microsoft 365 でよくある送受信トラブル「IP Throttling」の対策

ユーザーからのメールトラブルに関する申告

IP Throttlingに当たっているか？を簡単に見分けることができる唯一の方法は「送信元にバウンスメールが返り、そこにIP Throttling が発動していることが記載されている」ことになります。

IP Throttling のややこしい所はIP Throttling で遮断されたメールはメールの受信ログに載りません。
※なぜ載らないのかは次節で説明します。

Google Workspace や Microsoft 365 上でのメールの動き

IP Throttlingが発動した際によく間違えるのが、SMTPサーバ（通称メールサーバ）がIP Throttlingを発動してメールを遮断していると思い込んでいる管理者が多いことです。

これは大きな間違いであり、今後の対策の面でもしっかり把握しておいていただきたいのですが、SMTPサーバではなくネットワーク上のProxyやファイアーウォールに該当する箇所でインターネットアクセスを遮断しています。

要はメール一通一通を見て遮断しているのではなく、ネットワーク上で通信のIPを確認し遮断しています。IP Throttling が発生したからと言ってメールのホワイトリストやスパム・マルウェア設定をいじっても何も解決しません。

前の章で記載したように、メールがシステム上に入ってくる前にIPで遮断してしまうので、受け側のシステムには一切のログが残りません。

また、IPでブロックしたものに関してはシステム全体でのブロックになりますのでテナント・ドメインレベルでログが確認できるものではありません。

発動条件について

実はGoogleもMicrosoftもIP Throttlingが発動する基準は公開しておりません。そもそもIP Throttlingというセキュリティーが実装されている事も大々的には公開しておりません。

これはセキュリティー基準を教えてしまうと悪意のあるユーザーがセキュリティーを回避してしまうためとなります。しかし、IPやドメインのレピュテーションが下がる事で発生しますので、以下の方法などで事象の発生を制御したり問題の確認を取る事は可能です。

■IP レピュテーションの確認方法

　• Web サービスで公開されており、ISP などが参照し利用しているケースがあります。
　• Senderscore.org
　• Cisco Talos Intelligence Group - Comprehensive Threat Intelligence
　　* GoogleやMicrosoftはこれらのサービスとは別に独自でレピュテーションを算出しています。

◼ 一般的な IP レピュテーションのスコア算出要素

　• 送信量の安定性
　• スパム /フィッシング メールと判定される要素の有無
　• スパムレポート
　• スパムトラップ
　• 送信エラー数(Bounce, Block)

IP Throttling対策をする

IPスロットリングが発動してから主なユーザーはようやく対策を見出そうと動き始めていると思います。残念ながら、IPスロットリングが発動してしまってから対策を実施しても数日〜数か月の間は事象が解消されません。

GoogleもMicrosoftへもケースやサービスリクエスト（オフィシャルサポートへの連絡手段）を上げて対策を依頼しても中々動いてくれません。これにも諸事情があり、通常のメールの仕組みとは違いグループウェアは他のテナント（ドメイン）と共有でIPを遮断しているので、一企業からの申請だけで該当のIPを許可するようなことが無いからです。

GoogleやMicrosoftが対応してくれることは他の共有して利用しているテナントやドメインへの影響を考慮しつつ、事象が発生した企業へのアドバイスとなりますので即時解決に至らない場合が多いことは覚えておいてください。

GoogleやMicrosoftからの指示に従って、受信コネクタの作成や送信元のメール流量を制限するなどの解消策を取る事になりますが、一度IP Throttlingが発生すると、受け側も配信側も一定期間メールを受け取れずに業務への影響が多大になります。

企業によっては案件の損失や契約の不履行など企業生命を脅かす問題にも発展します。そんなリスクを減らすためには事前にIP Throttlingが発生しないよう対策を実施するお勧めします。

■主な IP Throttlingが発生するシチュエーション

• 旧メール環境からのメールリレー
  　新しくパブリッククラウドサービスでメールを構築した際、旧環境であるオンプレのメールサーバからメールをリレーさせると発生します。段階移行などをして頂く必要があります。
• 災害時の緊急連絡メール
  　緊急時にしか利用しないため、大量のメールがIPレピュテーションが温まらずに配信されてブロックされます。緊急連絡メールを配信する業者側がIP Throttling対策を行う事が求められます。
• 社内システムからの配信メール
  　新規システムのリリースやデータセンターの引越しなどで、社内システムからの配信メール元のIPが追加・変更される事で発生します。IP Throttling対策としてIPのウォームアップをして頂く必要があります。
• メルマガ配信メール
  　不特定多数にメールを配信すると、IPやドメインのレピュテーションが下がりIP Throttlingが発生する事があります。メールの送信でIPやドメインを分けるなどの対策を取って頂く必要があります。

事前事後共にGoogleWorkSpaceやM365の受信コネクタにIP Throttlingが発動しそうなIPを入れることで、発動を緩和することができます。しかし、受信コネクタに無暗にIPを入れてしまうことは自身のテナントやドメインを脅威に晒すことにも繋がるので設定する際は注意してください。

また、日ごろから利用しているIPのレピュテーションは常に意識して運用を心がけていただければと思います。

■受信コネクタの設定（各社参考リンク）

• GoogleWorkSpace
  受信メールのゲートウェイを設定する
• Microsoft365　　
  Exchange Online でコネクタを使用してメール フローを構成する

※受信コネクタに入れたIPは組織として信頼がおけるものにして下さい
※固定IPでれば自社しか使いませんが、共有IPは悪意の持った第三者が使っている事も多いため注意してください

◼ 高い IP レピュテーションを維持するためには

• SPF および DKIM を正しく構成しなりすまし対策をする
• 配布リストやメーリングリスト内の存在しないアドレスのクリーンアップ

まとめ

IP Throttlingは発生する前に対処したり事前に把握していることで問題が発生を回避したり問題の早期解消につながります。

クラウドサービスを利用している企業の管理者の方からは「クラウドサービス提供会社側に問題があるのでは？」「どうでもいいけど早く治してくれ！」といったコメントを多くいただくこともあります。

IP Throttlingに関しては、企業側での対応を検討してドメインやIPのレピュテーション（信頼度）を普段から上げるなど基盤サービスと言われる Google Work Space や Microsoft365 以外での対処も必要となります。

この記事を読んだ情報システム部門の方は改めてシステムの見直しや通常業務でIP Throttlingが発生しないよう、考慮いただく事をお勧めします。

メールに関するトラブルは企業の基盤システムを運用していく中で非常に重要な点になります。今後も元運用担当者から見たシステム上の問題や解消策について記事を書いていきますので、よろしくお願いいたします。

関連サービス