Outlook.com（@outlook.com / @hotmail.com など）の個人アカウントから突然メールが送れず、送信後に配信不能レポート（NDR）で「550 5.0.350」が返る――この症状は、Outlookアプリの不具合というより「配送経路や受信側のポリシーで拒否されている」可能性が高い状況です。この記事では、NDRの読み方から切り分け手順、すぐ試せる回避策、相手管理者へ依頼するポイントまでまとめます。
「送信できない」と「配信できない」は別問題：NDRが返る時点で見えること
Outlookで「送れない」と感じても、実際には次の2種類が混ざりやすいです。
- 送信自体ができない（端末側の問題）：送信ボタンが効かない、送信トレイから動かない、直後にエラーが出る、など。
- 送信はできたが配信できない（配送の問題）：送った後に配信不能レポート（NDR）が戻ってくる。
今回のようにNDR（配信不能レポート）が返ってきている場合、メールは一度は外に出ようとしており、途中（受信側または経路上）で拒否されていることが多いです。つまり「Outlookの送信ボタンが壊れた」というより、メールが“受け入れられなかった理由”を特定するのが近道になります。
最初にやるべき切り分け：原因が端末（Outlookアプリ）か、Outlook.com側か
結論から言うと、最初の一手はWeb版Outlook.comで同じ宛先に送って再現するかです。これで調査の方向性がほぼ決まります。
| テスト結果 | 濃厚な原因 | 次にやること |
|---|---|---|
| Web版でも同じNDR（550 5.0.350）が返る | 端末ではなく配送・アカウント・相手側拒否 | NDRの詳細を読み、相手ドメイン/Reported Error/拒否理由を特定する |
| Web版は送れるが、OutlookアプリだとNDRになる/送れない | Outlookアプリ側のプロファイル/設定/キャッシュ | プロファイル再作成、再サインイン、資格情報のクリア、アプリ更新 |
| 宛先によって成功/失敗が分かれる | 受信側ポリシーまたはコンテンツ判定 | 特定ドメインのみか、本文・リンク・添付がトリガーかを切り分ける |
この切り分けは地味ですが強力です。なぜなら、Web版Outlook.comはMicrosoft側の標準経路で送信されるため、ここで再現するなら「端末固有の不整合」よりも拒否される理由（受信側・経路・アカウント制限）に焦点を当てられるからです。
「550 5.0.350」が示唆すること：よくある原因を現場目線で整理
ステータスコードが 550 で始まる場合、SMTPの世界ではざっくり「受信側が受け取りを拒否した（Permanent Failure）」という意味合いになることが多いです。そこに付随する 5.0.350 は、NDR本文の診断情報（Diagnostic information）でより具体的な拒否理由に紐づきます。
このコードが絡むケースで現実に多いのは、次のいずれかです。
- 受信側のセキュリティ/ポリシーによる拒否（迷惑メール対策、なりすまし判定、URL/添付の危険判定、社内ポリシー）
- 送信元の信頼性（レピュテーション）に起因するブロック（短時間大量送信扱い、過去のスパム判定の影響、共有送信基盤の影響など）
- 送信ドメイン認証（SPF/DKIM/DMARC）の不整合（主に独自ドメイン利用時）
- コンテンツ判定（本文の文面、短縮URL、署名画像、添付ファイル形式、リンク先ドメインなど）
ここで重要なのは、「Outlook.comの容量が変わったのでは？」という疑いがあっても、NDRに550系が出ている場合は、容量よりも拒否のロジック（どこが、何を理由に拒否したか）に集中した方が解決が早いことが多い点です。
NDR（配信不能レポート）の読み方：ここだけ見れば道が見える
NDRは情報量が多く、慣れていないと「結局何が原因？」となりがちです。ですが、見るべき箇所は絞れます。
最低限チェックしたい項目
- Final-Recipient：実際に配信しようとした宛先（転送や別名が絡むとズレることがあります）
- Remote-MTA：拒否した側のメールサーバー（受信側か、ゲートウェイかの手がかり）
- Diagnostic information / Reported error / Error Details：拒否理由の本文。ここが最重要。
- 日時：相手側でログ検索してもらう際に必要
- 相手ドメイン：特定ドメインだけで起きるのかを判断
“相手側に渡す”なら全文が強い
もし相手先が会社・学校などで管理者がいる環境なら、あなたができる最も強いアクションはNDR全文を相手管理者へ渡すことです。特に「Info for Email Admins」「Diagnostic information」部分があれば、相手側は迷惑メール隔離や拒否ログを追えます。
WordPress記事としての実務観点では、読者に次のように伝えるのが効果的です。
- NDRのスクリーンショットより、本文コピペ（必要箇所を伏せて）の方が解析しやすい
- 「550 5.0.350」だけでは足りず、Reported Errorの周辺テキストが決定打になることが多い
すぐ試せる：本文・リンク・添付・署名が原因かを最短で見抜く方法
受信側のセキュリティは「差出人」だけでなく「内容」も見ます。そこで、次の“ミニマム送信テスト”が非常に有効です。
ミニマム送信テスト手順
- 件名：短く（例：test）
- 本文：プレーンテキストで1行（例：テスト送信です）
- 添付：なし
- リンク：なし（URL、短縮URL、署名リンクも外す）
- 署名：一時的にオフ（画像署名・SNSリンクは特に外す）
| ミニマム送信の結果 | 示唆 | 次の一手 |
|---|---|---|
| 通る | コンテンツ判定の可能性が高い | リンクを1つずつ戻す／添付を変える／署名を作り直す／クラウド共有に切替 |
| 通らない | 送信元/経路/受信側ポリシーの可能性が高い | NDR詳細の確認、相手管理者へ連携、送信制限やアカウント保護の確認 |
よく引っかかる“地雷”例
- 短縮URL（bit.ly 等）や追跡パラメータだらけのURL
- リンク先が新規ドメイン/評判の低いドメイン/リダイレクトが多い
- ZIP、マクロ付きOfficeファイル、実行形式に近い添付（拡張子が怪しいもの）
- 画像署名に埋め込みリンクが多数（SNSアイコンが並ぶ署名など）
- 本文が短すぎる/同一文面の大量送信（テンプレ一斉送信でスパムに見える）
ポイントは「いきなり全部を直す」ではなく、原因を“リンク/添付/署名/本文”のどれに寄せられるかを短時間で掴むことです。
宛先で失敗する相手が偏るなら：受信側（相手先）起点で考える
Outlook.com側で何かが“壊れた”なら、基本的には多くの宛先で同じように失敗しやすいです。逆に、次のような偏りがあるなら受信側の色が濃くなります。
- 特定の会社・学校のドメイン（例：@example.co.jp）にだけ送れない
- その組織の特定の部署やメーリングリストだけ弾かれる
- 同じ宛先でも、本文を変えると通る/通らないが変わる
この場合、あなたが単独でできることには限界があります。受信側のゲートウェイやメール基盤（Microsoft Exchange、Microsoft 365、Google Workspace、独自のセキュリティ製品など）が明示的に拒否している可能性があるためです。
相手管理者に確認してもらいたいこと（具体）
- 拒否ログに「あなたの差出人アドレス」が載っているか
- 迷惑メール隔離（Quarantine）や拒否ポリシーに該当していないか
- ドメイン/差出人の許可リスト（ホワイトリスト）で回避できるか
- DMARC/SPF/DKIMの評価結果（Pass/Fail）
- URLフィルタ・添付フィルタ・なりすまし対策でブロックされていないか
「Outlook.comからのメールを一律で厳しめに扱う」運用の組織も存在します。これは相手側の方針なので、相手管理者に相談して調整してもらうのが最短ルートになります。
相手管理者に渡すための“依頼テンプレ”
読者が相手先へスムーズに依頼できるよう、テンプレを用意しておくと実用性が上がります（あなた自身が送れない状況なら、別手段のチャットや問い合わせフォームで送る想定です）。
件名：Outlook.com からの送信が貴社ドメイン宛に拒否されます（NDR: 550 5.0.350）
お世話になっております。
Outlook.com 個人アカウント（差出人：[email protected]）から、貴社宛（宛先：[email protected]）へ送信すると
配信不能レポート（NDR）が返り、Status code: 550 5.0.350 が含まれています。
以下の情報を共有しますので、受信側で拒否された理由（ポリシー/隔離/なりすまし判定等）をご確認いただけますでしょうか。
・発生日時：YYYY/MM/DD HH:MM（タイムゾーンも）
・差出人：[email protected]
・宛先：[email protected]
・件名：XXXX
・NDRの Diagnostic information / Reported error（該当部分を貼り付け）
・Remote-MTA（記載があれば）
お手数ですが、拒否理由と、必要であれば許可リスト登録などの回避策をご教示ください。相手管理者がログを追える形にしてあげると、解決までの往復が減ります。
独自ドメインを使っている場合：SPF/DKIM/DMARCの確認ポイント
ここは該当者だけ読めばOKです。送信元が純粋に @outlook.com / @hotmail.com であれば、多くの場合DNS側のSPF設定をあなたが編集する必要はありません。一方で、次のような運用をしている場合はDNS認証不備が原因になりやすいです。
- 差出人が @yourdomain.com など独自ドメイン（Microsoft 365のメール、または外部サービス）
- 送信経路が複数（Webフォーム、CRM、メルマガ、別SMTP）
- 受信側がDMARCを厳格運用（failならreject）
この場合、「Outlookというアプリ」よりも「そのドメインの送信認証が整っているか」を見ます。
| 項目 | 何を意味するか | よくあるミス |
|---|---|---|
| SPF | そのドメインから送ってよいサーバーを宣言 | 送信元を追加していない／複数SPFレコードを作ってしまう／-allを厳しくし過ぎる |
| DKIM | メール本文が改ざんされていないことの署名 | 有効化していない／鍵が古い／送信経路によって署名されない |
| DMARC | SPF/DKIMの整合性と失敗時の扱い（none/quarantine/reject） | いきなりrejectにして誤判定が増える／Fromドメインの整合が取れていない |
DNSの具体値は利用サービス（Microsoft 365 / Google / さくら / そのほか）で変わりますが、実務ではまず「自分のメールがSPF/DKIM/DMARCでPassしているか」を確認し、failしているならDNSと送信経路を揃えます。受信側に「認証failで落としている」と言われたら、この方向の調整が本命になります。
Outlook.comアカウント側の安全性・送信制限を確認する
急に弾かれ始めた場合、アカウント自体が“怪しい挙動”として扱われているケースもあります。特に次に該当すると、短期間の制限や判定が入りやすくなります。
- 短時間に同じ内容を多数へ送った（案内メール、イベント告知など）
- 転送ルールや自動返信を最近いじった／不審なルールが増えている
- ログイン場所が急に変わった（海外IP、VPN、端末変更）
- 第三者にパスワードが漏れた可能性がある
やること（優先順）
- パスワード変更：推測されにくいものへ変更
- MFA（多要素認証）を有効化：可能なら認証アプリを利用
- 最近のサインイン履歴を確認：見覚えのない国/端末があれば対処
- 自動転送・受信ルールを確認：身に覚えがない転送や削除ルールがないか
- 端末のマルウェアチェック：ブラウザ拡張や怪しいアプリも見直す
これらは「今回の550 5.0.350が必ず解消する」保証はありませんが、再発防止と、調査時の信頼性確保に直結します。相手管理者に相談する際も「アカウント保護は実施済み」と伝えられると話が早いです。
Web版は送れるのにOutlookアプリだとダメ：アプリ側の対処
もしWeb版Outlook.comでは送れるのに、PCのOutlookアプリ（Microsoft Outlook）だけが不調なら、アプリ側のプロファイル不整合やキャッシュ破損が疑えます。ここは“修理”ではなく“作り直す”が効くことが多いです。
| 環境 | 有効な対処 | 狙い |
|---|---|---|
| Windows版Outlook（クラシック） | 新しいプロファイル作成 → アカウント追加し直し | 設定・キャッシュの破損を切り離す |
| Windows（資格情報が怪しい） | 資格情報マネージャーでMicrosoft関連の保存情報を整理 → 再サインイン | 古いトークン/認証情報の不整合を解消 |
| Mac版Outlook | アカウント再追加、Outlookのデータ再同期 | ローカルデータの不整合を解消 |
| スマホOutlookアプリ | アカウント削除→追加、アプリ更新、端末再起動 | トークン更新と送信経路の再確立 |
ただし今回のテーマは「NDRで550が返る」なので、アプリが原因のときでも“相手側拒否”が絡んでいる可能性は残ります。だからこそWeb版で再現するかを先に見るのが重要です。
容量（ストレージ）やiCloudとの関係：よくある誤解を整理
「最近クラウド側が変わった？容量が影響？」と疑いたくなる状況はよくあります。ですが、今回のようにNDRで550 5.0.350が返っているなら、中心は容量ではなく拒否の理由です。
- iCloudストレージの契約有無は、Outlook.comの送信可否に基本的に直接関係しません。
- Outlook.comのメールボックスが上限に近い場合、別のエラーや警告が出ることが多く、今回のような「相手からの550拒否」とは筋が違うことが多いです。
ただし、“容量がゼロ関係”と言い切るのも危険です。実務的には、次の観点だけは確認しておくと安心です。
- Outlook.comの設定画面でメールボックス使用量を確認（削除や整理が必要な状態か）
- 「送信済みアイテム」が異常に肥大化していないか（保存が詰まると挙動が怪しくなるケースもある）
ただ、優先順位としては（1）Web版で再現 →（2）NDR詳細 →（3）相手側確認が最短です。
原因別の対処をまとめて整理：読者が迷わないための一覧
| 状況 | 原因の方向性 | 最優先アクション | 次のアクション |
|---|---|---|---|
| Web版でも同じNDRが返る | 配送/受信側拒否 | NDRのReported ErrorとRemote-MTAを確認 | 相手管理者にNDR全文を渡してログ確認依頼 |
| 特定ドメインだけ送れない | 相手のポリシー/ゲートウェイ | 相手先にホワイトリスト/隔離確認を依頼 | 本文・リンク・添付を最小化して再テスト |
| 短文・添付なしなら送れる | コンテンツ判定 | 署名・URL・添付を疑う | リンクを減らす/クラウド共有に変更/署名を簡素化 |
| 多数宛先へ送った直後から弾かれる | 送信制限/レピュテーション | アカウント保護（パスワード変更、MFA） | 送信パターンを見直し、必要ならサポートへ情報添付で相談 |
| Web版は送れるがOutlookアプリだけ不調 | アプリのプロファイル不整合 | プロファイル作り直し/再サインイン | 資格情報クリア、アプリ更新、再同期 |
改善しないときにやること：サポートへ出す情報を準備しておく
ここまで試しても状況が動かない場合、個人Outlook.comでもサポート導線は用意されています。問い合わせの前に、次の情報を手元にまとめておくと、やり取りが短く済みます。
- 発生日時（複数回あるなら代表例を2〜3件）
- 差出人アドレス、宛先、件名
- NDR全文（「Info for Email Admins」「Diagnostic information」が含まれる形）
- Web版でも再現するかどうか
- ミニマム送信テストの結果（通る/通らない、何を外したら通ったか）
サポートや相手管理者が欲しいのは「気持ち」ではなく「ログに当てられる材料」です。NDRはその材料の塊なので、捨てずに残しておくのが重要です。
まとめ：最短で前に進む手順
- Web版Outlook.comで同じ宛先へ送って再現するかを最初に確認する
- NDRのReported Error / Remote-MTA / 相手ドメインを見て、拒否地点を絞る
- 本文・リンク・添付・署名を最小化してコンテンツ判定を切り分ける
- 特定ドメインで起きるなら、相手管理者へNDR全文を渡して隔離/拒否ログ確認を依頼する
- アカウント保護（パスワード変更、MFA、ルール確認）も同時に実施する
「Outlookから送れない」と感じたとき、NDRが返るなら勝負どころは“どこで拒否されたか”です。550 5.0.350という表示に引っ張られすぎず、NDRの詳細と切り分け手順で原因を狭めていきましょう。
コメント