メール配信IPを14個に増やしたら即ブロック?スノーシュースパム誤認の原因と対策

2026.07.06

株式会社プリモポスト取締役

日吉浩之メール到達エバンジェリスト

メール配信基盤を運用していると、多くのインフラエンジニアが必ずぶつかる壁があります。

それが「Microsoft（Hotmail / Outlook / Live）宛て配信のスロットリング」です。昨今、新規ドメインでは届けるのが難しい送信先です。

到達率を死守しながら、事業の成長に必要な単位時間あたりに送信できるメールの通数を専用IPを使って拡大していく。これはインフラ設計の定石ですよね。

しかし、この「良かれと思ったスケールアウト」が、世界最大級のブラックリストの管理事業者であるSpamhausの検知ロジックに引っかかり、システム全体がブラックリスト入りしてしまうことがあります。

今回は、国外で実際に発生した事例をもとに、メールインフラをスケールさせる際に陥りがちな「スノーシュースパム誤認」と、その回避策についてお伝えしていきます。

Spamhausのブラックリストに載るまで何が起きたのか

ある企業のインフラチームは、請求書や決済通知などの「トランザクショナルメール」を配信する基盤を運用していました。設定はよくある模範的な設定で、次のような状態でした。

MTAにPowerMTAを使用
SPF・DKIM・DMARCをすべて正しく設定済み
苦情率(complaint rate)は0.1%未満
同時接続数を抑え、リトライも保守的に設定

運用開始当初は専用IP1個の運用でしたが、配信量の増加とともにMicrosoft側の受信制限に引っかかり、スロットリングを示すエラーコードが頻発するようになりました。

そこでチームは、IPを1個から3個、最終的には14個の専用IPプールへと拡張。当然、IPウォームアップも慎重に行いました。

各IPで「毎分1通」という極めて保守的なペースからIPウォームアップをスタートし、徐々に「毎分4通」まで引き上げています。

この時点で送信は安定し、スロットリングもほとんど発生しなくなりました。

ところが数時間後、複数のIPが次々とSpamhaus CSS（ブラックリスト）に登録され始め、Microsoft側からも次のような強烈な拒否応答が返るようになりました。

550 5.7.1 blocked using Spamhaus

信じられないエラーが届いたのです。

業務で使用する普通の請求書メールを、ゆっくりしたペースで配信していたにもかかわらず、なぜブラックリストに載ってしまったのでしょうか。

そもそもSpamhaus CSSとは何か

CSS(Combined Spam Sources)は、Spamhausが自動生成している

「低評価のメールを送っているIPアドレスの一覧」

です。静的な送信元からの迷惑メールを主な対象にしており、スノーシュースパムのような手口もここに含まれます。

人間の担当者がメールの中身を1件ずつ確認して判定しているわけではなく、実際に観測された送信の振る舞い（一定のパターン）をもとに、システムが自動的に判定・登録する仕組みです。

Spamhausには他にも既知の悪質な送信者を登録するリスト（SBL）などがありますが、CSSはそれとは違い、いわば

「振る舞いのパターンが迷惑メールに似ているものを自動で仕分けるリスト」

です。

そのため、中身は正当な請求書メールであっても、送信の振る舞いが迷惑メールのパターンと統計的に似ているだけで、自動的に登録されてしまうことがあります。

なお、CSSへの登録は最後に不審な挙動が検知されてから概ね３日ほどで自動的に解除されるため、原因さえ取り除けば比較的早く回復するという特徴もあります。

原因はスケールではなく、スノーシューイング!?

この現象の問題はIP単体の送信レートではなく、「複数の新しいIPが同時に出現し、すべてが同じ宛先ドメインに向けて送信を始めた」という振る舞いでした。

あまり耳にすることが無い用語だと思いますが、スノーシュースパム（Snowshoe Spam）とは、送信元プロバイダのIP単位の制限やレピュテーション監視をすり抜けるために攻撃者が使う手口の名前です。

雪国の靴であるかんじき（スノーシュー）が体重を分散させて雪に沈み込まないようにするのと同じように、攻撃者は大量のメールを「多数の新しいIPやドメインに薄く広く分散」させて送信します。

「対称性（同じパターンの機械的な繰り返し）」を具体的に見る

今回のSpamhausに引っかかったケースを図にすると、次のようになります。

IP1: 送信開始 10:00、送信ペース毎分4通、宛先 Microsoftのみ
IP2: 送信開始 10:00、送信ペース毎分4通、宛先 Microsoftのみ
IP3: 送信開始 10:00、送信ペース毎分4通、宛先 Microsoftのみ
…（以下IP14まで、すべて全く同じ条件）

つまり「開始時刻・送信ペース・宛先」の3つが、14個すべてのIPで全く同じ設定がされている状態です。

人間の目には「几帳面で美しい運用」に見えますが、Spamhaus側の検知エンジンからすると、これは「1つの主体が14個の使い捨てIPを使い、Microsoft宛てだけに狙いを定めて、同じ量のメールを送っている」ように映ります。

これはスノーシュースパムの典型パターンである、1個あたりの送信量を薄くして多数のIPに分散させ、検知を逃れる手口と見分けがつきません。

逆に、実際に人間が普通に運用しているインフラであれば、IPごとに稼働開始のタイミングにズレが生じたり、サーバー負荷やネットワークの都合で送信ペースに多少のムラが出ていたはずです。

今回問題になったのは、「自然なばらつき」が一切なく、14個のIPが同一の挙動を取っていたこと、そのものでした。

ここで注目したいのが、Microsoft自体は当初このトラフィックを比較的スムーズに受け入れていたという点です。

単一IPからの送信ペースが緩やかだったため、Microsoft側のIP単体の流量制限ロジックでは「問題なし」と判定されていました。

しかしSpamhaus CSSは、Microsoftの局所的な判定とは独立して、インターネット全体の広域的な振る舞いを評価します。

局所的には行儀の良いクライアントに見えても、広域的には「突如出現したボットネットのような対称性」を持つ、メールトラフィックだと判断されてしまったわけです。

なお、Microsoft宛てだけに絞ってメールを送信する行為自体がリスク要因になりうることや、送信ドメインがすでにSpamhaus DBLに登録されていると、それが引き金となってCSSへの連鎖登録が起きることもある、という情報もあります。

どうしたらよかった!?インフラから「機械的な対称性」を排除する

原因がスノーシュースパムの挙動との類似にあると分かれば、対策は簡単です。システムから不自然な対称性を取り除き、健全な送信者が自然にIPウォームアップを行うことです。

1. 段階的な導入によるIPウォームアップ

新しいIPを一気に稼働させるのではなく、1から2個ずつのペアから始めます。

MicrosoftのSNDSでIPのステータスが安定して良好であることを確認してから、次のペアを追加していく、というように3から4週間かけて慎重にスケールさせます。

2. 送信レートの非対称化

すべてのIPで同じ送信ペースに揃えるのをやめ、IPごとに意図的なばらつきを持たせます。プール全体の送信ペースを不均一にすることで、機械的に均等割されたトラフィックに見えないようにします。

3. リトライ・接続タイミングの非同期化

リトライの間隔や接続のタイミングも、全IPで同期しないよう設計します。インフラ全体に意図的な非対称性を持たせることで、協調動作しているように見えるリスクを減らします。

4. IP単位でのレピュテーション監視

全体のトラフィック量やエラー率だけを見るのではなく、SNDSなどを使ってIPごとのレピュテーションを個別に監視します。1つのIPのステータスが悪化した時点で早期に検知できれば、ブラックリスト登録される前に対処できます。

最後に

インフラを設計する際、ノード間の均一性や負荷の均等分散は基本的に「良いこと」とされます。

しかしメール配信インフラにおいては、この「美しく統制された分散」が、受信側のセキュリティシステムには「サイバー犯罪者の攻撃」として映ってしまうという逆説が存在します。

「ルールを守ってゆっくり送っていれば安全」

というIP単体のミクロな視点だけでなく、

「インフラ全体のトラフィックの振る舞いが、外部のセキュリティシステムからどう見えているか」

というマクロな視点を持つこと。これが、メール配信インフラを安全にスケールさせるうえで欠かせない考え方だと言えるでしょう。

複数IPでの配信スケールを検討している方は、ぜひ一度、自分たちのIPウォームアップ計画に「対称性」が紛れ込んでいないか、ぜひ見直してみてください。