# Microsoft の451 4.7.500による配信遅延：送信者向けの対処法

正規URL：https://brew.new/ja/blog/microsoft-451-4-7-500-deferrals-playbook
執筆：Thomas Park
公開日：2026-10-05
更新日：2026-10-05

Microsoft の配信遅延（deferral）とは、Outlook.com や Microsoft 365 のサーバーが、今はメッセージを受け取らないというときに返す、4で始まる一時的なSMTPの拒否です。送信側のサーバーは、メッセージを保持したまま再試行すべきです。最もよく知られているのは `451 4.7.500 Server busy. Please try again later` で、同じコードが「送信の仕方が怪しい」という意味にも、「Microsoft の調子が悪い」という意味にもなります。

2026年9月4日は後者でしたが、経験豊富なメール運用者の少なくとも1人が、前者を疑って午前中を費やしました。ここでは、両者を見分ける方法を説明します。

## この記事のポイント

- まずホストを確認しましょう。`*.olc.protection.outlook.com` は Outlook.com の個人向けメール、`*.mail.protection.outlook.com` は Microsoft 365 のテナントです。参照するドキュメントも、エスカレーション先も異なります。
- 4xxは、キューに入れて再試行せよという意味です。RFC 5321 は、間隔を少なくとも30分空け、少なくとも4〜5日間続けるとしています。5xxは停止の合図で、Microsoft のポリシーは再試行を禁じています。
- Gmail と Yahoo は問題ないのに、すべてのIPが同じ1分のうちに Microsoft から同じコードを受け取ったなら、Microsoft 側を疑い、何かを変える前に mailop を確認しましょう。
- 2025年5月5日以降、Outlook.com は、1日5,000通を超えるメールを送信するドメインにSPF、DKIM、DMARCを義務付けています。`550 5.7.515` は、常に送信者側で直すべきものです。
- 送信IPは、今のうちにSNDSとJMRPに登録しておきましょう。SNDSのアクセス権は、再認証しない限り10か月で失効します。
- 再試行を増やしたり、新しいIPに切り替えたり、遅延したコンタクトを配信除外にしたりしてはいけません。

## まず、どちらの Microsoft とやり取りしているかを確かめる

Microsoft は、2つの受信システムを運用しています。

**Outlook.com** は個人向けのメールで、`outlook.com`、`hotmail.com`、`live.com`、`msn.com` が該当し、MXホストは `hotmail-com.olc.protection.outlook.com` のような形式です。[Outlook.com の Postmaster サイト](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting)、レピュテーションを確認するためのSNDS、独自の送信者サポートフォームがあります。

**Microsoft 365**（Exchange Online）は、企業のメールボックスをホストしています。`acme.com` 宛てのメールは、`acme-com.mail.protection.outlook.com` に届きます。エラーは [Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) に記載されており、ブロックへの対応は `sender.office.com` を通じて行います。また、テナントがあなたのメールをどう扱うかは、受信側の管理者が制御しています。

ドメイン名からは、どちらに送っているのかはわかりません。わかるのは応答からです。9月4日に [mailop に投稿された](https://www.mail-archive.com/mailop@mailop.org/msg27209.html)このログでは、`relay=` のホストが Microsoft 365 のテナントです。

```text
relay=xxxx-com.mail.protection.outlook.com[52.101.10.16]:25, dsn=4.7.500,
status=deferred (host xxx-com.mail.protection.outlook.com[52.101.10.16] said:
451 4.7.500 Server busy. Please try again later from [199.89.3.6]. (S77714)
[BN2PEPF000055E1.namprd21.prod.outlook.com 2026-09-04T10:28:53.346Z ...]
(in reply to end of DATA command))
```

## 応答を読み解く

基本コード（`451`）、拡張コード（`4.7.500`）、そして `(S77714)` のような括弧内のサブコードを読みます。Microsoft はSで始まるサブコードを公開していませんが、多くの送信者が同時に同じサブコードを報告しているなら、それ自体がシグナルです。

| 応答 | システム | Microsoft のドキュメントの記載 | 最初の対応 |
|---|---|---|---|
| `451 4.7.500 Server busy. Please try again later from [IP]. (S77714)` | Microsoft 365 | Learn では、4.7.500-699を「Access denied, please try again later」（アクセス拒否。後でもう一度お試しください）として掲載。不審なアクティビティにより、送信が一時的に制限されている状態。 | キューに再試行を任せる。まず影響範囲を確認する。 |
| `451 4.7.500-699 (ASxxx)` | Microsoft 365 | 接続元のIPが「以前よりはるかに多くのメールを送信し、それまでの送信パターンを変えた」場合のIPスロットリング。 | 送信量を増やすペースを落とす。「数日かけて」解消される。 |
| `451 4.7.650 ... temporarily rate limited due to IP reputation (S775)` | Outlook.com | Microsoft が公開している表には記載なし。 | 送信量と同時接続数を減らし、SNDSを確認する。 |
| `451 4.7.652 ... exceeded the maximum number of connections (S3115)` | Outlook.com | 表には記載なし。応答のテキストに原因が書かれている。 | 接続数を減らす。 |
| `421 RP-001`、`RP-002`、`RP-003` | Outlook.com | 送信レート、接続ごとのレート、接続数の上限を超えた状態で、「IPやドメインのレピュテーションに関連する」もの。 | 送信ペースを落とし、SNDSを確認する。 |
| `550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.` | Outlook.com | 1日5,000通を超えるメールを送信するドメインが、SPF、DKIM、DMARCの要件を満たしていない。 | 認証とアライメントを修正する。 |
| `550 5.7.1 ... part of their network is on our block list (S3150)` | Outlook.com | 自社のIP、またはIPの範囲がブロックされている。 | そのIPからの送信を止め、チケットを作成する。 |
| `550 SC-001`、`SC-004`、`OU-002` など | Outlook.com | コンテンツ、レピュテーション、迷惑メール報告を理由とするポリシー上の拒否。SC-004はJMRPを指している。 | 送信を再開する前に原因を突き止める。 |
| `550 5.7.606-649 Access denied, banned sending IP [IP]` | Microsoft 365 | IPがブロックされた送信者のリストに載っている。 | `sender.office.com` で削除を申請する。 |
| `550 5.7.511 Access denied, banned sender` | Microsoft 365 | 手動での調査が必要。 | NDR（配信不能レポート）を `delist@microsoft.com` に転送する。 |

出典：Microsoft の [Exchange Online のNDRリファレンス](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online)、[ASxxxに関する記事](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online)、Postmaster サイトのコード表、[550 5.7.515に関する記事](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com)。Al Iverson 氏による[S775](https://www.spamresource.com/2026/02/microsoft-rate-limiting-issues.html)と[S3115](https://www.spamresource.com/2025/07/microsoft-says-too-many-connections.html)の解説。Twilio SendGrid による[S3140/S3150のブロック](https://support.sendgrid.com/hc/en-us/articles/38465017420955-Troubleshooting-Microsoft-Delivery-Issues-With-Error-550-5-7-1-S3140-S3150-Blocks)の解説。

### 4か5かが、そのまま指示になる

M3AAWGの「[Sender Best Common Practices](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf)」は、一時的なエラーの後は「送信者は接続を閉じ、後で新しい接続を開くべきである」とし、一時的なエラー（tempfail）を決して恒久的なものとして扱ってはならないとしています。5xxについて、Microsoft の[送信者ポリシー](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies)には「送信者は、そのメッセージをその受信者に再送しようとしてはならない」とあります。

451はバウンスではありません。利用しているプラットフォームやスクリプトがバウンスとして扱っているなら、まずそこを直しましょう。

## Microsoft の障害か、自社のレピュテーションか

4.7.500についての Microsoft のガイダンスは、送信者自身の送信に原因があるとしています。たいていはそのとおりですが、いつもそうとは限りません。

### 2026年9月4日に起きたこと

Qboxmail は、問題が「中央ヨーロッパ夏時間（CEST）の9時47分に、すべてのIPで一斉に始まった」と [mailop で報告しました](https://www.mail-archive.com/mailop@mailop.org/msg27208.html)。サブコードはS77714、S77717、S77719でした。Poppulo の[ステータスページ](https://poppulo1.statuspage.io/incidents/w0671ycn23fw)は、英国夏時間（BST）の11時19分に始まった Microsoft の障害ID、EX1467029を引用しています。

emailexpert の[9月10日のまとめ](https://emailexpert.com/microsofts-ten-days-three-exchange-online-incidents-three-causes/)によると、ある運用者は光ファイバーの切断が原因だと考えていましたが、やがて One.com、Qboxmail、Mailjet、Poppulo が、すべての送信IPとリージョンで同じコードを報告しました。Microsoft は原因を迷惑メール対策のモデルとし、続いて、復旧中も発動し続けたスロットリングのルールを挙げました。emailexpert は、公開された障害後の報告書を見つけられませんでした。これとは別の認証の不具合（MO1465074）も、8月31日から9月3日まで約67時間続いています。この10日間については、[9月の State of Email](/ja/blog/state-of-email-september-2026) で取り上げています。

### 対応する前の5つのチェック

1. **自社での影響範囲**。プラットフォーム側の問題は、数分のうちにすべてのIP、ドメイン、配信ストリームに及びます。レピュテーションの問題は、たいてい1つから始まります。
2. **ほかのプロバイダー**。Gmail、Yahoo、Apple が通常どおり受け付けていて、ほかの送信者も Microsoft から同じコードを受けていると報告しているなら、原因はおそらく Microsoft です。
3. **直近72時間の自社の変更**。送信量の急増、新しいIP、インポートしたリスト、DNSの編集、再エンゲージメントの配信があったなら、いずれにせよ修正が必要です。
4. **周囲に聞く**。mailop のアーカイブとステータスページを確認しましょう。Microsoft 365 の管理者なら、**正常性 > サービス正常性**を開けます。その[問題の履歴](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health)（Issue history）には、テナントに投稿された過去7日間または30日間の障害が表示されます。Poppulo がEX1467029を見つけたのも、ここでした。
5. **SNDS**。遅延が積み重なっているのに、SNDSが緑でブロックもないなら、原因は自社ではない可能性が高いでしょう。

| シグナル | Microsoft を示す | 自社を示す |
|---|---|---|
| タイミング | すべてのIPで同じ1分のうちに始まる | 1つのIPやドメインだけ、または徐々に増える |
| ほかのプロバイダー | 正常 | 同じく悪化している、または迷惑メール報告が増えている |
| ほかの送信者 | mailop やステータスページで同じコードが報告されている | 誰も話題にしていない |
| 自社の最近の変更 | なし | 送信量の急増、新しいIP、新しいリスト |
| SNDS | 緑で、ブロックなし | 黄か赤、迷惑メール報告、「Blocked」 |
| コード | ほかの送信者も報告しているサブコード付きの4.7.500 | RP-00x、4.7.650、5.7.515、S3150 |

![Microsoft の応答に対応するための判断フローチャート。5xxのコードは、認証の修正、デリスト（ブロック解除）のポータル、サポートチケットのいずれかに進み、4xxのコードは障害の確認に進んだ後、収まるのを待つか、送信ペースを落としてSNDSを確認するかに分かれる。](/images/blog/microsoft-451-4-7-500-deferrals-playbook-flowchart.png)

*Microsoft の応答ごとの対応の振り分け。Microsoft のドキュメントと、2026年9月の障害の報告にもとづく。*

## SNDSとJMRP：必要になる前に設定しておく

[Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds)（SNDS）は、Outlook.com 向けに Microsoft が無料で提供している、IPごとのレピュテーションのポータルです。[SNDSのよくある質問](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ)には、承認された各IPについて表示される項目が挙げられています。

- **Filter result**（フィルターの判定結果）。迷惑メールと判定されたメッセージが10%未満なら緑、10〜90%なら黄、90%を超えると赤です。
- **Complaint rate**（迷惑メール報告率）。受信者数に対する迷惑メール報告の割合です。30%を超えるIPが0.3%未満に収まっており、この水準は「目指すべき良い目安」とされています。
- **RCPT commands** と **message recipients**（RCPTコマンドの数とメッセージの受信者数）。差が大きい場合は、リストが古くなっています。
- **IP status**（IPのステータス）：Blocked、Bot、Junked のいずれか。

データは「その日に送信したメッセージが100通未満のIPについては、表示されない場合がある」とされています。アクセスするには、IP、IPの範囲、またはASNを申請します。するとSNDSが、逆引きDNS（`postmaster@`、`abuse@`）やRDAPで見つけたアドレスに、リンクをメールで送ります。手動での申請は受け付けていません。

SNDSは2026年6月にリニューアルされました。Al Iverson 氏は、JMRPのリターンパスではもはやキャンペーンと受信者を確実に特定できないと、[6月19日に指摘しています](https://www.spamresource.com/2026/06/snds-and-jmrp-in-transition.html)。これらの情報は、別の場所に埋め込んでおきましょう。SNDSのホームページ（9月22日更新）によると、アクセス権は承認または移行から10か月で失効し、それまでに3回のリマインダーが届きます。カレンダーに入れておきましょう。

SNDSの中で登録する [Junk Mail Reporting Program](https://substrate.office.com/ip-domain-management-snds/Postmaster/Services)（JMRP）は、Outlook.com のユーザーが迷惑メールとして報告したメッセージを1通ずつ返送します。登録から「わずか72時間以内」に届き始めることも多くあります。報告した人はすべてのリストから除外し、新しいIPを追加したら、そのつど登録しましょう。自社で登録できない共有IPの場合は、プロバイダーに何を監視しているかを尋ねましょう。

## 送信者サポートとデリスト

**Outlook.com**。[Postmaster サイトのトラブルシューティングページ](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting)にあるサポートフォームを使うには Microsoft アカウントが必要で、対象は4つの個人向けドメインだけです。また、配信を「保証するものではありません」。Twilio SendGrid（ベンダーによる助言）は、ドメイン、IP、配信ストリームの説明、バウンスのテキスト、SNDSのスクリーンショットを添え、最初の自動返信にはエスカレーションを求めて返信し、自社の送信量の上限（volume quota）の提示と、Volume-Based Limit の見直しを依頼するよう勧めています。

**Microsoft 365**。`5.7.606-649` には、`sender.office.com` の[デリストポータル](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself)（ブロック解除の申請窓口）を使います。1回の申請で扱えるのは1つのアドレスと1つのIPで、確認はメールで行われます。削除には「24時間以上かかる場合があります」。`5.7.511` の場合は、NDRを `delist@microsoft.com` にメールで送ります。48時間以内に返信があるはずです。

ASxxxのスロットリングには、デリストの手続きはありません。受信側の企業が Microsoft 365 の手前でサードパーティーのサービスを使って受信メールをフィルタリングしている場合は、その企業の管理者がコネクターを設定すればスロットリングが解除される、と Learn の記事は説明しています。それ以外の場合は、送信実績を積むにつれて解消されます。

## 再試行、送信ペースの調整、ウォームアップ

**スケジュールに沿って再試行する**。[RFC 5321 の4.5.4.1節](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.4.1)は、「再試行の間隔は少なくとも30分にすべきである（SHOULD）」とし、諦めるまでの時間は「一般に少なくとも4〜5日は必要」としています。最初の1時間に2回試み、その後は2〜3時間ごとに1回です。急ぎの配信だからといって、この時間を短くしてはいけません。

**宛先ごとに送信ペースを調整する**。M3AAWGによると、受信側は、調整が「同じIPアドレスから送られてくるすべてのメールに対する一括の処理として」行われることを期待しています。Microsoft から遅延が返ってきたら、そのMXのグループ（Outlook.com または Microsoft 365）宛てのすべての送信を遅くしましょう。

**接続数に注意する**。Outlook.com のポリシーでは、送信者は事前の取り決めなしに「500を超える同時接続を開いてはならない」とされています。これは上限であり、`4.7.652 (S3115)` が返ってきたら、自社に割り当てられた上限を超えているということです。

**新しいIPとドメインは段階的にウォームアップする**。Microsoft によると、新しいIPは、送信量、リストの正確さ、迷惑メール報告の状況に応じて、「2週間ほど、あるいはそれより早く、完全にウォームアップが済むと見込める」とのことです。既存のSPFレコードの対象になっている新しいIPは、ドメインのレピュテーションをある程度引き継ぎます。最近エンゲージメントのあった人から送り始めましょう。

## やってはいけないこと

- **再試行を増やす**。数分ごとにキューを一斉に送り出すと、Microsoft がペースを落とさせたいIPに接続が集中し、4.7.652を招きます。
- **IPを切り替えて回避しようとする**。新しいIPにはレピュテーションがなく、問題が起きやすくなります。それに、新しいIPにメールを分散させるのは、スノーシュー型のスパム送信者がやることです。
- **5xxを再試行する**。Microsoft はこれを禁じており、「複数回の配信不能の応答」を受けた後は、その受信者への送信を止めなければなりません。
- **遅延したコンタクトを配信除外にする**。そのアドレスは、まだ有効です。
- **遅延した受信者に再送する**。そのメッセージはまだキューに残っているので、重複して送ることになります。
- **慌ててDNSを編集する**。`5.7.515` を受け取った場合を除き、障害の最中にSPFやDKIMを変更すると、2つ目の問題を増やすことになります。

DMARCのアライメントと、`p=none` からポリシーの適用への移行については、[到達率ガイド](/ja/blog/email-deliverability)をご覧ください。パスワードリセットや領収書を滞りなく届けるために専用のドメインに分ける方法は、[トランザクションメールのガイド](/ja/blog/transactional-emails)で解説しています。

## Brew での見え方

Brew は送信インフラを運用し、一時的なエラーを再試行するので、キューや接続数の上限を調整する必要はありません。表示されるのは、次の情報です。

- **「配信遅延」イベント**。遅延が起きると「配信遅延」イベント（`delivery_delayed`）が記録され、受信者のステータスは「受付済み」から「配信遅延」へ、その後「到達」か「バウンス」へと移ります。**イベント**ページで「配信遅延」と検索し、続けて `@hotmail.com` または `@outlook.com` と入力すると、Outlook.com に絞り込めます（ドメインのフィルターは OR で結合されます。Microsoft 365 の受信者は、それぞれ自社のドメインを使っています）。このイベントからわかるのは、メッセージが待機中であることだけで、その理由はわかりません。
- **バウンスの詳細**。「バウンス」イベントの「メタデータ」には、バウンスの種類と、プロバイダーからのメッセージが含まれます。
- **APIでの集計**。[分析の概要](https://docs.brew.new/api-reference/public-v1/analytics/brand-overview-totals-rates-timeseries)のエンドポイントは、到達数やバウンス数と並んで `deliveryDelayed` と `pending` を返します。MCPでは、`get_email_analytics` が同じ情報を返します。
- **4xxを考慮した配信除外**。ハードバウンスと迷惑メール報告は、すぐに配信除外になります。ソフトバウンスが配信除外になるのは、30日以内に3回起きた場合だけです。
- **段階的な増量**。[段階配信](https://docs.brew.new/create-emails/send-options#gradual-send)は、大規模な配信を、1時間ごとまたは1日ごとの割合のバッチに分けます。Outlook.com が遅延を返し始めたら、一時停止できます。
- **ドメインの健全性**。各ドメインの「到達率」カードは、受信トレイ到達、レピュテーション、認証、コンテンツ、送信設定の各項目にわたって、0〜100でスコアを付けます。同じ情報は、MCPツールの `get_domain_health` でも取得できます。受信トレイ到達テスト（10クレジット）では、Gmail、Outlook、Yahoo、Apple などのシードメールボックスにテストメールを送ります。

配信の Webhook、SNDSやJMRPのデータは、まだ Brew では確認できません（プロバイダーごとの件数は、イベントAPIで `groupBy=recipientDomain` を指定すると取得できます）。そのため、レピュテーションは Microsoft のポータルで確認してください。Microsoft の障害が疑われるときは、配信には手を付けず、「配信遅延」が「到達」に変わるのを見守ることをおすすめします。

## よくある質問

### Outlook や Microsoft 365 から返される「451 4.7.500 Server busy」とは、どういう意味ですか？

Microsoft 365（Exchange Online）からの一時的な拒否で、不審なアクティビティがあった場合の「Access denied, please try again later」（アクセス拒否。後でもう一度お試しください）として掲載されています。たいていは送信パターンが変わったことが原因ですが、2026年9月4日は Microsoft の障害（EX1467029）でした。サーバーに再試行を任せ、ほかの送信者にも同じことが起きているかを確認しましょう。

### Microsoft による遅延は、いつまで続きますか？

Microsoft によると、送信パターンにもとづくスロットリングは、送信実績を積むにつれて「数日かけて」解消され、デリストには24時間以上かかる場合があります。RFC 5321 が推奨するように少なくとも4〜5日間は再試行を続ければ、遅延したメールの多くは最終的に届きます。

### 550 5.7.515とは何で、どう直せばよいですか？

Outlook.com は、1日5,000通を超えるメールを送信していて、認証のルールを満たしていないドメインからのメールを拒否します。このルールは、2025年5月5日から適用されています。SPFとDKIMに合格し、ドメインでDMARCを公開し（`p=none` で十分です）、SPFかDKIMのどちらかが From ドメインとアライメントしている必要があります。

### Microsoft にIPアドレスをブロックされたら、新しいIPを取得すべきですか？

いいえ。Microsoft によると、新しいIPにはレピュテーションがなく、問題が起きやすくなります。原因を修正してデリストを申請し、今のIPで送信量を段階的に戻しましょう。

### Microsoft による遅延は、バウンスとして数えられますか？

いいえ。M3AAWGは、送信者は4xxを恒久的なエラーとして扱ってはならないとしています。バウンスになるのは、再試行が尽きた場合か、サーバーが5xxを返した場合だけです。Brew では、遅延は「配信遅延」イベントとして表示され、コンタクトが配信除外になるのは、ソフトバウンスが繰り返された後だけです。