取引先や知人にメールを送ったのに「配信できませんでした」と戻ってきた。Outlook.comやHotmail宛てだけ送信に失敗し、エラーメールに「550 5.7.1」「S3150」と書かれている。そんなときは、メールソフトの故障よりも、受信側のMicrosoftが送信元のIPアドレスやネットワークを拒否している可能性を先に確認してください。
この記事では、実際に発生した事例を匿名化して紹介します。エラーの意味、解除申請の進め方、BCC一斉送信の注意点、復旧後の確認まで解説します。確認日：2026年11月10日。
まず結論：S3150は「迷惑メールフォルダーに入った」とは違う
- S3150は、MicrosoftのOutlook.com系受信サービスが、送信元ネットワークの一部をブロックリストに含めている旨を示すエラーです。
- メールが相手の「迷惑メール」フォルダーに届くのではなく、受信先に受け付けてもらえず配送失敗している場合があります。
- 個人のメールソフトを再起動しても、相手の「受信拒否リスト」へ差出人を追加してもらっても、送信元ネットワークのブロックが解除されるわけではありません。
- 管理者は不達通知の原文を保存し、送信サーバー事業者とMicrosoftのOutlook.com Sender Supportに確認します。
実例：金曜日にS3150で拒否、月曜日に送信できる状態へ復旧
以下は、実際の業務用メール環境で起きた事例です。企業・団体名、ドメイン、個々の宛先、送信元グローバルIPアドレス、問い合わせ番号は公開せず、検証可能な範囲で経緯を整理しています。
| 日時 | 起きたこと・対応 |
|---|---|
| 11月6日（金） | 業務用メールからMicrosoft系のメールアドレスへ送信したところ、550 5.7.1とS3150を含む不達通知を受信。 |
| 11月6日（金） | Microsoftの送信者向けサポートに配送問題を申請し、メールサーバー事業者にも照会。 |
| 11月6日（金）13時41分ごろ | Microsoftから緩和対応（Mitigated）を示す返信。ただし、直後の13時48分ごろの再送テストではS3150が継続。 |
| 11月9日（月） | 再確認した結果、Microsoft系宛てへの送信が可能な状態に戻っていることを確認。 |
| 11月10日（火） | 経緯を記事向けに整理。ブロック原因やMicrosoft内部の解除処理の完了時刻は未確認。 |
重要なのは、解除申請への「対応した」という返信と、実際の配送が再開した時刻は一致するとは限らないことです。この事例でも、緩和の連絡が届いた直後のテストは失敗しました。一方、月曜日の確認では送信できるようになりました。
なお、今回の送信元はWebARENA SuiteXのメールプレミアムを利用した共用メール環境です。専用メールサーバーを所有していた事例ではありません。
S3150／550 5.7.1のエラーメールはどこを見ればいい？
不達通知（NDR、バウンスメール）には、多くの場合「Diagnostic information」「Diagnostic-Code」などの診断欄があります。今回の特徴的な一節は次のとおりです。
550 5.7.1 … part of their network is on our block list (S3150)
これは「送信元が利用するネットワークの一部がMicrosoftのブロック対象になっている」という趣旨です。550はSMTPの配送拒否を示すコードで、5.7.1は配送ポリシーやアクセス制限に関係するエラーとして使われます。S3150はこの事例を切り分ける追加情報です。
| 見つけた情報 | 確認する内容 |
|---|---|
550 5.7.1 | 配送を拒否されたこと。ほかの原因でも使われるため、これだけで原因を決めない。 |
S3150 | 送信元のネットワークに対するMicrosoft側のブロックを疑う手掛かり。 |
| 送信元IPアドレス | 自分の自宅やPCのIPではなく、利用している外部メールサーバーの送信IPであることが多い。 |
| 送信先のドメイン | outlook.com、hotmail.comなど、Microsoft系宛てで再現するか。 |
| 発生時刻・不達通知全文 | サポートに原因を調査してもらうため保存する。公開の相談掲示板には個人情報を載せない。 |
なぜ普通の業務メールが止められた？ 共用IPの仕組みを図解
Microsoftは送信者の評判を判断する際、送信IPアドレス、ドメイン認証、宛先リストの品質、迷惑メール報告率、メール本文など複数の要素を使用すると説明しています。したがって、メール本文が普通の連絡文でも、送信元IPの評価によって届かなくなる場合があります。
図解1：送信者のメールと受信者の間にある判定
| 送信側 | 通信の途中 | 受信側 |
|---|---|---|
| 業務PC・メールソフト | → SMTPで送信 → | 契約先のメール送信サーバー |
| 契約先の送信サーバー | → インターネット経由 → | Microsoftの受信サーバー |
| Microsoft側の受信判定 | → 許可なら配送／拒否ならエラー返送 → | Outlook.comなどの宛先 |
共用メールサービスでは、複数の契約者が同じ送信IPを使用する構成があり、IP単位で評価される場合は自分だけの送信履歴を見ても原因を説明できないことがあります。ただし今回の障害が他の契約者の送信に起因したかどうかは未確認です。
BCCで約80件に一斉送信したことが原因？
今回、エラーが発生する前に約80件の宛先へBCCを使った一斉送信が行われていました。送信量や頻度がメール配送の評価に影響することはありますが、これを理由に「80件のBCC送信がMicrosoftのブロックを発生させた」と断定する根拠はありません。送信元IP全体の評判など、ほかの要因も考えられるためです。
また、BCCという機能自体が迷惑メール扱いされるわけではありません。複数の相手に宛先を見せずに送るために必要な機能です。ただし、短時間に大量の宛先へ送る運用は、メールサービス側の負荷制限や送信先の判定に配慮する必要があります。
WebARENAの公式案内では、SuiteX メールプレミアムについて、1回のSMTPセッションでの宛先数の仕様上限は300件。一方、安定運用のためには1セッションあたり10～20件程度に分けることが推奨されています。「300件までなら迷惑メール判定されない」という意味ではありません。
図解2：「送信上限」と「Microsoft側の受信判定」は別
| 区分 | 判断する側 | 今回のポイント |
|---|---|---|
| SMTPセッションの上限 | 送信サーバー事業者 | WebARENAは安定運用として10～20件程度へ分割を推奨。 |
| 迷惑メール・ネットワークの判定 | 受信側のMicrosoft | 送信元IPの評判などを踏まえて配送を許可・拒否。 |
| 送信成功の確認 | 送信側管理者 | 送信済みに残るだけでは不十分。不達通知と受信テストで確認。 |
S3150でメールが届かないときの対処方法
1．まず不達通知を保存し、対象を切り分ける
- エラーメール全文を保存し、
S3150の有無、エラー時刻、送信元IPを確認する。 - 送信先のアドレスが正しいか、Microsoft系の宛先に偏って発生しているかを調べる。
- 同じメールサーバーから他社ドメインにも届かないのか確認する。個人情報を含まない短いテスト文で行う。
- SMTP認証エラーやDNSの設定不良など、別原因のエラーと混同しない。
2．メールサーバー会社に問い合わせる
共用メールサービスの利用者が自分でサーバーの送信IPを変更できるとは限りません。事業者には「送信先の種類」「エラー全文」「発生時刻」「送信IP」を伝え、ほかの契約者への影響や送信経路の対処が可能か確認します。独断で大量の再送を繰り返すのは避けましょう。
3．Microsoftの送信者サポートに配送問題を報告する
Microsoft公式のOutlook.comでの送信者サポートから、配送トラブルの問い合わせ手段を確認してください。サポートに必要な情報には、送信IP・送信元ドメイン・具体的な不達通知・発生時刻などがあります。申請すれば必ず解除されると保証されているわけではありません。
メールをMicrosoft 365（職場・学校）に送る場合と、Outlook.com（個人向け）に送る場合では調査窓口や判定基盤が同一とは限りません。本記事はOutlook.com系宛てのS3150事例を中心に説明しています。
4．申請後も、少数のテストメールで配送再開を確認する
今回の実例では、Microsoftから緩和対応を知らせる返答が来ても、直後は拒否が続きました。時間を置き、同意を得たテスト用の宛先へ少量のメールを送り、エラーが返らず実際に受信できたかを確かめます。申請の受付や「Mitigated」の返信だけで完全復旧と決めないことが重要です。
解除されたあとの再発防止：管理者向けチェックリスト
図解3：発生から復旧判定までの対応フロー
| 順番 | 確認・対応 | 完了の判断 |
|---|---|---|
| ① 不達を検知 | S3150／550 5.7.1、時刻、宛先ドメインを記録 | 該当する不達通知を保管 |
| ② 影響を調査 | 送信IP、共用サーバー、他ドメイン宛ての送信を確認 | Microsoft系での拒否を切り分け |
| ③ 支援を依頼 | メール事業者とMicrosoftの送信者窓口へ連絡 | 問い合わせ状況を管理 |
| ④ 復旧を確認 | 少数テストを行い、受信側でも着信確認 | 実際の配送が成功 |
| ⑤ 運用を見直す | 送信分割、リスト整理、認証、ログ監視 | 再発時に切り分けできる状態 |
- 送信を分割する：用途や契約サービスに合わせて、宛先数と送信間隔を調整する。ただし分割だけでブロックを防げる保証はない。
- 宛先リストを整理する：不要・古い宛先や、配信停止希望者を除外する。存在しない宛先への繰り返し送信を防ぐ。
- SPF／DKIM／DMARCを確認する：送信サービスの正規設定と一致しているか確認する。設定が正しくてもIPの評判による拒否は起こり得る。
- 送信元の監視：契約事業者と協力し、不正な大量送信、アカウント侵害、サーバーの配送ログを点検する。
- 重要な連絡は到達確認する：研修案内や期限のある通知は送信済みだけで安心せず、不達通知・確認返信などを運用に組み込む。
送信IPの評判を継続的に監視する管理者には、MicrosoftのSmart Network Data Services（SNDS）も参考になります。ただし共用IPでは事業者側が管理する部分が多く、利用者だけで情報取得や解除作業を完結できるとは限りません。
よくある質問
Q．Outlookのアプリを使っている人全員に届かなくなる？
いいえ。「Outlook」という名前のメールアプリと、個人向けのOutlook.comメールサービスは別です。今回のS3150はMicrosoft側のメール受信基盤での拒否を示すもので、受信者がどのメールアプリを使っているかだけで決まるものではありません。
Q．送信済みフォルダーにあればメールは届いている？
いいえ。送信側のメールサーバーへ渡せたことと、相手の受信サーバーが受け付けたことは別です。不達通知が後から返ることがあります。重要なメールは相手の受信確認が必要です。
Q．個別のIPブロック確認サイトでは「問題なし」。S3150は誤表示？
そうとは限りません。S3150のメッセージは、IP単独ではなくネットワークの一部を対象にしている旨を示します。公開ブラックリストに載っていないことだけでは、Microsoft内部の判定を否定できません。エラー全文をもとに管理事業者やMicrosoftへ確認してください。
Q．一度解除されたら、もう大丈夫？
今回の事例では11月9日に配送が再開しましたが、将来のブロックが起きない保証はありません。送信量を適切に管理し、不達を早く検知できる体制を整えることが重要です。
まとめ：原因の断定より「不達の検知・復旧確認・再発防止」が重要
Outlook.com宛てのメールが550 5.7.1（S3150）で拒否されたら、まず送信元のネットワークに対する受信側のブロックを疑います。今回の業務メールの実例では、金曜日に問題を確認して解除申請し、月曜日に配送再開を確認しました。ただし、BCC約80件の送信とブロックの因果関係や、Microsoft側の解除処理の正確な時刻は分かっていません。
調査ではエラー全文を保管し、メールサーバー事業者とMicrosoftの双方に確認すること。復旧はサポートからの返信だけでなく、実際の着信まで確かめることが大切です。
出典・確認日
- Microsoft：Outlook.comでの送信者サポート（2026年11月10日確認）
- Microsoft：Smart Network Data Services（2026年11月10日確認）
- WebARENA：電子メールの制限事項（SuiteX メールプレミアム）（2026年11月10日確認）
- WebARENA：1回のSMTPセッションで送信可能な宛先数について（2026年11月10日確認）
- 実際の業務メールの不達通知・送信者サポート回答・復旧確認記録（非公開、個人情報・法人情報は匿名化）
※この記事の実例は特定企業・団体の障害を公表するものではありません。サービスの一般的な対策と、一つの環境で確認できた事実を区別して記載しています。
