## この記事でわかること - Outlook / Microsoft 365 から返る `550 5.7.708` エラーの意味と、Microsoft が IP 評価で拒否する仕組み - SNDS（Smart Network Data Services）と JMRP（Junk Mail Reporting Program）の登録手順と役割の違い - Mitigation Request（解除申請）を出す前に整えておく必須項目と、提出後の流れ ## 5.7.708 が返ってきたときに起きていること @outlook.com / @hotmail.com / @live.jp など Microsoft が運営する受信ドメイン宛てにメールを送り、次のような英文エラーが返ってきたケースを想定してください。 ``` 550 5.7.708 Service unavailable. Access denied, traffic not accepted from this IP. For more information please go to https://sender.office.com/. Reasons for rejection may be related to content with spam-like characteristics or IP/domain reputation. ``` `5.7.708` は Microsoft が**送信元 IP のレピュテーション低下**を理由に受信拒否したことを示します。Microsoft の公式リファレンス [Error codes in non-delivery reports｜Microsoft Learn](https://learn.microsoft.com/exchange/troubleshoot/email-delivery/non-delivery-report-in-exchange-online/error-codes-in-non-delivery-reports) でも、5.7.708 は「sender IP は Microsoft のレピュテーションフィルタでブロック中」と定義されています。 似たコードに `5.7.606`〜`5.7.614`（地域・国レベルでのブロック）がありますが、5.7.708 は **IP 単位**でのブロックである点が異なります。配信ボリュームが大きくない中小企業でも、共有 IP 経由で送っている場合や、社内 PC が踏み台にされて大量送信した場合などに突然出ることがあります。 なお、本記事は **5.7.708 の IP ブロック解除に特化**した内容です。判定全般の解除（SmartScreen による迷惑メール判定など）は、既存記事 [Outlook で迷惑メール判定された時の解除](/blog/outlook-spam-recovery) を参照してください。両者は対処の入り口が異なります。Outlook の 550 系エラーをコード別に切り分けたい場合は、[Outlook 550 エラー ケース別の原因と対処](/blog/outlook-550-error-cases-guide) をハブとしてご利用ください。 ### Microsoft 側の判定の仕組みを最小限で理解する Microsoft の受信側はおおまかに次の順で判定します。 1. **接続段階のフィルタ**: 送信元 IP の評価・国・接続頻度 2. **認証段階のフィルタ**: SPF / DKIM / DMARC、いわゆる[ディーマーク](/blog/what-is-dmarc) ([参考](/blog/dmarc-setup-guide)) 3. **内容段階のフィルタ**: 本文・URL・添付の解析 5.7.708 は **1 段階目で弾かれている**状態です。つまり認証 3 点が完璧に揃っていても、IP の評価次第で受信されません。逆に言えば、5.7.708 を解除するには **IP レピュテーションを直接改善する** か、**Mitigation Request を出して人手で再評価してもらう** しか道はありません。 ![Outlook 5.7.708 から解除までの流れ](/blog/outlook-550-57708-fix/mitigation-flow.svg) ## SNDS / JMRP / Mitigation Request の役割を整理する 3 つの仕組みは似た名前ですが、目的とタイミングが違います。 ![Microsoft 3 つの送信者プログラムの役割](/blog/outlook-550-57708-fix/programs-comparison.svg) - **SNDS（Smart Network Data Services）**: 自社が保有する送信 IP の評価を**毎日確認**するための無償ツール。スパム率、トラップヒット数、フィルタ判定結果が IP ごとにレポートされる - **JMRP（Junk Mail Reporting Program）**: 受信者が outlook.com / hotmail.com で「迷惑メールとして報告」したメールのコピーが**自動転送**される無償プログラム。配信品質改善のフィードバックループに使う - **Mitigation Request**: 5.7.708 などでブロックされた送信 IP の**解除を申請**する窓口。[sender.office.com](https://sender.office.com/) から提出する 順序としては、**SNDS と JMRP は事前に登録しておくべき常時運用の仕組み**、Mitigation Request は **5.7.708 が発生した時に提出する非常用フォーム**です。SNDS / JMRP の参加実績があると、解除申請の信頼度が上がります（Microsoft は申請内容に「改善行動の根拠」を求めるため）。 ## 解除申請を出す前に整えるべきこと Mitigation Request はフォームを提出すれば即解除されるものではありません。Microsoft の自動評価で「再発の見込みがない」と判断されるよう、以下を**先に**整える必要があります。 ### 1. SPF / DKIM / DMARC を完備する 最低限、自社ドメインで以下を確認してください。 - SPF レコードに、Outlook 宛てに送る全送信サーバーの `include:` が揃っている（Microsoft 365 なら `spf.protection.outlook.com`） - DKIM 公開鍵が DNS に登録され、`dkim=pass` がレシーバ側で確認できる - DMARC レコード `_dmarc.example.co.jp` が存在し、最低でも `p=none rua=mailto:dmarc@example.co.jp` が設定されている 設定状況の確認は無料の [ドメイン診断ツール](/diagnose) でまとめてチェックできます。書き方の詳細は [SPF レコードの設定方法](/blog/spf-setup-guide) を併読してください。 ### 2. 不正配信源を遮断する 5.7.708 の最大の引き金は「自社の意図しない大量送信」です。次を一通り確認してください。 - 古い WordPress や CMS から大量送信が出ていないか - 退職者の SMTP 認証情報が漏れて踏み台にされていないか - 共用ホスティングで他社のメールが自社 IP から出ていないか - メール配信サービスの API キーが漏洩していないか なお、なりすまし配信を抑止するための DMARC 強化は [メール送信ドメインのなりすまし防止策](/blog/email-spoofing-prevention) を参照してください。 ### 3. SNDS と JMRP に登録しておく [SNDS](https://sendersupport.olc.protection.outlook.com/snds/) には、Microsoft アカウントでサインインし、自社所有 IP のリストを登録します。所有確認は IP の管理用メールアドレス（`abuse@example.co.jp` 等）への確認メールで行います。 [JMRP](https://sendersupport.olc.protection.outlook.com/pm/) は同じ画面から並行登録できます。受信報告の転送先メールアドレスを 1 つ用意するだけです。 両プログラムの登録は完了まで数日かかるため、**5.7.708 が出てから登録するのでは間に合いません**。日常運用として先に入れておきます。 ### 4. 申請内容を整理する Mitigation Request では、最低限以下の情報が必要です。 - 該当する送信元 IP アドレス（複数可） - 送信ドメイン名と運用主体 - 普段の送信ボリューム（日次・宛先タイプ） - 5.7.708 を受け取り始めた日時 - 直近で実施した改善内容（認証完備、漏洩アカウント停止 等） 「改善内容」は具体的な日付と作業名で書きます。「対応中です」だけでは再発リスクと判定されます。 ## 提出後の流れと、二度と出さないための運用 Mitigation Request を提出すると、自動応答メールで受付番号が届きます。続いて、Microsoft 側のレビュー結果が**通常 24〜48 時間程度**で返ります（保証はされません）。結果は次の 3 通りに分かれます。 - **解除済み**: 即時または数時間以内に Outlook 宛て送信が再開できる - **追加情報の依頼**: 改善内容の根拠資料を求められる。SNDS のスクリーンショット等を添付して返信する - **棄却**: IP の評価が低すぎる、または改善が不十分と判断された場合。SNDS で改善状況を確認しつつ、再申請は最低 1 週間以上空ける 申請後の再発防止には、次を運用に組み込むのが効果的です。 - **SNDS を週次で確認**: トラップヒットやスパム率の推移を確認し、悪化前に手を打つ - **DMARC レポートの定期確認**: 認証失敗メールの送信元を毎日把握する - **共有 IP 利用は最小化**: 重要な業務メールは専用 IP を持つ配信サービスを使う - **配信ボリュームの段階的増加（IP warm-up）**: 新しい送信 IP を使い始める際は、いきなり大量送信せず段階的に増やす Microsoft の判定全般を取り扱った [Outlook で迷惑メール判定された時の解除](/blog/outlook-spam-recovery) と本記事を併読すると、IP ブロックと判定低下の双方に対応できる体制が整います。Microsoft 365 宛てに NDR が返るパターンは [NDR 550 5.4.1 配信不能の原因と対処](/blog/ndr-550-541-fix)、Gmail 側で同種の認可拒否に遭遇しているなら [Gmail 5.7.1エラーの対処](/blog/gmail-550-571-fix) も合わせて確認してください。 ## 自社の状況を確認してみませんか 設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。 判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。