この記事では、メール送信時に返ってくる `550 5.1.1 user unknown`（宛先不明）の意味、よくある 4 つの原因、そして送信側でできる切り分けと対処を整理します。 ## エラーコード `550 5.1.1` の意味 メール送信が失敗すると、送信元には NDR（Non-Delivery Report、配信不能通知）と呼ばれるバウンスメールが返ってきます。その中に含まれるのが SMTP（メールを送受信する通信手順、RFC 5321）の応答コードです。 `550 5.1.1` は次のように分解できます。 - **`550`**: 永続的な配信失敗を表す SMTP の応答コード。先頭が `5` なので「再送しても結果は変わらない」恒久エラー - **`5.1.1`**: 拡張ステータスコード（RFC 3463）。`1.1` は「Bad destination mailbox address（宛先メールボックスが存在しない）」を意味する 文面としては、次のような形で返ってくることが多いです。 ``` 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table ``` ここで最も重要なのは、これが **`5xx`（永続拒否）** だという点です。`452 4.2.2`（受信箱満杯）のような `4xx`（一時拒否）であれば、送信側のサーバが時間をおいて自動的に再送し、待てば届く可能性があります。しかし `550 5.1.1` は「その名前の受信者がそもそも存在しない」という応答なので、**宛先そのものを直さない限り、何度送っても同じエラーが返ります**。一時エラーと永続エラーの違いは[メールバウンスの分類と対処](/blog/email-bounce-classification)で整理しています。 ![550 5.1.1 user unknown が返るまでの流れ](/blog/bounce-550-511-user-unknown/error-flow.svg) なお、サーバへの接続自体は成立しています。受信側のメールサーバ（MX）まではメールが届き、そのうえで「宛先のユーザーが見つからない」と判定されている状態です。SPF / DKIM / DMARC（メールが正規の送信元から送られたことを証明する仕組み）が正しく設定されていても、宛先が存在しなければこのエラーは返ります。認証起因の拒否とは別物なので、まず切り分けることが大切です。コード体系全体は[SMTP 応答コード早見表](/blog/smtp-reply-codes-reference)を参照してください。 ## よくある原因 4 つ `550 5.1.1` の原因は、ほぼ次の 4 類型に収まります。送信側が確認すべきポイントとあわせて整理します。 ### 原因 1: アドレスの打ち間違い 最も多く、最も簡単に直せるパターンです。`@` より前のローカル部の綴りミス、ドメインのタイプミス（`gmail.com` を `gmial.com` と打つなど）、全角文字やスペースの混入が典型です。手入力で宛先を打ったメールや、名刺から書き起こしたアドレスで起きがちです。 確認: バウンスメールに記載された宛先アドレスを、元の正しいアドレスと 1 文字ずつ照合します。直せばすぐ解決するケースが大半です。 ### 原因 2: 退職者・解約済みのアドレス 相手企業の担当者が退職してメールボックスが削除された、共有メールボックスやエイリアス（転送用の別名アドレス）が解除された、というパターンです。以前は届いていたアドレスが、ある日から `550 5.1.1` を返すようになったら、これを疑います。 確認: 相手の現役の連絡先を改めて取得し、有効なアドレスへ送り直します。先方の代表アドレスや別の担当者宛に状況を伝えるのが確実です。 ### 原因 3: サブアドレス（プラスアドレス）の扱い違い `user+tag@example.com` のように `+` を使ったサブアドレス（プラスアドレス）は、Gmail などでは有効ですが、受信側のメールサーバが対応していないと「そんなユーザーはいない」と判定され `550 5.1.1` が返ることがあります。挙動はプロバイダにより異なります。 確認: `+タグ` を外した素のアドレス（`user@example.com`）で送り直してみます。これで通れば、原因はサブアドレスの非対応だと切り分けられます。 ### 原因 4: 配信リストの腐敗 メルマガや一斉通知で、古い名簿に無効になったアドレスが蓄積している状態です。一斉配信のたびに大量の `550 5.1.1` が発生し、放置すると到達率や送信ドメインの評価（レピュテーション）を下げる原因になります。 確認: バウンスしたアドレスは速やかに配信リストから除外します。リスト衛生（list hygiene）を保つことが、結果的にほかの宛先への到達率も守ります。 ![550 5.1.1 の主な原因 4 つと確認ポイント](/blog/bounce-550-511-user-unknown/causes-table.svg) ## バウンスメールからの切り分け手順 原因を特定するには、返ってきたバウンスメールから情報を読み取るのが出発点です。 ### Step 1: 宛先と文面を確認する バウンスメール内の `Final-Recipient`（最終的な宛先）と、`550 5.1.1` に続く文面（`User unknown`、`No such user`、`does not exist` など）を確認します。宛先アドレスをここで原本と照合すれば、原因 1（打ち間違い）はこの段階で判別できます。 ### Step 2: コードの先頭が 5 か 4 かを見る `550`（5xx）であれば永続エラーなので、再送では解決しません。もし `450 4.1.1` のような `4xx` であれば一時的な宛先不明の可能性があり、対処が変わります。一時拒否側のコードについては[452 4.2.2 mailbox full の意味と対処](/blog/bounce-452-mailbox-full)も参考になります。 ### Step 3: 1 件か大量かで分ける 特定の 1 宛先だけで起きているなら原因 1〜3 を、一斉配信で多数の宛先が同時にバウンスしているなら原因 4（リスト腐敗）を疑います。前者は宛先個別の修正、後者はリスト全体のクリーンアップが対処になります。 ### Step 4: 認証の問題ではないことを確認する `550 5.1.1`（宛先不明）は受信者の存在に関するコードであり、認証失敗とは別です。ただし、似た番号の `550 5.7.x` 系は認証やポリシーによる拒否を示します。コードを取り違えると対処を誤るため、番号を正確に読み取ってください。認証起因の拒否は[550 5.4.1 Access denied の原因4つと対処](/blog/ndr-550-541-fix)や[Gmail で 550 / 571 が出るときの対処](/blog/gmail-550-571-fix)で扱っています。 ## 一斉配信で再発させないために 個別の `550 5.1.1` はその場で宛先を直せば済みますが、メルマガや通知メールでは「無効アドレスを送り続ける」こと自体がリスクになります。再発防止の観点で押さえておきたいのが次の 3 点です。 - **バウンス処理の自動化**: 配信ツールのバウンス記録を確認し、`5xx` で返った宛先は次回以降の配信から自動除外する運用にします - **定期的なリストの棚卸し**: 長期間反応のないアドレスや、過去にバウンスした宛先を定期的に整理します - **送信ドメイン認証の維持**: 宛先不明とは別軸ですが、SPF / DKIM / DMARC を整えておくと送信ドメインの信頼性が保たれ、ほかの拒否要因を減らせます。DMARC の基本は[DMARC とは何か](/blog/what-is-dmarc)を参照してください 無効アドレスを送り続けると、受信側から「管理されていない送信元」と見なされ、有効な宛先への到達率まで巻き添えで下がることがあります。バウンスを「その都度直す対象」ではなく「リストの健康状態のサイン」として扱うことが、長期的な到達率を守ります。 ## よくある質問 ### 550 5.1.1 は再送すれば届きますか 届きません。`550` は `5xx`（永続拒否）で、「宛先のユーザーが存在しない」という応答です。同じ宛先に再送しても結果は変わりません。まず宛先アドレスが正しいかを確認し、誤りがあれば修正して、正しいアドレスへ送り直してください。 ### 昨日まで届いていたのに急に user unknown になりました 相手のメールボックスが削除された、担当者の退職でアカウントが無効化された、エイリアスが解除された、といった受信側の変更が考えられます。相手の現役の連絡先を改めて確認し、有効なアドレスへ送り直すのが確実です。 ### user+tag@ の形式で送ったらエラーになりました `+` を使ったサブアドレス（プラスアドレス）は、受信側のメールサーバが対応していないと宛先不明と判定されることがあります。挙動はプロバイダにより異なります。`+タグ` を外した素のアドレスで送り直し、通るかどうかで切り分けてください。 ### 550 5.1.1 と 550 5.7.x の違いは何ですか `5.1.1` は「宛先（受信者）が存在しない」を示し、対処は宛先の修正です。`5.7.x` 系は認証失敗やポリシーによる拒否を示し、対処は送信側の認証設定やポリシー側の確認になります。番号を取り違えると対処を誤るため、バウンスメールのコードを正確に読み取ってください。認証失敗の切り分けは[DMARC が fail するときの調べ方](/blog/dmarc-fail-troubleshooting)が参考になります。 ## まずは現状を把握しましょう 自社のドメインがどのような状態にあるか、無料の[ドメイン診断](/diagnose)で現状をチェックできます。 SPF・DKIM・DMARC・SSL の状態が数十秒でレポートされます。 設定状況がわからない方は、[お問い合わせ](/contact)からお気軽にご相談ください。専門家がわかりやすくサポートいたします。