この記事では、Microsoft 365 / Exchange Online で発生する `550 5.4.1 Access denied` の意味、4 つの主要原因、切り分け手順を整理します。 ## エラーコード `550 5.4.1` の意味 メール送信が失敗したときに返される NDR（Non-Delivery Report、配信不能通知）には SMTP のステータスコードが含まれています。`550` は永続的な配信失敗を表す SMTP reply code、`5.4.1` は Microsoft が「受信者拒否（Access denied）」を示す目的で使用している拡張サブコードです。RFC 3463 上の `5.4.1` は元々「No answer from host」（送信先ホスト無応答）として定義されていますが、Microsoft 365 / Exchange Online は独自に「Recipient address rejected」の意味で `550 5.4.1` を返します。本記事は Microsoft 拡張の `550 5.4.1 Access denied` を対象としています。 Microsoft 365 環境では、典型的に次のような文面で返ってきます。 ``` Remote Server returned '550 5.4.1 : Recipient address rejected: Access denied' ``` この文面は **「メール自体は受信側に届いたが、相手側のポリシーで明示的に受信を拒否された」** ことを意味します。送信側のメール認証（SPF / DKIM / DMARC）が通っていても発生するため、認証設定だけを見直しても解決しないケースが多いのが特徴です。 メール認証の基本は[DMARC とは何か](/blog/what-is-dmarc)で整理しています。本記事は認証通過後の「受信側で弾かれる」パターンに絞って扱います。 ![NDR 550 5.4.1 の発生位置](/blog/ndr-550-541-fix/error-flow.svg) ## 主要な発生原因 4 つ ### 原因 1: 受信者メールボックスが存在しない / 削除済み 最も多いパターン。退職者のアドレス宛に送ってしまった、共有メールボックスが削除された、エイリアスが解除された等です。受信者ドメインの MX レコードは Microsoft 365 を指しているため接続自体は成立し、ユーザー解決の段階で `Access denied` が返ります。 切り分け：受信側の管理者に「該当アドレスが現在も有効か」を確認するのが最短です。 ### 原因 2: Connector 設定で送信ドメインが許可されていない 受信側の Exchange Online で **パートナー Connector**（Partner Connector）を使い、特定ドメインからのみ受信を許可している運用の場合、許可リスト外のドメインからの送信は `5.4.1` で弾かれます。BtoB の閉域メール運用や、子会社・グループ会社専用の Connector を組んでいる企業で発生しがちです。 切り分け：受信側に「Connector で送信元ドメインを制限していないか」「自社ドメインを許可リストに追加できるか」を依頼します。 ### 原因 3: メールフローポリシーで拒否 Exchange Online の **メールフロー ルール（トランスポートルール）** で、件名・本文・送信元ドメインの条件にマッチしたメールを拒否する設定が組まれていると、`5.4.1 Access denied` が返ります。情報漏洩対策（DLP）や、社外送信制御の一環で組まれていることが多いです。 切り分け：受信側で Exchange Admin Center → メールフロー → ルールの一覧を確認してもらいます。 ### 原因 4: ライセンス未割り当てユーザーへの送信 Microsoft 365 の Exchange Online ライセンスが割り当てられていないユーザーアカウントは、メールボックスを持たないため受信できません。新入社員アカウントの作成直後や、ライセンス見直しの過渡期に発生します。 切り分け：受信側管理者に「対象ユーザーに Exchange Online プラン（または Microsoft 365 Business / E3 等）が付与されているか」を確認します。 ## 切り分けの手順 ### Step 1: バウンスメールから情報を抽出 NDR の本文から以下を取得します。 - **Diagnostic information for administrators** ブロック内の Remote Server 文面 - **Reporting-MTA** と **Final-Recipient** - **Original Message Headers** の `Received` 行 これで、エラーが受信側の Exchange Online から返されているのか、中継サーバから返されているのかが分かります。 ### Step 2: 送信側で Message Trace を確認 送信元が Microsoft 365 の場合、Exchange Admin Center の **メールフロー → メッセージトレース** で対象メッセージを検索すると、配信状況の詳細イベントが取得できます。`Failed` イベントの詳細に `Access denied` が含まれていれば、受信側ポリシーでの拒否が確定します。 公式リファレンス: [Non-delivery report error codes in Exchange Online](https://learn.microsoft.com/exchange/troubleshoot/email-delivery/non-delivery-report-in-exchange-online/non-delivery-report-error-codes-exchange-online) ### Step 3: 受信側に確認依頼 切り分けの結果が揃ったら、受信側の IT 部門に以下を依頼します。 1. 該当アドレスの存在確認とライセンス状態 2. Connector / メールフロールールでの拒否ログの有無 3. 自社ドメインの許可リスト追加可否 ![Message Trace 確認の流れ](/blog/ndr-550-541-fix/trace-flow.svg) ### 似たエラーコードとの混同に注意 - `550 5.7.1`: 認可拒否（リレー拒否やスパム判定） - `550 5.7.26`: 認証失敗（SPF / DKIM / DMARC のいずれかに不合格）。詳しくは[Gmail 550 5.7.26 の対処](/blog/gmail-550-5726-fix)を参照 - `421 4.7.0`: 一時的な拒否。詳しくは[421 4.7.0 一時拒否の対処](/blog/smtp-421-470-fix)を参照 NDR 内のステータスコードを正確に確認することが、対処の出発点です。 ## 送信側で予防できること `5.4.1` は受信側起点のエラーですが、送信側でできる予防策もあります。 - 配信先リストを定期的にクリーンアップし、退職者アドレスを除外する - 一斉配信前にテストアドレスへ事前送信し、Connector 拒否を早期検出する - SPF / DKIM / DMARC を整え、認証起因の二次的な拒否を防ぐ 特に DMARC は受信側の判定材料になるため、未設定の場合は[DMARC 設定ガイド](/blog/dmarc-setup-guide)を参考に最小構成（`p=none`）から導入することを推奨します。 ## まとめ - `550 5.4.1 Access denied` は受信者側ポリシーによる明示拒否 - 原因は受信者不在 / Connector / メールフロールール / ライセンス未割当の 4 系統 - Message Trace と NDR ヘッダで切り分け、最終的に受信側 IT 部門と連携する ## 自社の状況を確認してみませんか 設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。 判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。