Outlook 550 エラー｜ケース別の原因と対処早見
目次
この記事でわかること
Outlook や Exchange Online（Microsoft 365）でメールを送ったとき、件名に「Undeliverable」と付いた不達通知（NDR、バウンスメール）が返ってくることがあります。本文には必ず「550 5.x.x」という数字のコードが含まれており、このコードが原因を特定する最大の手がかりです。
ただし 550 系は種類が多く、似たコードでも原因がまったく異なります。「宛先が存在しない」ものと「自社ドメインの認証設定が原因」のものを混同すると、直す場所を間違えて時間を浪費します。
この記事は、Web 担当者が手元の NDR を見ながら原因系統を素早く絞り込むための交通整理ハブです。
- 550 系コードを 4 つの系統に分類する見方
- 「どのサーバーが拒否したか」で自社側か受信側かを見分ける方法
- 系統ごとの症状・典型原因・対処の方向
- どのケースでも共通する初動チェック
個別コードの具体的な復旧手順は、各専用記事へリンクで案内します。
まず確認：NDR は「どのサーバーが」拒否したかで読む
550 系を読み解く前提として、最初に押さえたいのが「そのエラーを出したのはどのサーバーか」という視点です。
NDR の本文には、管理者向けの診断情報（Diagnostic information for administrators）として、どのサーバーがどのコードを返したかが記載されています。たとえば自社の送信サーバーが受信側サーバーへ接続し、受信側が「550」を返した、という流れが読み取れます。
ここで重要なのは、NDR を生成したサーバーと、実際に拒否したサーバーが別物のことがある点です。拒否したのが受信側サーバーなら原因と対処は相手側にあり、自社送信サーバーや Exchange Online 側がブロックしているなら原因は自社側にあります。
[自社送信] → [Exchange Online] → [受信側サーバー]
↑ ここで止まる ↑ ここで止まる
自社側の問題 受信側 / 宛先側の問題
コードの数字を見る前に「どこで止まったか」を掴むと、後の切り分けが一気に速くなります。次章から、その数字を 4 系統に分けて見ていきます。
系統1：宛先不在・宛先側の拒否（5.1.x / 5.4.1 / 5.5.0）
最も多いのが「宛先メールアドレスが見つからない、または受信側が受け取りを拒否した」系統です。原因は基本的に受信側にあります。
| コード | Microsoft が示す意味 | 典型原因 |
|---|---|---|
| 550 5.1.1 | Recipient not found（宛先が見つからない） | アドレスの打ち間違い、退職などで存在しないアドレス |
| 550 5.1.10 | Recipient not found | SMTP アドレス検索で宛先が見つからない |
| 550 5.4.1 | Recipient address rejected: Access denied | 宛先アドレスが存在しない（DBEB による境界拒否） |
| 550 5.5.0 | Mailbox unavailable | @outlook.com / @hotmail.com 宛で宛先が見つからない |
550 5.4.1 は Exchange Online Protection の「ディレクトリベースのエッジブロック（DBEB）」が、存在しない宛先を境界で弾く際に出ます（出典は記事末尾の参照を確認してください）。なお同じ 5.4.1 でも「Relay Access Denied」と表示される場合は、受信側がそのドメイン宛のメールを受け付けない設定や DNS の構成ミスが原因です。
対処の方向は、まずアドレスの綴りを確認し、正しいはずなのに弾かれる場合は受信側の管理者に宛先の有効性を確認してもらうことです。Outlook 宛のメールが届かないケースの切り分け全般は、Outlook にメールが届かない原因の切り分けで詳しく扱っています。550 5.4.1（Access denied）に絞った対処は550 5.4.1 Access denied の対処を参照してください。
系統2：送信ドメインの認証失敗（5.7.23 / 5.7.509 / 5.7.515）
自社ドメインの SPF / DKIM / DMARC といったメール認証に問題があると、この系統のコードで拒否されます。Web 担当者が DNS 側で対処すべき、最も「直せる」系統です。
| コード | Microsoft が示す意味 | 典型原因 |
|---|---|---|
| 550 5.7.23 | SPF violation で拒否 | 受信側が SPF 検証し、送信元 IP が SPF に含まれていない |
| 550 5.7.509 | DMARC 検証に失敗、ポリシーが reject | 送信ドメインが DMARC を通らず、相手の DMARC が reject |
| 550 5.7.515 | Access denied（認証バー未達） | 大量送信者向けの認証要件を満たさず、Outlook.com など消費者向けサービスに拒否された |
特に 550 5.7.515 は、Outlook.com / Hotmail / Live.com などマイクロソフトの消費者向けサービスへ送る大量送信者に課された認証要件を、送信ドメインが満たせなかったときに出ます。一般的な「認証に失敗した」ではなく、消費者向け宛先への高ボリューム送信に対する要件である点が特徴です。
対処の方向はいずれも共通で、送信ドメインの SPF・DKIM・DMARC を正しく公開し、整合（アライメント）させることです。550 5.7.515 の具体的な対処は550 5.7.515 の対処手順にまとめています。SPF や DMARC の設定不備は、この系統だけでなく将来の到達率全体に影響するため、早めの是正が有効です。
系統3：送信 IP の評価・送信制限（5.7.511 / 5.7.708 / 5.7.7xx）
送信元 IP の評価（レピュテーション）の低下や、テナント単位の送信制限に引っかかると、この系統で止まります。Outlook クライアント側では直せず、管理者やマイクロソフトサポートの対応が必要なことが多い系統です。
| コード | Microsoft が示す意味 | 典型原因 |
|---|---|---|
| 550 5.7.511 | Access denied, banned sender | 送信元 IP がブロック対象になっている |
| 550 5.7.708 | Access denied, traffic not accepted from this IP | テナントの送信トラフィックが不審と判定され、送信が制限された |
| 550 5.7.750 | unregistered domains からの送信ブロック | 未検証ドメインからの送信が多いと判定された |
550 5.7.708 は、テナントからのトラフィックの多くが不審と検知され、送信能力に一時的な制限がかかった状態で出ます。新規・トライアル・作成直後のテナントで評価が確立する前に起きやすく、侵害やオープンリレーがないか確認したうえで、通常のチャネルからマイクロソフトサポートに連絡する流れになります。詳細は550 5.7.708 の対処を参照してください。
550 5.7.511（banned sender）の場合は、delist@microsoft.com に NDR コードと IP アドレスを添えて連絡し、ブロック解除を依頼する手順が案内されています。
系統4：ポリシー・配送許可（5.7.1 / 5.7.13x）
最後は、宛先側の組織が設定したポリシーやアクセス許可によって拒否される系統です。
- 550 5.7.1（Delivery not authorized）：送信者にその宛先へ送る許可がない。社外からの受信を拒否する配布グループ宛などで起きやすい
- 550 5.7.1（Unable to relay）：受信側が最終宛先でないメールの中継を許可していない。MX レコードの向き先ミスが典型
- 550 5.7.133 / 5.7.134 / 5.7.13x：配布グループ・メールボックス・公開フォルダーなどが「組織外からの受信を拒否」に設定されている
この系統は受信側組織のポリシー設定が原因のため、送信側でできることは限られます。正当な送信であれば、受信側の管理者やグループ所有者に設定変更を依頼するのが基本です。
どのケースでも共通する初動チェック
コードの系統が分かったら、Web 担当者が最初に踏むべき共通の初動は次の 5 つです。
- コード全体を正確に控える：「550 5.7.515」のように 5.x.x まで記録する。下 1 桁の違いで原因が変わる
- NDR の診断情報を読む：どのサーバーがそのコードを返したかを確認し、自社側か受信側かを判断する
- 宛先アドレスの綴りを確認する：系統1（宛先不在）はここで多くが解決する
- 自社の認証設定を点検する：系統2 に該当しそうなら SPF / DKIM / DMARC の公開状況を確認する
- 再現性を確認する：特定の宛先だけか、全宛先か、特定タイミングかを切り分ける
なお 550 4.4.7（Message expired）のように 4 系統に収まらないコードもあります。これは一時的な配送遅延・タイムアウトを示し、再送で解消することがあります。判断に迷うコードは、推測で設定変更せず公式情報で意味を確認してから動くのが安全です。
よくある質問
550 5.4.1 と 550 5.7.515 は何が違いますか？
550 5.4.1 は宛先が存在しないなど受信側・宛先側の問題です。550 5.7.515 は自社ドメインの送信ドメイン認証（SPF / DKIM / DMARC）が大量送信者向けの要件を満たせず拒否された認証失敗系で、直す場所が異なります。
自社側が原因か受信側が原因かを見分けるには？
NDR の診断情報を読み、どのサーバーがそのコードを返したかを確認します。受信側サーバーが拒否したなら相手側、自社送信サーバーや Exchange Online が止めているなら自社側の問題です。
認証失敗系（5.7.x）の 550 はどう対処しますか？
送信ドメインの SPF・DKIM・DMARC を正しく公開し、整合（アライメント）させるのが基本です。これはこの系統だけでなく到達率全体に影響するため、早めの是正が有効です。
自社の認証状況を確認する
550 系がどの系統の問題かを切り分けたいときは、メールが届かない原因の切り分けツールが便利です。SPF・DKIM・DMARC・MX と Gmail 送信者要件を一画面でチェックし、重大なものから順に表示します。 自社ドメインの認証設定が今どうなっているか分からない場合は、無料ドメイン診断でも SPF・DKIM・DMARC の現状をツールが自動チェックできます。550 系の認証エラーに先回りして備える第一歩としてご利用ください。設定状況に不安があればお問い合わせからもご相談いただけます。
参照（公式情報で必ず確認してください）
- Microsoft Learn「Email nondelivery reports (NDRs) and SMTP errors in Exchange Online」
- Microsoft サポート「Fix NDR error 550 5.7.515 in Outlook.com」
- Microsoft サポート「NDR error codes 550 5.7.703, 550 5.7.705, 550 5.7.708, and 550 5.7.750」
- Microsoft サポート「NDR error code 550 5.4.1 Recipient address rejected: Access denied」
エラーコードの意味はマイクロソフト側の仕様変更で更新されることがあります。本記事は分類の地図として活用し、最終的な対処判断は公式情報の最新版で確認してください。